Declaração de Escopo ou Criar Backlog – Waterfall e Agile

Existe uma dúvida grande para quem esteve no mundo de projetos Waterfall e acabaram partindo para o Agile é:

No waterfall temos uma fase bem definida para documentação e aprovação de desenho de solução técnica logo antes do início dos desenvolvimentos (Declaração de Escopo) e como tratar esse item e em que momento fazemos isso no modelo Ágil?

É uma dúvida que sempre aparece em toda e qualquer discussão que encontro entre pessoas que estudaram e aplicavam waterfall e agora precisam entender onde no agile (Software em funcionamento mais que documentação abrangente) isso é possível.

Entendendo a documentação Waterfall x Agile

Mesmo em projetos ágeis existe sim a fase de escrita do backlog inicial de estórias (especificações) antes de se iniciar o desenvolvimento propriamente dito.

Entretanto, o que diferencia esta fase num projeto agile para o projeto Waterfall é que este backlog de itens inicia com uma maturidade e granularidade menor.

Primordialmente a equipe de desenvolvimento inicia os sprints com estórias pouco maduras – não mal especificadas, não entenda dessa forma, e sim com menos detalhes da solução final – já no decorrer do projeto com o feedback do cliente através das entregas feitas, o detalhamento e a maturidade do produto vai aumentando até o final do desenvolvimento.

Há de se salientar que não se sabe com exatidão no início do projeto quais serão todos os requisitos do projeto, o que vai evoluindo gradual e iterativamente.

Tão logo sejam produzidas estórias com detalhamento suficiente para o time iniciar o desenvolvimento, já se deve priorizar para o início.

Entretanto isto é bem diferente do waterfall onde TODOS os requisitos são levantados antes do projeto, criando uma declaração de Escopo do projeto e do Produto.

Consequentemente no agile ocorre da mesma forma que o waterfall, porém, não com o escopo completo, mas com partes valorosas e tecnicamente viáveis do mesmo – conhecido como MVP (Minimum Viable Product ou Minimum Valuable Product) – desenvolvidas durante iterações curtas, frequentes e contínuas.

Em suma a especificação técnica completa do escopo, antes do início do desenvolvimento em si, é o “abominado” BDUF1, principal característica que diferencia o ciclo waterfall de agile (agile = NO BDUF!).

Porém, ainda este detalhamento de pequenas partes do escopo, que é realizado antes das iterações, geralmente por POs – Product Owners, com a finalidade de deixar estas partes de escopo (e.g. Histórias de Usuários) em ready – isto é, prontas (maduras) para fazer – apesar de X contemplar a solução técnica Y, não contempla a especificação técnica detalhada.

Já a especificação técnica detalhada, a codificação e os testes (não necessariamente nesta ordem), incorporam tarefas realizadas durante as iterações.

A obscura Sprint Zero

Com o propósito de adaptar o agile numa estrutura híbrida – talvez por falta de entendimento do agile – alguns gerentes de projeto (agora Product Owners, Scrum Masters) acabam por utilizar a chamada Sprint 0.

Não se engane com a Sprint Zero, ela é tão boa e tão má quanto você quiser que ela seja.

