Hierarquia de requisitos, o que deve ser escrito por cada nível e por quem

img_2362

(Berlim, Alemanha) Às vezes, os conceitos de Agile mais óbvios não são tão fáceis de se aplicar quando precisamos de os utilizar. Especialmente quando temos que construir um entendimento comum, uma visão comum e consistente para o produto ou portfólio. O meu objetivo com este post partilhar uma opinião pessoal sobre como e quem deve responder a cada nível de requisitos.

A engenharia de requisitos sobrepoe-se em camadas de progressivos níveis de detalhe, desde a estratégia com descrições de nível superior do portfólio ou visão do produto, em níveis especializados de requisitos para implementar corretamente o produto, funcionalidade e story.

IMG_2497. jpg

Niveis de detalhe progressivos nos requisitos de estratégia até à implementação

Com Agile e Design Thinking aprendemos que pequenas metas ajudam de uma forma incremental, a moldar a estratégia em produtos reais. Aprendemos também sobre o quão importante é testar conceitos e tecnologias em Proof of Concepts, principalmente quando temos desafios de diferentes naturezas produtos e funcionalidades complexas. Conhecer os diferentes níveis de requisitos em Agile, saber quem os escreve, ajuda-nos a planear melhor os nossos produtos.

Sagas

Através de sagas os nossos gestores comunicam, não só a visão de portfólio, mas também:

  • A diferenciação desejada em comparação com os concorrentes;
  • O desempenho incremental;
  • As funcionalidades incrementais;
  • A ambição de inovação;
  • As reduções de custos desejadas;
  • Os critérios de distribuição orçamentais;
  • As metas partilhadas entre produtos do mesmo portfólio: qualidade, reduções de custos, otimização arquitetónica dos sistemas, aplicacoes ou componentes partilhados, negociação de contratos com fornecedores comuns, etc.

Resumindo, a Saga é o nível de requisitos usados para expressar requisitos de portfólio, otimizações desejadas e sinergias entre os produtos do mesmo portfólio.

Quem deve escrever sagas?

A meu ver, sagas devem ser escritas ao nível estratégico da organização, ao nível de gestao de portfólio de produtos.




Epics

O que escrever num Epic?

Epics são, na minha opinião, o nível de requisitos das funcionalidades do produto. Devem ser escritos, tanto quanto possível, respeitando a mesma estrutura das Stories: Quem? O Que? Para? Porque? Como?

Conteúdo típico para um Epic:

  • Aqui é onde o Product Owner expressa sua ambição para o produto.
  • Na minha opinião, o nível Epic é o mais adequado para explicar à equipe o contexto de negócios para exigir o conjunto de funcionalidades.
  • Algumas características são tão complexas que representam por sua quantidade de histórias ou de complexidade um único Epic.
  • Um épico também deve refletir os requisitos provenientes do nível acima, a partir do nível de carteira, expressa por sagas. Especialmente para os requisitos compartilhados entre os produtos na mesma carteira.
  • Também devemos incluir requisitos não funcionais específicos que serão aplicados diretamente para o recurso descrito ou conjunto de recursos: garantia de qualidade, segurança, requisitos legais, etc.

Quem deve escrever Epics?

A meu ver, Epics devem ser escritos ao nível do produto, por quem é responsável por definir a estratégia completa do produto na organização, e tem uma atitude de defender o produto da concorrencia. Se estamos em software ou indústrias digitais, onde já se pratica Agile, normalmente é o Product Owner quem conhece o produto e processos, mercado e como o negócio deve ser conduzido. Se estamos em indústrias mais tradicionais, onde o core business não é software, mas é suportado por ferramentas de software, podemos encontrar muitas vezes um gestor de produto, que representa o negócio, e um product owner do departamento de Tecnologias de Informacao (TI), responsável por traduzir os requisitos do negócio em requisitos técnicos específicos. Esta funcao de Product Owner em TI pode ser realizada por um Product Owner completamente dedicado a isso ou por algum profissional que acumule funcoes de Product Owner,  Scrum Master ou/ e Arquitecto de solucoes. Normalmente, esta é uma funcao de um recurso senior que faz de interface entre o negócio e a equipe de desenvolvimento.

A engenharia de requisitos é provavelmente uma das funcoes mais importantes na organização, que exige conhecimento especializado que nada tem a ver com a ocupacao hierarquica e/ou disciplinar. Em Agile, o que observamos é uma tendencia para a separacao de poderes e influencias, onde o conhecimento de especialistas se sobrepoe à hierarquia, sendo que o driver é a maximizacao de valor para o produto, em ultima instancia para o cliente.




Stories, tarefas e sub tarefas

O que escrever nas Stories?

Pessoalmente, eu diria, uma Story é o nível mais baixo de detalhe para requisitos.

Podemos ter stories funcionais, a descrever funcionalidades na perspectiva do utilizador, mas também podemos ter stories nao funcionais, na perspectiva da implementacao técnica ou de outros requisitos nao funcionais. Muitas vezes, por razoes de complexidade, observamos a relacao entre stories no backlog, dependencias e bloqueios sao também registados.

A metodologia Agile não sobrevive sem qualidade e testes, bugs também devem ser registados e descritos corretamente para rapidamente serem reproduzidos e corrigidos. A responsabilidade de descrever e registar bugs e defeitos não é restrita apenas aos engenheiros de teste. Esta é uma responsabilidade da equipe e de toda a organizacao.

Em relação a tarefas e subtarefas, eu diria que não fazem parte dos requisitos, mas sao passos simples para estruturar a implementação, tarefa a tarefa.

Quem os escreverá?

A meu ver, toda a equipe deve escrever stories, é claro considera-las ou não para implementacao é uma decisão do Product Owner, tal como a sua priorização é da sua responsabilidade.

Liberdade para personalizar tipo Issues por equipe ou organização

Devo dizer que a personalização dos items em backlog varia muito de uma organização para outra. Mas a parte importante aqui é que todos os grupos envolvidos num backlog devem compartilhar os mesmos significados para cada item ou issue type.




Deixar uma resposta

Este site utiliza o Akismet para reduzir spam. Fica a saber como são processados os dados dos comentários.