Planejamento a longo prazo e ágil?

Minha equipe recentemente passou pelo processo de definir um plano de quase um ano para o nosso trabalho. Separamos o plano em três fases. Cada fase incluirá alguns lançamentos.

Eu me pergunto, do ponto de vista ágil de você, isso está errado? Acho que não é uma má ideia, porque não gastamos muito tempo projetando nada além dos primeiros passos. É possível mudar de direção. Ao mesmo tempo, é bom não agirmos apenas com o curto prazo à vista.

Ter uma visão de onde o projeto está indo é uma Good Thing ^TM .

Acreditar que é exatamente isso que vai acontecer não é.

"Ao me preparar para a batalha, sempre achei que os planos são inúteis, mas o planejamento é indispensável."

- Dwight D. Eisenhower

A abordagem adotada pelas metodologias ágeis é dividir as coisas em pedaços digeríveis e reajustar a visão após a digestão de cada peça.

Isso significa que seu ponto final daqui a um ano não será exatamente o que você pensa que é agora. No entanto, você deve ter abordado todos os itens de alto valor em sua lista e ter mantido as partes interessadas envolvidas e felizes à medida que avança.

OK, a gerência recebeu um mito para planejar. Espero, por você, que eles não o segurem. Porque, invisível, estou disposto a apostar dinheiro para que sua equipe não realize nada como o que esse plano de longo prazo diz. De fato, se você atingir a média da indústria, perderá cerca de um fator de 2. E na maioria das organizações, uma estimativa, uma vez dada, se torna o clube em que eles são livres para bater em você com o quanto quiserem.

Você provavelmente pensa que estou apenas sendo cínico. Afinal, você acabou de comunicar tempos vagas para conjuntos de recursos não especificados que todos sabem que podem acontecer muito mais devagar ou mais rápido do que o projetado, certo? Desculpe, a maior parte disso pode ser verdade, mas não é assim que as pessoas tendem a ouvir esses números. Eles ouviram datas, e um encontro uma vez falado tende a ser ouvido como mais sólido do que você disse. Além disso, se houver uma cadeia de comunicação, ela se tornará ainda mais sólida. E uma vez que as vendas aos clientes externos tenham prometido algo com base no que você disse, você subitamente descobrirá que há muito menos flexibilidade nesses números do que deveria. E garanto que você subestimou o tempo que as coisas levarão.

Com esse ponto óbvio, recomendo que você leia Estimativa de Software para aprender algo sobre como a estimativa de software deve realmente ser feita. Você aprenderá muito sobre o que fez de errado e sobre como fazer melhor da próxima vez. (No processo, você aprenderá por que estou tão confiante de que superestimou o que fará.)

Dito isto, agile é basicamente reduzir o processo ao apropriado para uma equipe pequena. Freqüentemente, uma boa maneira de reduzir o processo é reduzir o planejamento a longo prazo em grande escala, em favor do planejamento de coisas menores no curto prazo. Também tende a ser mais honesto - porque você não sabe o que acontecerá no futuro. No entanto, isso geralmente não se encaixa nas necessidades comerciais maiores e, portanto, independentemente de você se declarar ágil, às vezes é necessário estabelecer planos mais longos.

Com isso dito, recomendo vivamente que descubra um fato importante sobre as datas que comunicou e que infelizmente provavelmente voltarão como prazos para mordê-lo. E esse fato é esse. Com quem as pessoas se preocupam, a data ou o conjunto de recursos? Aqui está o que eu quero dizer com isso. Frequentemente, as organizações têm datas específicas importantes. Por exemplo, faça algo para uma conferência ou antes do feriado. Nesse caso, o que importa é liberar algo, e não tanto se algo está completo. Outras vezes, há um conjunto de recursos que realmente precisam ser lançados juntos, e a integridade é mais importante do que quando exatamente acontece. Se você puder descobrir em que situação está, sua equipe estará em uma posição muito melhor para planejar como lidar com as (quase) inevitáveis ​​flexões que estão por vir.

