Idealmente, uma funcionalidade deve obedecer aos seguintes critérios.
- Deve fornecer valor comercial.
- Deveria ser estimável – Deve ter detalhes suficientes para que a equipe de desenvolvimento possa fornecer uma estimativa do trabalho envolvido em sua implementação.
- Deveria ser pequeno o suficiente para caber em uma iteração – portanto, se for muito grande, deve ser dividido em partes menores.
- Deveria ser testável – Você deve entender quais testes automatizados ou manuais um recurso deve passar para ser aceitável para o cliente.
As diferentes metodologias utilizam terminologias distintas para se referir às funcionalidades. Cabe à equipe decidir qual metodologia ou terminologia utilizar. A Programação Extrema (XP) usa os termos "histórias de usuário" ou "histórias" para representar funcionalidades; o Scrum usa "backlog do produto" para descrever uma lista de funcionalidades; o Desenvolvimento Orientado a Funcionalidades (FDD) usa "funcionalidade"; e o DSDM usa "requisito". Da mesma forma, existem diversas versões simplificadas do Processo Unificado (UP) ágil, que utilizam "requisito" e/ou "caso de uso" para definir funcionalidades entregáveis incrementalmente. Em última análise, o objetivo é o mesmo: entregar valor de negócio regularmente em pequenos incrementos, e o mais breve possível.
Diferenças metodológicas
Scrum chama um recurso de item em atraso, que tende a ser mais abrangente e também pode incluir itens não relacionados a funcionalidades, como "configurar hardware de produção" ou "pesquisar opções xyz".
XP chama um recurso de história, o que se presta a uma abordagem particularmente útil para definir a funcionalidade.
DSDM chama um recurso de requerimento, que também pode incluir mais do que apenas recursos do sistema.
Agile UP os profissionais usam os requisitos e casos de uso definir características.
Estrutura de decomposição de recursos (FBS)
Durante o planejamento detalhado, desenvolvimento ágil A abordagem de estrutura de decomposição de funcionalidades (FBS, na sigla em inglês) é favorecida em vez da estrutura de decomposição do trabalho (WBS, na sigla em inglês) usada em abordagens de desenvolvimento em cascata. As estruturas de decomposição de funcionalidades são vantajosas por alguns motivos:
- Elas permitem a comunicação entre o cliente e a equipe de desenvolvimento em termos que ambos possam entender.
- Elas permitem que o cliente priorize o trabalho da equipe com base no valor para o negócio.
- Elas permitem o acompanhamento do trabalho em relação ao valor real gerado para o negócio.
É aceitável começar com funcionalidades amplas e depois dividi-las em funcionalidades menores ao longo do tempo. Isso permite que o cliente evite se aprofundar em muitos detalhes até que eles sejam necessários para facilitar o projeto e a entrega.
Construindo uma lista inicial de funcionalidades
Antes do planejamento do lançamento e planejamento de iteraçãoA equipe precisa elaborar rapidamente uma lista com o máximo de funcionalidades potenciais para o sistema. Normalmente, há uma única pessoa responsável por coletar as funcionalidades (por exemplo, um gerente de produto, um cliente, um gerente de programa, um analista de negócios ou algum outro representante do cliente), mas as solicitações de funcionalidades podem vir de diversas fontes. Usuários, clientes, vendas, marketing, solicitações de propostas (RFPs), membros da equipe de desenvolvimento, gerência, concorrentes e regulamentações governamentais podem ser fontes de funcionalidades. A lista central de funcionalidades da equipe deve ter alguns controles para evitar itens duplicados, funcionalidades impossíveis e solicitações muito vagas. A equipe deve ser incentivada, no entanto, a adicionar novas funcionalidades à medida que as identificar, para que possam ser incorporadas ao processo de priorização e planejamento.
Uma lista inicial de funcionalidades pode ser um esboço, um superconjunto, a ser usado como base para o planejamento do lançamento e da primeira iteração. Ela representa o potencial atual do que o sistema pode se tornar, talvez ao longo de várias versões. Você não precisa esperar até que todas as funcionalidades estejam definidas para começar. entrega de softwareE você não precisa se apegar cegamente à lista original, às descrições originais ou às prioridades originais. Um dos principais pontos do desenvolvimento ágil é que essa lista (como tudo o mais) evolui, iteração após iteração.
Vamos supor que uma lista preliminar de funcionalidades esteja concluída, um plano de lançamento e um plano de iteração estejam elaborados e a primeira iteração esteja finalizada, antes mesmo da identificação de algumas funcionalidades críticas. Essas funcionalidades são simplesmente incorporadas ao plano de lançamento em desenvolvimento e a uma iteração posterior, sendo entregues o mais rápido possível. Enquanto isso, o tempo não é desperdiçado. A equipe começa a entregar valor o quanto antes e cria a infraestrutura necessária para que o projeto se adapte ao longo do tempo a novas prioridades, informações e dinâmicas de negócios.
Lista de recursos
Ao elaborar uma lista de funcionalidades, elas são inicialmente descritas em um breve parágrafo, geralmente de 2 a 4 frases. Essa descrição representa um resumo geral da funcionalidade, um ponto de partida para o entendimento inicial e uma base para comunicações futuras. É como um título para um artigo que será escrito posteriormente. O objetivo é dedicar tempo suficiente à descrição da funcionalidade para que se tenha uma noção razoável de seu tamanho, complexidade e prioridade em relação às demais. Mais detalhes surgirão durante o desenvolvimento. planejamento de iteraçãoMas a compreensão precisa e concreta da funcionalidade pode surgir durante a iteração, à medida que clientes e desenvolvedores a discutem o suficiente para implementá-la ou (em algumas metodologias) para criar testes de aceitação automatizados que a especifiquem deterministicamente.
Referências úteis
Histórias de usuários
Histórias de usuários aplicadas: para desenvolvimento ágil de software Por Mike Cohn
Webinar
Como executar o planejamento de PI com Digital.ai Agility
Recursos de organização
Gerenciar uma longa lista de funcionalidades pode ser difícil. É muito útil organizá-las especificando categorias, agrupamentos funcionais de alto nível, valor ou prioridade para o negócio e risco. Filtrar e classificar por esses atributos pode ajudar a dividir uma lista extensa de funcionalidades em partes gerenciáveis.
A lista completa de funcionalidades deve ser classificada em uma sequência contínua para facilitar a visualização, por parte da equipe do projeto, das funcionalidades mais valiosas. Se um projeto começa com 100 funcionalidades na lista, é comum que 50 delas se enquadrem na categoria de alta prioridade. Uma classificação sequencial das funcionalidades ajuda a identificar aquelas que são as mais importantes, e, portanto, devem ser implementadas primeiro para maximizar o valor entregue.
Contabilização de riscos
Deve-se levar em consideração os riscos associados a certas funcionalidades. Algumas funcionalidades envolvem designs, arquiteturas, frameworks ou algoritmos novos para a equipe, ou que apresentam riscos de alguma outra forma. Mesmo que essas funcionalidades não agreguem o maior valor ao negócio, muitas vezes faz sentido priorizar sua implementação o suficiente para abordá-las nas primeiras iterações. Se uma funcionalidade de alto risco for abordada no início do projeto e, por algum motivo, se mostrar inviável, a equipe ainda terá tempo para reagir e encontrar uma solução alternativa. Isso minimiza o risco geral para o projeto. Cabe à equipe de desenvolvimento trabalhar em estreita colaboração com o cliente para ajudar a identificar esses tipos de problemas, riscos e dependências. Em última análise, cabe ao cliente priorizar as funcionalidades, mas esse processo crítico não deve ocorrer isoladamente. As melhores equipes trabalham juntas para entregar valor e reduzir riscos ao longo de todo o ciclo de vida do projeto.
Características de estimativa
Após identificar as funcionalidades, o cliente geralmente trabalha com as principais partes interessadas no desenvolvimento para definir as estimativas de funcionalidades. As estimativas de funcionalidades são estimativas preliminares de alto nível que servem de guia para o desenvolvimento. planejamento de liberação e planejamento de iteração. As partes interessadas envolvidas na estimativa podem incluir arquitetos, líderes técnicos, desenvolvedores, testadores, redatores e gerentes. Muitas organizações estabeleceram processos nos quais os grupos trabalham juntos para fornecer rapidamente estimativas iniciais. Essa etapa pode ser útil para determinar inicialmente se o recurso deve ser dividido em mais detalhes.
Ao estimar funcionalidades inicialmente, o objetivo é chegar rapidamente a uma estimativa geral razoável. Em vez de se concentrar em saber se uma funcionalidade exigirá exatamente 17.5 horas de ideias (ou ursinhos de goma, ou nozes, ou qualquer outra unidade que esteja sendo usada; veja abaixo), o objetivo é chegar a uma estimativa razoavelmente próxima em uma fração do tempo. Se leva dois minutos para concordar que a funcionalidade levará de dois a três dias ideais para ser implementada, em vez de 30 minutos para estabelecer uma estimativa precisa de 17.5 horas de ideias, a primeira abordagem é preferível. Para estabelecer uma estimativa única quando as opiniões no grupo divergem, as equipes podem calcular uma média, desenvolver uma aproximação razoável, sempre usar o melhor cenário possível ou, potencialmente, usar um cálculo que envolva o melhor cenário, o pior cenário e a estimativa esperada, se uma maior complexidade for apropriada. Em qualquer caso, as discussões sobre estimativas diferentes geralmente fornecem conhecimento útil.
Inicialmente, o processo de definição e estimativa de funcionalidades pode parecer difícil. Quando as equipes o implementam pela primeira vez, podem precisar de várias reuniões para se familiarizarem com um processo que funcione bem para elas. Com o tempo, torna-se mais fácil dividir as funcionalidades em unidades de trabalho que podem ser entregues em uma única iteração. As equipes se tornam muito boas naquilo que praticam, e o desenvolvimento ágil permite que elas pratiquem a estimativa a cada versão e iteração.
Unidades de estimativa
As estimativas, por sua própria natureza, são imprecisas, e historicamente os desenvolvedores têm dificuldade em produzir estimativas úteis de todo o tempo necessário para concluir uma tarefa de desenvolvimento. As estimativas do tempo real de programação são frequentemente imprecisas (especialmente se não forem rigorosamente comparadas a números reais). Mas o tempo não relacionado à programação é ainda mais difícil de precisar. O que você diria se alguém lhe perguntasse quanto tempo leva para atravessar a cidade de carro? Você usaria uma medida relativa. "Uma hora fora do horário de pico, com bom tempo e sem obras; caso contrário, talvez duas horas", etc. Esses fatores externos são impossíveis de controlar e difíceis de prever. Além de desenvolver código, os programadores dedicam tempo a testes, escrita de documentação, design, participação em reuniões e revisões, verificação de e-mails e assim por diante. Comparado ao trabalho de programação, o trabalho não relacionado à programação é difícil de prever ou controlar. Ele pode variar de acordo com o setor, a organização, a época do ano e qualquer tipo de pressão externa que a organização sofra.
Algumas equipes pedem aos programadores que incluam cada atividade não relacionada à programação em suas estimativas. Mas, como já dissemos, isso não é fácil. Em um projeto ágil específico, muito antes de a equipe ter uma medida precisa do tempo gasto em atividades não relacionadas à programação, ela já sabe o trabalho relativo necessário para concluir diferentes funcionalidades e pode planejar de acordo. É por isso que é mais comum equipes Agile concentrarem suas estimativas no que pode ser estimado e medido com mais facilidade: a programação em si. Elas se concentram em quanto trabalho cada funcionalidade e cada tarefa técnica exigirá, em comparação com outras funcionalidades e tarefas técnicas. Elas permitem que a quantidade de tempo consumida por essas atividades não relacionadas à programação fique clara à medida que a velocidade real emerge após algumas iterações. Existem duas unidades principais de estimativa que as equipes Agile usam para concentrar o foco na programação dessa maneira:
- unidades de trabalho
- Horário ideal
unidades de trabalho
Uma unidade de trabalho é uma medida relativa que esperamos não ser confundida com o tempo real. Alguns exemplos dessas unidades são:
- Pontos
- Ursinhos de goma
- Libras-pé
- NUTs (Unidades Nebulosas de Tempo)
Esses valores representam a quantidade relativa de trabalho necessária para implementar uma funcionalidade (ou tarefa), em comparação com outras funcionalidades (ou tarefas). Somente depois que a equipe atinge uma velocidade consistente, geralmente após algumas iterações, é que ela pode começar a mapear essas unidades de trabalho para unidades de tempo real. Esse é exatamente o objetivo da velocidade: descrever quanto trabalho a equipe consegue realizar por unidade de tempo real.
Uma vez que a equipe ou organização tenha concordado com uma unidade de estimativa, todos devem se comprometer a implementá-la de forma consistente e a manter sua definição original. Principalmente nas primeiras iterações do projeto, todos devem resistir à tentação de tentar mapear essas unidades para unidades de tempo com qualquer precisão exata.
Horário ideal
Assim como as unidades de trabalho, o tempo ideal exclui o tempo não relacionado à programação. Quando uma equipe usa o tempo ideal para estimar, ela está se referindo explicitamente apenas ao tempo de programação necessário para concluir uma funcionalidade ou tarefa, em comparação com outras funcionalidades ou tarefas. Novamente, durante as primeiras iterações, o histórico de estimativas se acumula, uma velocidade real emerge e o tempo ideal pode ser mapeado para o tempo real decorrido.
Muitas equipes que utilizam o tempo ideal constataram que seu esforço final excede as estimativas iniciais dos programadores em 1 a 2 vezes, e que essa diferença se estabiliza, dentro de uma faixa aceitável, ao longo de algumas iterações. A proporção pode variar de tarefa para tarefa, mas, ao longo de uma iteração completa, as proporções desenvolvidas pelas equipes têm se mostrado bastante consistentes. Para uma determinada equipe, um histórico conhecido da proporção entre tempo ideal e tempo real pode ser especialmente valioso no planejamento de lançamentos. Uma equipe pode analisar rapidamente a funcionalidade necessária e fornecer uma estimativa geral de 200 dias ideais. Se o histórico da equipe for de aproximadamente 2.5 dias ideais, ela pode se sentir bastante confiante em apresentar uma estimativa de 500 dias de projeto. Em cenários de preço fixo, esse tipo de estimativa pode ser confiável.
Estimativa relativa
Muitas equipes Agile utilizam a prática de estimativa relativa para funcionalidades. Em vez de estimar funcionalidades em um espectro de comprimentos unitários, elas selecionam algumas (de três a cinco) categorias de estimativa relativa, ou grupos, e estimam todas as funcionalidades em termos dessas categorias.
Planejamento de funcionalidades versus planejamento de tarefas
Embora a ênfase nesta fase inicial do planejamento seja na velocidade e no trabalho relativo por funcionalidade, em algum momento as funcionalidades precisam ser decompostas em suas respectivas tarefas e estimadas com mais precisão. Isso ocorre durante o planejamento de releases e o planejamento de iterações. Em geral, as estimativas de funcionalidades e as estimativas de tarefas têm propósitos diferentes:
- As estimativas de funcionalidades ajudam a orientar o planejamento em diferentes versões e iterações.
- As estimativas de tarefas ajudam a direcionar a alocação de recursos dentro de uma iteração.
Como servem a propósitos diferentes, a estimativa de uma característica não precisa coincidir precisamente com a soma das estimativas de suas respectivas tarefas. No entanto, em uma gama de características, deve haver pelo menos uma correlação aproximada entre as estimativas das características e a soma das estimativas das tarefas para essas características.
Perguntas
Qual o tamanho de uma funcionalidade?
Isso pode variar bastante dependendo do trabalho de desenvolvimento que sua equipe está realizando. Uma regra geral é que uma funcionalidade deve ser pequena o suficiente para ser concluída dentro de uma iteração e grande o suficiente para justificar um cronograma. Por exemplo, você não gostaria de agendar apenas funcionalidades de uma hora para uma equipe de dez pessoas trabalhando em um sprint de um mês. Isso representa itens demais para agendar e acompanhar. Se houver alterações específicas na funcionalidade que sejam tão pequenas, geralmente é melhor agrupá-las em um item maior para fins de agendamento. Transforme cada hora de trabalho em uma tarefa vinculada àquela funcionalidade.
As correções de bugs são funcionalidades?
Sim, podem ser. O Scrum, por exemplo, ensina que todo o trabalho que a equipe precisa realizar deve estar na lista de backlog. Métodos comuns para lidar com bugs incluem: 1) criar um item de funcionalidade para cada bug; 2) criar um item de funcionalidade chamado "corrigir bugs" em cada iteração, detalhando a lista ou os tipos de bugs a serem corrigidos; ou 3) tratar os bugs separadamente e não contabilizar o tempo gasto neles. A quantidade e a complexidade dos bugs que sua equipe espera encontrar devem ser fatores importantes na escolha do método.
Por que estimar características?
As estimativas de funcionalidades ajudam a direcionar a classificação e o agendamento que ocorrem no planejamento de releases e no planejamento de iterações. Para saber quanto trabalho agendar dentro de um determinado período, você precisa ter uma estimativa do tamanho de cada parte do trabalho. Veja também velocidade ágilSe duas funcionalidades têm o mesmo valor comercial, mas uma tem metade do tamanho da outra, a equipe será mais eficiente se trabalhar na primeira funcionalidade, portanto, ela deve ser priorizada em relação à segunda.
Devemos atualizar as estimativas de funcionalidades se as estimativas de tarefas não coincidirem?
Não, as estimativas de funcionalidades determinam o agendamento. As estimativas de tarefas determinam a alocação de recursos. Embora deva haver uma correlação entre os valores, eles não precisam estar alinhados precisamente.
