Logo Tech Writers

Tech writers

Esse é o nosso blog para apaixonados por tecnologia! Aqui, softplayers e outros especialistas compartilham conhecimentos fundamentais para o desenvolvimento dessa comunidade.

SEJA UM TECH WRITER
Proud Tech: Um evento para apaixonados por tecnologia
Tech Writers Outubro 11, 2021

Proud Tech: Um evento para apaixonados por tecnologia

Somos uma empresa de tecnologia criada em 1990 para desenvolver softwares de gestão para a Gestão Pública, Indústria da Construção e Justiça. O sonho que começou com uma conversa entre 3 amigos tornou-se realidade e hoje é vivenciado por quase 2.000 softplayers.   Com uma equipe robusta e cheia de vontade de inovar, garantimos mais eficiência em organizações públicas e privadas, incluindo prefeituras, grandes construtoras e o maior Tribunal de Justiça do mundo!  Nesse contexto, nossos profissionais de desenvolvimento tornaram-se especialistas em suas áreas de atuação. Porém, enfrentavam o desafio da comunicação entre as equipes. Se a equipe que desenvolve soluções para a Gestão Pública tinha problemas, era bem provável que uma pessoa de outra equipe pudesse ajudar. Mas, como elas estavam muito distantes e focadas em suas operações, a troca dificilmente acontecia.   A solução para o problema foi o “Proud Dev”, um evento criado pelos próprios desenvolvedores com o objetivo de conectar as pessoas e tornar de conhecimento geral as experiências, os problemas e as soluções de cada área.   No dia 02 de julho de 2019, os nossos devs se conheceram e fortaleceram a comunidade que faz a empresa acontecer através de palestras e debates técnicos.   O evento foi realizado com muita dedicação e desejo de continuar. O orgulho de desenvolver com propósito foi fortalecido e a expectativa para a edição de 2020 era grande, mas a pandemia causada pela COVID-19 desacelerou esse e outros planos. Nesse momento, as nossas equipes estavam 100% focadas em como garantir que os clientes continuassem trabalhando e adaptando-se ao modelo de trabalho remoto.  Mas, em 2021, vamos tirar o atraso! Com um comitê técnico totalmente dedicado em pensar trilhas, roteiros e palestras, agora o evento abre as portas também para outros profissionais de tecnologia e convidados dos softplayers. A proposta da edição deste ano é unir desenvolvimento, produto e negócios para o compartilhamento de conhecimentos, problemas e soluções do dia a dia na prática.  De forma totalmente online e gratuita, você pode fazer parte dessa história!  Para participar, fique de olho nos conteúdos de nossas redes sociais sobre o evento que contará com nossos especialistas e nomes como Rodrigo Branas, Elemar Junior e Klaus Wuestefeld.  Não perca essa oportunidade de se desenvolver e se conectar! 

A tecnologia e as diferentes gerações
Tech Writers Outubro 07, 2021

A tecnologia e as diferentes gerações

