25
0
No panorama atual sobre metodologias de desenvolvimento de software uma proposta que vem se destacando é SAFe (http://www.scaledagileframework.com/), um framework para permitir escalar práticas ágeis em corporações ou grandes projetos. A natureza particular dessa proposta é a ênfase que o framework dá ao gerenciamento de requisitos. Isso não surpreende quando sabemos que este framework vem sendo elaborado desde 2009 por Dean Lenffingwell, o mesmo autor de Managing Software Requirements – A Unified Approach, que serviu de base teórica para os cursos de gerenciamento de requisitos da IBM Rational. Aliás o autor foi um dos idealizadores do IBM Rational RequisitePro, ferramenta de gestão de requisitos que ficou famosa na década de 90.
Vinte anos depois, vimos o aparecimento de novas ferramentas, como o IBM Rational Requerements Composer (RRC), que sucedeu ao RequisitePro, com vantagem, e que incorpora agilidade e colaboração. Esperávamos também que novos conceitos aparecessem na área de requisitos. Estes vieram na forma de histórias (user stories), temas (themes) e épicos (epics). Novos conceitos que ampliaram a forma de capturar requisitos, melhor adequados à ênfase em colaboração, flexibilidade e iterações de projeto mais curtas.
Para aqueles que, como eu, lembram-se da pirâmide de requisitos, uma forma simbólica de mostrar níveis de narrativa dos requisitos, devem observar a falta que fazia um método para transformar uma necessidade em uma característica (feature). Portanto damos as boas vindas aos épicos e temas, (sem falar nas histórias de usuários) porque eles vieram para cobrir uma falta de unidade na área dos requisitos de mais alto nível de abstração. Hoje, o que é comum entre as empresas, vemos o interesse em se usar histórias de usuários combinadas ao papel do Product Owner que, mesmo não desbancando o papel de gerente de produto, divide com ele a responsabilidade da manutenção do backlog do sistema. Nessas corporações faz muita falta um processo que permita organizar o trabalho desse novo papel na escala adequada ao negócio.
É nesse cenário que o framework SAFe fica mais interessante. Com uma abordagem focada na gestão e captura dos requisitos, ao invés de no design e implementação, o framework atende a uma demanda do desenvolvimento ágil que necessita soluções para escalar a efetividade do trabalho dos product owners e product managers. SAFe propõe esse mecanismo definindo diferentes níveis de times, organizando os product managers em torno dos product owners. E os mecanismos para criar essa escalada estão no próprio conceito de time ágil: times Scrum para os níveis operacionais que tenham prazo de entrega e equipes Kanban para times de decisão que tem a prioridade como principal objetivo. Dizendo de outra forma: a dinâmica de times varia conforme a importância da prioridade versus previsão de entrega, ou seja, na medida em que a questão do time-box, que fixa o tempo da sprint, fica menos importante que a questão da “prioridade imediata”.
Mas então, como SAFe materializa essa variação na dinâmica da equipe? Simples, definindo três níveis com dinâmicas diferentes: Dinâmica das Equipes (teams), dinâmica do programa ou projeto (program) e dinâmica do portfólio. Esses três níveis de abtração organizacional possuem também três níveis de narrativa de requisitos. Isto significa que o conceito (e vocabulário) ao nível de cada uma das dinâmicas, do que se entende por requisito já está definido, o que facilita imensamente o trabalho de definir responsabilidades e artefatos para cada nível da organização. Esquematicamente:
| Dinâmica de portfólio | Temas ou Épicos |
| Dinâmica de programa ou projeto | Características (Features) |
| Dinâmica de equipe | Histórias de usuários |
Com a delimitação de níveis fica mais clara a utilização de variações de processo, quero dizer, um processo Kanban pode ser o mais adequado para tratar temas ao nível de portfólio porque, por exemplo, o acesso ao público gerencial é sob demanda e não sob a égide de uma agenda time-box (o caso de uma sprint ou iteração). Um processo como Scrum poderia ser mais adequado ao nível operacional de um sistema que tem releases periódicas e poderia ter suas entregas fixadas por sprints.
Nota: para aqueles que enxergaram na tabela das dinâmicas a mesma pirâmide do RequisitePro, um aviso. Lá tinhamos níveis de detalhe em que o requisito estava formulado, assim como aqui, mas o objetivo não é rastreá-los ou decompô-los, apenas delimitar diferentes dinâmicas organizacionais. Em suma o framework não define tudo, mas nos dá um caminho para elaborar processos de desenvolvimento mais harmônicos entre os níveis organizacionais. Voltaremos ao assunto do SAFe abordando outros aspectos interessantes.
Por enquanto, nestes tempos em que ainda não temos análise automática de requisitos, feita por algum algoritmo de linguagem de máquina ou inteligência artificial (vêr referência) , só nos resta construir bem os requisitos e apoiar-nos numa boa dinâmica de equipe para implementarmos a melhor solução. 
Referências
Moacyr Mello é IBM Certified IT Specialist, tem 28 anos de experiência em tecnologia de informação e atua nas áreas de processos e requisitos na IBM Rational desde 1999. É Engenheiro Eletricista pela Escola Politécnica da USP, com especialização em gestão de projetos pela FGV.