É bom ter um plano, desde que você considere o trabalho em andamento e não algo escrito em pedra.

A chave aqui é fazer lançamentos regularmente (pelo menos mensalmente), reunir feedback real de seus usuários e atualizar seu plano com base nesse feedback.

Isso significa que seu plano mudará quando o escopo do projeto for alterado. Isso é bom , porque significa que seus usuários aprenderam mais sobre o que desejam.

Assumindo por project-managemente agilevocê quis dizer Scrum, este não seria o caminho exato para ir.

Na Scrumperspectiva, se você tem um plano de um ano, deve ter pelo menos o número de Sprints que houver meses em um ano. Portanto, seu plano de um ano está ficando mais ágil, pois é mutável entre dois Sprints.

A não Sprintpode ser superior a um mês, em que os Teamcommit confirmam Sprint Backlog Itemso status de Done.

Doneé uma palavra importante aqui, e cada uma delas Scrum Teamdeve ter uma definição de concluído, ou seja, onde não há trabalho a ser feito. Quando a Sprint Backlog Itemé Concluído , isso significa que a análise, a arquitetura e a documentação técnica estão escritas e que o recurso foi exaustivamente testado (testes de unidade, testes de integração, testes funcionais ...).

Uma vez que deve priorizar os Itens, é ele quem é responsável pelo retorno do investimento, ou então sabe o que é mais importante para o usuário final. Além disso, a Equipe avaliará o tempo necessário para desenvolver completamente um recurso, embora possa haver trechos de código reutilizáveis ​​aqui e ali que atendam às necessidades desse recurso, ou seja, para evitar mais complexidade e ter certeza de que um Item não deve mais do que o que a equipe disse que exigiria. O Backlog do produto não precisa ser perfeito! A simples enumeração de histórias de usuários que podemos pensar no sistema a desenvolver é suficiente nessa etapa do processo.Product Backlog implementado, e os Itens priorizados com recursos menos importantes na parte inferior e os mais importantes no topo, a Equipe (dos desenvolvedores) determina quanto tempo o desenvolvimento de cada um Product Backlog Itemdeve levar com base em sua própria experiência. É aí que você pode determinar que o projeto exigirá um ano inteiro de trabalho. Considere que apenas oProduct Owner

É durante o período em Sprint Planning Meetingque a equipe se compromete com o que será desenvolvido para o próximo Sprint, criando assim o Sprint Backlog. A Sprint Backlogconsiste de um subconjunto com base no Product Backlog Itemsque os Teamcompromete-se a ser feito no final da Sprint. Considerando, por exemplo, um Backlog de produtos de 50 itens, e todos os 50 itens precisam de um ano para serem concluídos, a equipe pode querer selecionar, digamos 5 itens do Backlog de produtos, e criar o Sprint Backlog com esses 5 itens. Esses mesmos 5 itens podem ser expandidos / explodidos em vários outros itens quando necessário, fazendo com que a equipe mude de idéia após a revisão e se comprometa a fazer apenas 4 itens de 5 itens selecionados anteriormente no Backlog do produto.

Depois que a Reunião de Planejamento da Sprint terminar, que pode durar mais de 8 horas por um mês inteiro, dentro da qual a Equipe não se comprometerá apenas a fazer o trabalho dos itens selecionados, mas planeja como fará o trabalho. para que todos na equipe saibam exatamente o que devem fazer, o processo Sprintcomeçará. É importante que a equipe seja multifuncional pelo bem do projeto.

Dito isto, no final de cada Sprint, que dura um mês na situação atual, todos os Itens que se Teamcomprometeram a executar devem ser uma peça entregável de recursos totalmente funcionais que visam os Itens selecionados no Backlog do Produto. Ele deve ser entregue, mas não é obrigatório que seja entregue se não fizer sentido fazê-lo de acordo com o Product Owner.