https://open.spotify.com/episode/5leslsZoPVvcfucIXPga9C?go=1&sp_cid=65617f9945b6dafa4bd6df3d4f755a20&utm_source=embed_player_p&utm_medium=desktop Como é o impacto da tecnologia em diferentes gerações? No nosso primeiro bate-papo, convidamos duas pessoas de gerações distintas para debater sobre o impacto da tecnologia na sociedade. Uma delas é Moacir Marafon, um dos Sócios Fundadores e Presidente do Conselho da Softplan. Para fazer um contraponto, também recebemos Thiago Mathias Simon, um Desenvolvedor Júnior que, com apenas 19 anos, ingressou na empresa através de um programa de capacitação que é resultado de uma parceria entre a Softplan, o Senai SC e a ACATE. O host dessa conversa é o Guilherme Brasil, que a partir de hoje irá conduzir, mensalmente, debates que vão ampliar a sua visão sobre como os recursos atuais têm transformado a vidas das pessoas. A conversa foi muito proveitosa e falaremos sobre os principais pontos dela nesse artigo. A relação de cada convidado com a tecnologia Cada um dos convidados do bate-papo viveu a questão da tecnologia de uma maneira diferente, visto que nasceram em gerações totalmente distintas. Marafon teve seu primeiro contato com a tecnologia em uma matéria de introdução à computação no curso de Engenharia Civil. Quando se formou na faculdade, ele comprou uma calculadora Casio programada com 1700 bytes de memória, onde fazia programas e gravava os cálculos. Conforme Marafon adentrava no universo da tecnologia, ele se apaixonava e queria desvendá-lo ainda mais. Logo depois, ele foi trabalhar no Governo do Estado e encontrou um minicomputador com uma linguagem de programação Basic Comercial. Como autodidata, Marafon evoluiu sua experiência de programador e se encantou com essa área. Por isso, resolveu voltar para a Universidade Federal de Santa Catarina e fez parte da primeira turma de pós-graduação do curso de Ciências da Computação. Quando terminou, seu sonho de empreender no mundo da tecnologia ficou mais forte e acabou conhecendo dois parceiros que, juntos, criaram a Softplan. Diferente de Marafon, Thiago nasceu em um contexto digitalizado, no qual já existiam computadores em casa. Com isso, ele teve o convívio próximo com a tecnologia desde muito cedo. Com nove anos de idade, por exemplo, Thiago já tinha aula de operador de computador de forma EAD (ensino a distância). No ensino médio, o jovem iniciou o curso técnico em Desenvolvimento de Sistemas, que foi seu primeiro contato efetivo com a parte de programação. Hoje, com apenas 19 anos, ele trabalha na Softplan. Pode-se concluir que a tecnologia esteve presente em todos os momentos de sua vida. Thiago afirma que, atualmente, é difícil imaginar ir para algum lugar sem ter um celular do seu lado. A diferença geracional interfere no avanço da tecnologia? Durante a conversa, tivemos o privilégio de ter a perspectiva de diferentes gerações para analisar essa pergunta. Marafon, que se enquadra no começo da geração X (nascidos entre 1960 e 1980), expôs características marcantes da sua época. Entrou no mercado durante uma das maiores crises econômicas do Brasil, na qual as pessoas vivenciavam uma grande dificuldade para trabalhar na área de suas graduações. Para ele, a geração X é caracterizada por dar muito valor ao emprego e à estabilidade. Consequentemente, não era aconselhado a se arriscar, já que mudanças poderiam ser perigosas. Mas Marafon acredita que sua geração pode levar tais características e, juntamente com as gerações mais novas, gerar criações tecnológicas bem-sucedidas. Thiago, que faz parte da geração Z (nascidos entre 1995 e 2010), acredita que a diferença geracional interfere no avanço da tecnologia, mas não necessariamente de uma forma negativa. Ele observa a tecnologia como algo indispensável. Uma empresa que não possui um espaço virtual para ter um posicionamento, acaba tendo dificuldades de se comunicar e conectar com seu público, sobretudo jovens. A tecnologia vai evoluindo justamente por conta das diferenças geracionais, em que cada indivíduo com sua experiência apresenta ideias distintas e inovadoras que se complementam. Ao discutir esse tema e analisar a velocidade dos avanços na tecnologia, Guilherme, host do podcast, de forma resumida exprimiu sua opinião na seguinte frase: ‘’Essa convivência de várias gerações freia a velocidade, que já é exorbitante, da evolução tecnológica.’’ Regionalização do uso da tecnologia Cada vez mais, há um aumento do número de pessoas que se conectam à internet no Brasil. Para um país que possui desigualdades sociais visíveis, essa é uma notícia agradável de analisar. Certamente, ainda existem áreas onde não há acesso a internet. De modo geral, o país tem garantido a acessibilidade do mundo digital com uma velocidade rápida. A pesquisa TIC Domicílios, realizada pelo Centro Regional de Estudos para o Desenvolvimento da Sociedade da Informação (Cetic.br), mostra que o uso da internet no Brasil cresceu em 2020, passando de 74% para 81% da população, o que representa 152 milhões de pessoas. O aumento foi representativo, mas os 29% que ainda não tem acesso não podem ser esquecidos. Por isso, é responsabilidade dos governantes tornar o mundo digital próximo de toda a sociedade. O Presidente do Conselho da Softplan expôs, como exemplo, a sua vivência com a situação de regionalização do uso da tecnologia. Seus familiares vivem no interior de Santa Catarina, onde a questão do acesso a internet está, hoje em dia, sendo superada. As crianças, desde muito cedo, já sabem utilizar smartphones e computadores. Algo positivo, já que isso é resultado da democratização do acesso a internet. A riqueza da convivência de gerações distintas Quando diferentes tipos de gerações trabalham de forma unida, certamente há benefícios para uma determinada empresa e, além disso, pode gerar avanços na tecnologia. Analisar perspectivas distintas é fundamental, pois sempre há uma outra maneira de fazer algo ou de enxergar a solução para um problema. O debate entre as gerações é muito proveitoso. Quando se pensa em profissionais mais jovens, ideias como criatividade, energia, agilidade, praticidade estão quase sempre relacionadas. Juntando essas características com uma geração antiga, que é mais experiente, não tem como o resultado dar errado. Gostou do conteúdo? Ouça o bate-papo completo. Nele falamos de outras questões relacionadas ao que trouxemos neste artigo.

Benefícios dos testes funcionais automatizados
Tech Writers Outubro 04, 2021

Benefícios dos testes funcionais automatizados

As coisas mudam rapidamente na indústria de TI. Novas tecnologias e versões surgem quase que diariamente e para acompanhar essa revolução tecnológica sem perder a excelência dos produtos entregues, as empresas estão realizando grandes investimentos em testes de software.   A ampla variedade de aparelhos, redes e plataformas acarretam um árduo trabalho humano nas empresas de tecnologia, que visam melhorar a experiência dos usuários através de testes de software.   Estes testes são manuais e repetitivos, e infelizmente podem ficar comprometidos devido a prazos curtos e dias exaustivos. Isso pode ser uma das causas do início da indústria de testes automatizados.  É nítido que cada dia mais as empresas estão buscando qualidade nos produtos /software, e podemos viabilizar mais agilidade por meio do uso de scripts automatizados. E mais do que nunca, hoje em dia temos um leque de opções de ferramentas de automação de teste, que nos auxiliam a produzir códigos cada vez mais robustos e eficientes.  O termo automação é amplo e carrega sentidos diferentes, algumas pessoas pensam que estamos falando de teste unitário, outros o veem como um script de teste funcional de regressão e ainda há o conceito de teste de desempenho, estresse e segurança. No entanto, temos que entender que todos realmente são scripts, mas a diferença está no objetivo do teste a ser executado.  O objetivo principal do teste automatizado é reduzir ao máximo o esforço de teste manual, com um conjunto mínimo de scripts, gerando mais credibilidade, otimizando a mão de obra humana, dando rapidez nas execuções e liberando a equipe para dar mais foco em assuntos estratégicos no projeto.   Os testes funcionais automatizados, por sua vez funcionam como um robô que simula a ação humana, abrindo o navegador, ou aplicativos móveis, realizando interações e inserindo valores nos campos, clicando em botões nas telas e comparando com os resultados esperados.  Os principais benefícios dos testes automatizados são:  Os testes automatizados levam menos tempo para serem executados do que os testes manuais: Os testes manuais podem ser lentos, principalmente quando há inúmeros deploys. Os testadores devem ler o procedimento, entender os cenários e executar uma ação manual, como digitar um comando ou pressionar um botão e ainda, registrar os resultados. Todos esses procedimentos podem ser substituídos por testes automatizados, permitindo que os testes sejam concluídos em um intervalo de tempo ideal. Os testes automatizados são menos sujeitos a erros do que os testes manuais: Cansaço, estresse, pressões do dia a dia e trabalho repetitivo podem levar a erros humanos. O teste, quando automatizado elimina essa possibilidade trazendo credibilidade as verificações de resultados esperados, pois o robô segue os passos definidos e não pula execuções. Os testes automatizados podem ser executados sem qualquer interação do usuário: Outra vantagem dos testes automatizados é a possibilidade de programar o disparo automático da execução dos scripts, sem a necessidade de uma ação humana. Permitindo por exemplo um teste diário do conjunto “x” de cenários, e até mesmo testar o comportamento do sistema em horários e dias alternativos, como sábado e domingo. Os testes automatizados podem ser executados em paralelo: Enquanto um testador humano só pode fazer uma coisa por vez, os robôs de automação podem simular vários testes ao mesmo tempo. Com testes automatizados bem arquitetados podemos verificar diferentes funcionalidades, em diferentes navegadores e sistemas operacionais, todos executados em paralelo e de maneira isolada. Os testes automatizados podem criar relatórios de teste bem elaborados: Os testes automatizados podem fazer mais do que o próprio teste. Eles também podem automatizar coisas que são normalmente feitos manualmente após a conclusão do teste. Neste caso, a criação de um relatório de teste automatizado que indica tudo que passou, falhou ou não foi executado. Além disso, o teste automatizado pode gerar evidências como prints e vídeos em tempo real de execução.  Dos benefícios mostrados acima, considero dois como os mais importantes: a eficiência e a precisão.   A eficiência dos scripts de testes automatizados são a chave mestre para agregar valor ao processo de teste manual. Ajudam a ganhar vantagem sob prazos curtos, pouca documentação e constantes interações.  Já a precisão, podemos considerar como a joia do processo automatizado, pois a padronização dos códigos proporciona resultados precisos e ajuda bastante para manter a qualidade do software.  Por isso devemos analisar juntamente com a equipe e saber as funcionalidades que devemos investir em automação, para garantirmos entregas mais rápidas e eficientes de qualidade aos clientes finais. 

Como começar a programar em Java: escolha a JDK e a IDE certa
Tech Writers Setembro 20, 2021

Como começar a programar em Java: escolha a JDK e a IDE certa

