Idealmente, um recurso deve seguir os seguintes critérios
- Deve fornecer valor do negócio.
- Deveria ser estimável – deve ter definição suficiente para que a equipe de desenvolvimento forneça uma estimativa do trabalho envolvido em sua implementação.
- Deveria ser pequeno o suficiente para caber dentro de uma iteração – portanto, se for muito grande, deve ser dividido ainda mais.
- Deveria ser testável – você deve entender em qual teste automatizado ou manual um recurso deve passar para ser aceitável para o cliente.
As diferentes metodologias usam diferentes terminologias para se referir aos recursos. Cabe à equipe decidir qual metodologia ou terminologia usar. A programação extrema (XP) usa os termos “histórias de usuário” ou “histórias” para representar recursos; scrum usa “backlog do produto” para descrever uma lista de recursos; o desenvolvimento orientado a recursos usa “recurso”; e DSDM usa “requisito”. Da mesma forma, existem várias versões leves do processo unificado, ou UP ágil, que usam “requisitos” e/ou “casos de uso” para definir a funcionalidade de entrega incremental. Em última análise, o objetivo é o mesmo – entregar valor comercial regularmente em pequenos incrementos, e mais cedo ou mais tarde.
Diferenças de metodologia
Scrum chama um recurso de item pendente, que tende a ser mais granulado e também pode incluir itens que não são recursos, como "configurar hardware de produção" ou "pesquisar opções xyz".
XP chama um recurso de história, 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 PARA CIMA praticantes usam requisitos e casos de uso para definir características.
Estrutura de divisão de recursos (FBS)
Durante o planejamento detalhado, desenvolvimento ágil favorece uma abordagem de estrutura analítica de recursos (FBS) em vez da estrutura analítica de trabalho (EAP) usada em abordagens de desenvolvimento em cascata. As estruturas de detalhamento de recursos são vantajosas por alguns motivos:
- Eles permitem a comunicação entre o cliente e a equipe de desenvolvimento em termos que ambos possam entender.
- Eles permitem que o cliente priorize o trabalho da equipe com base no valor do negócio.
- Eles permitem o rastreamento do trabalho em relação ao valor comercial real produzido.
É aceitável começar com recursos grandes e depois dividi-los em recursos menores ao longo do tempo. Isso permite que o cliente evite mergulhar em muitos detalhes até que esse detalhe seja necessário para ajudar a facilitar o design e a entrega reais.
Construindo uma lista inicial de recursos
Antes release planejamento e planejamento de iteração, a equipe precisa elaborar rapidamente uma lista do maior número possível de recursos potenciais para o sistema. Normalmente há uma única pessoa responsável pela coleta de recursos (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 recursos podem vir de muitas fontes. Usuários, clientes, vendas, marketing, RFPs, membros da equipe de desenvolvimento, gerenciamento, concorrentes e regulamentações governamentais podem ser fontes de recursos. A lista central de recursos da equipe deve ter alguns controles para evitar itens duplicados, recursos impossíveis e solicitações excessivamente vagas. A equipe deve ser incentivada, entretanto, a inserir novos recursos à medida que os identificam, para que possam ser incluídos no processo de priorização e planejamento.
Uma lista de recursos inicial pode ser um esboço, um superconjunto, a ser usado como entrada para o planejamento do release e primeira iteração. Representa o potencial atual do que o sistema pode se tornar, talvez ao longo de vários releaseS. Você não precisa esperar até que todos os recursos sejam definidos antes de começar entregando software. E você não precisa aderir insensatamente à lista original, às descrições originais ou às prioridades originais. Um dos principais pontos do desenvolvimento ágil é que essa lista (como todo o resto) evolui, iteração por iteração.
Vamos fingir que uma lista aproximada de recursos foi concluída, uma release o plano e o plano de iteração são elaborados e a primeira iteração é concluída, antes que alguns recursos críticos sejam identificados. Esses recursos simplesmente são incluídos na evolução release planeje e uma iteração posterior e seja entregue o mais rápido possível. Mas enquanto isso, o tempo não é perdido. A equipe começa a entregar valor o mais rápido possível e cria a infraestrutura para permitir que o projeto se adapte ao longo do tempo às novas prioridades, informações e dinâmicas de negócios.
Lista de recursos
Ao elaborar uma lista de recursos, os recursos são inicialmente descritos em um parágrafo curto, geralmente de 2 a 4 frases. Esta descrição representa um resumo de alto nível do recurso, um espaço reservado para entendimento preliminar e uma base para comunicação futura. É como um título para um artigo que será escrito mais tarde. O objetivo é gastar apenas o tempo suficiente descrevendo o recurso para ter uma compreensão razoável do tamanho relativo, complexidade e prioridade em comparação com todos os outros recursos. Mais alguns detalhes surgirão durante planejamento de iteração. Mas o entendimento preciso e concreto do recurso pode emergir durante a iteração, à medida que clientes e desenvolvedores o discutem o suficiente para implementá-lo ou (em algumas metodologias) para criar testes de aceitação automatizados que o especificam de forma determinística.
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 PI Planning com Digital.ai Agility
Recursos de organização
Gerenciar uma única longa lista de recursos pode ser difícil. É muito útil organizar recursos especificando categorias, agrupamentos funcionais de nível superior, valor de negócios ou prioridade e risco. Filtrar e classificar por esses vários atributos pode ajudar a dividir uma lista de recursos muito grande em partes gerenciáveis.
Toda a lista de recursos deve ser classificada em uma única sequência contínua para fornecer à equipe do projeto para que todos possam ver facilmente quais recursos são os mais valiosos. Se um projeto começa com 100 recursos na lista, não é incomum que 50 desses recursos caiam em uma categoria de “alta” prioridade. Uma única classificação sequencial dos recursos ajuda a identificar aqueles que são os “mais altos dos altos” e, portanto, devem ser concluídos primeiro para maximizar o valor entregue.
Contabilização do risco
Considerações adicionais podem ser feitas para o risco associado a certos recursos. Alguns recursos envolverão designs, arquiteturas, estruturas ou algoritmos que são novos para a equipe ou que são arriscados. Mesmo que esses recursos não forneçam o maior valor comercial, geralmente faz sentido aumentar sua prioridade o suficiente para abordá-los nas primeiras iterações. Se um recurso de alto risco for abordado no início do projeto e, por algum motivo, se mostrar impraticável, a equipe ainda terá tempo para reagir e contornar o problema. 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 os recursos, mas esse processo crítico não deve ocorrer no vácuo. As melhores equipes trabalham juntas para agregar valor e reduzir riscos ao longo da vida de um projeto.
Estimando recursos
Depois de identificar os recursos, o cliente geralmente trabalha com os principais interessados no desenvolvimento para definir as estimativas dos recursos. As estimativas de recursos devem ser estimativas preliminares de alto nível usadas para conduzir release planejamento 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 criaram processos onde os grupos trabalham juntos para fornecer estimativas iniciais rapidamente. Esta etapa pode ser útil para determinar inicialmente se o recurso deve ser mais detalhado.
Ao estimar recursos inicialmente, o objetivo é convergir rapidamente para uma estimativa razoável de alto nível. Em vez de focar se um recurso exigirá exatamente 17.5 horas de ideia (ou Gummi Bears, ou NUTs, ou qualquer unidade que esteja sendo usada; veja abaixo), o objetivo é chegar razoavelmente perto em uma fração do tempo. Se levar dois minutos para concordar que o recurso levará de dois a três dias ideais para ser implementado, em vez de 30 minutos para estabelecer uma estimativa precisa de 17.5 horas de ideias, a primeira abordagem é preferida. Para estabelecer uma estimativa única quando as opiniões do grupo variam, as equipes podem fazer uma média, desenvolver uma aproximação razoável, sempre usar o melhor cenário possível ou potencialmente usar um cálculo envolvendo melhor caso, pior caso e estimativa esperada se houver mais complexidade apropriado. Em qualquer caso, as discussões sobre estimativas divergentes geralmente produzirão conhecimento útil.
Esse processo de definição e estimativa de recursos pode inicialmente parecer difícil e, quando as equipes o implementam pela primeira vez, podem exigir várias reuniões para se familiarizar com um processo que funcione bem para elas. Com o tempo, fica mais fácil dividir os recursos em unidades de trabalho que podem ser entregues em uma única iteração. As equipes ficam muito boas no que praticam e o desenvolvimento ágil permite que as equipes pratiquem a estimativa a cada release e iteração.
Unidades de estimativa
As estimativas, por sua própria natureza, são imprecisas e, historicamente, os desenvolvedores tiveram dificuldade em produzir estimativas úteis de todo o tempo necessário para concluir uma tarefa de desenvolvimento. As estimativas do tempo de programação real são muitas vezes imprecisas (especialmente se não forem rigorosamente comparadas com os números reais). Mas o tempo sem programação é ainda mais difícil de definir. O que você diria se alguém lhe perguntasse quanto tempo leva para atravessar a cidade? Você usa uma medida relativa. “Uma hora fora do horário de pico, com bom tempo, se não houver construção, caso contrário, talvez 2 horas”, etc. Esses fatores externos são impossíveis de controlar e difíceis de prever. Além de desenvolver código, os programadores gastam tempo testando, escrevendo documentação, projetando, participando de reuniões e revisões, enviando e-mails e assim por diante. Comparado ao trabalho de programação, o trabalho de não programação é difícil de prever ou controlar. Pode variar de acordo com seu setor, sua organização, a época do ano e qualquer tipo de mudança de pressão externa sobre a organização.
Algumas equipes pedem aos programadores que incluam cada atividade não relacionada à programação em suas estimativas. Mas, como dissemos, isso não é fácil de fazer. Para um determinado projeto ágil, muito antes de a equipe ter uma medição precisa do tempo gasto fazendo coisas não relacionadas à programação, eles podem saber o trabalho relativo necessário para realizar diferentes recursos e podem planejar de acordo. É por isso que é mais comum que as equipes Agile concentrem suas estimativas no que pode ser estimado e medido de maneira mais direta: a programação real. Eles se concentram em quanto trabalho cada recurso e cada tarefa técnica exigirá, em comparação com outros recursos e tarefas técnicas. Eles permitem que a quantidade de tempo consumida por esse material não programado se torne clara à medida que a velocidade real surge 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
- hora ideal
unidades de trabalho
Uma unidade de trabalho é uma medida relativa que esperamos que não possa ser confundida com o tempo real. Algumas dessas unidades:
- Pontos
- Ursinhos de goma
- Libras-pé
- NUTs (Unidades Nebulosas de Tempo)
Eles representam a quantidade relativa de trabalho necessária para implementar um recurso (ou tarefa), em comparação com outros recursos (ou tarefas). Somente depois que a equipe estabelecer uma velocidade consistente, geralmente em algumas iterações, eles poderão começar a mapear essas unidades de trabalho em unidades de tempo real. Esse é exatamente o ponto da velocidade: descrever quanto trabalho a equipe pode fazer por unidade de tempo real.
Uma vez que a equipe ou organização tenha concordado com uma unidade de estimativa, eles devem concordar em fazer um esforço para implementá-la de forma consistente e manter sua definição original. Especialmente nas primeiras iterações do projeto, todos devem resistir ao impulso de tentar mapear essas unidades para unidades de tempo com precisão exata.
hora ideal
Assim como as unidades de trabalho, o tempo ideal exclui o tempo de não programação. Quando uma equipe usa o tempo ideal para estimar, ela está se referindo explicitamente apenas ao tempo do programador necessário para realizar um recurso ou tarefa, em comparação com outros recursos ou tarefas. Novamente, durante as primeiras iterações, o histórico de estimativas se acumula, surge uma velocidade real e o tempo ideal pode ser mapeado para o tempo real decorrido.
Muitas equipes que usam o tempo ideal descobriram que seu esforço final excede as estimativas iniciais do programador em 1-2x e que isso se estabiliza, dentro de um intervalo aceitável, após algumas iterações. Em uma base de tarefa por tarefa, a proporção irá variar, mas ao longo de uma iteração inteira, as proporções que as equipes desenvolvem provaram permanecer bastante consistentes. Para uma determinada equipe, uma proporção histórica conhecida de tempo ideal para tempo real pode ser especialmente valiosa no planejamento releases. Uma equipe pode analisar rapidamente a funcionalidade necessária e fornecer uma estimativa de alto nível de 200 dias ideais. Se a proporção histórica de ideal para real da equipe for de cerca de 2.5, a equipe pode se sentir bastante confiante em apresentar uma estimativa de 500 dias de projeto. Em cenários de lance fixo, esse tipo de estimativa pode ser confiável.
Estimativa relativa
Muitas equipes Agile usam a prática de estimativa relativa para recursos. Em vez de estimar recursos em um espectro de unidades de comprimento, eles selecionam algumas (três a cinco) categorias de estimativa relativa, ou baldes, e estimam todos os recursos em termos dessas categorias.
Recursos versus planejamento de tarefas
Embora a ênfase neste estágio inicial de planejamento esteja na velocidade e no trabalho relativo por recurso, em algum ponto os recursos devem ser divididos em suas respectivas tarefas e estimados com mais precisão. Isso acontece durante release planejamento e planejamento de iteração. Em geral, estimativas de recursos e estimativas de tarefas atendem a propósitos diferentes:
- As estimativas de recursos ajudam a impulsionar o agendamento releases e iterações.
- As estimativas de tarefas ajudam a direcionar o carregamento de recursos em uma iteração.
Como eles atendem a propósitos diferentes, a estimativa de um recurso não precisa se alinhar precisamente com a soma de suas estimativas de tarefa. Em uma variedade de recursos, no entanto, deve haver pelo menos uma correlação aproximada entre as estimativas de recursos e a soma das estimativas de tarefas para os recursos.
Perguntas Frequentes
Qual é o tamanho de um recurso?
Isso pode variar em grande parte com base no trabalho de desenvolvimento que sua equipe está fazendo. Uma regra geral é que um recurso deve ser pequeno o suficiente para ser concluído em uma iteração e grande o suficiente para justificar o agendamento. Você não gostaria, por exemplo, de agendar nada além de recursos de uma hora para uma equipe de dez pessoas trabalhando em um sprint de um mês. São muitos itens para agendar e rastrear. Se houver alterações de recursos específicas tão pequenas, geralmente é melhor agrupar essas alterações menores em um item maior para fins de agendamento. Faça de cada hora de esforço uma tarefa sob esse recurso.
São recursos de correção de bugs?
Eles podem ser. O Scrum, por exemplo, ensina que todo o trabalho que a equipe precisa realizar deve estar na lista de pendências. Métodos comuns para lidar com bugs incluem 1) criar um item de recurso para cada bug, 2) criar um item de recurso chamado 'corrigir bugs' dentro de cada iteração e detalhar a lista ou tipos de bugs a serem corrigidos ou 3) lidar com bugs separadamente e não rastreando o tempo contra eles. O número e o tamanho dos bugs que sua equipe espera encontrar devem ser um fator importante na determinação do método escolhido.
Por que estimar características?
As estimativas de recursos ajudam a direcionar a classificação e a programação que acontecem em release planejamento e planejamento de iteração. Para saber quanto trabalho agendar em um determinado período, você deve ter uma estimativa do tamanho de cada trabalho. Veja também velocidade ágil. Se dois recursos tiverem o mesmo valor de negócios, mas um tiver metade do tamanho do outro, a equipe será mais eficiente se trabalhar no primeiro recurso, portanto, deve ser classificado acima do segundo.
Devemos atualizar as estimativas de recursos se as estimativas de tarefa não baterem?
Não, as estimativas de recursos direcionam o agendamento. As estimativas de tarefas orientam as alocações de recursos. Embora deva haver uma correlação entre os valores, eles não precisam estar alinhados com precisão.
