Uma metodologia de desenvolvimento flexível é uma ótima idéia que é muito complicada. O Agile Lite é uma tentativa de simplificar a situação. Você não precisa de livros ou seminários para explicar o Agile Lite. Apenas um texto pequeno com alguns pontos é necessário. Aqui está o texto.

O Agile Lite é bem simples. Pode ser aplicado a qualquer projeto, desde que o trabalho seja dividido em tarefas menores (problema). Como outras metodologias ágeis, ele usa ciclos curtos de desenvolvimento - sprints. Mas, diferentemente deles, o Agile Lite reconhece claramente a prevalência de burnout no setor de desenvolvimento de software e tenta mitigá-lo diretamente, introduzindo um ciclo de desenvolvimento de três semanas / descanso de uma semana.

Regras básicas:

• Na primeira semana de cada ciclo, gerentes de projeto, desenvolvedores e outras partes interessadas determinam o próximo sprint. Embora uma semana tenha sido reservada, o planejamento do sprint não levará mais de duas horas e, com a organização certa, levará cerca de 45 minutos. Esta é uma semana intencionalmente fácil: muitos podem simplesmente tirar férias para surfar, pintar ou algo mais.
  
• O Sprint é executado nas três semanas restantes. Durante esse período, os engenheiros trabalham nas tarefas que lhes são atribuídas durante o planejamento. Como os funcionários podem ser remotos e distribuídos por fusos horários, as reuniões ao vivo não são frequentes e a maior parte da comunicação passa por um rastreador (que funciona mais rápido que o e-mail). Um quadro Kanban comum como o Trello é bom e uma planilha é improvável. Planadores diários não são incentivados: o pulso geral do projeto é totalmente rastreado pelas atualizações do rastreador.
  
• Após o início do sprint, você não pode adicionar tarefas ao sprint, mas pode excluí-las. Isso reduz a alternância de contexto, o que é bom.
  
• Tarefas inacabadas são consideradas na próxima sessão de planejamento do sprint - e é decidido mover a tarefa para o próximo sprint, retorná-la à lista de desejos ou redesigná-la para outro desenvolvedor.
  
• Cada tarefa está na lista de desejos ou no sprint atual. Cada tarefa deve levar de 4 a 8 horas para ser concluída.
  
• Como já mencionado, os desenvolvedores são aconselhados a descansar durante a semana de planejamento para que o cérebro se recupere do sprint anterior. Isto não é uma cruzada. Os desenvolvedores não trabalham nos fins de semana. Tudo isso ajuda a evitar o desgaste, o que é útil para todos.

Embora o trabalho principal no sprint possa ser planejado, às vezes acontece algo inesperado. Esses problemas inesperados são chamados de problemas de suporte.

Durante o planejamento do sprint, sugerimos alocar tempo para resolver tarefas de suporte que não são passíveis de planejamento. Por exemplo, "durante o próximo sprint, Dave recebe 12 horas para resolver tarefas de suporte (detalhes sobre os quais serão determinados posteriormente)". Geralmente, é útil manter a rotação, onde os desenvolvedores responsáveis ​​pelos problemas de suporte mudam a cada sprint.

Para melhorar a precisão da previsão, em cada sessão de planejamento do sprint, é analisada a quantidade de trabalho de suporte realmente realizado no sprint anterior e é tomada uma decisão sobre se leva mais ou menos tempo para dar suporte ao próximo sprint.

Na prática, grupos diferentes têm definições diferentes para tarefas de suporte. Talvez isso signifique suporte ao cliente / cliente. Talvez o apoio de outros desenvolvedores. Cabe a você decidir quais elementos dessa metodologia geral são melhores para sua equipe.

Ao eliminar a complexidade desnecessária, o Agile Lite é a melhor e mais sustentável maneira de desenvolver software. Ajuda no desenvolvimento, garantindo um nível consistentemente alto de produtividade.

Agile Lite para desenvolvedores

Se você não é novo no setor, pode ter sofrido um desgaste. Ele tem muitos motivos, mas a maneira mais fácil de descrever o desgaste é o resultado de trabalhar demais com muito estresse por muito tempo.

Tudo começa com um projeto. Cada projeto tem uma especificação detalhada e prazo. Quando a especificação muda, o prazo não é. No final, o prazo chega e a especificação se transformou em algo diferente de onde começou. Obviamente, isso é considerado culpa sua, e você é solicitado a ficar até mais tarde ou a "esticar o alvo". Como resultado, você trabalha todo fim de semana, mas, independentemente de seus esforços, o gerente está sempre insatisfeito e o projeto está constantemente "atrasado".

Querendo sair de férias ou de férias, você parecerá um vadio que não apoiará a equipe. Você pode estar trabalhando em um escritório aberto; todo mundo sabe quando alguém chega e sai, e todo mundo assina um contrato tácito para não trabalhar menos que os outros. Portanto, as pessoas sabem como parecer ocupadas. Quando alguém pergunta como você está, você simplesmente responde: “Ocupado! Estou tão ocupado!

Mas no final, algo acontece. Você pode mudar de emprego, mas geralmente são outras empresas do setor de software. Talvez você dê toda a sua força para completar a devastação e depois a empresa o solte, porque você já "não se encaixa na cultura". Talvez você pare e comece a negociar carros, porque a programação é muito frustrante. Como diz o ditado, se você quer perder o prazer de um hobby, tente ganhar dinheiro com ele.

Eu ofereço uma solução. Este é um formulário Agile claramente projetado para evitar o esgotamento: Agile Lite. Não há horas extras. O trabalho de engenharia está em andamento, e os desenvolvedores têm tempo suficiente para recarregar seus cérebros. A sobrecarga de gerenciamento é mínima.

Quase todo o sistema é descrito nos seis pontos acima. Pode ser alterado de acordo com seus objetivos. Mas eu gostaria de destacar um recurso do Agile Lite. Aqui dizemos explicitamente: “Ei, equipes flexíveis queimam da mesma maneira que em outras metodologias de desenvolvimento. Pode valer a pena escrever regras explícitas para evitar o superaquecimento do mecanismo, que é a equipe de engenharia. ”

Vamos parar de superaquecer os motores. Temos muito trabalho. De fato, este é um poço sem fundo. Mas a vida é muito curta para gastá-la completamente em trabalho, estresse e, finalmente, esgotamento.

Agile Lite para gerentes

Sua empresa teve problemas com os desenvolvedores? Os projetos frequentemente perdiam os prazos? Você trabalhou com desenvolvedores que iniciam perfeitamente, depois se degradam lentamente e desaparecem? Talvez este seja um programador talentoso que tenha sofrido burnout.

O burnout é extremamente comum na indústria de software e é uma das principais razões pelas quais muitos projetos de software falham. O burnout pode ser melhor descrito como sintomas de transtorno de estresse pós-traumático associado a um determinado projeto ou organização. Por exemplo, o cérebro parece desligar e você sente extrema ansiedade com a simples menção de um determinado projeto. Isso é esgotamento. Um desenvolvedor nesse estado, provavelmente, não poderá continuar trabalhando neste projeto e, nos projetos subseqüentes, não poderá trabalhar com força total. Burnout pode prejudicar uma carreira.

Isso é semelhante ao acionamento de um motor de carro em alta velocidade por muito tempo, sem adição de óleo ou combustível. No final, esse mecanismo quebrará e será difícil montá-lo de volta.

Os princípios básicos do Agile Lite estão descritos acima e estão sujeitos a alterações de acordo com seus objetivos.

FAQ + declarações típicas

A única regra geral no mundo do desenvolvimento ágil é que todo mundo faz errado. @fwip

Então, os engenheiros têm 12 semanas de folga por ano para surfar e pintar? Como isso funcionará em um mundo onde o trabalho das 9 às 00 horas, 21 a 00 horas, seis dias por semana se torna a norma?

Acho que seus desenvolvedores devem descansar o quanto precisam.

Observo que a semana de trabalho de 40 horas já foi considerada uma ideia radical. O Google começou com 80% do tempo de trabalho para grandes projetos, agora temos 75%, eu gostaria de reduzi-lo para 10% (método Ferris) até o final da década de 2020.

O sistema 996 (das 9:00 às 21:00 6 dias por semana) é a abordagem oposta, que busca estender a semana de trabalho de 40 horas para uma de 72 horas. Eu vejo isso como uma regressão e acho que devemos parar de fetichizar horas extras. De fato, isso não aumenta a produtividade.

Além disso, você decide o que fazer durante a "semana de descanso": saia de férias, atribua uma carga de trabalho mais leve ou outra coisa. A resposta pode depender da semana em particular.

Talvez "semana fácil" seja mais fácil para as pessoas do que "semana de descanso". Use o que for mais conveniente para você.

O surf e a pintura não são de forma alguma obrigatórios, são dados apenas como exemplos. Eu mesmo nem surfo e pinto.

As pessoas recebem tarefas ou elas próprias prevêem o que receberão?

Eles prevêem. Tudo bem se suas estimativas estiverem erradas. Isso faz parte do processo e tudo em uma equipe.

Poderia ser chamado de iterações em vez de sprints?

Claro! Sprint é ideal para mim.

É possível fazer uma iteração deslizante no estilo kanban, onde as datas de início e término variam e dependem das circunstâncias?

Eu realmente aprecio o conceito de um ciclo de trabalho com determinadas datas de início e término, e definido por um bloco de tarefas. As iterações deslizantes que não são sincronizadas com um loop específico irão estragá-lo.

Por que exatamente três semanas de corridas?

Porque desenvolvimento e recuperação são colocados em 13 slots por ano. Quando o ciclo é concluído, um novo começa. Uma semana de "descanso" permite que você reinicie antes do início de um novo sprint. Trata-se de alcançar uma cadência e intervalos claros e consistentes.

Isso significa que as datas de início e término dos sprints geralmente caem no meio do mês?

Sim

Os desenvolvedores estão envolvidos no planejamento do sprint?

Sim Eles não são proibidos de participar da reunião. Isso simplesmente não é necessário, especialmente se o rastreador de tarefas funcionar bem, e a equipe discutiu alguns dos pontos para o próximo sprint durante o anterior.

Eu sou para menos reuniões. Poucas pessoas gostam deles. Se você é um desses, não conte comigo.

O planejamento de um sprint demora uma semana?

Não, esse é o ponto. Esta é uma semana fácil.

Os stand-ups são realmente um problema?

Na minha experiência, sim. Normalmente, todos estão em círculo, ouvindo uma pessoa por 20 minutos. Obviamente, essa é a abordagem "errada", mas nunca vi alguém fazer a coisa certa e preferiria abandonar completamente os planadores diários. Ainda mais difícil (ou pelo menos inconveniente) de fazer isso quando sua equipe está distribuída geograficamente. Mas se eles são muito valiosos para você, não me deixe impedi-lo.

Devemos fazê-lo desta maneira?

Não. Ninguém o força a nada. Estas são recomendações, não regras.

Isto não é uma religião.

Essas regras são políticas apenas no sentido em que a propaganda da semana de trabalho de 40 horas foi política.

O que funciona para você pode não funcionar para os outros. Você sabe disso?

Eu tenho certeza disso!

Reivindicações frequentes

Você não precisa fazer previsões sobre o tempo, porque as estimativas são impossíveis.

As previsões são consideradas previsões, não contratos assinados em sangue. Portanto, se eles não forem respeitados, isso é normal. Faça todos os esforços e tente fazer uma previsão em incrementos de 4 horas.

Os desenvolvedores não podem ser confiáveis, e você precisa acompanhar o tempo todo, porque é assim que o trabalho é feito.

Eu realmente discordo, mas não consigo explicar rapidamente o porquê. Temos diferenças fundamentais na visão de mundo.

Isso não é ágil.

Claro que Agile, ele está certo no título.

Isso não é realista.

E ainda assim funciona.

Você está agindo errado.

Infelizmente, o problema com o Agile é que ele não pode ser feito corretamente.