Tradução de https://github.com/davebs/AgileLite

“Desenvolvimento ágil de software” é uma ótima idéia que foi supercomplicada pelas indústrias de publicação e consultoria. Agile Lite é uma tentativa de simplificar a situação. Você não precisa de um livro ou de um workshop para explicar o Agile Lite. Você só precisa de um arquivo de texto com vários parágrafos. Este é o arquivo de texto.

O Agile Lite é bem simples. Ele pode ser aplicado a qualquer projeto com pessoas trabalhando nele, supondo que o trabalho possa ser dividido em tarefas integrantes menores que chamaremos de Problemas. Como outras metodologias ágeis, utiliza ciclos curtos de desenvolvimento chamados Sprints. De forma relativamente única, o Agile Lite reconhece explicitamente a prevalência de burnout na indústria de desenvolvimento de software e tenta mitigá-lo diretamente por meio de um ciclo de desenvolvimento de 3 semanas de atividade por uma semana de inatividade.

A configuração básica é esta:

• A primeira semana de cada mês é gasta com os líderes e partes interessadas do projeto definindo o próximo sprint. Apesar de uma semana ser alocada, uma sessão de planejamento de sprint não deve levar mais de 2 horas e, provavelmente, cerca de 45 minutos, se feita corretamente. É uma semana intencionalmente leve e muitas pessoas podem simplesmente tirar um tempo para pintar, surfar ou qualquer outra coisa.

• O sprint ocorre durante as 3 semanas restantes do mês. Durante esse período, os engenheiros trabalharão nos problemas que foram alocados a eles durante as sessões de planejamento da sprint. Como a equipe pode ser totalmente remota e distribuída em fusos horários, as reuniões “ao vivo” acontecem com pouca frequência e a maioria das comunicações acontece por meio do sistema de rastreamento de problemas (que é mais rápido de se trabalhar do que de e-mail). Um quadro kanban compartilhado como o Trello é um sistema de rastreamento de problemas suficiente, mas uma planilha provavelmente não é. Os levantamentos diários são desencorajados; um pulso básico no projeto pode ser obtido revisando as atualizações do sistema de rastreamento de problemas.

• Depois que um sprint é iniciado, os problemas não podem ser adicionados ao sprint, mas podem ser removidos. Isso reduz a mudança de contexto e isso é bom.

• Os problemas que não são concluídos durante a sprint são revisados ​​na próxima sessão de planejamento da sprint e é decidido se o problema deve ser encaminhado para o próximo sprint, colocado de volta no Backlog ou transferido para outro desenvolvedor.

• Um problema está no backlog ou no sprint atual.

• Como mencionado, os desenvolvedores são encorajados a tirar a semana de planejamento para permitir que seu cérebro se recupere do sprint anterior. Não há marchas de morte. Os desenvolvedores não trabalham nos finais de semana. Isso tudo ajuda a evitar o burnout. Evitar o burnout é bom para todos.

Isso é muito bonito isso. O sistema realmente não prescreve práticas de engenharia e acho que está tudo bem. As práticas de engenharia podem ser definidas em um nível por projeto.

O trabalho de suporte é feito rotativamente porque às vezes as coisas acontecem inesperadamente e precisam ser resolvidas, mas um número surpreendente de problemas pode esperar até mais tarde.

O Agile Lite é uma maneira melhor e mais sustentável de desenvolver software. Ele capacita os desenvolvedores de software, ao mesmo tempo em que fornece um nível consistentemente sólido de produtividade para as partes interessadas do projeto.