Uma das principais atividades que ajudarão a tornar seu programa SAFe® um sucesso é a preparação cuidadosa de seus recursos antes do planejamento do Incremento do Programa (PI). E uma parte importante desta preparação é dividir qualquer um dos recursos direcionados que são grandes demais para serem entregues facilmente no PI.
Nesta apresentaremos como trabalhar com o fatiamento de recursos e, em homenagem a Richard Lawrence e seu popular pôster Story Splitting, apresentar uma imagem complementar do Feature Slicing para você usar em seu programa SAFe.
Incremento do Programa são apenas grandes histórias, não são?
É muito tentador para Owners e Gerentes de Produto tratar os recursos como se fossem histórias de Usuário gigantes e aplicar a mesma abordagem de divisão dos recursos na lista de pendências do programa, como eles já usam para as histórias de usuários nas listas de pendências da equipe.
Assim como descobrimos que isso pode causar problemas para descrever os recursos usando o formato de história também achamos problemático aplicar as mesmas regras de divisão aos recursos que aplicamos às histórias de usuários.
No Scaled Agile Framework, é feita uma distinção clara entre o objetivo, a estrutura e o conteúdo dos recursos e o de histórias .
- Featues são as ‘unidades’ visíveis de benefício comercial que o cliente reconhece e é nesse nível de granularidade que o cliente prioriza suas necessidades;
- As features podem abranger várias funções, histórias de usuários e casos de uso;
- Várias equipes podem trabalhar simultaneamente a mesma feature e também pode se agrupar para fornecer recursos;
- Uma feature pode levar muitas Sprints para serem concluída, sendo implementada em história por história; Para as features os recursos devem ser facilmente concluídos no incremento de programa; lembre-se de que os recursos são para incremento do programa mais longos, assim como as histórias para os Sprints;
- Histórias de Usuários são as unidades de trabalho em que cada equipe divide suas features para ajudá-los a desenvolver e entregá-las. Elas existem para ajudar a equipe (e suas partes interessadas) a examinar, discutir, concordar e sequenciar o trabalho que acreditam ser necessário para a entrega de tal feature;
- As histórias devem ser concluídas dentro de uma única Sprint de duas semanas;
- As histórias podem existir sem as features, permitindo que as equipes façam alterações sem a necessidade de features adicionais.
Existem várias fontes de regras para a divisão de histórias, sendo nossas favoritas as publicadas por Richard Lawrence (incluindo seu popular cartaz de divisão de histórias) e Dean Leffingwell (consulte o artigo da história fornecido como parte do site interativo do Scaled Agile Framework www.scaledagileframework .com ).
Essas regras ainda se aplicam às features e realmente ajudam as equipes na identificação, separação e sequência das histórias que foram identificadas para implementá-la, mas não são tão úteis no que diz respeito ao fatiamento das features.
Por exemplo:
Não recomendamos adiar os requisitos de desempenho relacionados a uma feature para uma outra feature posterior, embora apenas possamos implementar essas histórias de desempenho no final do desenvolvimento dessa feature.
A mesma lógica se aplica ao tratamento de fluxos de erro, CRUD e variações de dados; podemos atrasar histórias que implementam esses importantes atributos de software para uma feature no final de seu desenvolvimento, mas não adiaríamos esse trabalho para uma feature específica.
Ao fatiar tais features, é sempre importante lembrar que esses são os verdadeiros elementos de valor do sistema e, portanto, devem sempre fornecer uma solução robusta e utilizável para os usuários, sendo sempre construídas história a história, mas, por si só, devem fornecer uma solução utilizável completa.
Há outra diferença importante entre dividir histórias e features:
Quando dividimos uma história, geralmente dividimos a história original em um conjunto de novas histórias de tamanho semelhante que substituem completamente a história original.
Ao fatiar features, geralmente trabalhamos apenas na fatia mais importante e deixamos o restante para ser tratado posteriormente.
Incremento do Programa fatiado em Features
Então, vamos imaginar que uma equipe tenha acabado de dimensionar uma feature (normalmente nos Story Points) e tenha descoberto que é muito grande para ser entregue facilmente no próximo incremento do programa.
Para dividir essa feature, eles precisarão selecionar um método de fatiar que lhes permitam priorizar ou adiar algumas das funcionalidades. Depois de fatiá-la eles selecionarão as partes do valor comercial que fornecerão o benefício ao cliente rapidamente.
Veja abaixo 10 padrões de fatiamento que podem ser utilizadas:
1 – Mantenha a simplicidade
Busque a implementação mais simples que pode ser lançada sem comprometer o desempenho do sistema. Adie as que não forem necessárias no momento para as features posteriores.
2 – Adiar o comportamento opcional
A feature inclui muitos comportamentos opcionais? Separe esses comportamentos opcionais a serem executados quando a funcionalidade principal for entregue.
3 – Variações de negócios separadas
O recurso pode ser lançado de forma incremental para diferentes áreas da empresa. Comece com a variante comercial mais simples primeiro para gerar feedback rápido. Por exemplo, poderíamos fazer uma solução simples para o banco de varejo antes de elaborá-lo e oferecê-lo ao banco de investimento, comércio e outras áreas bancárias?
Considere também variações geográficas: em muitas empresas, as regras de negócios variam de acordo com a geografia, com regras diferentes para os EUA, Europa, Ásia e Brasil. Talvez possamos iniciar o recurso em uma região geográfica antes de adicionar suporte para os outros por meio de recursos adicionais.
4 – Canais diferentes separados
A feature pode ser lançada de forma incremental para oferecer suporte a diferentes canais, rotas para o mercado, a mesma funcionalidade em diferentes mídias? Por exemplo, diferentes sistemas operacionais ou os diferentes canais usados para fornecer serviços bancários de varejo para clientes, incluindo serviços móveis, aplicativos bancários e serviços bancários nas agências.
É logicamente a mesma feature em todos os casos, mas a entrega do Recurso em cada canal pode ser considerada um Recurso diferente (e, em alguns casos, pode não ser necessário).
5 – Endereçar diferentes grupos de usuários individualmente
Usuários diferentes desejam conjuntos de histórias diferentes? Compreender as necessidades dos diferentes grupos de usuários pode ajudá-lo a dividir as features e entender melhor os benefícios específicos de cada grupo de usuários. Por exemplo, nosso novo Recurso pode apelar para diferentes dados demográficos, mas cada grupo demográfico deseja aplicar o Recurso de uma maneira diferente.
Nesse caso, o recurso de fatiamento nos permitirá focar apenas o subconjunto das histórias que cada demografia precisa e capturar o interesse dos grupos mais importantes anteriormente.
6 – Considere o fornecimento incremental de dados
Todos os dados são necessários antes que qualquer benefício possa ser fornecido? Talvez os dados possam ser consumidos de forma incremental ou provenientes de fontes secundárias existentes?
7 – Isolar variações especiais
Concentre-se primeiro nos casos populares / de alto volume e adicione os casos de canto mais especializados como recursos adicionais – você pode descobrir que o valor deles é muito pequeno e nunca é necessário.
8 – Interrompa capacitadores comuns
Os recursos de negócios geralmente dependem dos mesmos comportamentos subjacentes do sistema, fazendo com que o primeiro dos recursos implementados pareça muito grande e complexo. A quebra desses facilitadores comuns pode arriscar, reduzir a estimativa e simplificar a implementação de muitos recursos de negócios.
9 – Encontre um grupo de histórias
Lembre-se de que 80% dos benefícios comerciais provavelmente virão de 20% das histórias. Encontre essas histórias e trate-as como seu próprio recurso. Consulte Mapeamento de histórias para obter mais informações.
10 – Break Out A Spike
Às vezes você não sabe o suficiente para planejar algo. Como último recurso, estourar um pico.
Incremento do Programa – Um único corte
Também encontramos vários anti-padrões utilizados com frequência, incluindo:
1 – Adiando requisitos não funcionais
Ao implementar uma feature, podemos nos concentrar nos aspectos não funcionais depois que as histórias iniciais estiverem funcionando, mas não devemos liberá-lo se estiver abaixo dos níveis aceitáveis de qualidade e desempenho.
Há circunstâncias, é claro, em que uma liberação limitada de uma feature pode ser feita para obter feedback do cliente e que, ao limitar explicitamente o número de usuários, o número de requisitos não funcionais aplicáveis é aplicável.
Deve-se tomar muito cuidado para garantir que as pessoas não pensem que ele possa ser aberto a todos, sem trabalho adicional e a adição de outros Recursos.
2 – Fatiar muito cedo
Fatie apenas uma feature se for:
- Necessário em um futuro próximo;
- Grande demais (no momento atual) para fluir efetivamente pelo sistema.
Lembre-se de que as estimativas para concluir as features mudam ao longo do tempo, ou seja, o que parece ser muito grande hoje pode ter uma estimativa muito menor no futuro.
3 – Fatiamento excessivo
Não há necessidade de dividir uma feature em vários recursos menores de uma só vez. Geralmente, basta encontrar a primeira ou duas fatias a serem implementadas e deixar o restante inicial para ser abordado posteriormente, depois que as fatias iniciais foram implementadas.
4 – Fatiar por componente
Os tecnólogos geralmente acham difícil resistir ao fatiamento por componente arquitetônico, subsistema ou camada. Essa é uma solução tática que é frequentemente aplicada no nível da estória, principalmente quando se lida com equipes de componentes ou quando as equipes estão lutando para ajustar suas histórias em Sprints de duas semanas.
Esse é um mau hábito que deve ser eliminado ainda mais ao lidar com itens maiores, como features.
Esquecendo o teste de feature
As features geralmente exigem testes adicionais além do necessário para concluir suas histórias.
Um anti-padrão de fatiamento é adiar esse teste para uma fatia posterior, em vez de incluir quantidades apropriadas de testes em cada um dos novos recursos menores que estão sendo criados.
Fatiar por etapa do fluxo de trabalho
Geralmente é tentador dividir uma feature em uma série de partes em torno das etapas ou operações do fluxo de trabalho que ele envolve. Por exemplo, olhando a entrada, o processamento e a saída final do processo como features separadas ou, em um nível mais simples, a criação, acesso, atualização e exclusão de itens.
Esse é um anti-padrão comum quando se trata de dividir os recursos, pois há pouco ou nenhum valor comercial em apenas poder concluir a primeira etapa de algo.
Concentre-se na identificação do comportamento principal envolvido na feature e na criação da solução de ponta a ponta mais simples.
Recursos adicionais podem adicionar variações quando a funcionalidade básica de ponta a ponta foi lançada e está nas mãos dos usuários.
Isso geralmente leva à situação em que 90% dos recursos estão completos, mas os usuários ainda não conseguem atingir nenhum de seus objetivos reais. Eles podem entrar, encontrar, manipular, mas não conseguem concluir o processo que estão tentando executar.
Referência
- https://www.ivarjacobson.com/