É durante o Sprint Review Meetinglocal em que Product Owneré necessário ser convocado que o Teamdemonstra o que foi feito durante o Sprint e onde é necessário dizer por que não fez, se aplicável, todo o trabalho com o qual se comprometeu. O trabalho desfeito é então colocado de volta no Product Backloge disponível para o próximo Sprint. Certifique-se de que esses itens desfeitos sejam incluídos no próximo Sprint, a menos que seja indicado o contrário pelo Dono do produto, caso o objetivo tenha mudado. Mas o mais importante, embora o objetivo de um sistema tenha mudado durante um Sprint, não o interrompa a menos que seja absolutamente necessário. Somente o Dono do Produto tem autoridade para interromper o Sprint.

Uma vez o Sprint Review Meeting terminado, que deve durar não mais de 4 horas por um Sprint mensal (se bem me lembro), é hora de chegar ao Sprint Retrospective Meeting. A Sprint Retrospectiveé necessária para a Teamocorrer de modo que ele pode discutir, na presença do Scrum Master e o Product Owner (opcional) o que deu errado, como o Time Scrum pode melhorar o seu desempenho, etc. e trazer os ajustes necessários.

Quando a caixa de tempo para o Sprint Retrospective término, o novo Sprint Planning Meetingocorrerá para planejar o próximo Sprinte criar o novo Sprint Backlog.

Lembre o Team é responsável por manter a Daily Scrumreunião de 15 minutos em que cada membro da equipe responde às três perguntas (não nessa ordem específica):

1. O que você fez desde o último Daily Scrum?
2. O que você planeja fazer até o próximo Daily Scrum?
3. Quais são os problemas ou impedimentos que você encontrou desde o último Daily Scrum?

Não Scrum Masteré obrigatório estar presente, mas é necessário garantir que a Equipe se reúna no Daily Scrum e que os Membros respondam às três perguntas corretamente.

O Scrum Master é responsável pelo respeito das Regras do Scrum pelos outros membros da equipe Scrum (Scrum Master, Product Owner e Team).

No final, seguindo estas regras simples, sua equipe de desenvolvimento se tornará ágil. Agilidade é a capacidade de acompanhar qualquer alteração o mais rápido possível, ou seja, no final de cada Sprint, onde é possível conhecer as alterações trazidas pelo Dono do Produto ao Backlog do Produto. Em caso de desastre total e mudança completa de orientação, o máximo de perda que a empresa precisa absorver é um mês de desenvolvimento, o que é bastante negligenciável, considerando que existem aproximadamente apenas 20 dias úteis em um mês.

Se você precisar de mais informações detalhadas sobre o Scrum e o Agile Software Development, consulte o Scrum.org e o Guia do Scrum .

Bem, isso é uma resposta e tanto! Espero que isso ajude você pelo menos no gerenciamento de projetos.

EDIT # 1

Enquanto você planeja realizar três ou quatro fases, como você chama, é mais provável que sua equipe perca o foco do ponto de vista objetivo primário. Se você demonstrar, após apenas o primeiro trimestre, o que sua equipe fez, poderá haver algumas mudanças importantes a serem realizadas, que exigirão uma reformulação importante e repensar a arquitetura do seu software, retomando-a com talvez mais de 20 dias de trabalho perdido. O princípio da agilidade é poder acompanhar as mudanças assim que elas ocorrerem, ou assim que possível dentro de um período de tempo razoável, ou seja, para o Scrum, a caixa de tempo de um Sprint.

1. Eu acho que você deve ter o maior número possível de lançamentos. O único feedback / métrica real para o progresso no desenvolvimento de software é o código implantado na produção. Portanto, qualquer que seja o processo que você use, com mais freqüência você implanta ao vivo, mais ágil você fica. Ou seja, você obtém feedback real de usuários reais mais cedo e pode se adaptar mais cedo.

2. Embora você não deva fazer o Big Design na frente , acho bom pensar no panorama geral toda vez que você estiver para ajustar e reabastecer a lista de pendências, tanto para Scrum (para o próximo sprint) quanto para Kanban / fluxo (quando houver espaço no limite WIP). Se você considerar o todo (produto, serviço etc.), será mais fácil considerar quais itens de trabalho terão mais valor a seguir.

3. Esteja ciente de que o quadro geral muda. Sempre que considerar a lista de pendências, ajustar prioridades, etc., considere também as mudanças no cenário geral. As coisas mudam com o tempo, incluindo necessidades de clientes específicos e até mercados inteiros. Sua visão geral deve refletir isso para que suas prioridades possam ser alinhadas com a realidade toda vez que você reabastecer a lista de pendências, e não apenas no início quando você fizer o plano.

Em suma, acho que você fica mais ágil quanto mais inspeciona e se adapta.

O planejamento do quadro geral não leva muito tempo e é crucial que os grandes projetos tenham o quadro geral em mente ao definir seus sprints, caso contrário, os atalhos feitos em um sprint podem criar problemas mais tarde.

Você deve:

1. Tenha um plano diretor (de preferência sem prazos), que evoluirá à medida que você avança.

2. Ao definir um sprint, verifique se ele é consistente com o cenário geral. Isso nem sempre significa que você muda sua ideia do que é desejado para o sprint. Às vezes, você descobre, ao definir um sprint, que sua imagem geral deve ser ajustada. De uma forma ou de outra, o plano geral e o sprint devem ser consistentes entre si, entrando no sprint.

3. O plano diretor deve ser ajustado conforme você avança. Você aprenderá as coisas enquanto trabalha. Novas oportunidades surgirão, pontos de conflito no plano surgirão. Você pode ajustar o plano mestre em tempo real. Mas quase sempre você deve revisitá-lo entre os sprints - para incorporar lições do último sprint e garantir que o próximo sprint esteja em harmonia com o cenário geral.

Eu acho que é melhor se o backlog e o grande plano de projeto forem estruturas separadas. O grande proprietário do projeto mantém o plano mestre em um formato hierárquico de estrutura de tópicos para manter o contexto e, em seguida, recursos / tarefas podem ser extraídos para alimentar o backlog, que, por sua vez, alimentará o próximo sprint.

Ao contrário do plano mestre, a lista de pendências pode ser adicionada por outros membros da equipe. Cabe ao proprietário do projeto principal garantir que os itens da lista de pendências e o plano geral se harmonizem - às vezes ajustando o item da lista pendente e, às vezes, o plano geral.

Esse método mantém o poder do ágil e o poder de alinhar todos os elementos do seu projeto da melhor maneira possível em um determinado momento, por meio de um planejamento geral.

Jim

Vou adicionar a forma abreviada do meu discurso anti-ágil aqui.

O Agile pode ser muito destrutivo para grandes projetos, especialmente ao criar bibliotecas e estruturas que serão fundamentais para o desenvolvimento futuro. Uma preocupação realmente importante nas fases iniciais é "meu design suportará os recursos que precisamos fornecer ao longo do próximo ano?". A maioria das estratégias ágeis não permite esse tipo de visão de futuro e, portanto, são criados pontos de falha no projeto.

Estou um pouco dolorido nesse ponto, porque eu mesmo fui queimado por isso. Estamos reescrevendo algumas das nossas principais bibliotecas. As primeiras fases foram concluídas e atingiram os objetivos do recurso para seus sprints. É tudo muito ágil. Em seguida, fui contratado para adicionar alguns recursos de carregamento dinâmico. No entanto, fiquei paralisado por cerca de seis semanas porque o que foi escrito antes presumia que nunca haveria carregamento dinâmico, perdi muito tempo reescrevendo e trabalhando com o que já estava lá. A pior parte é que o carregamento dinâmico estava nas especificações no início; se o trabalho inicial tivesse em mente todos os requisitos futuros e fizesse o 'grande trabalho de design antecipado' que as práticas ágeis consideram ruins, eu poderia ter implementado meu recurso em alguns dias.

A lição é: use o Agile para pequenas coisas que você deseja jogar fora. Às vezes pode ser ótimo. No entanto, não é a única e verdadeira maneira de desenvolvimento de software. Ao escrever um código básico que seja de alto risco ou que tenha uma vida útil longa, faça o grande design.