Por exemplo em algumas empresas Brasileiras – como não conseguem “vender” um projeto sem passar por uma definição de escopo (ou montar um contrato agile2 – adotou-se em muitos lugares a Sprint 0 (Zero) em alguns lugares chamada de Fase de Discovery (acredito eu que esse nome de fase foi adaptado das metodologias SAP).

Desta maneira na fase de Discovery é identificado um “primeiro backlog” do projeto e as necessidades técnicas – como infraestrutura, envolvimento de equipes, etc.

Ataques dos Radicais Puristas

A Sprint Zero por pior que seja, em alguns círculos é considerada uma ótima prática, principalmente para fechar negócios com clientes antigos (aqueles acostumados com BDUF) quando você está migrando para a transformação digital.

Existem “puristas radicais agilistas” que são contrários a isto dizendo que estas coisas cascateiam o agile. Neste caso se isto for feito antes de cada Sprint, até concordo, senão começam a existir as famosas “sprints de…”, conhece?

  • Sprint de Especificação;
  • Sprint de Codificação;
  • Sprint de Testes;
  • Sprint de Homologação; e
  • Sprint de Bugfix.

Percebe que você começou a usar waterfall dentro do agile? Eu chamo de “CascatÁgil” aí não tem como te defender.

Sem dúvida e particularmente acho excelentes estes ciclos de descoberta colocados no início dos projetos, ou menores, antes de releases (considerando release como um conjunto de sprints), usando práticas colaborativas e disciplinadas como Design Sprint. Geram clareza e uma visão bem útil do escopo a ser entregue no ciclo, riscos, integrações, enfim.

Outras coisas importantes

Se você parar para pensar o Design Thinking3 também demanda tempo e consome parte da Sprint. Se quiser considerar algo fora da execução, ou de uma Sprint exploratória, acho que não há muito problema.

O importante é você entender que waterfall não é um processo. É um material de melhores práticas que em algum momento vocês optaram por uma razão específica.

O agile não ter funcionado em uma primeira tentativa, não quer dizer que não se adeque.

Mas há um trabalho de preparação e acompanhamento que o Scrum Master e o Product Owner precisam fazer em conjunto.

Quão grande este trabalho vai ser, depende da maturidade do time, exposição prévia ao agile e a sua própria postura frente a isto.

Mesmo que o Design Thinking e similares, em minha opinião, podem “tomar tempo” do projeto, mas nunca da Sprint, pois ele não é trabalho de Sprint. Nada que um bom plano não resolva. Não há problema algum, acredite.

Métodos, cultura e barreiras intransponíveis

O Waterfall é um ciclo de vida, e não um processo, um “Body of Knowledgement” ou um framework. Sempre disse que à partir do momento em que larguei a codificação diária para trabalhar com projetos eu passaria de códigos para pessoas (é aqui que mora o perigo do waterfall e do agile).

As organizações, através das pessoas, constroem métodos para este ciclo de vida e isto vira uma cultura quase intransponível.

E lá vai um pecado: sim, existem produtos e contextos em que o Waterfall é recomendado e deve continuar, até simultaneamente ao Agile, no portfólio.

Sim, antes da adoção de Agile, é fundamental tratar as principais dores da organização e persistir muito. Alguns casos de implantação que já duram 2 e 3 anos e ainda não é possível afirmar que são verdadeiros sucessos.

Utilizar Design Thinking dentro do tempo da sprint, NÃO! De maneira nenhuma Entendo que poderia sim fazer parte de uma fase de Discovery.

Sprint é para desenvolver o que foi refinado (ready) e entregar (done)!

Resumindo, o ponto principal, é saber que a gente pode colocar atividades de planejamento e estruturação antes de efetivamente entrar no desenvolvimento, sem desviar do conceito, capisce?

Por que a documentação do waterfall dentro de um ambiente agile não funcionou?

  1. Falta de comunicação e integração do time;
  2. Falta de definição e acordados entre todos, os critérios para ready;
  3. Não registro adequado da “documentação” de ready.
    Às vezes isto acontece porque os times (squads) acreditam que esta documentação é proibida e só pode existir post-its, quando na realidade isto é uma bobagem.
    Na verdade, os times usam ferramentas colaborativas como Confluence out até SharePoint para isto;
  4. Não existiram Product Owners ou ele(s) desconheciam suas responsabilidades e não fizeram um refinamento adequado das histórias, de forma disciplinada e envolvendo outras pessoas do time e/ou até outras áreas, como arquitetura, infra, operações, etc, gerando aquele efeito “surpreeesa” na hora H;
  5. Ao invés de histórias, o time começou a trabalhar com épicos e quando percebeu já estava dentro da Sprint; daí começou a entender melhor o escopo, começou a descobrir histórias e cortar ou incluir coisas (ou seja, caos, a visão do inferno);
  6. O time, além de aceitar histórias “cruas” (sem atingir ready), aceitou histórias demais.
    Isto é comum no início da adoção do agile e é por estas e outras que a maioria desiste.
    Normalmente nas primeiras sprints de um time, são colocadas poucas histórias, como se fossem “desentupidoras de cano”. Elas servem para o time (squad), entender a sua dinâmica, as suas dificuldades e, principalmente, a sua velocidade;
  7. E claro, a “cereja do bolo”: o Scrum Master não cumpriu o seu papel e não protegeu o time sobre todo este cenário caótico, até mesmo com um showstopper!

Lembre-se sempre, método x processo. Novamente a expectativa de migrar do waterfall para o Agile é que o ágil é considerado a varinha de condão…

O papel do Product Owner

Mas Coimbra, você acredita que o envolvimento na área de infraestrutura e outras áreas de TI é papel do PO? O PO já tem muito trabalho em envolver as áreas de negócio, vencer as resistências, como pode isso?

São estas questões muito delicadas. Dependem muito de como as organizações descrevem as roles PO, SM, PM, etc.

Na realidade, o time, deve garantir que todas as informações necessárias para desenvolver o escopo com qualidade técnica e sem riscos, sejam coletadas e registradas, atingindo o ready e, posteriormente, integrando o DoD (definition of done) do que será executado nas iterações.

Nas organizações que vêem o PO como parte ativa e integrante dos times, sim, é dele esta responsabilidade, geralmente acompanhado por alguém mais técnico do time.

Nos casos em que o PO é visto como um participante externo ao time, esta responsabilidade é do time.

De qualquer forma, nos dois cenários, o SM deve garantir que todas estas partes externas ao time – como infra, operações, segurança, governança, etc – sejam envolvidas.

Particularmente o primeiro cenário, onde o PO é parte integrante do time é um cenário que acredito ser mais saudável.

Projetos Híbridos e o consenso geral da nação

Inegavelmente você deve sempre buscar uma abordagem híbrida para o projeto, é o balanço entre planejamento em ondas sucessivas e iterações curtas para entregar incrementos que possam ser potencialmente liberados.

Com o propósito de melhorar a cada dia, vale a pena dar uma olhada em onion planning e rolling wave planning (RWP) para fazer um planejamento desde a visão, roadmap do produto, release planning até chegar no planejamento das iterações.

Uma vez que você não caiu no purismo da galera de que tudo se resolve com abordagens puramente ágeis. Em muitos ambientes (normalmente matriciais e bimodais) pode ocorrer o efeito rebote de gerar stress, cobranças, problemas de engajamento e de uniformidade na comunicação.

O Guia Ágil do PMI possui uma parte em que é mostrado como realizar um assessment da forma com que o projeto tem que ser conduzido. Recomendo a leitura.

Conclusão

Em resumo, documentação de escopo em waterfall e agile em ambos os casos o maior problema pode estar no processo e não no método.

Team contract, Definition of Done, sprints bem definidas com as epics, stories e tasks explicadas.

O PO e o SM precisam estar de olho no time e na visão, além de corrigir o rumo antes de terminar as iterações.

Em muitos casos deixamos de seguir um processo que tínhamos pensando porque o método traria novidades. Ledo engano.

Referências

  1. BDUF – Big Design Up Front
  2. Contratos para projetos ágeis – 10 tipos de contratos
  3. Entendendo como o Design Thinking, o Lean e o Agile trabalham juntos
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto. Agile Scrum Foundation (ASF) e DevOps Foundation pela Universidade Estabilis. Scrum Foundation Professional Certificate (SFPC) pela CertiProf, LLC.
DevOps Essentials Professional Cetificate (DEPC) pela CertiProf, LLC.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Coimbra, PMP

Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra. Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá. Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC. Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto. Agile Scrum Foundation (ASF) e DevOps Foundation pela Universidade Estabilis. Scrum Foundation Professional Certificate (SFPC) pela CertiProf, LLC. DevOps Essentials Professional Cetificate (DEPC) pela CertiProf, LLC. Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

%d blogueiros gostam disto: