Be-a-Ba do planejamento ágil? Pirâmide das abstrações

Sempre é um prazer fazer um workshop de alinhamento e desmistificação do que é e não é Agile. Acredite, leve isso para a vida, qualquer reunião, evento, projeto, férias, aquisição, etc, o primeiro passo é alinharmos expectativas e objetivos.

Entre todos os temas instigantes para discutir e entender, um é fundamental, é o que diferencia um planejamento tradicional do ágil, uma abstração para a qual criei o diagrama simplório de uma pirâmide – Pirâmide das Abstrações!

O instanciamento mais praticado do SCRUM para projetos de desenvolvimento de software possui um pré-game que termina com o Release Plan, que planeja tempo, escopo e suporta o de custos, seguido de N sprints de detalhamento e construção, para o qual criei o diagrama abaixo:

piramide abstração 2 - scrum

A dificuldade no entendimento inicial de como planejar sem empenhar semanas ou meses de um analista entrevistando, detalhando e modelando todo o sistema é a uma das principais angústias … senão vejamos:

PRÉ-GAME

Pré-Game é a etapa que antecede o que o PMBOK chama de Iniciação, com o termo de abertura e apresentação de stakeholders. Eu trabalho exatamente desta forma, inicio com o Project Model Canvas, kickoff de um projeto 100% ágil.

No PMC discutimos principais dores (justificativas) e ganhos (benefícios e requisitos), também antecipamos a todos as principais premissas, restrições e riscos já percebidos, quem são os principais stakeholders e equipe prevista, além de eventuais pacotes de entrega desejados e datas-marco almejadas.

Técnicas colaborativas e visuais, como atas em tempo real usando Mapas visuais nas paredes em quadros brancos e postits coloridos, customer journey maps, user story mappings. O término de um Pré-Game é um Go-No Go para o Release Plan.

Uma etapa que pode demorar alguns dias, concentrados ou distribuídos em semanas, meses ou anos, trabalho inicial de entendimento de uma ideia, desafio, problema ou necessidade. Usualmente, um analista de negócios, contando com a ajuda de profissionais conforme disponibilidade e relevância do projeto.

Vamos planejar? Aqui entra a pirâmide das abstrações \o/
piramide abstração 1

1. RELEASE PLAN

É o ato de planejar escopo e tempo, gerando insumos para planejar também custos, trata-se de um planejamento cooperativo, usando de um turno a alguns dias com a participação de stakeholders, usuários e equipe de TI.

A técnica inicia com a apresentação pelos protagonistas até aqui do Pré-Game daquilo que já sabemos sobre o projeto e colaborativamente estabelece-se um processo de entendimento em alto nível de abstração de quais são e o que são as funcionalidades e necessidades para o planejamento do projeto e produto.

Assim que a complexidade de cada item já é perceptível, a partir da comparação entre eles, contando com a experiência de cada um em projetos e produtos anteriores, é o suficiente para seguir adiante. Eu costumo dizer que o difícil é desapegar da necessidade de saber detalhes para estimar a complexidade:

Um bom release plan é a arte de apenas fazer as perguntas realmente necessárias e que contribuam para o entendimento de complexidade e comparação.

A necessidade e modelo mental é usar o conhecimento mínimo necessário para que todos na sala entendam a complexidade inerente a cada item discutido, sempre em alto nível, quer sejam histórias do usuário (interações funcionais), épicos ou features, histórias técnicas ou itens relevantes de TO DO LIST especiais, como negociações com outras equipes, alinhamentos, etc.

É desnecessário dizer que existem conhecimentos e boas práticas que usamos, como a criação de buffers frente a riscos, planejar de forma a prever menor entrega no início, obedecendo a Curva de Tuckman, bem como técnicas para reduzir a curva: Podemos errar, mas podemos usar gestão de riscos para evitar.

2. DoR (Definition of Ready) – iterativo

De posse de um Release Plan com abstrações de alto nível, o detalhamento entra em um ciclo virtuoso que gerará cadência e alta produtividade, onde normalmente com um sprint de antecedência parte da equipe irá detalhar melhor e documentar as histórias que serão desenvolvidas e entregues no sprint seguinte.

Descemos um nível na pirâmide, detalhando Regras de negócio e funcionais, UX e protótipos, SEO, cenários de testes e o que mais for acordado como sendo critérios de DoR pelo time, usualmente seguindo orientações corporativas de governança e PMO. Cadência, ciclos concorrentes onde ao mesmo tempo que desenvolve o que já foi detalhado para este sprint, outra parte detalha o próximo sprint.

3. DoD (Definition of Done) – iterativo

Os detalhes finais para implementação são de propriedade da equipe de desenvolvimento quando for desenvolver, recebendo o DoR das histórias do sprint corrente, devem fazer o “design” de engenharia de software, camadas e serviços, contratos de serviço entre elas.

Só no sprint vamos nos preocupar com detalhes técnicos, antes disso apenas sabemos osuficiente para dimensionar e confirmar se tal abstração de complexidade cabe ou não em cada sprint planejado. No Scrum a propriedade sobre implementação são responsabilidade da equipe dentro de cada sprint, desde que o DoR tenha sido atingido previamente, seguindo um Release Plan inicial.

A imagem abaixo é um desafio para ver se alguém entendeu os paranauês, porque apesar de ficar estranho o deslocamento na base, na prática é o que usualmente acontece, há um sprint #0 (zero) de preparação do primeiro DoR e a partir do sprint #1 entra em cadência. O sprint #0 é aproveitado para arquitetura-básica, organização, provas de conceito e etc, preparando os desenvolvedores a começarem nas melhores condições a sprint #1 e matarem a pau!

piramide abstração 4

piramide abstração 2 - scrum

Na prática, há um tanto de aprender fazendo, por isso é importante contar com alguém que já tenha alguma experiência ou tenha a manha da facilitação, porque manter o foco a cada momento no nível realmente necessário de abstração é uma construção coletiva.

EQUILÍBRIO

É claro que no Release Plan e DoR haverá momentos de incursão a detalhes conforme estes façam-se necessário, mas na prática a medida que uma equipe vai ganhando fluência em projetos ágeis, esta antecipação eventual ficará restrita a pontos obscuros, em que não há realmente clareza e somente com antecipação de maiores detalhes a complexidade se descortina. Mas na dúvida, pró-complexidade, em planning poker temos uma máxima, na dúvida entre 3 e 5, deve ficar 5, …

Isto é planejamento ágil e por isto a pirâmide das abstrações, sempre lembrando a Curva de Tuckman, a pirâmide é uma conquista que demanda tempo, experimentação, acertos e erros, esta experiência não se compra em drágeas na farmácia. Mas, por outro lado, com o passar do tempo é um conhecimento e habilidade que deve ser desenvolvida, senão há alguma coisa errada no seu Agile.

tirinha de humor5

3 comentários sobre “Be-a-Ba do planejamento ágil? Pirâmide das abstrações

    • O DoR estabelece os critérios que a própria equipe estabelece para dizer que uma história já está detalhada o suficiente para que os desenvolvedores entendam e desenvolvam bem feito, de forma produtiva, com qualidade e valor (ex: US, regras de neg e func, protótipo, cenários de testes).
      Já, o DoD são os critérios que estabelecem se uma história foi construída e “entregue” com sucesso. (ex: desenvolvido, commitado, versionado, com X% de cobertura, GC, publicado em ambiente de testes, testado sem bugs) …

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s