Apesar de ser uma linguagem que está no mercado desde os anos 90, ela possui várias vertentes, várias abordagens e vem se atualizando e se adequando aos novos cenários. Além disso, muitas empresas usam Java como stack principal de desenvolvimento, o que torna o mercado de trabalho cheio de oportunidades para quem domina a linguagem. Antes de qualquer coisa, você precisará ter um ambiente instalado em sua máquina para trabalhar com Java. O básico é uma JDK (Java Development Kit) e uma IDE (Integrated Development Environment). Bem, é ai que você começa a sentir quão amplo Java é. Existem, basicamente, dois tipos de JDKs: a Enterprise e a Open. Desde que a Sun Microsystems foi adquirida pela Oracle, em Janeiro de 2010, a Oracle vem trabalhando em um perfil mais fechado e corporativo do Java, alinhado com os seus valores enquanto empresa. Para uso não comercial, o Java Enterprise é livre para uso apenas em sua versão mais recente. No entanto, dado a grande comunidade Global do Java, hoje temos também a Open JDK, fork do projeto principal da JDK durante sua versão 8, mantendo todos os princípios do software livre. E qual delas você deve escolher? Depende da sua necessidade. Acredito que, se você está começando no mundo Java, a melhor opção é a versão mais recente (stable) do Open. Essa é a que possui o maior número de features, com maior número de pessoas interessadas e discutindo sobre os problemas em torno dela. Além disso, por ser desenvolvida pela comunidade, a comunidade em si apoia em seu uso, que se mostra um caminho muito mais fácil que aprender totalmente sozinho.   A JDK  Em termos práticos, para instalar a Open JDK, você pode acessar este link e baixar a versão correta para o seu sistema operacional. No caso da opção pela JDK da Oracle, acesse este link e baixe a versão correta para o seu sistema operacional. Depois de baixado o instalador da JDK, instale em seu sistema como um programa normal. Em alguns sistemas e instaladores, o Java já se configura automaticamente para uso. Para confirmar isso, abra um terminal e digite java –version . Caso a instalação tenha se configurado corretamente, você deverá ter uma saída com o número da versão que você instalou, conforme exemplo a baixo:  Caso não tenha nenhum tipo de resposta ou resposta como “comando não encontrado”, você precisa adicionar o diretório “bin” dentro do diretório de instalação do Java ao path do seu sistema operacional. Isso varia muito de sistema para sistema. Nesse caso em específico, sugiro que busque diretamente sobre a sua necessidade em um buscador da internet.  A IDE  Uma vez feita a configuração de sua JDK, é possível realizar a escrita de artefatos Java diretamente em editores de texto, bem como sua compilação e execução em prompts de comando. Porém, a fim de facilitar o trabalho com Java, existem ferramentas chamadas IDEs (Integrated Development Environments) que agrupam ferramentas e funcionalidades destinadas ao uso com linguagens de programação. IDEs tendem a ser flexíveis e aceitar diversas configurações e plugins para atender diversas necessidades e linguagens de programação distintas. No caso do Java em específico, a IDE mais tradicional de todas é o Eclipse. O Eclipse já vem com uma série de ferramentas básicas configuradas para uso, como ferramentas de depuração de código (execução linha a linha, permitindo visualização de valores de variáveis em tempo real e simulação de execução de trechos de código) e versionamento de fontes (como GIT, SVN, vss, etc). O Eclipse pode ser baixado aqui. Além disso, em algumas de suas distribuições, é possível baixar junto a JDK a qual é configurada automaticamente por ele. Vale ressaltar que o próprio Eclipse possui várias versões. Durante sua instalação, ele questiona sobre o seu uso. A distribuição mais completa é a Java EE for web developers (e a que recomendo a instalação), pois permite diversos tipos de desenvolvimento com Java. É óbvio que, se o seu objetivo for algo muito específico dentro de Java (como desenvolvimento para dispositivos embarcados), essa versão não lhe atenderá e outra versão do Eclipse necessitaria ser baixada.   Porém, não se prenda ao Eclipse. IDEs dinâmicas como o Visual Studio Code estão crescendo na comunidade de desenvolvimento, pois permitem desenvolver em mais de uma linguagem com precisão, exigindo apenas esforço maior de configuração no início de seus projetos. Porém, tem maior versatilidade em projetos de maior complexidade e de diversas linguagens de programação distintas.   O Workspace  A instalação de IDEs em seu sistema operacional segue a instalação como de qualquer programa. No primeiro acesso, ela tem, por costume, pedir um diretório que será seu workspace (área de trabalho). O workspace, assim como as configurações internas da IDE, tende a ser de escolhas pessoais de forma a organizar todos os seus artefatos e projetos que você irá desenvolver. Pense a respeito e crie metodologia própria, pois não existe situação mais confusa que ambiente de trabalho desorganizado.  Considerações Tendo a IDE instalada, basta criar seu novo projeto ou clonar um repositório remoto, criar seus artefatos. Enfim, as portas de desenvolvimento em Java estão abertas. Basta explorar! Vale ressaltar que esse artigo é um pequeno recorte do grande mundo de desenvolvimento de software.  Para ver mais artigos muito interessantes sobre o universo do desenvolvimento, fique de olho aqui neste mesmo blog. Até uma próxima!  Fontes e Sugestões  Como instalar uma Open JDK no Windows. Como instalar o Visual Studio Code no Windows para trabalhar com Java

Dívida técnica de software: fio dental ou tratamento de canal?
Tech Writers Setembro 06, 2021

Dívida técnica de software: fio dental ou tratamento de canal?

Dívida técnica é um assunto que vem ganhando cada vez mais importância. Isso pela a crescente necessidade de adaptação das empresas, com rapidez, seus produtos de software às volúveis necessidades dos clientes, dos negócios ou do mercado. Se esse aspecto da qualidade do produto for negligenciado, o risco e o esforço para adaptar e evoluir o software tende a aumentar indefinidamente. Pior, pode rapidamente tornar a operação e os negócios insustentáveis.  Quando os times e as organizações percebem isso, uma dúvida surge automaticamente: O que devemos fazer com a nossa dívida técnica? Quando vamos atacar esse problema? Quanto esforço vale a pena investir nisso? Devemos planejar e incluir itens no nosso backlog com o objetivo de reduzir essa dívida? Qual ponto do sistema eu melhoro primeiro? Kent Beck, um dos criadores do XP, TDD e do manifesto ágil, costuma explicar algumas possíveis abordagens com uma metáfora que eu gosto bastante. Segundo ele, existem duas formas de reduzir a dívida técnica de um software: uma delas é como passar fio dental. A outra, é o tratamento de canal.  Fio dental Na primeira forma, o time de desenvolvimento torna o ato de refatorar o código em um hábito diário. Assim como passar fio dental, um time ágil, disciplinado e bem orientado, sabe que é preciso realizar esse ato de “higiene” constantemente, aos poucos, conforme vai realizando suas outras atividades de evolução ou correção do sistema.  Por exemplo, antes de alterar o comportamento de um pequeno componente do software que não possui cobertura de testes, alguns testes podem ser criados para assegurar os comportamentos já existentes. O código a ser alterado pode, antes, ser refatorado para que o trabalho a ser realizado logo em seguida seja mais fácil e menos arriscado.  Com isso, a qualidade do código vai melhorando de forma gradual e constante, com a dívida técnica sendo reduzida consistentemente e com baixo risco. Com esses bons hábitos fazendo parte da cultura do time, é possível cuidar da “saúde” interna do software, assim como passar fio dental nos ajuda a garantir a nossa saúde bucal.  Se não tivermos o hábito de passar fio dental, com o passar do tempo, corremos o risco de adquirirmos graves problemas e doenças bucais. Isso ocorre até um momento em que a dor desses problemas nos impede de realizarmos nossas atividades do dia a dia. Chegou o momento de irmos ao dentista e fazermos um tratamento de canal.  Tratamento de canal Na segunda forma, tentamos resolver um problema grande, que cresceu com o passar do tempo, de forma mais brusca, invasiva e arriscada. O tratamento é doloroso e, como toda cirurgia, envolve riscos para o paciente.  No caso do software, o equivalente a isso é quando o time resolve fazer grandes ações para reduzir a dívida técnica do software. Caros e arriscados projetos que visam a melhoria da qualidade interna do software, eventualmente tornam-se longas empreitadas cujos benefícios e o término são difíceis de mensurar. Um grande risco, no caso do tratamento de canal em software, é quando uma das dívidas técnicas adquiridas é a falta de testes automatizados. Ao remodelar o código sem a proteção de testes regressivos automatizados, o time se arrisca a alterar, de forma indesejada, o comportamento já existente do software. Em outras palavras, estragando o que já funcionava antes.  Outro problema dessa abordagem é a incerteza do retorno sobre o investimento. O retorno de termos baixa dívida técnica em uma parte do sistema é que provavelmente será mais fácil, mais barato e menos arriscado alterar aquele ponto do sistema no futuro. Ao realizarmos grandes investidas para reduzir a dívida técnica de uma parte do sistema, podemos não ter certeza de que iremos alterar de novo aqueles mesmos pontos. Pode demorar meses ou até anos para percebermos retorno de tais refatorações, pois isso está condicionado à necessidade de mudar, evoluindo ou corrigindo, esses pontos.  Opinião pessoal Até mesmo o tipo de melhoria pode ter sido mal escolhido por não sabermos exatamente que mudanças ocorrerão no futuro. Por exemplo, podemos refatorar o código e encapsular parte do comportamento de uma classe utilizando o padrão de projetos Strategy, visando facilitar a implementação de “prováveis” novas variações desse comportamento. Se, com o passar do tempo, as alterações que forem realizadas na classe nunca demandarem esse tipo específico de variação, teremos que lidar com a complexidade introduzida pelo padrão sem usufruir dos benefícios.  Particularmente, eu prefiro a primeira opção. Se as melhorias forem feitas logo antes de realizarmos as mudanças desejadas, além de termos um retorno imediato, teremos mais certeza do ponto do código e do tipo de alteração que será realizada. Assim, saberemos quais melhorias no código facilitarão esse trabalho. Além do mais, como hoje existe uma necessidade de alterar um certo ponto do código, há uma boa chance desse mesmo ponto ser alterado novamente no futuro. Não é coincidência, faz parte da natureza do desenvolvimento de software.  No entanto, aproveitando ainda a metáfora, algumas vezes ações um pouco mais incisivas são realmente necessárias para curar condições graves na saúde (nossa e do software). No caso de software, um aspecto de dívida técnica em que vale a pena investir em ações maiores e focadas, é melhorar a cobertura e eficácia dos testes automatizados. Em muitos casos, o risco desse tipo de melhoria é mais baixo e temos como resultado uma proteção para realizarmos futuras melhorias com mais segurança.  Mas, o que traz um melhor retorno para a organização é fomentar uma cultura de melhoria contínua da qualidade de código. Nela, os times sabem que podem agir para reduzir a dívida técnica diariamente, cobrindo o código legado com testes e refatorando logo antes e durante a realização de suas atividades.  Se você gostou deste artigo, tenho certeza que vai curtir também as indicações abaixo. _ Refactoring – Not on the backlog! do Ron Jeffries. O título do artigo é um tanto radical, mas serve para destacar as diferenças dessa abordagem. O artigo tem explicação criativa por uma outra metáfora e utiliza desenhos; _ OpportunisticRefactoring  do Martin Fowler; _ What Is Clean Code?  do Robert C. Martin (Uncle Bob). Fala sobre uma regra aplicada pelos escoteiros e que pode ser adotada como um bom hábito pelos desenvolvedores.

