Do BDD ao TDD, os prós e contras de várias técnicas Agile

Embora essa lista esteja longe de ser definitiva, o importante é entender que Agile não tem rregras e regulamentos tão rígidos

Author Photo
4:04 pm - 18 de abril de 2018

Para quem olha de fora, o Agile pode parecer um único conjunto de práticas. Mas uma vez mergulhando no método, é possível perceber  que praticantes de Agile usam muitas técnicas diferentes. Como você descobre quais são certas para você e sua equipe?

Aqui está um resumo de alguns prós e contras de vários frameworks e técnicas Agile.

1 – Behavior-driven development (BDD)

Definição:  O BDD é uma prática em que os membros da equipe discutem o comportamento esperado de um sistema para criar um entendimento compartilhado da funcionalidade esperada. Ele sintetiza e refina práticas derivadas do  desenvolvimento orientado a testes  (TDD) e do  desenvolvimento orientado a testes de aceitação  (ATDD).

Por que funciona? O BDD coloca o foco no fornecimento de funcionalidades específicas em vez do MVPl. Isso é importante porque garante que você esteja entregando o valor que a empresa precisa.

Como isso pode decepcionar: Você está medindo a funcionalidade, mas não necessariamente a qualidade do trabalho subjacente. A menos que você também esteja fazendo um desenvolvimento orientado a testes, você corre o risco de construir a coisa certa da maneira errada – com código que será mais difícil de manter ou estender mais tarde. Além disso, há menos ferramentas de software disponíveis para suportar o BDD.

2 – Distributed agile

Definição:  Minha opinião: refere-se ao uso de membros da equipe Agile em diferentes locais, organizações e até mesmo fusos horários. Em vez de reuniões presenciais, as equipes ágeis distribuídas usam mensagens instantâneas, e-mail, videoconferência e outras ferramentas para coordenar seu trabalho diário.

Por que funciona? O trabalho distribuído torna possível escapar de qualquer restrições de espaço ou localização imediata. Ferramentas modernas de colaboração como o Slack, o Skype, o Teams e o Hangouts tornaram isso possível. É possível trabalhar juntos em histórias sem estar no mesmo lugar e fazer perguntas sem atrapalhar o fluxo de seus colegas de trabalho.

Confiança, relacionamento e comunicação ainda são essenciais. É por isso que o Distributed Agile funciona melhor quando você tem pelo menos dois colegas de equipe em um determinado local, eles se encontram cara a cara periodicamente e entendem bem a língua e a cultura um do outro. É útil ter toda a equipe reunida em um curto período de tempo e fusos horários que todos estejam disponíveis para que você possa colaborar fisicamente e virtualmente quando necessário. Essa solidariedade da equipe faz toda a diferença quando você está tentando resolver um problema difícil, obter feedback de negócios ou de usuários ou apenas integrar novos membros da equipe.

Como isso pode decepcionar: Agile funciona melhor quando há comunicação rápida e frequente entre os membros da equipe e outras colaborações formais e informais. É por isso que os agilistas tradicionais acreditam que só funciona quando as equipes estão 100% no mesmo local.

Minha experiência é que você pode alcançar essa forte colaboração em um ou dois fusos horários, mas ela começa a desmoronar quando há lacunas significativas de fuso horário, idioma e cultura. O objetivo de um standup é que a equipe se comunique e avance. Você pode ter uma reunião de status global decente, mas tentar escolher um momento em que todos possam ser eficazes em um standup global é extremamente difícil, se não impossível.

3 – Kanban

Definição: “O Método Kanban é um meio para projetar, gerenciar e melhorar os sistemas de fluxo de trabalho. Também permite que as organizações iniciem com um fluxo de trabalho existente e gerem mudanças evolutivas. Eles podem fazer isso visualizando seu fluxo de trabalho, limitando o trabalho em andamento (WIP), etc. 

Por que funciona? O Kanban é bom para cenários como o gerenciamento de tickets de suporte, onde nem sempre se sabe quando o trabalho está chegando. É especialmente útil quando você pode ter um método alternativo de medir valor/produtividade, como pedidos fechados. O Kanban também permite que você gaste menos tempo em atividades de “overhead”, como standup, demos e retrospectivas diárias.

