BABOK Agile Extension – Fazendo o BA pensar em entregar e o Agilista pensar em descobrir
“Uma visão sem ação não passa de um sonho.
Ação sem visão é só um passatempo.
Mas uma visão com ação pode mudar o mundo”.
- Joel Barker
Nada melhor para entender “qualé” da extensão ágil do BABOK 2.0 do que contato direto com um dos seus responsáveis, no caso o Luiz Claudio Parzianello (@lcparzianello).
Tive a oportunidade de interagir com o Luiz em duas ocasiões. A primeira foi na sexta passada quando ele palestrou no @PensandoLean realizado pela @Oncast, um evento muito bem bolado e realizado, que envolveu um curso de dois dias (do qual me arrependo fortemente de não ter participado) e um fórum cheio de palestras de peso, com a do próprio Luiz e de Mary e Tom Poppendieck, “os caras” do Lean Software Manufacturing.
A segunda ocasião foi aqui em Porto Alegre onde estou passando o feriadão. Uma feliz coincidência. Nos encontramos para uma conversa rápida na qual pude tirar algumas dúvidas a respeito da extensão ágil do BABOK que está me intrigando faz algum tempo.
Depois de trocar algumas ideias, chegamos à conclusão que a extensão ágil do BABOK tem funções distintas dependendo de quem a lê.
Fazendo o Analista de Negócios pensar na entrega (Deliver)
O Luiz prega algo que costuma passar batido pelos analistas de negócios: “a forma com a qual a solução é entregue é de total interesse do negócio”.
Tendemos a nos adaptar ao ambiente no qual estamos trabalhando, pensar nos requisitos de todos os níveis, em entender o problema, mas esquecemos de nos preocupar com a maneira com a qual a solução é entregue e como isso afeta o negócio.
Um esforço de análise de negócios que possa soar como ideal, no qual uma solução é definida com uma excelente análise do problema cai por terra se esta solução não for entregue em tempo e adaptada às mudanças naturais no ambiente de negócios.
Se pensarmos em questões como time to market e aprendizado organizacional, vamos notar que projetos cascata trazem um enorme risco inerente, principalmente pelo fato de termos um enorme lapso de tempo entre a concepção do projeto e a primeira entrega da solução ou parte dela. Só isso já deveria acender uma luz vermelha no painel de controle do AN.
Ou seja, o analista de negócios deve entender de metodologias ágeis, entender como funcionam projetos iterativos e de entrega contínua. Como bom profissional de negócios, vale a pena entender que o agilismo é filho da produção enxuta, do “Lean”, algo que nós administradores de empresas conhecemos bem desde meados dos anos 90, ou seja, nada radical ou absurdo e origem de muitos sucessos na indústria.
Por fim, descobrir sem entregar, é como visão sem ação (ou com ação muito mal feita). Não passa de sonho.
Fazendo o Agilista pensar em descobrir (discovery)
Já fiz uma sátira aqui no blog fantasiando que o Scrum foi definido em um bar e que quando alguém questionou de onde viriam os requisitos, alguém alcoolizado veio com a ideia do Product Owner e o pessoal se deu por satisfeito, bebeu mais e dormiu com a consciência limpa. Ahh, começaram a entregar software na semana seguinte. Algo que não deixa de ser impressionante.
Agora, falando sério, de onde vem “o que deve ser feito”? Um product backlog não cai do céu, e poucos POs devem ter a capacidade de psicografar requisitos direto do além.
O backlog, ou o termo que prefiro usar, o roadmap do produto que está sendo entregue nasce de um roadmap de alto nível, o roadmap do negócio dentro do qual este produto está inserido. O Luiz tem um slide que deixa isso muito claro, inclusive apresentando como a estrutura da estória do usuário faz com que esses dois roadmaps convergirem de forma genial.
E o quê orienta o roadmap do negócio? Simples, algo chamado estratégia.
Ou seja, se o agilista realmente deseja cumprir a sua missão de entregar valor, precisa entender de negócios, melhor, precisa entender de análise de negócios. Vale a pena abrir um pouco de espaço para ela no meio das discussões de assuntos legais como TDD, pareamento e integração contínua.
Apenas entregar transforma aquele gráfico do Scrum em uma montanha russa na qual o único objetivo é se divertir.
Por fim, entregar sem descobrir é como ação sem visão (ou com visão mal feita). Não passa de passatempo.
Conclusão
Ainda não sabemos se em contextos ágeis teremos a figura do Analista de Negócios, se chamaremos ele de PO dependendo do momento ou mesmo se conseguiremos ter a figura do product champion, mas está claro que descoberta e entrega devem parar de ignorar uma a outra. Projeto algum é completo sem uma delas.
