Como representar um projeto ágil para pessoas focadas em cascata [fechado]

Nossa equipe foi solicitada a representar nossos esforços de desenvolvimento em um plano de projeto. Ninguém está insatisfeito com nosso trabalho ou questiona nossa capacidade de entregar, estamos apenas participando de uma chamada de gado de TI para planos de projeto. O problema é que somos uma equipe ágil e não pensamos em nosso trabalho em termos de um plano formal de projeto.

Embora tenhamos uma ideia geral do que estamos trabalhando a seguir, não temos 100% de certeza até planejar uma iteração. Até agora, nossa equipe operava em grande parte no vácuo e não era obrigada a apresentar nossa metodologia ou métricas a terceiros. Seguimos a maioria das práticas adotadas na programação extrema .

Realizamos reuniões trimestrais de planejamento para ter uma idéia geral das histórias nas quais trabalharemos por um quarto. Dito isso, nossas histórias são documentadas em cartões 3x5 e são estimadas apenas no início da iteração em que serão trabalhadas. Após a estimativa, documentamos a história em Team Foundation Sever . Durante uma iteração, anexamos o código às histórias e marcamos as histórias como concluídas após a conclusão. A partir desses dados, somos capazes de gerar gráficos de queima e velocidade. Mais importante ainda, sabemos nossa velocidade média para uma iteração, impedindo-nos de morder mais do que podemos mastigar.

Não estou tentando modificar a maneira como desenvolvemos o desenvolvimento, mas quero apresentar nossas atividades de desenvolvimento em um relatório que alguém familiarizado apenas com o Waterfall entenderá. Em Como é um plano de projeto ágil , Kent McDonald faz um bom trabalho ao estabelecer as diferenças entre os planos de projeto ágil e em cascata. Ele especifica as diferenças em marcadores consumíveis:

• Um plano de projeto ágil é baseado em recursos
• Um plano de projeto ágil é organizado em iterações
• Um plano de projeto ágil tem diferentes níveis de detalhes, dependendo do período de tempo
• Um plano de projeto ágil é de propriedade da equipe

Ser capaz de explicar as diferenças é ótimo, mas qual a melhor forma de apresentar os dados?

Mostre a eles o manifesto ágil semi-arsed .

Definitivamente, diz a você o que é o sistema Agile , comparando-o aos métodos em cascata :

Indivíduos e interações sobre processos e ferramentas
e temos processos e ferramentas obrigatórios para controlar como esses indivíduos (preferimos o termo 'recursos') interagem

Trabalhar software em documentação abrangente
, desde que esse software esteja documentado de maneira abrangente

Colaboração do cliente sobre negociação de contratos
dentro dos limites de contratos rígidos, é claro, e sujeito a rigoroso controle de alterações

Responder à mudança após seguir um plano,
desde que exista um plano detalhado para responder à mudança e seja seguido com precisão

Eu tive que fazer isso uma vez. A equipe queria fazer o Agile, o cliente queria (e entendeu o Agile), um terceiro externo (os chame de "auditores"), queria ver os relatórios do Waterfall.

Uma razão importante pela qual poderíamos mentir era porque o terceiro realmente não se importava, eles só queriam marcar as caixas. Se o Cliente estivesse feliz e a Equipe estivesse feliz, os "Auditores" dificilmente retornariam e examinariam os relatórios que fornecemos a eles, antes de marcar as caixas finais.

Não faça isso se o terceiro for importante e realmente se importa com o uso de cascata . Se os auditores sabem que você está sendo ágil e não atualizaram a documentação para dar suporte a você - você pode mentir.

O que você faz? Mentira , mas mentira branca.

• Reformule Recursos, como requisito "Deve ter um Recurso".
• Seu trabalho é em Iterações, as iterações geralmente duram X semanas, um plano em cascata gosta de ver as coisas geralmente em Semanas, portanto, não há grande problema. Você pode rotular o final de cada iteração como um marco. Marcos são cachoeira. As iterações tendem a ter um tema (ou uma Epopéia associada), para que você possa colocar o título do tema / epopéia no marco (por exemplo, 21/11 Ter a GUI concluída).
• Calcule sua velocidade (a partir de seus gráficos de redução / aumento) e calcule quanto tempo um Ponto de História representa, em média (pelo menos na sua velocidade atual), isso lhe dará durações de tarefas. Muitas vezes, imprecisos e descontrolados, mas serão significativos até certo ponto.
• Seu plano possui diferentes níveis de detalhes, dependendo do período - basicamente o mesmo para a cascata. É possível que um plano em cascata tenha detalhes diferentes, dependendo do público.

• Um plano Agile é de propriedade da equipe. Um plano em cascata pertence ao gerente de projeto. Você provavelmente já tem um gerente de projeto e provavelmente está fazendo essa tradução . Eles devem se apropriar deste documento traduzido e proteger a equipe do grupo que pode chover sobre eles por causa disso. O trabalho de um gerente de projetos ágil ou em cascata é proteger a equipe de distrações que as impedirão de trabalhar.

• Claro que você realmente não sabe o que está fazendo na próxima iteração, mas sabe aproximadamente o que está fazendo. Você tem uma ideia disso e ainda mais dura a iteração depois. (Eu ouvi isso chamado Radar de Iteração). Mentir e dizer que sim. e quando se debruçar sobre o cartão de história que não está no seu Radar de Iteração, basta colocá-lo em algum lugar. Espero que você não precise enviar muitas atualizações no plano do projeto, ou elas perceberão que você não fez o que disse que faria.

Basicamente, isso é uma dor. A tradução levará muitas horas de trabalho. Se você precisar fazer muito, automatize-o.

A primeira pergunta a fazer é o que a empresa realmente deseja? Algumas empresas ficam perfeitamente felizes ao ver sprints ágeis representados / divididos em um gráfico de Gantt. Pode não fazer sentido para alguém que realmente entende os sprints e pode mudar regularmente, mas é familiar para as pessoas que o solicitam. Em seguida, juntamente com o gráfico de Gantt, apresente a burndown etc.

Passamos por algo semelhante e, eventualmente (se o Agile estiver funcionando), ele se venderá (se não funcionar, por que você está fazendo isso?). As pessoas começam a entender "esforço" e que uma certa equipe é capaz de "queimar" 40 pontos de esforço em uma corrida de duas semanas e é realmente muito boa, em média, para estimar esses pontos de esforço. Depois de verem os benefícios para eles, eles venderão o processo para o restante dos negócios para você. Mas o ponto principal é que você nunca pode forçá-lo a alguém, pois ele apenas revidará.