Este artigo não trata como as coisas devem ser feitas quando você já é ágil, mas como você pode ter que operar até que os parceiros de negócios e gerentes tenham obtido uma mentalidade ágil, ou seja, já realizado a transição do modelo cascata para o modelo ágil.
Assim, se empresa está mudando para o modelo ágil ou sua equipe ou programa diz que eles estão agilizando, mas o gerenciamento não é tão ágil e a realidade organizacional exige uma “data fixa” para a entrega.
O que fazer?
Datas fixas no modelo ágil
As datas fixas são causadas por vários motivos, incluindo necessidades comerciais e conformidade regulamentares.
Em agile, datas fixas são definidas por time-boxes na forma de sprints e incrementos de programa e marcos são simplesmente eventos onde o que é “feito” é entregue.
Em ágil, nós “flutuamos o escopo” em vez de ter um escopo fixo, mas para alguns uma data fixa muitas vezes implica um escopo fixo.
Quando uma data fixa com um escopo fixo implícito para entrega aumenta, as seguintes 3 perguntas podem ser feitas:
- Questão de Previsibilidade: O que pode ser feito até a data fixa?
- Pergunta do custo do atraso: Qual é o Custo de Atraso (CoD) associado a cada recurso ou parte do recurso (por exemplo, critérios de aceitação, história do usuário) se não for entregue na data fixa?
- Pergunta de Planejamento e Orçamento de Pessoas: Se mais equipes forem adicionadas à iniciativa, qual será o impacto no escopo sendo entregue na data fixa?
Questão de previsibilidade
Previsibilidade do futuro é mais fácil dizer do que fazer. O desenvolvimento de software é feito em um ambiente adaptativo complexo não diferente do clima ou da política.
Às vezes, podemos ver tendências que nos levam a dar previsões, projeções, estimativas ou palpites.
No entanto, estes nunca devem ser dados como compromissos e aqueles que recebem essas informações nunca devem considerá-los como tal.
A comunicação excessiva deste ponto deve ser uma preocupação primária daqueles que fornecem as estimativas.
Então, o primeiro passo é descobrir o que “pode” ser feito com a(s) equipe(s) já instalada(s), conforme descrito no gráfico abaixo:
Possíveis problemas além do modelo ágil
Nessas situações também podemos nos deparar com vários outros problemas:
- A falta de uma compreensão clara de por que o épico ou recurso está sendo construído/necessário;
- Épicos e características sem critérios de aceitação claros e como validar a definição de “pronto”;
- Épicos não decompostos corretamente em históricas;
- Recursos não decompostos corretamente em histórias de usuários;
- Em consequência do item acima, é improvável que a estimativa seja correta;
- Pode não haver tempo suficiente para realizar as estimativas, mas a gerência quer uma resposta para o que pode ser feito até a data de vencimento;
- A estimativa é considerada um compromisso da administração / partes interessadas, não como uma estimativa;
- A equipe(s) pode não ter um histórico de velocidade e não haver tempo para a equipe(s) para decompor as características em histórias de usuários evitando que o método de ponto-história normalizada tradicionalmente utilizado para descobrir a capacidade de uma nova equipa e o roteiro do produto.
Quando tudo isso ocorre, sem tempo para se decompor até as histórias dos usuários, o melhor que podemos fazer é fornecer uma estimativa inicial dividindo épicos em recursos.
Custo de atraso
Uma vez que um épico tenha sido decomposto em histórias com critérios de aceitação, podemos perguntar qual pode ser o custo do atraso para cada recurso individual e / ou critérios de aceitação específicos em um recurso.
Descobrir o WSJF (Weighted Shortest Job First) para os recursos individuais pode ser uma boa maneira de começar, mas esse tempo de descoberta pode não ser permitido (como a organização pode não ter uma mentalidade ágil ainda) para passar por este exercício.
No entanto, apenas questionando sobre qual pode ser o custo do atraso para cada recurso e / ou critérios de aceitação específicos em um recurso, pode-se realizar uma breve conversa sobre como diferenciar requisitos, priorizar ou até mesmo se decompor mais.
Planejamento e orçamento
Quando há uma data e um escopo fixos, uma preocupação da administração é se há equipes suficientes trabalhando na iniciativa para atender a essa data e escopo e quanto isso vai custar.
Se inclinarmos a lista de recursos por meio da colaboração adequada com os negócios, o escopo se tornará menor e, espera-se o mesmo menos complexo.
Quando tivermos uma lista de recursos inclinados, precisamos dimensioná-los. Quem é disponibilizado para dimensionar os recursos também pode ser limitado a um pequeno grupo de arquitetos.
Se 1 ou 2 arquitetos estiverem dimensionando esses recursos juntos, o método binário ou o método do elefante branco de duas pessoas pode ser aplicado para que isso seja feito rapidamente.
Quando tivermos recursos de tamanho relativamente pequeno, médio, grande e extra grande, devemos considerar a decomposição (se o tempo e o ambiente permitirem) dos recursos de tamanho grande e extra grande em recursos de tamanho pequeno e médio.
Depois que isso for feito, os arquitetos poderão escolher o menor recurso, considerar quantas pessoas-dia ou pessoas-horas o recurso pode levar para desenvolver e testar e dimensionar relativamente o restante dos recursos para esse menor recurso.
Resultado
O descrito acima não é a história tradicional que aponta o exercício de dimensionamento relativo que os programas ágeis e as equipes usam.
É utilizado quando o Modelo Ágil ainda não chegou à gerência e o ambiente não permite o método tradicional que permite o refinamento e a decomposição adequada do programa e do produto, planejamento, liberação ou planejamento de PI e planejamento de Sprint.
No entanto, e sei que isso parece atrasado, uma vez que fizemos o acima, podemos fazer o planejamento de capacidade tradicional e converter o tempo / dias em pontos de história.
Ao fazer isso, podemos fornecer uma estimativa de nível de recurso que nos permita planejar o que pode ser feito no tempo alocado e ajudar a gerência a decidir se equipes adicionais são necessárias ou garantidas para cumprir os requisitos (fixos ou inclinados) pela equipe.
Próximos passos
A falta de planejamento adequado visando a transição para o Modelo Ágil deriva de várias fontes.
No entanto, gostaria de chamar a atenção dos meus leitores para a Primeira Diretriz de Retrospectivas, para ter uma visão dos possíveis próximos passos:
Independentemente do que descobrimos, entendemos e acreditamos realmente que todos fizeram o melhor trabalho possível, considerando o que sabiam na época, suas habilidades e habilidades, os recursos disponíveis e a situação em questão.
Portanto, aprimorar habilidades e habilidades da administração parece ser um bom próximo passo na solução dos problemas subjacentes, inibindo a mudança para a verdadeira agilidade.
