Do Requisito ao Código, com ou sem escalas?

Dois giros no Mapa de Tudo, um rolê aleatório sobre testes e uma nova sigla para você: FU2.

É corriqueira e comovente a esperança nutrida por muitos de percorrer aquela linha direta dos requisitos ao código sem escalas ou, quando muito, rabiscando um protótipo bem low-fi. É como se aquelas escalas mal descritas — casos, histórias, hipóteses, arquitetura, decisões, engenharia e especificações — não acontecessem de um jeito ou de outro. Veja:

Domingo é aniversário da Maninha (fato). Você troca ideia com o cônjuge (parte) sobre o presente ideal. Lista necessidades (contando casos ou histórias) e cogita alternativas (hipóteses). Uma análise benefício/custo guia a escolha (arquitetura). A logística — onde comprar, como, quem? — é decidida ali mesmo (decisões, engenharia, especificações). Você perdeu e perderá a manhã de sábado — início de mês!! — na muvuca do shopping atrás do presente ideal (software rodando). Tomara que a chata da Maninha goste (indicador).

Não se trata de uma prescrição. É o caminho natural das coisas, das mais diversas coisas¹. Da forma que eu acho que te interessa, o giro fica assim:

1. Requisitos são necessidades, vontades e restrições apresentadas pelas partes envolvidas.

2. A transcrição dos requisitos na forma de Casos ou Histórias busca o desenvolvimento de um entendimento compartilhado. Neste ponto nós estamos tentando confirmar o que precisa ser feito.

3. Cada requisito pode ser atendido de infinitas maneiras. Por isso elaboramos Hipóteses sobre como satisfazê-los².

4. Quando as incertezas acerca de determinadas hipóteses ultrapassam o limite do razoável, desenvolvemos e validamos Protótipos.

Quanto mais inovador o produto/projeto, maior a demanda por ciclos de descoberta e exploração. Protótipos dos mais diversos tipos e resoluções, provas de conceito, MVPs (Minimum Viable Product) e diversos tipos de mapas e modelos nos ajudam a aprender, a desanuviar e avançar.

5. As hipóteses de “amplo espectro” começam a ser compiladas na Arquitetura da solução. O stack de tecnologias costuma ser uma das primeiras decisões do projeto.

Encontramos, finalmente, a deixa do penúltimo post:

[Clientes e usuários] deixam de ser meros expectadores em revisões e ganham voz e poder em todas as tomadas de decisão. Todas, inclusive naquelas em que um time técnico julga ter exclusividade.

Mapas Wardley, que estão se tornando meu novo bombril³, viabilizam essas conversas…

… porque possibilitam o entendimento de todo o stack, de toda a cadeia de valor. É claro que, com todo o resto sendo igual, a turma que paga a conta pode dar autonomia para o time técnico definir seu stack. Raro é “todo o resto ser igual”. Quanta gente não foi pega de surpresa com as contas das nuvens, por exemplo?

Eu vejo a combinação dos Mapas Wardley com Mapas de Histórias…

… e me lembro do triste tempo em que tentávamos acompanhar a rastreabilidade de requisitos com matrizes⁴. Em vão.

Voltando…

6. Negociações, validações e decisões nos levam da arquitetura para a Engenharia. A engenharia vai detalhar o seu trabalho na forma de

7. Especificações. Que podem ser escritas, por exemplo, como prompts.

Incomodados com a pecha de casa de ferreiro, espeto de pau, há tempo brincamos com geradores automáticos (ou semi) de código. MDA, xUML, BDD, BPEL, no-code, low-code e agora uma algazarra de IAs. A evolução é indiscutível. Sobre a necessidade dos seis passos anteriores, o que dizer?

[Volte ao post anterior e assista o vídeo]

Foto de Chris Lawton na Unsplash

Rolê aleatório, quiçá controverso, sobre testes

Lá na pré-história deste finito um sujeito cancelou a assinatura quando se deparou com um “bullshitagenzinhas ágeis”. Já não me lembro se eu estava desancando a coisa no atacado ou no varejo. Se foi este o caso, é grande a chance do alvo de minha ironia ser um resquício de cascata do tipo DoR ou DoD⁵. Ou será que eu estava reclamando da turma que insistia em empurrar a escrita de BDDs e TDDs⁶ para o pessoal de negócios?

Para a turma de negócios, os únicos testes que interessam consomem apenas 2 ou 3 caracteres. Em inglês, 4U⁷. Sim, o for you é intencional. Mas na realidade temos 1 W e 2 Us:

• Does it Work?

• Is it Used?

• Is it Useful?

Na minha enrolada tradução, o 4U virou FU2. Veja o potencial da sigla: FU-dois! Olha como ela gabarita o teste dos irmãos Heath⁸: Simple, Unexpected, Concrete, Confirmation, Emotional, Story.

Será que a seriedade deste papo se perdeu nas gracinhas? Espero que não.

Cotação

Você não pode voltar e mudar o início, mas pode começar de onde está e mudar o fim.

-C.S. Lewis

ps: Ou seja, nunca é tarde demais para participar do FAN Essencial.

1. E por isso eu tenho tratado a singela matriz DEDE como um “Mapa de Tudo”.

2. É muito comum, em nossa área, a confusão entre os termos requisito e hipótese. Evito o uso deles como se fossem intercambiáveis por uma razão óbvia: não pega bem falar para um cliente que a sua necessidade ou dor é uma “hipótese”. Pra que complicar? Requisito (o que), hipótese (possível como).

3. Porque caminham para ter 1001 utilidades.

4. Algumas caríssimas, diga-se de passagem.

5. Definition of Ready, Definition of Done.

6. Behavior-Driven Development e Test-Driven Development. Por falar nisso.

7. Depois de tanto tempo divulgando livros ruins, é hora de enaltecer aqueles que entregam coisas úteis, usáveis e que funcionam em praticamente todas as páginas. É o caso do excelente Essential Balances: Stop Looking and Start Seeing What Makes Organizations Work, de Ivo Velitchkov (KVISTGAARD, 2020), por exemplo. Sim, o 4U é dele. Numa nota que encerra a introdução!

8. Ideias que Colam. Por que Algumas Ideias Pegam e Outras Não, de Chip e Dan Heath (Alta Books, 2018).