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

Tradução completa em https://github.com/adolfont/AgileLite/tree/master/portuguese

“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 a próxima 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.

• A 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. Uma vez que a equipe pode ser totalmente remota e estar distribuída em diferentes 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 é. Reuniões Diárias em pé são desencorajadas; uma tomada de pulso básica do projeto pode ser obtida revisando as atualizações do sistema de rastreamento de problemas.

• Depois que uma sprint é iniciada, Problemas não podem ser adicionados à 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 a próxima sprint, colocado de volta no Backlog ou transferido para outro desenvolvedor.

• Um Problema está no backlog ou na sprint atual.

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

É basicamente 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 nível de 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.