Gráfico CFD: O que é no Scrum, métricas e exemplos de padrões
Tech Writers Agosto 16, 2021

Gráfico CFD: O que é no Scrum, métricas e exemplos de padrões

Se você, ao longo de sua jornada, já trabalhou ou teve algum contato com Kanban, provavelmente já ouviu falar do gráfico CFD, certo? O Gráfico CFD, ou Cumulative Flow Diagram (Diagrama de Fluxo Cumulativo), é uma ferramenta aplicada nas metodologias Scrum e Kanban. Apesar de bastante conhecido, o CFD é um gráfico cuja interpretação pode não ser feita de forma superficial. Por isso, hoje vamos te explicar os conceitos do gráfico CFD com exemplos práticos para você extrair todo o seu potencial. Vale destacar aqui que o CFD costuma não trazer respostas, mas sim fornecer insights valiosos para que você possa se aprofundar na causa raiz dos problemas identificados. Continue lendo e descubra mais sobre o que é o gráfico CFD, principais conceitos e padrões de gráfico no dia a dia. O que é um gráfico CFD no Scrum? O CFD (Cumulative Flow Diagram) é um gráfico capaz de identificar, de forma visual, diferentes gargalos ou disfunções que o seu time possa estar enfrentando no dia-a-dia. Muitos o consideram um dos mais importantes gráficos na gestão de fluxo. Este gráfico fornece desde informações mais básicas sobre o fluxo de trabalho, como, por exemplo: Quantidade de trabalho já concluída; Quantidade de trabalho em andamento; Ritmo de entregas, etc. Dessa maneira, é possível identificar problemas mais complexos. Um dos principais objetivos do CFD é mostrar, de forma clara, o quão estável é seu fluxo de trabalho e onde você pode agir para torná-lo mais eficiente e previsível. Para que serve o CFD no Scrum? O Gráfico CFD (Cumulative Flow Diagram) serve para monitorar o progresso das atividades realizadas pela equipe na metodologia Scrum. Assim, permite que todos acompanhem a evolução do trabalho em tempo real, o que facilita a identificação de possíveis gargalos e problemas que possam prejudicar o andamento do projeto. Com ele, é possível saber se o fluxo de trabalho de um time Kanban está estável ou não. O CFD também serve para medir a eficiência da equipe em relação aos objetivos estabelecidos e aos prazos definidos, desse modo permitindo realizar ajustes e melhorias para garantir a entrega do produto final no prazo e com a qualidade desejada. Como ler um gráfico CFD? Antes de partir para a análise de algumas situações cotidianas em projetos, vamos apresentar o CFD e seus principais conceitos. Abaixo, veja uma ilustração simplificada de um CFD: Exemplo de Gráfico CFD — Créditos: Kanbanize A construção de um gráfico CFD para Scrum é simples: No eixo horizontal, nós temos a linha do tempo, que você pode escolher representar em dias, semanas, sprints, etc; Já no eixo vertical, temos, de forma acumulada, a quantidade de tarefas no processo ao longo do tempo. Cada uma das curvas representa uma etapa do fluxo de trabalho conforme elas aparecem no próprio quadro kanban do time (backlog, em desenvolvimento, em testes, finalizado, etc). O gráfico CFD também é cumulativo: cada uma das curvas só pode aumentar ou, na pior das hipóteses, manter seu valor caso não esteja havendo movimentação naquele estágio. Se você observar alguma curva caindo no eixo Y, algo está errado. A linha superior da curva irá representar o ponto de entradas das tarefas naquela etapa do fluxo, já a inferior mostra a saída da tarefa daquela etapa. Apenas com base nisso, já é possível a extração de algumas métricas bem interessantes. Por exemplo, traçando uma linha paralela entre a linha superior da curva do estágio “backlog” e a linha superior da curva do estágio “pronto”, você terá a quantidade de tempo que um item demorou para ser concluído a partir do momento que entrou para o seu backlog. Ou seja, o seu lead time. De acordo com a imagem abaixo, fazendo uma análise muito semelhante, você chegará a outras métricas como cycle time, WIP, quantidade de trabalho ainda a ser feito, entre outras. Visualização de Métricas no CFD — Créditos: Mauricio Fritsch Quais são os cenários comuns do CFD? Uma maneira bastante simples e prática de analisar o quão estável é seu fluxo de trabalho através do CFD se dá pela análise da forma como as diferentes curvas do gráfico estão progredindo. Nesse ponto, existem alguns padrões bastante comuns para destacar: Quando as curvas do CFD estão progredindo em paralelo: Padrão 1 — Curvas progredindo em paralelo — Créditos: Kanbanize Esse cenário seria o considerado ideal para um fluxo de trabalho estável e fluído. O fato de as diferentes curvas estarem progredindo de forma paralela significa que você tem um fluxo de trabalho onde o time consegue produzir em velocidade estável nos diferentes estágios e novas tarefas entram nos estágios do fluxo na mesma proporção de tarefas que estão saindo dele. Na prática, dificilmente você verá um gráfico CFD tão bonito e estável como esse no dia a dia. Mas isso também pode ser uma boa notícia, já que é quando as coisas não vão tão bem que você terá as maiores oportunidades de aprendizagem com o CFD. Quando uma das curvas do gráfico está se alargando rapidamente: Padrão 2 — Curvas se alargando rapidamente — Créditos:            Kanbanize Esse cenário representa uma situação típica em fluxos de trabalho. A faixa que está se alargando no CFD nos traz a informação de que a quantidade de itens sendo trabalhados simultaneamente naquele estágio está aumentando. Ou seja, os itens estão saindo do estágio numa velocidade menor do que a velocidade em que entram. Mas o que está acontecendo no dia a dia do time para que o gráfico tenha esse comportamento? O CFD é capaz de responder a perguntas como essa? A resposta é não. O CFD vai ajudar você a identificar que o seu fluxo de trabalho está com um problema, que, no caso em questão, pode estar sendo causado por diferentes razões. As tarefas podem estar se acumulando devido a bloqueios, trocas de contexto, pressão para mais tarefas serem executadas em paralelo, entre outros motivos. Você precisará de um trabalho de investigação mais profundo para chegar até a causa raiz. No cenário em questão, uma boa abordagem seria promover uma redução no limite de WIP do estágio que está inchando, além de se certificar que o time está realmente focando os esforços na conclusão dos itens que já estão no estágio antes de iniciar outras tarefas. Uma das curvas do gráfico CFD está rapidamente se estreitando: Padrão 3 — Curvas se estreitando rapidamente — Créditos: Kanbanize Esta situação aponta um cenário oposto ao apresentado anteriormente. Quando uma curva aparece se estreitando no gráfico CFD, isso significa que a quantidade de atividades naquele estágio está diminuindo, ou seja, a quantidade de itens que estão saindo daquele estágio é maior do que a quantidade de itens entrantes. Uma possível abordagem para esse cenário seria pensar: será que o WIP do estágio em questão não está maior do que o necessário? O fluxo de trabalho não poderia ser otimizado se mais esforço estivesse sendo colocado em algum outro estágio? Quando uma das curvas apresenta comportamento de escada: Padrão 4 — Escadas — Créditos: Pawel Brodzinski Nesse cenário, é possível observar que a quantidade de itens no estágio de teste cresce continuamente, mas não estão sendo concluídos, pois a curva “done” não acompanha o mesmo crescimento. Quando você vê um gráfico CFD onde há curvas com esse comportamento de escada, isso provavelmente, está ligado a itens muito grandes sendo trabalhados. Itens muito grandes passarão muito tempo sendo desenvolvidos e mais um tempo considerável sendo testados e validados para que, só então, possam ser considerados concluídos. O mesmo cenário pode acontecer em situações onde o trabalho vai sendo acumulado para ser validado somente ao final de um ciclo ou próximo da data de entrega, ao invés de ser continuamente testado, validado e entregue. Outra hipótese seria ainda a de que os testadores estão levando muito mais tempo do que o previsto para concluir os testes por estarem encontrando grande quantidade de bugs, por exemplo. De novo, conforme mencionado outras vezes, podemos não saber a causa raiz, mas já sabemos por onde começar a investigar. Quando todas as curvas do CFD apresentam linhas retas: Padrão 5 — Todas as Curvas com Linhas Retas — Créditos: Pawel Brodzinski Bom, a interpretação dessa situação é um tanto quanto óbvia. Se existe uma curva estagnada em linha reta, isso significa que o trabalho está parado naquele estágio do fluxo de trabalho. Nesse cenário, temos três curvas diferentes estagnadas. Ou seja, todo o fluxo está estagnado. Novamente, a causa raiz do problema pode não ser uma, mas sim várias: a primeira e mais óbvia seria verificar se houveram feriados, se as pessoas do time de desenvolvimento estavam em férias ou outros eventos que impediram o trabalho do time. Uma hipótese diferente é a existência de outras razões impedindo que o trabalho do time avance. Por exemplo, itens muito grandes trabalhados com grande prazo de conclusão podem ser o caso. Num cenário como esse, possíveis abordagens seriam investigar a existência de bloqueios que estejam travando o fluxo de trabalho. Após identificá-los, é importante agir para removê-los ou ainda investigar se o time não está trabalhando em itens muito grandes. Nesse caso, o ideal seria quebrá-los, se possível, em itens menores. No cenário em questão, independente de qual tenha sido a razão da estagnação, depois de um tempo a situação foi resolvida, pois é possível ver em seguida as curvas voltando a progredir. Quando somente algumas curvas apresentam linhas retas: Padrão 6 — Algumas Curvas com Linhas Retas — Créditos: Pawel Brodzinski Muito parecido com o cenário anterior, a diferença é que, neste caso, a estagnação está ocorrendo em somente parte do fluxo. Nesse caso, enquanto o estágio de desenvolvimento parece estar progredindo bem e dentro do esperado, o estágio de testes e a conclusão dos itens pararam de progredir num dado momento e não retomaram ao ritmo normal, sinalizando a não-resolução do problema até aquele instante. Tendo em vista que o ritmo de desenvolvimento segue normal, uma hipótese forte aqui seria estar acontecendo um problema especificamente na etapa de testes, com os testadores ou com o próprio ambiente de testes, por exemplo. Como os itens não estão podendo ser testados, por consequência, também não serão entregues. Por isso, a curva “done” também fica estagnada. Ao se deparar com um CFD deste tipo, algumas coisas podem ser feitas. A primeira delas, seria, assim como no caso anterior, investigar o motivo do bloqueio no estágio em questão. Outra possibilidade seria analisar se as pessoas não estão trabalhando de forma muito isolada e se um melhor trabalho em equipe já seria eficiente pra destravar esse fluxo. Quando as curvas do gráfico CFD apresentam descidas: Padrão 7 — Linhas Descendo — Créditos: Pawel Brodzinski Chegamos ao nosso último cenário de exemplo. Aqui, temos uma situação clara de algo que, definitivamente, não deveria estar acontecendo dentro do seu projeto. As curvas descerem significa que existiam itens sendo trabalhados dentro do seu fluxo que voltaram no fluxo ou simplesmente desapareceram. É um exemplo clássico de quando há alguma disfunção acontecendo dentro do fluxo. Explica-se também a por entregas/projetos cancelados ou pela desistência de continuar trabalhando em determinado item, o que, provavelmente, significa que o time descobriu tardiamente que aquele item em questão não fazia mais sentido dentro do projeto. Uma dica, nesse caso, seria avaliar se o seu time tem o hábito de voltar itens no fluxo e se essa é a melhor abordagem. Algumas pessoas podem fazer isso com boas intenções quando desejam, por exemplo, passar o item em questão para uma outra pessoa dentro do time. Um exemplo seria um testador que encontra um bug e deseja passar o item novamente para o estágio de desenvolvimento para a correção do bug. Esse tipo de abordagem pode não ser a ideal, pois, além de gerar esse tipo de disfunção, ao voltar o item para uma etapa anterior é possível que o item perca prioridade diante de outras tarefas já em desenvolvimento. A abordagem mais adequada, de acordo com o caso, seria manter o item na etapa de testes e comunicar uma pessoa desenvolvedora que foi um encontrado um bug o qual está impedindo a liberação do item e cuja correção precisa ser priorizada. Quais métricas são possíveis de visualizar a partir de um CFD Scrum? A partir do gráfico CFD, é possível visualizar várias métricas, como, por exemplo: Lead time: o tempo que determinada tarefa leva para sair de “To Do” até a coluna “Done”. É possível ver a evolução do lead time ao longo do tempo e identificar quais fatores contribuem para aumentá-lo ou reduzi-lo; Throughput: a quantidade de tarefas concluídas em um determinado período de tempo; WIP (Work in Progress): a quantidade de tarefas em andamento em cada estágio do processo; Cycle Time: o tempo médio para a conclusão de uma tarefa, desde o início até o final; Tempo médio de espera: o tempo médio que uma tarefa fica parada em uma determinada coluna antes de ser movida para a próxima Essas métricas são essenciais para avaliar a eficiência do processo de desenvolvimento de software e identificar possíveis melhorias. Ainda tem alguma dúvida sobre o gráfico CFD? Deixe seu comentário e confira outros artigos do Tech Writers.