A performance de um time muito comumente avaliada pelo gráfico de “Velocity” é um instrumento valioso tanto para o time de desenvolvimento quanto para os patrocinadores do projeto já que reproduz com fidelidade a performance do time e a sua evolução.
Em situações normais é esperado – e acontece – que a performance do time aumente à medida que o projeto se desenrola já que o grau de incerteza das tarefas diminui , a maturidade do time sobre o domínio do projeto aumenta, a interação e colaboração se afina e etc.
No entanto, é desaconselhável – pra não dizer errado – que a performance do time seja prevista baseado em fatores externos ao projeto corrente como, histórico de outros projetos, experiência individual de cada membro do time e etc. já que “cada caso é um caso”. Um único projeto já possui em sua essência variáveis suficientes para tornar o seu futuro imprevisível, quem dirá então quando envolvidos outros projetos para comparação.
O passado é o real que já foi. E que já não é mais. E, portanto, não é.
Clóvis de barros em ePAMINONDAS: o gATO EXPLICADOR
Entenda, cada projeto tem um grau de ânimo dos patrocinadores, orçamento e flexibilidade deste, experiências e expectativas do time, fatores geográficos, climáticos, psicológicos, políticos e tantos outros que não permitem que dois projetos por mais semelhantes que sejam, tenham equivalência total. É imperativo que cada projeto precisa ser analisado e avaliado como único e inédito. Ponto.
O tempo é finito. Trate-o como tal. Divida seu trabalho em partes que possam ser realizadas em um intervalo de tempo curto, regular e definido – de preferência, entre uma e quatro semanas. Se você tiver sido contaminado pelo Scrum, chame esses períodos de sprints.
jEFF sUTHERLAND em Scrum: A arte de fazer o dobro do trabalho na metade do tempo
Não pretendo falar sobre todo o potencial do acompanhamento (realista) da velocity do time neste artigo. O meu desejo aqui é alertar para a única forma confiável que existe para predizer se para futuras sprints a performance tende a aumentar ou não. E esta forma é olhando pra trás.
Claro que eu não inventei isso mas me inspirei no que Jeff Sutherland e seu filho escreveram. Eu verifiquei isso ao longo de minhas experiências profissionais tanto como desenvolvedor quanto como gerente.
O mapa não é o terreno! Você já ouviu isso e se trabalha com desenvolvimento de software sabe que isso é verdade sempre. O planejado e o realizado podem ser bem diferentes um do outro, portanto, confie no terreno, não no mapa. Aceite e interaja com o que é realidade do projeto não com o que foi pensado e definido para o projeto.
As restrições de WIP identificam gargalos e áreas problemáticas no processo, auxiliando o time a tomar decisões para resolvê-las.
Mary provinciatto e paulo caroli em Sprint a Sprint erros e acertos na transformação cultural de um time ágil
Trabalhe com o Work in Progress (WIP) possível e incremente-o sempre que o time for capaz. Gerar um WIP maior do que o time tem historicamente praticado e maior que a capacidade percebida do time só vai aumentar a pressão e consequentemente o número de erros, bugs, refatorações e o desgaste de cada um dos envolvidos e entre eles.
Por este motivo olhar para trás, acompanhar o ramp-up do time, a evolução natural que o terreno permite e definir um crescimento racional e alcançável além de criar uma expectativa realista para os patrocinadores sobre o futuro do projeto, aumenta o engajamento do time, cria a – deliciosa – sensação de obtenção de resultados, torna o time ainda mais disposto a obter melhores resultados e melhora o gerenciamento.
Velocity aumenta e diminui. Cada sprint é uma sprint. Acompanhe cada realidade individualmente e aprenda junto com o seu time o que o projeto permite. Um time engajado vai sempre entregar o melhor possível, sempre! Acredite no time e resolva os impedimentos, a performance é consequência.