Como isso pode decepcionar: O Kanban pode ser difícil para equipes novas, pois o processo não é claramente definido, como acontece com outras metodologias. Não há demonstração, então a equipe não recebe feedback da empresa sobre se está entregando a coisa certa. E como não há retrospectiva de sprint, melhorar seu processo pode ser difícil. Você pode facilmente ficar preso em um processo ruim, indefinidamente.

4 – Pair programming

Definição: A programação em pares consiste em dois programadores compartilhando uma única estação de trabalho (uma tela, teclado e mouse entre os pares). O programador no teclado geralmente é chamado de driver; o outro, também envolvido ativamente na tarefa de programação, se concentra mais na direção geral. É o navegador. Espera-se que os programadores troquem de função a intervalos regulares, de minutos.

Por que funciona? A programação em pares foi projetada para trabalhar em tarefas complexas. Também é ótimo para transferência de conhecimento quando você está participando de um novo desenvolvimento. Com a programação em pares, você melhora a qualidade geral.

Como isso pode decepcionar: A programação em pares pode ser um exagero para tarefas de rotina. Ter dois desenvolvedores trabalhando nessas tarefas juntos provavelmente não é a melhor maneira de gastar o dinheiro da empresa. Além disso, alguns desenvolvedores são muito mais felizes e produtivos trabalhando por conta própria.  Sou um defensor da programação em pares, desde que você dê às suas equipes alguma autonomia sobre quando faz sentido e quando não faz.

5 – Scrum

Definição: O Scrum é uma estrutura de processos usada para gerenciar o desenvolvimento de produtos. O Scrum é empírico na medida em que fornece um meio para as equipes estabeleçam uma hipótese de como elas acham que algo funciona, a experimentem, e refletam sobre a experiência para fazer os ajustes apropriados.

Por que funciona? O Scrum oferece definições claras de processo. Isso significa que os membros da equipe sabem exatamente o que é esperado deles. Há muitos pontos de verificação para garantir que você continue entregando valor, sem sair dos trilhos. No geral, o Scrum é uma ótima metodologia para o desenvolvimento de produtos.

Como isso pode decepcionar: O Scrum é uma luta quando as equipes só conhecem os processos – “as coisas que fazemos” – sem entender por que fazemos isso. Por exemplo, supõe-se que uma apresentação diária seja uma reunião rápida para fornecer transparência e descobrir obstáculos para avançar em m projeto. Mas um standup ruim pode se transformar em um relatório de status de 40 minutos. Pode fazer o negócio se sentir bem, mas não impulsiona o trabalho. Da mesma forma, retrospectivas sem reflexão sincera podem se transformar em sessões de “tapinha nas costas” em vez de oportunidades para melhorar futuros sprints.

Agile

6 – Test-driven development (TDD)

Definição: O desenvolvimento orientado a testes é um estilo de programação no qual três atividades são fortemente entrelaçadas: codificação, teste (na forma de testes de unidade de escrita) e design (na forma de refatoração).

Por que funciona? O TDD garante uma programação de melhor qualidade. Com o TDD você escreve apenas o código suficiente para satisfazer o teste. Isso resulta em um código mais modular e mais enxuto, que não é apenas testado, mas também mais extensível e sustentável. O TDD também reduz o custo total de propriedade (TCO). Você tem menos defeitos. Você também detecta defeitos no início do ciclo quando custa menos para consertar.

Como isso pode decepcionar: O TDD pode levar de quatro a seis meses para obter proficiência. Durante esse período de rampup, o TDD irá atrasá-lo. O TDD também requer investimento inicial adicional. Mas isso acaba sendo compensado por menores custos de longo prazo.

Embora essas sejam algumas das práticas Agile mais comuns, essa lista está longe de ser exaustiva. O importante é ter em mente que o Agile não é um livro rígido de regras e regulamentos. É uma abordagem flexível e iterativa para o desenvolvimento de software que é especialmente adequada para empresas que buscam uma mentalidade de produto , com ênfase em agilidade, velocidade de lançamento no mercado e a melhor experiência para o cliente. Organizações diferentes chegarão de diferentes maneiras, mas todas elas podem se beneficiar ao encontrar um estilo Agile que funcione para elas.

Newsletter de tecnologia para você

Os melhores conteúdos do IT Forum na sua caixa de entrada.