Metodologias Ágeis
Uso de Análise de Pontos de Função em Ambientes Ágeis
Este artigo apresenta as principais questões sobre a utilização de Pontos por Função em Ambientes ágeis que utilizam a técnica de Pontos por Estória (Story Points).
Para que serve:
Mostrar que mesmo tendo o propósito de ser aplicada em qualquer ambiente de desenvolvimento e independente de tecnologia, essa técnica pode não se mostrar útil em um ambiente ágil de desenvolvimento, devido a características peculiares da técnica de Análise de Pontos de Função.
Em que situação o tema é útil:
A procura pelo conhecimento e aplicação de metodologias ágeis vem aumentando. Desta forma, este artigo tem a finalidade de prover (i) um melhor entendimento de como e o que acontece quando se utiliza Análise de Pontos por Função (APF) em ambientes ágeis; e (ii) apresentar as principais divergências entre estimativas ágeis e APF.
“Há alguns anos atrás, antes de Bill Gates e seus amigos fundarem a Microsoft, em 1604 para ser preciso, William Shakespeare escreveu o livro Medida por Medida, que retratava o relacionamento entre justiça e misericórdia. O livro apresenta um conto complicado envolvendo autoridades pomposas de inflexível certeza moral, de delegação de poderes para indivíduos despreparados com identidades ocultas ou enganosas, abuso dos inocentes, virtudes corrompidas, reputações arruinadas e, claro, as sempre populares luxúrias e ganância. Agora, todos concordam que Shakespeare era um gênio, mas como ele pode descrever de forma tão precisa o ambiente moderno de desenvolvimento de software a quatrocentos anos atrás?”
[Brindley 2008]
Comumente ouvimos falar que algum projeto foi um sucesso por ter sido finalizado “quase” no prazo estipulado ou mesmo ter ultrapassado “pouco” o custo original [DeMarco 1982]. Esta visão de sucesso está ligada diretamente a uma série de fatores os quais podemos identificar e mensurar, e assim constatar o desempenho positivo ou negativo em um determinado contexto.
Na Engenharia de Software, podemos afirmar que o surgimento desta preocupação com a obtenção de bons resultados se deu a partir da conferência de Engenharia de Software da OTAN, onde se percebeu uma grande quantidade de problemas existentes no contexto do desenvolvimento do Software àquela época, utilizando-se pela primeira vez o termo Crise do Software [Bemer 1968].
Um pouco mais adiante na linha da história, foi percebida a necessidade de se estabelecer um sistema de medição para prover um mecanismo de quantificação do que acontece no processo de desenvolvimento de software. Esta necessidade foi formalizada por DeMarco [Demarco 1982] em sua famosa frase: “Não podemos controlar aquilo que não podemos medir” e até mesmo Edward Deming [Deming 1986] quando o mesmo criou o ditado: “Em Deus nós confiamos, para todo o mais, tragam-me dados”.
Assim como Shakespeare acreditava que deveria existir um balanceamento entre justiça e misericórdia, somos sabedores que projetos de TI devem buscar um equilíbrio entre diversos números observáveis, mensuráveis e sempre conflitantes motivações e influências. Mas a observação mais comum em ambientes de TI é culpar as métricas ou estremecer diante da possibilidade de ser medido, e às vezes julgados, o que não muda os resultados desastrosos que acontecem em empresas de TI [Brindley 2008].
Por exemplo, os resultados divulgados pelo Standish Group e os relatórios conhecidos como “Chaos Report” que mostraram que quase 30 anos depois da Conferência da OTAN, os resultados da indústria de software ainda não são considerados um sucesso.
A Figura 1 mostra a evolução dos indicadores de sucesso de projetos de acordo com o “Chaos Report”, onde Sucesso são aqueles projetos que foram terminados sem estouro de custo, prazo e com todos os requisitos desenvolvidos, Desafiados são aqueles onde o custo foi maior do que se previa, ou aqueles que foram entregues após o prazo, ou se entregou com menos requisitos do que o desejado, enquanto projetos cancelados (Falha) são aqueles finalizados antes da sua conclusão (abortados ou nunca utilizados).
