Ter datas de entrega fixas para elementos é uma forma de trabalho "Ágil"?

Continuamos nos dizendo que trabalharemos de maneira ágil em um novo projeto pela gerência sênior. Eles criaram stand-ups, planejamento de sprint, retrospectivas etc. etc. No entanto, agora eles elaboraram um plano que detalha todo o trabalho que eles querem que entregemos com datas para cada elemento e mostramos as datas novamente com o que será demonstrado em cada 1. Esse plano vai para o segundo trimestre de 2017.

Para mim, isso parece o Waterfall no pior sentido, foi elaborado um plano sem a participação da equipe técnica, onde certas histórias do plano não são muito claras e nenhuma foi estimada pela equipe de desenvolvimento.

No entanto, eu sei que o argumento deles será "as principais partes interessadas precisam ter datas e deve haver um plano, não podemos apenas trabalhar com uma lista de pendências". Para mim, isso parece que as principais partes interessadas não compraram o Agile e, portanto, estamos fadados a deixar de implementá-lo em um nível inferior.

É um julgamento justo ou estou exagerando neste plano !?

Há uma diferença entre cumprir o prazo e cumprir todos os requisitos. É como o velho ditado "rápido, bom ou barato, escolha dois".

Portanto, aqui você tem datas fixas para entrega - isso é bom, significa que você está dentro do prazo, pois o que você entregar no final do seu último sprint será o produto final. Você se lembra que sempre precisa lançar o software em funcionamento no final de cada corrida, não é?

O que pode acontecer é que faltam alguns recursos no software final. Bem, isso acontece com todas as metodologias de desenvolvimento, incluindo a cascata. Tudo o que acontecerá é que você será encarregado de produzir um lançamento de patch posteriormente ou uma versão 2. Isso pressupõe que sua entrega final seja boa o suficiente!

Portanto, datas fixas não são uma maneira não-ágil de trabalhar. Agile não significa que exista um orçamento ilimitado para você brincar com suas novas ferramentas de planejamento. Isso significa que você terá que se concentrar na entrega, isso nunca é uma coisa ruim.

Não. Esse é o tipo exato de coisa que as empresas que não são de software tendem a fazer. Existem planos, prazos e orçamentos. E inevitavelmente falhará, já que os humanos são péssimos em prever o futuro.

Vamos analisar os vários pontos aqui:

Continuamos nos dizendo que trabalharemos de maneira ágil em um novo projeto pela gerência sênior.

Se você fosse ágil, teria equipes auto-organizadas, sem saber como trabalhar pela gerência.

No entanto, eles agora elaboraram um plano detalhando todo o trabalho que desejam que entregemos com datas em relação a cada elemento e mostramos as datas novamente com o que será demonstrado em cada um.

Não. Essa é praticamente a antítese do desenvolvimento iterativo. Algo vai acontecer (alguém fica doente, alguém sai, algum requisito foi esquecido, seus servidores morrem, o que seja) e então você perde um desses objetivos. Agora, a gerência começa a recalcular todo o plano, ou quebra o chicote no desenvolvimento.

nenhum foi estimado pela equipe de desenvolvimento.

Então como é que a gestão sabe que este plano é viável em tudo ? No Agile, o trabalho é uma negociação. O negócio diz: gostaríamos disso. A engenharia diz: ok, assumindo XYZ, isso levará 3 semanas. Não há colaboração do cliente no que você está descrevendo. Não há indivíduos e interações.

Para mim, isso parece que as principais partes interessadas não compraram o Agile e, portanto, estamos fadados a deixar de implementá-lo em um nível inferior.

Você não está necessariamente condenado, mas se não, é apenas uma coincidência. Quando todo o trabalho aparecer porque o gerenciamento não pode ver o futuro, você perderá suas datas (ou produzirá códigos de má qualidade ou exigirá mais recursos do que o esperado). Isso será culpa sua . A gerência provavelmente o pressionará a trabalhar mais horas para chegar à data, ou talvez jogue as pessoas no problema.

Na melhor das hipóteses , o gerenciamento é realmente ágil e inteligente o suficiente para reduzir o escopo. Isso significa que eles passaram todo esse tempo construindo um grande plano detalhado que é inútil.

Se há uma expectativa de que conjuntos específicos de recursos sejam entregues em datas específicas, então não, isso não é gerenciamento ágil de projetos. O gerenciamento ágil de projetos é de natureza empírica. As projeções não são feitas com base nos desejos dos executivos, mas na análise do desempenho anterior.

Sua descrição corresponde ao que considero ser ágil no culto à carga. O foco está nos processos e cerimônias específicos e não nos conceitos centrais do gerenciamento de projetos com base em evidências. Você pode ter alguma sorte em fazer com que os empresários entendam se você relaciona isso ao Lean ou ao TPS . O verdadeiro problema que você precisa resolver aqui é fazer com que a gerência supere o medo do desconhecido. A resposta certa para os executivos é "não podemos dizer agora quando as coisas serão feitas, mas quando começamos a agregar valor, podemos construir projeções com base em nossa experiência". Os desenvolvedores tendem a dizer coisas como "é feito quando é feito" e "não sei quando será feito". Os gerentes não dizem coisas assim aos executivos, isso faz com que pareçam bobagens.

Muito provavelmente, o plano falhará e precisará ser revisado. O maior risco para a equipe é que haverá um grande esforço para cumprir os prazos e a qualidade sofrerá. Em algum momento você não estará no alvo (provavelmente, será o primeiro prazo) e haverá um empurrão para chegar a essa data. Horas extras serão esperadas e haverá pressão para cortar custos (pular teste de unidade, revisões de código etc.) Essa é uma ladeira escorregadia e, assim que você começa por esse caminho, é um pouco de espiral descendente e as coisas ficam feias. A produtividade piorará à medida que o projeto continuar dessa maneira.

Se você pode fazer com que a equipe de desenvolvimento apresente uma frente unificada, você realmente deve recuar e manter a linha na qualidade. Minha experiência é que os gerentes de projeto tendem a pensar que a saída do software é linear. Ou seja, cada período X produzirá Y 'precentage complete'. Ou seja, se você não estiver "50% completo" na metade do tempo permitido, os klaxons começarão a tocar. Na realidade, se você estiver fazendo o certo, o primeiro recurso tende a demorar muito mais que o 50º (de tamanho semelhante.) Se você conseguir passar pelo período inicial de crise de perigo ("o que está acontecendo?", "Eu não"). Não vejo nada sendo feito! ") Você provavelmente ficará bem.

Bem-vindo ao negócio real.

Há um estilo de negócios mais antigo, que eu costumo chamar com desprezo de "desenvolvimento tradicional" e, em seguida, há um novo estilo, "desenvolvimento ágil". Se eu tentar tratá-los como ideais opostos, vemos uma divisão direta no meio: planos e requisitos vão para a coluna tradicional, descoberta e evolução vão para a coluna ágil. É limpo, arrumado e errado.

Na realidade, os negócios são uma busca pelo meio termo entre os dois. É fácil mostrar que um dos extremos realmente cai de cara no chão. Nós, que amamos o Agile, demonstramos ansiosamente todos os problemas do puro ideal do desenvolvimento tradicional, e há muitos que podem mostrar as muitas maneiras pelas quais o Agile puro se desintegra. As empresas ágeis de sucesso são as que encontram seu equilíbrio particular entre as duas. As empresas tradicionais de sucesso são as que encontram seu equilíbrio particular entre as duas. Você não pode ter um sem o outro.

Até o nosso abençoado processo SCRUM mostra um equilíbrio entre os dois. Embora exista uma clara tentativa de maximizar a agilidade, existem algumas trocas importantes. Por exemplo, o Dono do Produto tem o poderoso trabalho de defender todos os clientes. O SCRUM intencionalmente não especifica como essa interação funciona. Intencionalmente ignora o fato de que todos precisam ser pagos no final do dia. É o trabalho do Dono do Produto criar a ilusão de que isso não importa.

(É interessante notar que o ágil puro funciona muito bem, desde que você não seja pago até produzir um produto e não tenha acesso a informações proprietárias até estar investido. Acho que os únicos engenheiros de software confortáveis com esse comércio são os empresários)

Portanto, a gerência determinou quais recursos estarão lá e quando precisarão estar lá. Isso é bom. Uma frase que ouvi é "o cliente escolhe o quê e quando, o produtor escolhe quem e como". Você se inscreveu no "o quê" e no "quando". Eles não declararam nada sobre quem ou como, além de oferecer a você a chance de usar "Agile" como seu como. Tudo o que resta é ajudar a gerência a entender quantas pessoas eles precisarão contratar para atender às suas necessidades.

Em um mundo perfeito, sua empresa é ágil do lado de fora. Ele interage com seus clientes de maneira ágil, permitindo que os desenvolvedores se desenvolvam rapidamente para eles. No entanto, muitas vezes a empresa deve interagir com o exterior enquanto se desenvolve com agilidade no interior. No meio, há sempre um conjunto complexo de compensações, exclusivo para cada empresa.

Pessoalmente, trato essa situação como um caso de teste para quem pensa entender o desenvolvimento ágil. Em algum momento no futuro, você terá que desenvolver um produto para um prazo, e esse par produto / prazo será relativamente fixo. Se um produto / prazo fixo atrapalhar seu processo, você pode realmente dizer que era ágil em primeiro lugar?

Meu conselho: não pense nisso como uma cachoeira. Você ainda controla o "como". Você ainda pode fazer todos os sprints rápidos e protótipos flexíveis pelos quais o Agile é tão famoso. Você apenas precisa estar ciente de que a borracha encontra a estrada e precisa entregá-la. Este é o mundo real, não o mundo ideal. Teria sido melhor para eles perguntar em primeiro lugar? Certo. Pode não ter sido sua ligação. Pode haver milhares de razões relacionadas a negócios para fazê-lo da maneira que você simplesmente não entende completamente. Sinta-se à vontade para reagir a eles, mas entenda que eles podem ter uma boa razão para o que fizeram.

O Agile não impede que você planeje marcos (por exemplo, lançaremos a V 1.0 em três meses), mas o que entra em cada marco não pode ser corrigido.

Eu acho que como você deve reagir depende da natureza do projeto. Se o projeto for enviar um homem para a lua até o segundo trimestre de 2017, todos concordariam que está fadado ao fracasso. Se você acha que pode entregar um MVP até o final do segundo trimestre de 2017, deve trabalhar com ele sprint a sprint.

Se a gerência achar que sua equipe está fazendo o melhor possível e você puder mostrar progresso a cada sprint, poderá negociar por mais tempo.

CADA projeto relevante para os negócios tem restrições:

• Tempo
• Recursos
• Um conjunto mínimo de recursos esperado

Isso não é mais nada. Desenvolver agilidade não significa "as pessoas nos pagam dinheiro, para que possamos desenvolver o que quisermos sempre que estiver pronto" - você sempre terá um prazo. Sempre haverá alguma data com alguns requisitos mínimos e, se não forem atendidos, o projeto será cancelado e será chamado de falha. Às vezes, eles podem estar implícitos - para que o gerente saiba "Se eu não tiver uma interface de usuário funcional com esses recursos após quatro semanas, este projeto está fadado ao fracasso" - ou pode haver acionistas que definam uma meta.

Existem muitos projetos resultantes da legislação. - Se o governo decidir que você deve implementar o recurso X até 2017 para respeitar uma nova lei, você terá um prazo inegociável e um conjunto de recursos que precisam estar prontos. A única variável é a quantidade de recursos que o gerenciamento pode alocar para a tarefa. - E nesses projetos, onde o prazo final é uma decisão externa, eles precisam acompanhar o seu progresso, ouvir seu prognóstico e formar equipes das equipes ou terceirizar parte do trabalho para atingir seus objetivos.

Tudo isso não se opõe ao desenvolvimento ágil. Você ainda terá seus sprints, desenvolverá seus recursos em seu próprio período de tempo. Você sempre obterá suas prioridades de recursos de um cliente - e trabalhará para fornecer o máximo possível desses recursos até o prazo final.

Se o prazo realmente for cumprido com os recursos disponíveis, é um problema de gerenciamento. Você pode fornecer seu prognóstico e atualizações de status semanais / diárias e eles podem decidir se precisam de mais recursos. Caso contrário, você continuará trabalhando em sprints e entregando executáveis ​​- o mesmo que em qualquer projeto.

Como alguém já apontou antes, o manifesto diz:

Indivíduos e interações ao longo do processo

Eu sugiro que você dê uma olhada no plano proposto e sugira mudanças nele. Lembre-se de que o Manifesto diz que o backlog nunca é final, continua evoluindo.

Então você pode levar suas sugestões para a equipe. Se você tiver um raciocínio válido e a equipe concordar com isso, qualquer proprietário de produto que se preze irá considerá-los e melhorar o backlog para refletir a opinião de toda a equipe.

Este é o ponto em que poderia ser de duas maneiras.

1. O proprietário e a empresa do produto concordam com o seu raciocínio e podem aumentar os recursos para cumprir o prazo, se essa for uma opção OU eles podem optar por descartar alguns recursos para cumprir o prazo.

2. Eles ainda podem querer manter sua própria versão contra a opinião coletiva da equipe.

Se o resultado for # 2, isso não será Agile.

Se você terminar com o número 1, eu diria que a equipe está no caminho certo, porque o Agile não é apenas sobre os Devs "Respondendo à mudança", mas também sobre o negócio ser capaz de responder à mudança.

Imagine pedir a alguém para pintar uma parede, uma casa e depois uma rua inteira para você, quanto tempo você daria a essa pessoa para fazer isso?

Seja qual for a sua resposta, você estará errado. É isso aí.

Não há como eles estarem certos quanto às datas se não perguntarem às pessoas que precisam fazer o trabalho o que pensam.

A propósito, se você (como equipe) aceitar essas datas, estará errado lá.

Você deve pedir algum tempo para trabalhar nesse planejamento juntamente com as partes interessadas, para poder definir prioridades, dependendo de quão fácil e rápido é fazer as coisas.

Por exemplo, talvez o trabalho final demore duas vezes o tempo que eles pensavam, mas eles poderiam usar uma versão beta muito antes do que esperavam.

Em suma, você não pode deixar que as pessoas pensem que você será capaz de fazer X no tempo Y se não puder ou puder ser mais rápido; é sua responsabilidade deixar claro o que você precisa em termos de detalhes e tempo.

Não é um planejamento nenhum.

Mas se você aprende, não conhece o plano e apenas trabalha sprint por sprint. Poderia estar funcionando de novo.

Sempre haverá datas e orçamentos. Sempre existe o risco de que eles sejam perdidos ou superados e, quando isso acontecer, você sempre terá que voltar ao plano B.

Se você trabalha de maneira ágil, o plano B é a última demonstração do sprint.