Agile BA Parte III - Criando Caso

Última parte de uma pequena série que tratou dos problemas da Anne, uma Scrummaster que foi ligeiramente afetada por um curso de Análise de Negócios. Como adiantei na semana passada, vou criar caso questionando algumas estórias.


Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião[1] popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos[2], as User Stories são formadas por três elementos:

• Cartão: onde escrevemos as estórias [3];
• Conversas: que nos levariam a entender e detalhar as estórias; e
• Confirmação: o 'the end', o fim da estória.
  

A motivação para tamanha invenção gira em torno da palavrinha 'documentação' (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo [4] reforça: "os cartões representam os requisitos do cliente, mas não os documentam". Vai na linha de um mestre-pacificador (mezzo tucano) [5] que vive insistindo: "gente, modelagem não é documentação... modelagem não é documentação... isso é um mito". Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: "Nós organizamos as cento e poucas estórias por processos de negócios...". Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) [2]: "É difícil saber por onde começar".

[Nuvens negras fecham o céu. Dois relâmpagos, como flashes do último modelo da Nikon, iluminam a figura de longas barbas esvoaçantes que, do alto da montanha, proclama: "Véio, se tu não sabe por onde começar, já começou errado!"]

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de "organização de estórias". Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo [6].


Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador [7], "um caso de uso é o nosso constructo para um processo de negócio"; "[os modelos de casos de uso] descrevem o negócio e o seu ambiente".

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso [2]:

• Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
• Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
• Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD's e afins por aí.
• Estimáveis: ok, UCP's são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
• Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado - regrinha básica;
• Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que [8]: "Se um requisito não pode ser testado então ele não é um requisito".
  

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de 'casa de ferreiro... espeto de bambu' (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas...



... começando do começo: o Negócio.



Notas:

1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
   
2. User Stories Applied: For Agile Software Development
   Mike Cohn. Addison-Wesley (2004).
   Obs: Mesmo autor do artigo sobre UCP referenciado acima.
3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre "estória versus história"? Pois é, me lembrei deles na hora de traduzir stories.
4. The Power of Stories
   Rachel Davies. XP 2001.
5. Debunking Modeling Myths
   Scott W. Ambler. Software Development (Agosto/2001).
6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
7. The Object Advantage - Business Process Reengineering with Object Technology
   Ivar Jacobson. Addison-Wesley (1995).
8. Requirements-Led Project Management
   Suzanne e James Robertson. Addison-Wesley (2005).
   

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios