├── LICENSE ├── nao-saber-aquilo-que-fazemos.md ├── ser-honesto.md ├── planning-poker.md ├── README.md ├── dividir-para-conquistar.md └── errar-por-preguica.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Thiago M Pereira 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | -------------------------------------------------------------------------------- /nao-saber-aquilo-que-fazemos.md: -------------------------------------------------------------------------------- 1 | # Não prestamos a devida atenção naquilo que fazemos 2 | 3 | Frequentemente em nossa indústria, fazemos as coisas acontecerem, ou seja, recebemos informação e desenvolvemos essa informação, seja em forma de projeto ou em user stories. 4 | 5 | Dado isso, teremos o cenário onde normalmente o time de engenharia não se preocupa com a questão de estimativas ou de prazos, até porque esse tipo de informação normalmente algumas pessoas que estão no dia a dia do time acabam fazendo, como é o caso de um Scrum Master, Agile Coach, Product Owner ou Product Manager. 6 | 7 | Agora, no nosso dia a dia dentro de um time de engenharia, conseguimos extrair dois tipos de informação que são fundamentais para o sucesso do trabalho, que são: 8 | 9 | 1. Aquilo que mais nos deu trabalho para concluir; 10 | 2. Aquilo que foi mais fácil de concluir. 11 | 12 | Essas duas informações são o ponto inicial para que o nosso planejamento possa ter sucesso a médio e longo prazo, e quando eu digo longo prazo é justamente a parte de implementar uma idéia que possa ser aceita pelo time, e quando falamos de estatística, temos que ter um bocado mais de tato, porque temos que usar os números SEMPRE em prol do time, a fim de motivá-los e nunca deixar que o desânimo possa tomar conta. 13 | 14 | ## Conclusão 15 | 16 | Para fechar esse tópico, podemos pensar em maneiras de melhorar o nosso onboarding, ensinando e evangelizando sobre filosofia ágil e como que ela é aplicada no contexto da empresa e o mais importante, incentive as pessoas a não apenas olhar os princípios do manifesto, e sim que elas possam buscar conhecimento por cada um dos que estavam lá e evitar cair nas buzzwords. 17 | 18 | [Início](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/README.md) -------------------------------------------------------------------------------- /ser-honesto.md: -------------------------------------------------------------------------------- 1 | # Ser honesto na hora de estimar 2 | 3 | No novo livro do Robert "Uncle Bob" Martin, Clean Agile, tem um capítulo que fala sobre estimativas honestas e em poucas palavras, ele fala: 4 | 5 | "The most honest estimate is "I don´t know". However, that estimate is not complete. You may not know everything, but there are some things you do know. So I expect you to provide estimates based on what you know." 6 | 7 | Em PT-BR 8 | 9 | "A estimativa mais honesta é "não sei". No entanto, essa estimativa não está completa. Você pode não saber tudo, mas há algumas coisas que você sabe. Então, espero que você forneça estimativas com base no que sabe." 10 | 11 | Com base nisso, tracei um paralelo com diversas vezes que estimamos por medo ou por querer agradar, ou melhor, não desagradar a área de produto, arquitetos, tech leads, enfim, o meio da pirâmide e isso nos traz consequências muito ruins ou até mesmo ligamos o botão dos "5 story points", que eu chamo de estimativa "em cima do muro", como falado no tópico sobre [errar por preguiça](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/errar-por-preguica.md). 12 | 13 | Enquanto não tivermos honestidade em estimar e tirarmos o medo da frente dos olhos, dificilmente iremos entregar valor nos sprints, e o resultado disso sabemos qual é: 14 | 15 | - Desmotivação do time, porque ninguém gosta de trabalhar 2, 3, 4 sprints NA MESMA estoria; 16 | - Desconfiança da área de produto para com o time de desenvolvimento; 17 | - Pressão pela entrega; 18 | - Falta de qualidade, pois na hora do aperto vão falar pra abrir mão da qualidade; 19 | - Turnover começa a crescer, principalmente entre aqueles que a voz é ignorada. 20 | 21 | ## Conclusão 22 | 23 | Na minha opinião, prefiro errar por convicção., pois consigo melhorar e adaptar sprint a sprint, do que errar por omissão, ou como falamos anteriormente, por preguiça, porque essa omissão é muito obscura, ou seja, jamais saberemos onde se encontra o ponto de melhoria porque o erro não traduz em estimativas e criamos o efeito bola de neve, porque não vamos conseguir estimar o "mais próximo da realidade", vamos colocar qualquer estimativa para que o planning acabe logo, vou trabalhar por X sprints na mesma estoria e seguir a vida. 24 | 25 | Que no planning possamos ser honestos para que não caiamos na esfera da desmotivação. 26 | 27 | 28 | [Início](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/README.md) -------------------------------------------------------------------------------- /planning-poker.md: -------------------------------------------------------------------------------- 1 | # Planning Poker 2 | 3 | Lembra quando falamos sobre a questão do comparativo, pois bem, no planning poker devemos sempre nos perguntar e comparar as estorias que foram feitas em sprints aneriores (ou olhar para a nossa régua) para estimarmos com um pouco mais de precisão. Quando estamos diante de estimar alguma estoria, devemos antes de mais nada abrir a nossa régua (caso exista) ou trazer as estorias que foram feitas no último sprint e utilizar a estimativa para comparar o grau de dificuldade, lembrando que toda estimativa **DEVE** estar em total concordância com todos os integrantes do time. Após concordar e mesmo assim haver divergência entre ser mais fácil ou mais difícil, jogaremos o planning poker até chegarmos em um acordo e claro, podemos utilizar o exercício de [2 minutos de reflexão](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/errar-por-preguica.md) e evitem puxar a estimativa para baixo e parem de jogar planning poker quando todos os integrantes do time entrarem em acordo. 4 | 5 | **Cuidado para não induzir a pontuação, principalmente entre os mais Jrs ou entre os mais novos de casa.** 6 | 7 | Geralmente não enxergamos valor no planning poker porque temos sempre um time-box a cumprir, uma área de produto que "tem mais o que fazer", ou temos que entregar o sprint corrente e se quisermos reverter esse quadro, que possamos nos cobrar durante o planning poker, porque sabemos claramente quando as pessoas entram no modo automático para estimar. 8 | 9 | Muitas vezes o planning poker não flui porque em todos os sprints erramos nossa estimativa, então, de que adianta dar uma pontuação "sabendo" que vamos errar de novo? E por esse motivo, temos que enxergar mais valor, comparar e seguir em frente que vamos evoluindo inclusive nesse aspecto. 10 | 11 | ## 5 absoluto 12 | 13 | Considerando que time nenhum usa 21 para estimar algo, consideraremos a sequência fibonacci 2, 3, 5, 8 e 13 e olha lá quem ta no meio disso tudo, ele mesmo, o famoso 5 e ele não está ali a toa, está ali porque, como eu gosto de dizer, em times que não tem maturidade ou não tem o hábito de comparar ou ver valor no planning, usa o 5 para estar legal com todo mundo (não vai querer desagradar produto e nem engenharia), ou em outras palavras, é a estimativa daqueles que estão em cima do muro e em times bagunçados, é o número que mais aparece, o que mais erramos e o que mais perpetua por vários sprints a fio. 14 | 15 | **"Contestar"** o 5 é difícil demais para porque o padrão de comportamento está intrínsico no time e até no planning poker o uso do 5 está **"viciado"**, então temos duas opções: "confiar no time e conviver com o fracasso sprint a sprint" ou "mudar a forma de fazer as mesmas coisas". 16 | 17 | ## Conclusão 18 | 19 | Planning poker é uma maneira elegante de estimarmos tarefas e pelo que eu percebo dos times que eu entro, é que a falta de paciência na segunda rodada do poker a ansiedade por sair da reunião aumenta, portanto, exercício de pensar o máximo de tempo ajuda a não ter essa ansiedade e além disso podemos utilizar técnicas de [**Refinement**](https://www.scrum.org/resources/blog/scrum-trenches-product-backlog-refinement-scrum-team-responsibility). 20 | 21 | [Início](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/README.md) -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Dividir para conquistar 2 | 3 | A ideia desse material é mostrar como o processo de previsibilidade, planejamento e estimativa que estamos acostumados a fazer, seja pelas buzzwords ou simplesmente pelo que ouvimos falar está totalmente desalinhado com o conhecimento base em métodos ágeis e como voltar as origens faz com que tenhamos sucesso. 4 | 5 | ## Bases literárias 6 | 7 | Como base desse material, estou utilizando duas fontes fidedignas, que são Jeff Sutherland (criador do Scrum e o livro Scrum - A arte de fazer o dobro do trabalho pela metade do tempo) e Robert C. Martin (Uncle bob), e no caso do Bob Martin, to usando duas referências literárias (Agil Estimating and Planning & Clean Agile - Back to Basis). 8 | 9 | ## Introdução 10 | 11 | Nesses quase dez anos trabalhando com "métodos ágeis" (o que não quer dizer que algum lugar que passei chegasse a 50% das práticas supostas), um do maiores desafios é justamente quando falamos de estimativas e previsibilidade das coisas e nesse sentido, sempre somos pegos de surpresa para responder "Quando isso tudo vai ficar pronto?" e claro que a resposta vem imediata, dotada do senso de incerteza com uma dose de coragem, que tem base na mais profunda mentira, misturada com a km do vento ao soprar ao norte, e assim se resulta numa previsão "tosca" que nunca será cumprida, os stakeholders passarão a não confiar na equipe de desenvolvimento, o clima de incerteza é instaurado, o turnover aumenta junto com a pressão e assim seguimos fazendo aquilo que achamos correto fazer, ou em outras palavras, uma tremenda bagunça. 12 | 13 | Quando vamos ao **Google** buscar o termo metologias ágeis, hora ou outra vamos nos deparar com o [Manifesto para Desenvolvimento Ágil de Software](https://agilemanifesto.org/) e claro que sabemos do que se trata não é mesmo: 14 | 15 | - **Indivíduos e interações mais que processos e ferramentas** 16 | - **Software em funcionamento mais que documentação abrangente** 17 | - **Colaboração com o cliente mais que negociação de contratos** 18 | - **Responder a mudanças mais que seguir um plano** 19 | 20 | Mas com base nisso, a boa parte dos times de engenharia, quando passam pelo onboarding da empresa, não passam pelo processo de entendimento sobre o que eu chamo de "filosofia ágil", ou seja, entender a história por trás do manifesto, entender os quatro grandes tópicos e o que cada um deles representam, ler algo sobre ao menos algum dos integrantes que lá estavam,como por exemplo, **Kent Beck** (Extreming Programming), **Jeff Sutherland** (Criador do Scrum), **Bob Martin** (Clean Code, Clean Agile, Clean Coder, etc), **Andy Hunt & Dave Thomas** (Pragmatic Programming), **Martin Fowler** (TDD), **Brian Marrik** (The Craft of Software Testing), provavelmente você que está lendo sequer sabe quem são certo? E claramente quando acessamos o site do Manifesto Ágil, olhamos apenas para os quatro valores, ignorando a lista daqueles que estavam lá definindo isso. Dado isso, segue a lista para que possamos ao menos dar um Google em cada um deles para ao menos conhecer o motivo pelo qual cada um deles eram considerados os maiores especialistas na época: 21 | 22 | - Kent Beck 23 | - Mike Beedle 24 | - Arie van Bennekum 25 | - Alistair Cockburn 26 | - Ward Cunningham 27 | - Martin Fowler 28 | - James Grenning 29 | - Jim Highsmith 30 | - Andrew Hunt 31 | - Ron Jeffries 32 | - Jon Kern 33 | - Brian Marick 34 | - Robert C. Martin 35 | - Steve Mellor 36 | - Ken Schwaber 37 | - Jeff Sutherland 38 | - Dave Thomas 39 | 40 | Sei que é meio complicado lembrar dos nomes de quem estava lá, mas somos os primeiros a criticar quando vem um Product Manager cheio de documentação e comunicação por email e lá dizemos **"Indivíduos e interações mais que processos e ferramentas"** ou **"Software em funcionamento mais que documentação abrangente"**, mas sequer sabemos o que de fato foi pensado e por quem foi pensado. Por trás da filosofia ágil se encontra o uso da técnica do TDD e simplesmente continuamos a dizer que isso não funciona, sendo que o próprio Kent Beck estava lá colaborando no dia do manifesto e que entraram em um acordo que para ser ágil seria necessário a prática de TDD também, assim como técnicas de entrega contínua e indo um pouco além, quando falamos em métodos ágeis, ao lembrar dos valores, chegamos também de forma macro a valores do Extreme Programming (Comunicação, Simplicidade, Feedback, Coragem e Respeito) também criado por Kent Beck e ainda persistimos em dizer que XP não funciona e olha só que legal, o primeiro valor do manifesto ágil foi idealizado pelo próprio Kent Beck e não tem nada a ver com o que costumeiramente pensamos sobre mandar uma mensagem no slack pro product owner é pior que ir lá falar com ele, pelo contrário, tem a ver literalmente com a comunicação efetiva e feedback contínuo com a própria equipe de engenharia (o livro Clean Agile do Robert "Uncle Bob" Martin fala sobre isso). 41 | 42 | Quando chegamos ao estado caótico, optamos por olhar para o mercado atrás de gurus que supostamente resolveriam os problemas que sabemos como resolver, mas temos demasiado ego inflado pra assumir que o que fazemos é uma verdadeira porcaria não é mesmo? 43 | 44 | Antes de chegar numa solução, que tem por base voltar para o "básico" do Agile, vamos entender o que de fato nos leva ao desespero: 45 | 46 | 1. [Não prestamos a devida atenção naquilo que fazemos;](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/nao-saber-aquilo-que-fazemos.md) 47 | 2. [Erramos porque somos preguiçosos;](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/errar-por-preguica.md) 48 | 3. [Planning Poker](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/planning-poker.md) 49 | 4. [Ser honesto ao estimar](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/ser-honesto.md) 50 | 5. [Dividir para conquistar](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/dividir-para-conquistar.md) -------------------------------------------------------------------------------- /dividir-para-conquistar.md: -------------------------------------------------------------------------------- 1 | # Dividir para conquistar 2 | 3 | Calma, não vamos falar da técnica em si, utilizada por Júlio Cesar, detalhada em seu [livro **De Bello Gallico** (Guerra das Gálias)](shorturl.at/fkyKT), que explicou como a vitória romana na guerra gaulesa era essencialmente uma política de “dividir” seus inimigos, aliar com tribos individuais durante suas disputas com adversários locais. 4 | 5 | Trazendo isso para o contexto Ágil, gosto do termo dividir para conquistar quando tratamos de **SPLIT** de estórias de usuário, que consiste em dividir uma estoria em diversas outras menores para que possamos entregar valor sempre, que a estória possa ser planejada de maneira mais eficaz, mais acertiva e claro, que possamos entrar em um processo de entrega daquilo que é suposto entregarmos (em termos de story points por iteração). 6 | 7 | ## Por que devemos dividir? 8 | 9 | A resposta é simples: "Dar visibilidade do que está sendo feito". É muito cômodo pra nós, do time de desenvolvimento pegar coisas para fazer sem nos preocupar com que outras pessoas pensam, ou melhor, sobre o que o nosso utilizador final pensa, no que nossos stakeholders pensam, no que nosso produto pensa e isso é algo muito comum, porque somos acostumados a tomar pancadas e não nos preocuparmos com isso, pois pensamos que a empresa vai sobreviver ou pensamentos do tipo "novidade estarem chateados conosco por não entregarmos DE NOVO". 10 | 11 | Outro motivo que eu uso para incentivar a divisão de estória é para evitarmos todo sprint ter perguntas de "Quando vai ficar pronto?", "Nossa, faz dois sprints que a estória não muda de status, o que está acontecendo?" e por ai vai. 12 | 13 | Eu sou um profissional que odeia passar vergonha e vamos lá, começar uma estória, dizer que vamos entregar no final do sprint e levar 4 para terminar é motivo de muita vergonha, é gostar de levar na cara e ser taxado de incompetente. 14 | 15 | Eu entendo que é um complicado dividir, mas custa nada parar um pouco para pensar em como podemos fragmentar a estória, e por isso vou dar algumas dicas que foram obtidas dos livros "Agile Estimating and Planning" e "Clean Agile - Back to Basis" do Bob Martin. 16 | 17 | - Dê o primeiro passo e decida o que é uma estória grande, ou seja, você pode definir 13 como uma estória muito grande e complexa e decidir não colocar isso dentro de um sprint. 18 | Sei que vai doer, mas não aceite e não se submeta a prometer uma estória que você sabe que não vai cumprir. 19 | 20 | - Após decidir, que sejamos honestos em nossas estimativas, ou seja, se temos duas estórias com 8 pontos, mas uma é mais difícil que a outra, essa deve ser 13, logo, não vai entrar, logo, **DEVE** ser dividida em várias partes. 21 | 22 | - Estime novamente cada fragmento da estória, lembrando que devemos comparar inclusive os fragmentos, ou seja, não é porque a estória é de 13 que eu tenho que fragmentar em duas de 5 story points e uma de 3 story points. 23 | O exercício de estimar é interessante, porque na comparação dos fragmentos podemos ver que o 13 não era bem 13 e que era bem mais que isso, como ocorreu semanas atrás no time que eu atuo, onde ao dividirmos, chegamos em um fragmento que era outro 13 e dividimos de novo e no final chegamos a ter 12 estorias, totalizando em quase 47 story points e lembre-se, derivamos uma estória de apenas 13 em 47 story points só utilizando a comparação como parâmetro para estimar. 24 | 25 | **OBS.:** Se o time ainda não possui maturidade para duas ou mais pessoas trabalharem em cada fragmento da estória, priorize os fragmentos, suba uma estória para o sprint e as demais fiquem priorizadas no backlog. Digo isso porque sabemos que nem sempre é possível escrever uma estória utilizando de maneira [**INVEST**](https://bit.ly/2seGEMl) e que leva tempo para o time de desenvolvimento passar a trabalhar em pair ou ambos no mesmo contexto. 26 | 27 | ## Tarefas de até um dia 28 | 29 | Um maneira interessante, e que eu aprendi no momento em que eu deixei o waterfall, foi que criar tarefas no momento do planejamento ajuda a ter sucesso na entrega e melhor ainda, quando eu divido uma estória em diversas sub tarefas, consigo perceber o tamanho real do que nos espera. 30 | 31 | Infelizmente na maioria dos times, quando quebramos tarfas, pegamos alguns contextos macros e colocamos como tarefa, o que faz estorias muito grandes com apenas quatro tarefas, o que é ruim, porque gera uma expectativa muito grande para nossa área de produto, que vai ver uma estoria com quatro tarefas e vai achar que aquilo é pequeno e o resultado já sabemos, não vamos entregar, área de produto vai ficar chateada, vai gerar incertezas e cobranças, bla bla bla. 32 | 33 | Então além de quebrar, que possamos pensar e incentivar a quebra de tarefas e sub-tarefas de até um dia para serem feitas. Isso vai ajudar a ter visibilidade real do que é necessário ser feito para que aquela estoria possa ir para produção e o mais interessante, quando realizamos esse exercício de pensar em tarefas de até um dia, conseguimos chegar as vezes na conclusão de que estimamos muito abaixo ou muito acima, o que pode fazer nossa estimativa mudar. Esse percepção faz com que aos poucos, vamos tendo maturidade em planejar e estimar estorias. 34 | 35 | ## Comparar 36 | 37 | Sim, invistam tempo comparando o esforço entre duas ou mais estorias, pois assim conseguimos voltar um bocado ao passado para conseguir prever o futuro. 38 | 39 | Infelizmente as pessoas não gostam de ficar comparando porque geralmente a reunião de planejamento é curta, as pessoas ficam com aquele estresse emocional de querer sair de uma sala de reunião o quanto antes, MAS, se fizermos o exercício e comparar, de quebrar em tasks de até um dia, melhoramos o humor no planning e passamos a enxergar valor necessário para que ele possa ser o mais acertivo possível e para que possamos passar com mais transparência o que realmente é necessário para que aquela feature possa estar em produção o quanto antes. 40 | 41 | Crie uma régua com estorias já entregues com suas pontuações ou qualquer métrica que seja utilizada para fazer o comparativo, e sempre esteja atualizando essa régua e com isso podemos usar sempre uma referência. 42 | 43 | ## Conclusão 44 | 45 | A parte do planejamento é a mais importante em qualquer modelo de trabalho, seja ele waterfall ou ágil, porque a partir do valor que é dado no planejamento, as features que nos propomos a entregar, começam a de fato serem entregues. 46 | 47 | Sempre escutei que toda estimativa é burra, porém, quanto mais acertivo eu for, melhor será, porque eu reduzo a capacidade de errar e quando eu tenho o mindset voltado para que toda estimativa é burra, a porcentagem do meu erro pode subir, causando assim distúrbios de todos os lados, que gera pressão, que gera turnover. 48 | 49 | Portanto, invistam tempo planejando as coisas, nem que leve o dia inteiro, mas invistam esse tempo planejando ponto a ponto, abram o código e busquem aquilo que é suposto fazer para que as estorias fiquem o mais granular possível, para que eu possa entender o que eu posso deixar com uma prioridade menor, que consigamos deixar de fazer algo porque é irrelevante para a feature em questão. 50 | 51 | Planejar exige tempo e disposição, portanto, faça. -------------------------------------------------------------------------------- /errar-por-preguica.md: -------------------------------------------------------------------------------- 1 | # Errar por preguiça é o pior erro 2 | 3 | Errar é humano, mas errar por preguiça, em TI, deveria ser considerado um atentado contra a nossa classe, pois não podemos compactuar com a preguiça e no caso de estimativas, temos preguiça de olhar para o passado, e nem to falando de um passado tão passado assim, e sim um passado de um sprint, ou seja, temos preguiça de olhar para o que foi feito e comparar o nível de dificuldade e aceitar a derrota e de fato colocar uma "estimativa" que mais fazia sentido para aquele item. 4 | 5 | Não estou dizendo que devemos olhar para a nova estoria e filosofar em cima dela, e sim para pararmos um pouco e comparar com itens já entregues. Esse comparativo serve para colocarmos na nossa cabeça se o que estamos planejando é ou não complicado e o grau de dificuldade, se faz ou não sentido ter um item daquele tamanho, quais impactos reais a nível técnico e de negócio, etc. 6 | 7 | Vamos tentar um exercício no próximo planning, quando o item chegar para sabermos quantos story points vamos colocar, **PARE**, pegue um post it e entregue a cada um dos developers para que **TODOS** possam refletir sobre essa história por 2 minutos, anotem aquilo que foi pensado nesses dois minutos e logo em seguida estimem todos juntos usando o planning poker. 8 | 9 | O exercício acima vai confirmar três coisas: 10 | 11 | - Se a tarefa for muito facil, os story points vão se alinhar (exemplo, 2 ou 3); 12 | - Se a tarefa for muito difícil, os story points vão se alinhar (exemplo, 13); 13 | - Se a tarefa for o meio termo, os story points vão divergir (basicamente entre 5 e 8). 14 | 15 | Se convergir para cima, estaremos diante de algo possívelmente difícil e se for o contrário, algo fácil. Fazer o processo de pensar por dois minutos impede que alguém possa ser "manipulado" ou "induzido ao erro" na hora de estimar. 16 | 17 | Esse exercício pode ter uma variação quando colocamos o que pensamos num quadro e passamos a discutir aquilo antes mesmo de pontuar, e podemos (ou não) utilizar essa informação como base de comparação para as demais estimativas. Lembrando que comparativo é a primeira medida que pode ser utilizada. 18 | 19 | ## Teorema das 2 faixas iniciais 20 | 21 | Com base no que lemos acima, no planning vamos trabalhar inicialmente com duas faixas (geralmente eu escolho: 3 e 8) e defino que estorias muito grandes (13) **não** podem fazer parte de um sprint e que devem ser partidas em vários fragmentos (basicamente assumimos que o 13 é algo muito difícil de se fazer e que não é possível terminar em um sprint) e no planning poker converse com todos sobre considerar inicialmente duas faixas. 22 | 23 | A ideia é bem simples, limitar a dois o erro ao invés de errar em mais faixas de sequência fibonacci, até porque quando estimamos alguma coisa, colocamos uma expectativa para os interessados no produto, incluindo a própria área de produto, principalmente quando estimamos algo baixo, como 1 ou 2 e estamos fartos de ver estorias de 1 ponto sendo levadas por dois, três sprints a frente e o ideal é não criar ou aumentar o clima de incerteza, tanto do time de engenharia, que fica desmotivado, quanto do time de produto, que coloca expectativas muito altas naquilo que "prometemos" entregar dentro do sprint. 24 | 25 | Usando essas duas faixas, vamos para a primeira estoria: 26 | 27 | - **US001** -Criar fluxo de pagamento. 28 | 29 | **Primeira questão:** "Essa estoria está **MAIS PERTO** do **3** ou do **8**? 30 | 31 | No momento o time faz uma votação pra saber se está mais perto de um ou de outro e digamos que o time decidiu o seguinte: 32 | 33 | Time: "Está mais próxima do **3**." 34 | 35 | **Segunda questão:** "Essa estoria é IGUAL (nível de complexidade) a estoria que definimos em nossa régua como **3**? 36 | 37 | Time: "É mais difícil do que 3" 38 | 39 | E ai nesse momento não terá a tréplica e **assumimos essa estoria como 8** (porque pode ocorrer de nesse caso ser mais fácil que 8 e assumimos apenas duas faixas, ou seja, vamos definir para um lado e para o outro e de novo, não vamos arredondar para baixo). 40 | 41 | Vai haver gente chorando e achando ruim, MAS, esse é o caminho para que em curto e médio prazo consigamos dar melhor previsibilidade as coisas, então você leitor (scrum master, agile coach ou pessoa que assumiu o processo) pegue pra si essa responsabilidade e vai até o fim porque os frutos vão aparecer. 42 | 43 | - **US002** - Criar layout da página de Login/Logout/Esqueci Minha Senha 44 | 45 | **Primeira questão:** "Essa estoria está **MAIS PERTO** do **3** ou do **8**? 46 | 47 | No momento o time faz uma votação pra saber se está mais perto de um ou de outro e digamos que o time decidiu o seguinte: 48 | 49 | Time: "Está mais próxima do **3**." 50 | 51 | **Segunda questão:** "Essa estoria é IGUAL (nível de complexidade) a estoria que definimos em nossa régua como **3**? 52 | 53 | Time: "Sim, tem o mesmo grau de dificuldade ou até mais fácil que **3**" 54 | 55 | E então assumimos essa estoria como **3** . 56 | 57 | Essa prática funciona como um remédio amargo que tem que ser tomado, é uma maneira de acertarmos aos poucos o nível de planejamento e também nos coloca em uma situação que ao longo do tempo (e o ideal é que se faça isso APENAS em três sprints) passamos a ter mais confiança naquilo que fazemos. 58 | 59 | Após o terceiro sprint utilizando dessa técnica, podemos então abrir a terceira faixa (5) e ficaria o diálogo mais ou menos assim: 60 | 61 | - **US001** -Criar fluxo de pagamento. 62 | 63 | **Primeira questão:** "Essa estoria está **MAIS PERTO** do **3** ou do **8**? 64 | 65 | **Time:** "Está mais próxima do **8**." 66 | 67 | **Segunda questão:** "Essa estoria é IGUAL (nível de complexidade) a estoria que definimos em nossa régua como **3**? 68 | 69 | **Time:** "Não, essa estoria é mais fácil que nossa estorias de 8 pontos" 70 | 71 | **Terceira questão:** "Essa estoria é igual nossa estoria de **3**? 72 | 73 | **Time:** "Não, é mais difícil" 74 | 75 | E então nesse momento que abrimos a **terceira** faixa, justamente o 5 e colocamos essa estoria como primeira a herdar a posição para que nos plannings futuros possa ser comparada. 76 | 77 | Esse exercício faz com que o 5 saia da zona de conforto e então chegamos ao momento que estimar 5 passa a ser mais "próximo da realidade" do que antigamente. 78 | 79 | ## QAs podem ajudar 80 | 81 | QAs podem ajudar a não errarmos por preguiça e vou listar algumas ações que possam fazer o time refletir sobre o tamanho do item a ser desenvolvido: 82 | - Planejar os testes antes do planning 83 | - Quando evitamos os problemas e os antecipamos, conseguimos mostrar para o time a quantidade de testes que supostamente vamos executar para aquele item em específico. Esses testes podem ser feitos junto com a área de produto, assim como pode ser apresentado ao Product Manager ou Product Owner antes de realizar o planning. Escrever antes os testes e os mostrar antes da fase de construção faz com que nosso time tome atenção a todos os casos durante o processo de desenvolvimento. 84 | - Criar um mapa mental 85 | - O mapa mental é uma maneira vital para ajudar o time a pensar em quais pontos do nosso produto que supostamente aquela feature em questão pode ser decisiva (ou seja, que possa haver algum tipo de ligação). Mostrando no mapa, podemos enxergar quantas partes do nosso produto possa vir ser afetada caso façamos essa feature em questão. O mapa mental também serve como comparativo, pois conseguimos traçar a estimativa de acordo com a quantidade de lugares onde essa feature possa afetar no nosso produto. 86 | 87 | ## Conclusão 88 | 89 | Para concluir esse tópico, quando passamos a ter comparativos, conseguimos chegar perto de estimativas mais confiáveis e uma das maneiras de termos um pouco de fator comparativo, podemos criar uma régua de estimativas para que possamos colocar o que foi feito (obviamente que não podemos colocar na nossa régua uma história que falamos 3 e estamos cerca de 10 sprints com a mesma historia sendo desenvolvida) e passar a comparar e claro, a régua é uma ferramenta que deve ser frequentemente atualizada. 90 | 91 | Lembrando que comparativo não pode ser levado como verdade absoluta, e sim apenas como uma ferramenta de estimativa onde estaremos mais próximo do que julgamos ser "o certo." 92 | 93 | Aceitar que muitas vezes utilizamos o 5 como muleta para "tirar o nosso da reta" e criar uma maneira efetiva de melhorar o que estimamos. 94 | 95 | Quanto mais próximos do "certo" estivermos, melhor será para nossa auto estima e nosso lado para com a área de produto será melhor visto, teremos mais confiança e vão confiar mais no time. 96 | 97 | [Início](https://github.com/thiagomarquessp/dividir-para-conquistar/blob/master/README.md) --------------------------------------------------------------------------------