Pontos de história versus pontos de função, qual é a diferença e por que isso importa? Os pontos da história são indicadores arbitrários do esforço esperado. Eles são inconsistentes e inadequados para uso como métrica primária em projetos de software. Recomendamos que você mude para os pontos de função COSMIC do padrão ISO e forneça 14 razões para isso.
Pontos de história versus pontos de função, qual é a diferença e por que isso importa? Os pontos da história são indicadores arbitrários do esforço esperado. Eles são inconsistentes e inadequados para uso como métrica primária em projetos de software. Recomendamos que você mude para os pontos de função COSMIC do padrão ISO e forneça 14 razões para isso.
O que são pontos de história?
Em projetos de software Agile, um story point (SP) é a quantidade de esforço acordada pela equipe para realizar algum trabalho. As tarefas são estimadas no número de SP necessários para realizar o trabalho. Os pontos da história são uma “moeda local” arbitrária. Não existem regras rígidas e rápidas sobre o tamanho que um ponto da história deve ter. Eles nem fazem parte do Guia Scrum. A magnitude de um story point varia de equipe para equipe. Também pode variar com o tempo. Um storypoint e a estimativa do tamanho de um trabalho em SPs são apenas o “palpite coletivo” da equipe em um determinado momento usando uma métrica inconsistente. Essencialmente, os pontos da história são um proxy não confiável por horas de acordo com Mike Cohn. Para ainda mais desafios com SP, consulte Problemas com pontos da história.
De onde vieram os Story Points?
Os pontos da história foram ideia de alguns dos signatários do Manifesto Ágil. Eles são usados apenas por equipes ágeis de desenvolvimento de software. Um dos princípios fundamentais do desenvolvimento ágil de software é que as equipes se auto-organizem. Consequentemente, tornou-se prática aceite que eles também deveriam inventar os seus próprios indicadores de esforço. Os pontos da história diferem de equipe para equipe e também mudam com o tempo. Como consequência, são inconsistentes e não confiáveis para qualquer finalidade de gestão. Qualquer referência à “velocidade ágil” com base nos pontos da história entregues tem apenas um mérito modesto como indicador da taxa de progresso.
Permitir que a equipe determine sua própria métrica de tamanho/esforço tem algum valor para melhorar a coesão da equipe. Além disso, é útil ter um meio de estimar o trabalho auxiliar (tarefas que não são específicas da entrega de funcionalidade), embora também possa ser utilizada uma estimativa simples em horas.
Os problemas com os pontos da história
- Os pontos da história são inconsistente, ao longo do tempo e de equipe para equipe.
- Eles não pode ser usado como uma métrica básica em projetos
- Eles são inadequado para contratos
- Eles são geralmente inadequado para melhoria de processos
Pontos de história versus pontos de função COSMIC
| Finalidade/Benefício | Pontos de Função CÓSMICO | Pontos de história |
|---|---|---|
| Bom para estimativa de sprint | Sim | Sim |
| Bom para dimensionamento de aplicativos | Sim | Não |
| O tempo gasto dimensionando histórias de usuários melhora a qualidade | Sim | Sim |
| Consistente entre equipes | Sim | Não |
| Consistente em organizações e setores | Sim | Não |
| Adequado para contratos de desenvolvimento | Sim | Não |
| Contratos de Desenvolvimento com escopo incerto. | Sim | Não |
| Adequado para aprendizagem organizacional | Sim | Não |
| Ajuda a reduzir custos no desenvolvimento terceirizado | Sim | Não |
| Adequado para prever e gerar relatórios sobre qualidade | Sim | De alguma forma |
| Adequado para estimativa antecipada de tamanho e custo | Sim | De alguma forma |
| Bom para estimativa de projeto | Sim | De alguma forma |
| Bom para dimensionar trabalhos não funcionais | Não * | Sim |
| Bom para dimensionamento de portfólio de software e planejamento de alto nível | Sim | Não |
| O dimensionamento pode ser automatizado | Sim | Não |
| Bom para relatórios em nível de diretoria (de atividades de desenvolvimento e manutenção) | Sim | Não |
| Bom para comparar a produtividade da equipe | Sim | Não |
* Muitos requisitos não funcionais podem, na verdade, ser rearticulados como requisitos funcionais.
O fator mais significativo na determinação de um projeto de software é o tamanho do software a ser entregue. Existem muitos outros fatores significativos também. Mas o tamanho é o #1. Sem uma moeda comum para o tamanho do software, os projetos são difíceis de estimar, são ainda mais difíceis de medir e, se não for possível medi-los, são muito difíceis de gerenciar.
Inconsistente
As estimativas de pontos da história são específicas para a equipe que realiza o trabalho. Um storypoint é, na verdade, um proxy do esforço estimado para realizar algum trabalho. Normalmente há apenas uma “sensação” do tamanho. À medida que os membros da equipe vão e vêm, a opinião sobre a quantidade de esforço para realizar algum trabalho pode variar, de modo que a magnitude de um ponto da história pode mudar. Conseqüentemente, as estimativas de tamanho em pontos da história não fazem sentido para comparações com outra equipe, muito menos com outro projeto, organização ou outro setor.
Inoportuno
As equipes ágeis normalmente estimam o tamanho em pontos da história apenas algumas semanas antes de realizar o trabalho. Isso faz com que o planejamento de longo prazo do gerente de projeto trabalhe muito duro.
“O fator mais importante em um projeto de software é o tamanho do software. E a melhor maneira de medir o tamanho do software são os pontos de função COSMIC. “
As organizações precisam melhorar
É virtualmente impossível, na maioria das organizações, poder olhar para frente ou para trás em um projeto e usar pontos de história para comparação ou aprendizado sobre as características de um projeto em detrimento de outro. Os pontos da história inibem o aprendizado.
A principal métrica em um projeto de software
As principais preocupações ao gerenciar um projeto de software são: tamanho, esforço, tempo, qualidade e risco do software. As organizações precisam de métricas consistentes para tudo isso. Se você souber o tamanho, poderá determinar rapidamente as métricas apropriadas de qualidade, cronograma e recursos. O tamanho é a métrica principal. Os pontos da história combinam tamanho e esforço do software, portanto, não podem ser medidos adequadamente.
As organizações precisam de medidas indiscutíveis para estimar e aprender.
Se você puder estimar consistentemente o tamanho do software a ser entregue e tiver dados de desempenho de projetos anteriores comparáveis, poderá determinar rapidamente o esforço e o cronograma estimados e, portanto, os recursos necessários. Isso não pode ser feito com story points quando não está claro se eles medem tamanho ou esforço. O que torna o gerenciamento de projetos muito mais fácil e eficaz é ter um conjunto indiscutível de métricas com as quais trabalhar. Depender apenas dos pontos da história inibe o aprendizado e a melhoria organizacional.
Story Points são inadequados para desenvolvimento terceirizado
Os pontos da história não têm lugar em contratos de desenvolvimento terceirizados. Por exemplo, você não pode ter um contrato para entregar 100 story points, porque não há uma compreensão absoluta e consistente da magnitude de um story point. O resultado disso é que o cliente não tem visibilidade da relação custo-benefício nem forma de controlá-la.
A qualidade sofre
Os contratos ágeis tendem a ser caracterizados pela incerteza e pela falta de detalhes sobre os requisitos, antes de contratar um empreiteiro de desenvolvimento. Como resultado, a maioria dos contratos para desenvolvimento de software são essencialmente tempo e materiais baseado. Num contrato T&M é difícil negociar um preço pela funcionalidade com uma determinada qualidade e por um determinado custo. Muitos fornecedores concordarão em formar uma equipe que fornecerá qualquer funcionalidade solicitada pelo cliente. Em muitas circunstâncias que o autor viu, a organização de desenvolvimento também tem o direito de cobrar pelo esforço para corrigir bugs no software que entregou. Eles podem ganhar tanto dinheiro corrigindo seus próprios bugs quanto desenvolvendo a funcionalidade em primeiro lugar. Para resolver este problema. propomos contratos baseados em preços fixos firmes por ponto de função com restrições de qualidade baseadas em defeitos descobertos por ponto de função.
Os pontos da história podem inflar os custos
Num contrato de desenvolvimento subcontratado, verificamos frequentemente atrasos e custos excessivos causados por trabalho de má qualidade. Freqüentemente, os problemas de qualidade são causados pelo cliente que atendeu aos requisitos de baixa qualidade. Pode não ser do interesse comercial da organização de desenvolvimento desafiar a qualidade dos requisitos ou mesmo apontar os perigos de continuar. Independentemente de qual parte é a culpada pela criação do trabalho extra, é muitas vezes do interesse comercial da organização de desenvolvimento permitir que os problemas de qualidade causem o atraso e depois receber um pagamento extra para fazer o trabalho de reparação. Como isso é culpa dos pontos da história, você pergunta? Os pontos da história perpetuam a ambigüidade, e essa ambigüidade leva a contratos de T&M em vez de um contrato baseado em um preço unitário firme para a funcionalidade entregue.
“O uso apenas de Story Points em contratos terceirizados perpetua a má qualidade e custos mais elevados.”
PARE, existe uma maneira melhor, e ela sempre esteve aqui.
Pontos de função COSMIC – o melhor amigo do gerente de desenvolvimento
Poucos gerentes de software estão realmente cientes de que existem padrões universais comprovados para medir o tamanho da funcionalidade do software. A ideia de medir o tamanho funcional já existe há muito tempo. O Ponto de Função é o software equivalente à medição de peso em Quilos.
A edição mais atualizada é o COSMIC Function Point (CFP). É o refinamento moderno de uma técnica comprovada. Isso é livre (código aberto) e é baseado em princípios fundamentais de software e, portanto, é universalmente aplicável.
O processo de medição é chamado de dimensionamento funcional e é uma forma de medir o tamanho da funcionalidade do software usando uma métrica que é sempre a mesma e, portanto, comparável entre equipes, projetos, organizações e setores.
- Por que é melhor?
- Ele supera todas as limitações dos pontos da história mencionadas acima.
- É comprovado e maduro (um padrão ISO)
- Por que não ouvi falar disso antes?
- Em suma, não está na moda
- Até agora, tem sido demorado fazer o trabalho de medição.
- Devo usar o CFP e também os story points?
- Sim, você pode continuar a usar story points junto com o CFP.
- Os pontos da história estão funcionando para mim, devo mudar?
- Depende de quem você quer dizer com 'eu'. Em algumas equipes internas de software (maduras e estáveis), os story points podem funcionar muito bem para estimar histórias de usuários e sprints, e há poucos motivos para mudar no que diz respeito a uma equipe individual. Mas, por todas as razões listadas acima, as fraquezas permanecem ao nível da organização. Essas fraquezas nunca serão superadas se você continuar usando apenas os pontos da história.
“O fator mais importante em um projeto de software é o tamanho. E a melhor maneira de medir o tamanho é usando pontos de função COSMIC “
Leia mais para obter evidências adicionais do uso bem-sucedido e alta previsibilidade do CFP em projetos ágeis
Conclusão e recomendação
Recomendamos que qualquer equipe que já esteja usando story points continue a fazê-lo. Paralelamente, eles também devem medir seu software em Pontos de Função Cósmica. Limite o uso do SP ao trabalho dentro da equipe de desenvolvimento. Ao analisar estimativas, métricas contratuais, capacidade de sprint e gerenciamento de projetos, use apenas CFP. Com o tempo, você poderá descobrir que não usa mais o SP e se concentra no tamanho funcional do software entregue.
Saiba mais sobre os Pontos de Função COSMIC: toda a documentação abrangente do método COSMIC está disponível para download gratuito em www.cosmic-sizing.org. Sugerimos que você comece por lendo esta introdução ao dimensionamento COSMIC . O método de dimensionamento é baseado em princípios fundamentais de engenharia de software e é muito fácil de aprender.
Por Colin Hammond, CEO da ScopeMaster Ltd e Carlos Symons, cofundador da COSMIC
