Prof. Adolfo Neto (DAINF-UTFPR)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Agile Lite: Agile sem todo o burnout, Dave Sullivan ======

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.