Dimensionamento de projectos Agile

Novo post no About Agility (em Inglês), sobre como dimensionar projectos desenvolvidos com metodologias Agile (Agile Methodologies), de modo a que o cliente sinta segurança em comprar o projecto.
Para isso é essencial o seguinte:

• Completa transparência. O cliente tem de perceber que:
• quase de certeza, o resultado final do projecto não vai ser aquilo que está especificado na proposta;
• que pode haver várias features (ou mesmo módulos inteiros) que podem ter de ficar para um segundo projecto;
• mas também que os módulos que ficarem implementados vão realmente fazer aquilo que o cliente precisa, de uma forma eficiente, e com uma elevada taxa de adopção por parte dos utilizadores;
• e que a decisão final sobre a prioridade de uma feature ou módulo é sempre do cliente, e a única limitação é que a timebox seja respeitada.
• que a timebox encontrada não é o resultado de um joguinho de poker, mas sim de uma especificação de alto nível e de uma ferramenta de Sizing de projectos construida com a experiência de centenas de projectos Agile.

• Mas também tem de ser responsabilizado nestes pontos:
• especificação fornecida para a construção do Sizing, sobretudo relativamente à complexidade pretendida em cada feature (por exemplo, se diz que um form de recolha de dados terá uma página com cerca de 20 campos, e a análise detalhada após o inicio do projecto mostra que na realidade é necessário um wizzard com 3 páginas e 60 campos, tem de ter a noção que para implementar este form vai ter de abdicar de outra feature)
• disponibilidade para assistir às demos e para as reuniões de fecho de sprint e negociação do sprint seguinte, e de key users para as demos e para testarem a aplicação nos períodos de teste.

E a verdade é que funciona mesmo, como já pude comprovar nalguns projectos.