{"id":7651,"date":"2018-06-28T14:21:07","date_gmt":"2018-06-28T17:21:07","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7651"},"modified":"2018-06-28T15:36:47","modified_gmt":"2018-06-28T18:36:47","slug":"agile-para-pmps-pmbok-para-agilistas-divide-et-impera","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2018\/06\/agile-para-pmps-pmbok-para-agilistas-divide-et-impera\/","title":{"rendered":"Agile Para PMPs, PMBoK Para Agilistas: divide et impera"},"content":{"rendered":"

SPOILER ALERT – Para voc\u00ea que bateu o olho neste text\u00e3o e achou TLTR (ou Too Long To Read), inclu\u00ed uma tabela comparativa ao final, como resumo do blog post.<\/span><\/i><\/p>\n

 <\/p>\n

Divide et impera <\/span><\/i>– Dividir para conquistar. C\u00e9sar, Napole\u00e3o e outros grandes gestores provavelmente n\u00e3o constru\u00edam EAPs (Estrutura anal\u00edtica do projeto) e nem montavam Story Maps com post-its para planejar a conquista de territ\u00f3rios b\u00e1rbaros, mas j\u00e1 utilizavam o conceito que est\u00e1 por tr\u00e1s dessas t\u00e9cnicas: quebrar partes maiores de escopo em partes menores e mais gerenci\u00e1veis.<\/span><\/p>\n

 <\/p>\n

\"napole\u00e3o<\/p>\n

 <\/p>\n

Vamos ser humildes e assumir: n\u00e3o d\u00e1 para assoviar e chupar cana ao mesmo tempo. Embora eu mesmo nunca tenha tentado realizar essa proeza, penso que esse dito popular expressa bem a ideia de que nossa limitada mente humana n\u00e3o \u00e9 muito boa na execu\u00e7\u00e3o de v\u00e1rias tarefas simult\u00e2neas e muito menos no planejamento de v\u00e1rios assuntos ao mesmo tempo. Nosso c\u00e9rebro pode at\u00e9 ser um processador super-poderoso, mas ainda assim tem apenas um \u00fanico n\u00facleo. <\/span><\/p>\n

Pensar em estrat\u00e9gias de solu\u00e7\u00e3o de problemas grandes e complexos \u00e9 uma tarefa quase imposs\u00edvel, porque envolve atacar diversos aspectos desses problemas ao mesmo tempo. Por isso, dividir o escopo de um empreendimento em partes menores e mais gerenci\u00e1veis \u00e9 a estrat\u00e9gia que vem obtendo o maior grau de sucesso na Hist\u00f3ria, pois nos permite focar em uma coisa por vez, respeitando assim nosso limite humano de processamento. <\/span><\/p>\n

Al\u00e9m de aliviar as coisas pro nosso c\u00e9rebro, essa estrat\u00e9gia tem outras vantagens como prevenir o famoso <\/span>scope creep<\/span><\/i>, um dos maiores vil\u00f5es na gest\u00e3o de qualquer iniciativa, e facilitar o gerenciamento da execu\u00e7\u00e3o, etapa em que o produto \u00e9 constru\u00eddo. N\u00e3o quero deixar este text\u00e3o ainda maior ent\u00e3o n\u00e3o vou me aprofundar nos aspectos da constru\u00e7\u00e3o, mas tem uma coisa que eu tenho que destacar: uma estrat\u00e9gia eficiente de execu\u00e7\u00e3o depende necessariamente da quebra desse escopo em peda\u00e7os menores. Como dizem os adeptos do m\u00e9todo Kanban: o problema n\u00e3o \u00e9 o Waterfall, \u00e9 o tamanho do lote que \u00e9 grande demais.<\/span><\/p>\n

Para fazer a divis\u00e3o descrita acima, o PMBoK apresenta a EAP – Estrutura anal\u00edtica do projeto, do ingl\u00eas WBS – Work Breakdown Structure. Voc\u00ea pode at\u00e9 ter desconfiado, mas n\u00e3o foi a galera da Sess\u00e3o da Tarde que fez essa tradu\u00e7\u00e3o. Talvez o melhor seria “Estrutura do projeto quebradinho”, mas o termo “anal\u00edtico” \u00e9 mais apreciado no erudito e rebuscado idioma Consult\u00eas Erudito, aquele que os consultores do passado usavam para dificultar a comunica\u00e7\u00e3o com o cliente e parecerem mais s\u00e1bios do que realmente eram. J\u00e1 nos projetos \u00e1geis, a t\u00e9cnica mais comumente utilizada \u00e9 o Story Mapping – Mapeamento de hist\u00f3rias. Felizmente ainda n\u00e3o inventaram uma tradu\u00e7\u00e3o a l\u00e0 “Estrutura anal\u00edtica das hist\u00f3rias”.<\/span><\/p>\n

Apesar de ambas as t\u00e9cnicas serem baseadas no conceito de break down – que significa quebrar em peda\u00e7os menores, apesar de \u00e0s vezes esse trabalho dar vontade de chorar – \u00a0sua aplica\u00e7\u00e3o e abrang\u00eancia s\u00e3o diferentes. Essa diferen\u00e7a faz com que essas t\u00e9cnicas possam ser usadas de maneira complementar, com uma cobrindo os pontos fracos da outra. Logo, conhecer as nuances das duas ferramentas pode ajudar meus amigos PMPs a gerenciar melhor seus projetos, assim como \u00a0conhecer a EAP pode abrir a mente dos meus amigos agilistas para dimens\u00f5es que nem sempre s\u00e3o consideradas em iniciativas \u00e1geis. O intuito desse texto n\u00e3o \u00e9 ensinar a usar uma t\u00e9cnica ou outra. \u00c9 apenas compar\u00e1-las e provocar os leitores a abrirem a mente e a se aventurarem na utiliza\u00e7\u00e3o de t\u00e9cnicas diferentes. Portanto, adotei a licen\u00e7a po\u00e9tica de simplificar alguns conceitos para facilitar a compara\u00e7\u00e3o, ok? N\u00e3o precisa me xingar nos coment\u00e1rios.<\/span><\/p>\n

Como eu sou f\u00e3 de Kanban e do algoritmo FIFO (<\/span>first in, first out)<\/span><\/i>, comecemos pelo que veio antes. A EAP \u00e9 apresentada como a ferramenta para detalhar o que um <\/span>projeto<\/b> deve entregar, e isso \u00e9 muito importante. Hoje em dia, o termo “projeto” virou sin\u00f4nimo de iniciativa, mas idealmente, esse projeto \u00e9 uma iniciativa com in\u00edcio, meio e fim. Ou seja, pro PMBoK, n\u00e3o basta ser iniciativa, tem que ter a “terminativa” tamb\u00e9m. Esse conceito marca a gest\u00e3o de projetos de forma t\u00e3o importante que, parafraseando o professor Rodrigo Caixeta l\u00e1 da ProjectLab: “<\/span>\u00c9 melhor um fim horroroso do que um horror sem fim<\/span><\/i>“. Por isso, apesar de ter algum n\u00edvel de flexibilidade e estar sujeito \u00e0 mudan\u00e7as ao longo do projeto, o escopo tem um limite, porque o projeto tem um limite. <\/span><\/p>\n

Um dos motivadores da utiliza\u00e7\u00e3o de m\u00e9todos \u00e1geis \u00e9 a volatilidade que o mercado imprime aos projetos. Esperar um marco t\u00e3o raro quanto o fim do projeto para tomar decis\u00f5es e reavaliar estrat\u00e9gias pode levar ao desperd\u00edcio. \u00c0s vezes, quando um produto \u00e9 entregue, j\u00e1 n\u00e3o faz mais sentido. Por isso, quando usamos ferramentas mais \u00e1geis como o mapa de hist\u00f3rias, ou melhor, Story Mapping, o fim do projeto, ou o limite do escopo n\u00e3o \u00e9 t\u00e3o importante pois essa t\u00e9cnica tem uma vis\u00e3o mais abrangente, mais pr\u00f3xima do ciclo de vida de um produto (n\u00e3o quer dizer que n\u00e3o exista expectativa por prazo; depois cheque <\/span>esse blogpost aqui<\/span><\/a>). O ciclo de vida de um produto \u00e9 afetado por diversos projetos com objetivo de evoluir esse produto. O mapa de hist\u00f3rias pode representar, entre outras coisas, o escopo do roadmap de evolu\u00e7\u00e3o deste produto.<\/span><\/p>\n

 <\/p>\n

Numa abordagem h\u00edbrida da vis\u00e3o de roadmap, cada pequeno incremento na evolu\u00e7\u00e3o do produto \u00e9 realizado por uma itera\u00e7\u00e3o, que pode ser representada por um projeto (ou fase de um projeto), que por sua vez, pode ser representado por uma EAP, mais ou menos como demonstrado na figura abaixo:<\/span><\/p>\n

 <\/p>\n

\"ciclo<\/p>\n

 <\/p>\n

Visualmente, a EAP \u00e9 representada como um organograma, onde todo o escopo \u00e9 “subordinado” ao projeto. Embora a EAP seja um artefato atemporal, isto \u00e9, sem rela\u00e7\u00e3o com o cronograma do projeto e com a ordem em que devem acontecer as entregas, seus primeiros n\u00edveis n\u00e3o representam pacotes em si, mas sim divis\u00f5es l\u00f3gicas que buscam organizar a estrat\u00e9gia de entrega do escopo do projeto. Num segundo n\u00edvel de divis\u00e3o est\u00e3o os grupos de pacotes (ou produtos). Os pacotes de entrega, ou seja, o escopo em si, s\u00e3o representados no \u00faltimo n\u00edvel da EAP, mais ou menos assim:<\/span><\/p>\n

 <\/p>\n

\"\u00faltimo<\/p>\n

 <\/p>\n

Embora exista um certo preconceito contra o gerente de projetos “tradicional” e muita gente acredite que para o PMBoK seja fun\u00e7\u00e3o desse gerente elaborar a EAP sozinho, a verdade \u00e9 que o processo de constru\u00e7\u00e3o da EAP, a exemplo do Story Mapping, deve ser feita de forma iterativa e colaborativa com a equipe do projeto e das principais partes interessadas. A diferen\u00e7a \u00e9 que o processo iterativo de planejamento descrito no PMBoK recomenda que a constru\u00e7\u00e3o da EAP passeie por todas as <\/span>\u00e1reas de conhecimento do projeto<\/b>, ou seja, ao elaborar o cronograma, estrat\u00e9gia de gest\u00e3o de riscos, gest\u00e3o de pessoas, contratos e terceiriza\u00e7\u00e3o, gest\u00e3o de partes interessadas, gest\u00e3o de qualidade, gest\u00e3o de comunica\u00e7\u00e3o, gest\u00e3o de custos etc., dando visibilidade a outras dimens\u00f5es do projeto, que t\u00e9cnicas mais light acabam ignorando.<\/span><\/p>\n

A t\u00e9cnica de constru\u00e7\u00e3o da EAP tem o objetivo final de gerar um baseline do escopo do projeto ou de parte dele. Ou seja, a partir da constru\u00e7\u00e3o deste artefato, \u00e9 gerado um compromisso para o projeto ou para uma fase do projeto. \u00a0Outra ideia falsa que \u00e9 espalhada em confer\u00eancias mundo afora, \u00e9 a que os processos do PMBoK tornem necess\u00e1rio fazer um “<\/span>waterfall”<\/span><\/i> e construir todo a EAP detalhada do projeto de uma vez s\u00f3. A EAP tamb\u00e9m pode ser elaborada iterativa e incrementalmente, por fase de projeto, onda, sprint etc., e permitir a descoberta gradual do escopo. No meu ponto de vista, a principal desvantagem da EAP em rela\u00e7\u00e3o ao Story Mapping \u00e9 que a obrigatoriedade de um compromisso com os pacotes da EAP n\u00e3o permite uma vis\u00e3o clara de prioriza\u00e7\u00e3o, dado que todos os pacotes tem a mesma import\u00e2ncia. Como consequ\u00eancia da aus\u00eancia dessa vis\u00e3o, o time do projeto pode ser direcionado a entregar tudo o que foi mapeado, mesmo que em dado momento do projeto esses pacotes n\u00e3o fa\u00e7am mais sentido.<\/span><\/p>\n

O Story Mapping n\u00e3o traz a ideia do compromisso representado pela EAP de maneira t\u00e3o forte. Essa flexibilidade tem origem no pr\u00f3prio manifesto \u00e1gil que foca em “<\/span>responder \u00e0 mudan\u00e7as mais do que seguir um plano<\/span><\/i>“. Isto \u00e9, mais do que uma ferramenta de levantamento de escopo, o Mapa de Hist\u00f3rias \u00e9 uma ferramenta \u00a0para maximiza\u00e7\u00e3o do valor entregue por esse escopo. O ponto de comprometimento depende muito mais do m\u00e9todo de trabalho adotado pela equipe; Por exemplo, pode ocorrer no “<\/span>Replenishing<\/span><\/i>” do Kanban ou no “<\/span>Sprint Planning<\/span><\/i>” do Scrum. <\/span><\/p>\n

Existem diversas formas de representar um mapa de hist\u00f3rias. Uma das vers\u00f5es mais comuns apresenta pelo menos duas dimens\u00f5es temporais. A primeira dimens\u00e3o temporal \u00e9 chamada de <\/span>Backbone – <\/span><\/i>espinha dorsal. Ela representa o fluxo de valor e fica logo ao topo do mapa. O fluxo de valor \u00e9 lido da esquerda para a direita e \u00e9 escrito na ordem em que acontecem as grandes atividades que o usu\u00e1rio poderia realizar. Esse fluxo \u00e9 dividido para representar o passo a passo daquela grande atividade. Essa divis\u00e3o \u00e9 chamada de “esqueleto andante”. Para cada atividade, s\u00e3o mapeadas as hist\u00f3rias de usu\u00e1rio, essas sim representando “requisitos” ou “caracter\u00edsticas” do produto. <\/span><\/p>\n

\"sentido<\/p>\n

Um dos princ\u00edpios do Manifesto \u00c1gil \u00e9 a \u00a0Simplicidade: a arte de maximizar a quantidade de trabalho que n\u00e3o precisou ser feito. O mapa de hist\u00f3rias provoca a discuss\u00e3o sobre MVP – <\/span>Minimum Viable Products, <\/span><\/i>ou<\/span> “Produtos M\u00ednimos Vi\u00e1veis”. Numa vis\u00e3o simplificada, esses produtos representam um agrupamento de hist\u00f3rias e features que visam entregar a menor quantidade de escopo poss\u00edvel para que seja realizado um lan\u00e7amento (release) que traga valor para produto, do ponto de vista do cliente\/usu\u00e1rio. Pelo lan\u00e7amento “minimizado”, \u00e9 poss\u00edvel testar se o produto entrega o valor esperado. Mais ainda, \u00e9 poss\u00edvel obter o feedback do produto final e assim re-priorizar o escopo do projeto. Dessa maneira o Story Mapping direciona a efici\u00eancia (fazer menos) com a efic\u00e1cia (fazer o que \u00e9 preciso).<\/span><\/p>\n

O Story Mapping foca no valor entregue para o usu\u00e1rio final, mas n\u00e3o considera por exemplo, a influ\u00eancia de outras partes interessadas da organiza\u00e7\u00e3o e seu impacto no processo de constru\u00e7\u00e3o em si. Uma estrutura mais completa como a EAP garante que al\u00e9m do usu\u00e1rio final, ser\u00e1 entregue valor a todos os envolvidos no projeto, gerenciando expectativas e outros aspectos pol\u00edticos, \u00a0pois ela reconhece a exist\u00eancia de duas origens distintas de escopo: o Escopo do Produto e o Escopo do Projeto. Por exemplo, considere que seu projeto precisa entregar um Ovo para gerar valor para o cliente final. T\u00e1, \u00e9 um exemplo besta, mas \u00e9 f\u00e1cil de entender e simples de desenhar:<\/span><\/p>\n

\"o<\/p>\n

Um Story Mapping mapearia esse ovo. A EAP iria mais al\u00e9m: mapear o Ovo, mas tamb\u00e9m mapearia a necessidade de Constru\u00e7\u00e3o da Galinha, o que pode ser um processo bem mais complexo que o Ovo em si. Note que frequentemente existe certa frustra\u00e7\u00e3o por parte dos times de projetos \u00e1geis, pois os aspectos da Galinha frequentemente limitam e bloqueiam a evolu\u00e7\u00e3o da entregas do Ovo. Principalmente quando deparado com um projeto h\u00edbrido ou em escala organizacional \u00e9 bastante comum que a equipe do projeto tenha que entregar coisas chatas e complexas como:<\/span><\/p>\n

 <\/p>\n