É possível adotar uma abordagem ágil e flexível para projetos que exigem estimativas de tempo gasto e tempo economizado?

Como alguém que já trabalhou efetivamente com o Agile antes, estou tentando convencer meus atuais empregadores de seus benefícios. No entanto, a administração insiste em manter a capacidade de fazer estimativas iniciais para avaliar o valor comercial dos projetos.

A maioria dos meus clientes é interna, e recentemente fui encarregado de orientar as equipes e pedir idéias sobre processos de negócios para automatizar. Eu deveria descobrir quanto tempo isso levava para eles, calcular quanto tempo a solução economizaria e estimar o tempo total de desenvolvimento. Dessa forma, os gerentes poderiam tentar medir a eficácia de uma solução em termos de tempo economizado.

No entanto, parece-me que não há como abordar esse requisito de maneira "ágil". Requisitos flexíveis significam que não apenas as estimativas do tempo gasto serão erradas, como também as estimativas do tempo potencial economizado. Expliquei isso, expliquei por que era provável que fosse problemático, mas me disseram que não era negociável.

A pergunta Como vender o desenvolvimento Agile para clientes (em cascata) tem alguns conselhos úteis sobre como "vender" o Agile para clientes externos. Não estou tentando vendê-lo para clientes externos: estou tentando descobrir como posso melhor conciliar as demandas do gerenciamento interno, mantendo uma metodologia que acredito que funcione bem.

Existe alguma maneira de abordar essa tarefa de maneira flexível que permita reter pelo menos alguns benefícios do Agile?

Como outras respostas declararam, a gerência tem todo o direito de obter uma estimativa de alto nível antecipadamente de um projeto. Eles não são irracionais por tentar determinar o ROI.

No entanto, uma das abordagens de que mais gosto no Agile é que o escopo de um projeto não é fixo. Ele pode ser dimensionado inicialmente nos níveis Épico e Épico, para que os negócios possam determinar o ROI com base nos recursos mais importantes. Talvez a interface do usuário sofisticada com sinos e assobios tenha baixo valor comercial, mas o mecanismo de fluxo de trabalho para lidar com reclamações tenha um ROI alto.

Quando você agrupa todo o projeto, fica mais difícil atender ao ROI do que se concentrar na funcionalidade crítica de negócios desejada.

Aqui está uma maneira que eu fiz isso:

Leve seus marcos da EAP e transforme cada um deles em um recurso de entrega

Isso permite que você categorize seu projeto em mini subprojetos com valor comercial variável. Cada um deles deve ser independente em termos de valor comercial.

Tamanho da camiseta o esforço nos recursos

Essa é uma maneira muito fácil de obter uma idéia aproximada do tamanho ou envolvimento de um determinado recurso. Talvez os recursos de baixo valor ainda tenham um ótimo ROI se parecerem com vitórias fáceis.

Dividir um recurso em histórias

Siga o exercício para encontrar um pequeno recurso que seja bem compreendido e divida-o em histórias inicialmente. Estime essas histórias por pontos. Agora você tem uma base onde

Pequeno -> 40 pontos

Esta será uma base de comparação com outros recursos

Associar o esforço do ponto da história a todos os recursos

Compare seu pequeno recurso com outros recursos. Por exemplo,

O Recurso Médio Y parece ter o dobro do tamanho e esforço do Recurso Pequeno X de 40 pontos na história.

O recurso médio Y tem provavelmente 80 pontos de história. Continue até que você tenha pontos de história estimados em um nível alto para todos os recursos.

Estime a velocidade da sua equipe

Olhando para sua equipe de desenvolvimento, tente determinar quantos pontos de história essa equipe poderia efetivamente entregar em um determinado sprint. Se você tem projetos anteriores do Agile como exemplo nesta equipe, esse é um ótimo lugar para começar. Se você não tem esse histórico atrás da equipe, faça um Sprint Planning falso com sua equipe, onde começa a analisar o seu recurso Small que detalhou. Que tipo de estimativas horárias as pessoas estão dando por suas tarefas nessas histórias?

Com base em quanto trabalho a equipe pensa que pode entregar em 2 semanas, use esse número total de pontos da história como a velocidade potencial média da sua equipe!

Encontre sua data de conclusão projetada

Se sua equipe no planejamento simulado de sprint se sentir confortável fornecendo 25 pontos de história em um sprint, e seu total de pedidos em atraso parecer 300 pontos para a versão dourada do Cadillac do seu projeto, parece que sua equipe idealmente levaria 12 sprints ou 24 semanas para complete tudo.

Agora, é trivial transformar o custo dos recursos da sua equipe em dólares por semana, a fim de obter um custo por ROI versus valor comercial. A negociação pode continuar sobre quais são os recursos mais importantes e, em seguida, seu gerenciamento de projetos se torna basicamente um Problema de Mochila.

Este não é um problema com "gerenciamento". É um requisito absoluto ser capaz de estimar o custo e o benefício de qualquer projeto em potencial antes de iniciar. Caso contrário, como alguém saberia o que vale a pena fazer (ou tentar)?

Então por que Agile?

Eu argumentaria que usar métodos ágeis não é escolher incerteza. Em vez disso, o Agile é um argumento de que a incerteza é inevitável, e as especificações e estimativas detalhadas dos métodos tradicionais introduzem uma falsa certeza - o que pode ser bastante caro.

Alguns pontos-chave em termos de estimativa de tempo:

• Mudanças nos requisitos ao longo de um projeto são inevitáveis; O Agile leva isso em consideração, em vez de fingir que não haverá mudanças.
• As especificações detalhadas geralmente contêm falhas de design que não são descobertas até o início do projeto. Isso pode significar mudanças maiores em um projeto tradicional do que em um projeto ágil.
• Uma estimativa de tempo com base em "quão grande de uma coisa eu acho que todo esse projeto é?" provavelmente será tão preciso quanto somar o tempo estimado para muitos requisitos detalhados.
• O principal que leva a boas estimativas é um ciclo de estimativa, medição e revisão - que pode ser aplicado a qualquer processo consistente.
• A estimativa de "trabalho salvo" será orientada pelos requisitos principais do projeto e não pelos detalhes, por isso duvido que o Agile prejudique muito a capacidade de estimar isso.

Atualizar:

Apenas para esclarecer, sua resposta aos seus chefes parece ser "Não podemos estimar muito bem o tempo economizado ou o esforço total de desenvolvimento usando o Agile, porque é flexível". Eu acho que isso está errado. Acredito que essas estimativas também podem ser feitas ao usar um processo Agile, pois a incerteza existe. E é claro que o Agile permite um processo mais flexível e responsivo à medida que o projeto se desenrola.

Esta é certamente uma das partes mais difíceis da introdução do Agile

"A administração ainda precisa de estimativas de tempo"

Minha abordagem é:

• Almofada 300%. O velho ditado de 300% é útil quando você está em uma situação em que ser realmente ágil no nível de gerenciamento não vai acontecer. Esta não é uma "abordagem ágil", talvez, mas é um compromisso para esta situação. Você poderá chegar à frente algumas vezes - mas não conte com isso!

• Peça uma revisão com base no trabalho realizado no que seria o ponto "intermediário" do projeto. Projete quando você seria concluído com base no trabalho realizado. Em seguida, converse com a gerência e analise quais serão sacrificadas - funcionalidade ou qualidade - dado que o tempo é fixo com base em suposições no início do projeto.

• Verifique se você está colaborando com os recursos concluídos e com a qualidade da gerência para que eles tomem essas decisões

• Siga o fluxo desse projeto e permita que as coisas comuns aconteçam - prazos perdidos, qualidade comprometida, funcionários esgotados e estressados ​​(e possivelmente afastados) que saem. Quando o próximo projeto de fase surgir, discuta esses 'efeitos colaterais'.

• Concentre-se e demonstre as vantagens de uma abordagem ágil "verdadeira". Fale sobre a melhoria da qualidade. Fale sobre a capacidade de fazer alterações no final do dia, antes e depois da entrada em produção. Falou sobre menos necessidade de retrabalho. Fale sobre uma dívida menos técnica que acabará por levar o desenvolvimento a um rastreamento. Faça analogias com o mundo real, por exemplo, podemos adiar uma troca de óleo a qualquer dia, mas adiar por tempo suficiente e o motor sofrer, apresentar um desempenho ruim e eventualmente explodir uma haste.

• Mantenha seu currículo e o perfil LinkedIn atualizados. Se você não conseguir suporte gerencial depois de defender seu caso algumas vezes, siga em frente. Algumas organizações não serão listadas nos seus argumentos, então mude para as que o fazem. Chamado de emprego darwinismo;)

Eu acho que você está fazendo suposições falsas sobre o desenvolvimento Agile. Requisitos de flexibilidade e mudança são literalmente incorporados ao Manifesto Ágil .

Bem-vindo, alterando os requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.

Requisitos flexíveis (leitura: alteração) são bem-vindos no Agile. É verdade que, se você perguntar à maioria dos desenvolvedores, eles acrescentarão uma ressalva de que a alteração deve ser razoável. Pedir a uma equipe que construa um jogo em 3D e depois mudar os requisitos para "sistema de controle de um reator nuclear" é um pouco demais. Mas adicionar, remover ou modificar requisitos no escopo do projeto é perfeitamente adequado.

A questão é como você lida com as mudanças nos requisitos? A resposta típica é usar iterações curtas para que você possa fazer ajustes no curso antes de perder muito tempo. Isso também força a equipe a decompor os requisitos em pedaços menores, para que todos possam entendê-los melhor e implementá-los em uma quantidade razoável de tempo e esforço.

A simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial.

Eu também gosto deste princípio ágil. Normalmente, isso significa que uma equipe deve se esforçar para entregar apenas as coisas necessárias por meio de uma implacável eficiência. Por exemplo: se o cliente acha que precisa de algo, mas parece suspeito, procure um pouco. Talvez os usuários finais realmente não tenham utilidade para isso, portanto o trabalho não deve ser feito.

No entanto, acho que sua pergunta atingiu outro aspecto desse princípio. O software geralmente serve ao objetivo de automatizar um processo manual. O próprio software existe para maximizar a quantidade de trabalho não realizado - pelos usuários finais.

Medir a quantidade de trabalho que o software salvará os usuários finais é definitivamente uma métrica digna. Eu mesmo medi isso em minha carreira. Na verdade, é um componente crítico de uma análise de custo / benefício: quanto esforço o projeto de software levará para implementar, comparado com quanto esforço o produto final salvará os usuários finais.

Isso é absolutamente compatível com a filosofia de desenvolvimento Ágil (ou qualquer outra) e seu gerenciamento absolutamente deve comprar isso.

Sim, a agilidade tem algumas vantagens.

• Ele permite que as pessoas de negócios mudem de idéia no meio do voo.
• Isso meio que protege os negócios contra as estimativas perpetuamente ruins do engenheiro.
• Entrega valor cedo e frequentemente, antes que a visão final seja alcançada.
• Isso poupa alguns dos custos iniciais de planejamento, que geralmente podem gerar um plano ruim de qualquer maneira .
• É super legal. Direita?

Mas você ainda precisa fornecer estimativas iniciais razoavelmente precisas.

Caso contrário, você está efetivamente pedindo à empresa que invista em seu produto sem nenhuma evidência de que seu produto vale o investimento inicial - e, em alguns casos, qualquer coisa.

E eu posso ouvir isso agora.

Eu já ouvi isso antes. Tenho certeza de que já disse isso antes:

Oh - mas Haow !? HAOW faz um mero homem mortal como eu olhar meus olhos para o destino de tais coisas! Coisas que somente os deuses podem adivinhar e dirigir. Coisas que os homens mortais só podem sonhar nos mais profundos sonhos e esquecer ao acordar do dia! Oh tipos gerenciais tirânicos, HAOW tais demandas podem ser atendidas !?

Use seu desempenho passado como um guia e seja honesto .

• Converse bastante com a parte interessada e / ou o usuário final para determinar a complexidade do produto e / ou seus principais componentes em relação a outros componentes principais nos quais você trabalhou. Faça uma estimativa inicial pontual relativa.
• Aumente esse número pela quantidade histórica de alterações de escopo e falhas de erros que você já viu historicamente.
• Aplique sua velocidade histórica à estimativa pontual para chegar a uma linha do tempo aproximada. E, aplique um cone razoável de incerteza .
• Reveja sua estimativa e compreensão do projeto. Esteja certo de que você estaria disposto a tomar uma decisão sobre o enfrentamento de um projeto com base em sua avaliação.

Por fim, apresente seu cone de incerteza às partes interessadas, exponha suas suposições e preocupações e deixe por isso mesmo.

Como um aparte, eu também sugeriria uma heurística de estimativa pontual objetiva para verificar a sanidade de você e / ou as estimativas normais da sua equipe.

Você pode usar essa estimativa como uma enésima votação durante o planejamento do pôquer, ou na validação de sua estimativa privada, se estiver indo sozinho. Por exemplo, minha equipe tende a estimar cerca de 1 ponto por minuto de discussão de descoberta pouco técnica sobre uma história. Isso é especialmente útil se o seu intestino lhe contar que a história é de 5 pontos, mas você levou 20 minutos para entender o que precisa ser feito - geralmente é um bom indicador de que ainda existem complexidades e mal-entendidos à espreita.

Nunca trabalhei em nenhuma empresa capaz de ter consistentemente boas estimativas de tempo, nem trabalhei com alguém que afirma ter feito isso também. A pesquisa mostrará que a estimativa é um problema não resolvido em todo o setor.

Eu tentava me convencer a medir a velocidade com base em pontos abstratos da história, e se você não puder fazer isso, melhoraria suas estimativas.

O Agile é uma ótima solução para toda uma gama de problemas, mas apesar do que alguns evangélicos sugerem, não é a única solução e nem sempre é a solução certa.

Seu caso declarado simplesmente não é um problema ágil:

Recentemente, fui encarregado de rodar equipes e pedir idéias sobre processos de negócios para automatizar. Eu deveria descobrir quanto tempo isso levava para eles, calcular quanto tempo a solução economizaria e estimar o tempo total de desenvolvimento. Dessa forma, os gerentes poderiam tentar medir a eficácia de uma solução em termos de tempo economizado.

Você tem a tarefa de determinar o custo e o benefício da automação de alguns processos de negócios, que não é uma tarefa ágil sujeita a alterações, é um problema específico com solução específica. Você produzirá uma lista com um número arbitrário de processos de negócios e, para cada um, haverá um custo estimado de automação, um custo estimado de não automação e um benefício estimado de automação. A gerência comparará isso com seus orçamentos, recursos, requisitos e metas estratégicas e determinará qual (se houver) desses processos para automatizar. Se você é consciente, destacará as tarefas selecionadas que têm potencialmente menor ROI, mas que reduzirão o custo de outras fases, melhorando o ROI total. Você também pode ter identificado maneiras diferentes de obter a automação, incluindo desenvolvimento sob medida interno e externo (usando técnicas ágeis e / ou em cascata), comprando soluções prontas para uso, usando provedores de serviços terceirizados e assim por diante. Todo esse processo estava muito na moda nos anos 90, quando era conhecido como reengenharia de processos de negócios.