Hoje em dia o adjetivo ‘ágil’ é comum da linguagem de TI. Nem sempre por razões lícitas ou bem entendidas pois como “ser ágil” virou sinônimo de estar na linha da frente, então algumas empresas e grupos dizem ser ágeis apenas para ficar bem na imagem perante seus clientes ou potenciais clientes. Mas o que é realmente ser ágil de verdade ? Como saber se um grupo, uma equipe, uma empresa é realmente ágil ?
Quando se pergunta a alguém o que é ser Ágil, a primeira resposta mais comum é : “Ser ágil é seguir o Manifesto Ágil“. Mas não. O Manifesto Ágil é um efeito de ser ágil, não uma causa. O Manifesto nasce de uma necessidade de fugir do padrão tradicional, de um conjunto acumulado de falhas, mas não necessariamente de uma mudança de paradigma profunda que depois é expressa no Manifesto. O próprio nome “Manifesto” descreve um conjunto de ideias politicas, mas não necessariamente existe uma ideologia subjacente e a mensagem é mais ou menos “sabemos como, não o por quê”. Se compararmos o manifesto com outras coisas que também são consideradas Ágeis como XP, Scrum, Lean, TDD – entre outros – vemos que existem outros valores em jogo e alguns até mais longe do cliente e mais perto de quem constrói o software.
Então o que significa “Ágil” ?
Existem várias pessoas [1][2][3] tentando definir o que Ágil significa. De alguma forma o Manifesto é invocado. Mas como disse ele é um efeito, não uma causa. Algumas pessoas até acham que não ha muita necessidade em dar nomes aos bois e que se você está aprendendo a ser melhor, então é isso [4]. Como uma boa definição não pode conter o próprio conceito sendo definido, temos que ir um pouco mais fundo. Um ponto que parece pacifico entre todas as definições é que ser ágil significa inspecionar frequentemente. Isto significa que, constantemente, o que temos é confrontado com o que queremos e dessa analise nasce o que faremos a seguir. Isto nos leva a um modelo iterativo. A iteração é portanto uma consequência que advém da necessidade de inspecionar constantemente. Iterativo é até um pouco limitador porque significa que a inspeção se dá no fim de cada iteração. Sim, isso é verdade, mas não é toda a verdade. Dentro da iteração também acontece inspeção, só que acontece um nível mais fino. No limite, todo e qualquer detalhe foi inspecionado constantemente. Quando o programador está escrevendo o código, a inspeção já está acontecendo. O XP leva isto bem a sério e é esta a origem do Pair Programing. Ao programar em par, mais coisas são inspecionadas com mais frequência. Desde da escrita das palavras propriamente dita até ao modelo de domínio, o design e a arquitetura, inclusive até os requisitos.A inspeção constante também está presente no manifesto “Software em funcionamento”. Observar o software funcionar é em si uma forma de inspeção, contudo uma forma macro de fazer a inspeção.
A primeira parte do significa de ´”Ágil” é, portanto : inspeção constante.
Mas inspecionar não significa nada se não soubermos de onde partimos e onde queremos chegar. Este “onde” não é físico. Existem muitas analogias com transportes como o clássico da navegação do barco. Partimos de um porto e queremos chegar num porto. Embora isto exija inspeção constante de onde estamos e como alterar o rumo em resposta, deixa a ideia que o nosso objetivo está fixo. O objetivo não está fixo. Ele se move. Daí o nome “ágil” que dá a ideia de movimento. Mas o objetivo se move não em essência mas em forma. Isto é difícil de explicar com analogias de transportes. A melhor analogia seria usar um valor humano como a Bondade ( ou qualquer outra qualidade humana). O objetivo é fixo, a pessoa quer ser boa, mas não ha um manual de como ser Bom. Então o que podemos fazer é atuar naquilo que achamos hoje, que é ser Bom e esperar as consequências. Quando as consequências acontecerem podemos inspecioná-las, se elas se encaixam com o que queremos , se o nosso conceito de Bom nos levou às consequências que queríamos. Senão, então ajustamos o nosso conceito. Este processo é sem fim, pois não é possível chegar na essência das coisas de forma iterativa por múltipla inspeção, mas conseguiremos refinar o nosso conceito de “Bom” tanto quanto quisermos ou acharmos necessário. Em um ponto, iremos parar. É assim que o Ágil vê o conceito de Produto. A essência do Produto final é um objetivo fixo, mas o nosso conceito do que é o Produto – a forma – vai mudando com o tempo. A cada inspeção encontramos algo que poderemos melhorar e num certo ponto não achamos necessário mudar mais nada. Não que chegaremos no Produto perfeito, mas chegaremos em uma aproximação boa o suficiente para o nosso Objetivo. A este conceito de que a cada inspeção faremos ajustes para “melhorar” o Produto de forma que fique mais perto do que é o Objetivo ideal é que denomina acrescentar Valor.
A segunda parte do que significa “Ágil” é, então : prover o incremento constante de Valor.
Uma outra forma de dizer que estamos adicionando mais Valor é dizer que estamos adicionando menos coisas inúteis. Temos menos desperdício. Então muitos tomam “Diminuir Desperdício” como sinônimo de acrescentar Valor. Contudo, esta é uma forma mais fraca do mesmo principio. Pela simples procurar em eliminar o desperdício não estamos necessariamente incrementando o Valor. Para incrementar o Valor ha que perseguir isso explicitamente. Os métodos Lean focam neste ponto do desperdício e sua diminuição, contudo parecem mais preocupados em diminuir o desperdício no processo do que aumentar o Valor do Produto. Como disse, toda a eliminação de desperdiço é aumento e valor, mas nem todo o aumento de valor advém da eliminação de desperdício.
O que acontece quando inspecionamos e não gostamos do que vemos ? Talvez a nossa expectativa estava inchada ? Talvez a implementação foi à quem do que poderia ser ? Talvez a implementação foi exatamente o que foi pedido, mas simplesmente as ideias mudaram ? As ideias mudam a todo o momento. E em consequência a expectativa muda a todo o momento. A inspeção deve ser realizada tendo em conta o que era esperado quando começamos quando iniciamos a realização. Não o que esperamos agora. Então a primeira coisa a fazer é avaliar a inspeção em relação às expetativas que deram origem ao trabalho. Estas expetativas podem ter mudado enquanto o trabalho era realizado, mas não seria justo julgar o implementado pela ideia novas. Eu mandei você pintar a parede de azul ( a cor que eu queria antes) e não gostei do seu trabalho que ela não está verde ( a cor que quero agora). Este tipo de mistura no julgamento parece idiota, mas acontece na prática mais vezes do que você pode pensar. Por quê ? Porque a expectativa não foi bem gerenciada. Não foi informado ao cliente que iriamos demonstrar o que ele pediu um mês atrás, não o que ele pediu ontem.
Inspecionar, significa olhar para o trabalho com os olhos de quem esperava (no passado). Se o que era certo no passado, mudou, então precisamos Adaptar o que temos à nova expectativa.
A terceira parte do que significa ser “Ágil” é : Adaptação.
A adaptação acontece em vários níveis. Existe a adaptação a novos requisitos como exemplifiquei, a adaptação a um novo modelo de domínio, a adaptação a uma nova regra, a adaptação a um novo design, a adaptação a uma nova arquitetura, a adaptação a uma nova forma de distribuição, a adaptação a um novo mercado, etc… A adaptação é, como a inspeção, constante e presente em todos os detalhes. Sabendo que a adaptação é necessária e irá acontecer, não iremos desperdiçar forças tentando resistir a ela. A mudança é inevitável, e portanto, a Adaptação também.Este principio está presente tanto no conceito de Refactoring, como no Manifesto : “Responder a mudanças“, como no conceito de Arquitetura Aberta.
Finalmente, a inspeção e adaptação não se fazem no vazio. Ha, como disse, um objetivo. Chegar nesse objetivo exige um esforço e exige saber quando o alcançamos. Existem pessoas se esforçando para alcançar o objetivo e pessoas definindo o objetivo. É possivel que a mesma pessoas faça os dois papeis, mas normalmente estamos no contexto comercial onde quem sabe o objetivo é o contratante e quem realiza o esforço é o contratado. Sendo pessoas é vital que exista uma boa comunicação entre as pessoas. “Boa Comunicação “não significa comunicação rápida, nem canais de comunicação sofisticados, a boa e velha conversa é a melhor forma de comunicação para estes objetivos.”Boa Comunicação” significa comunicação clara, sem ambiguidade, sólida, transparente.
A ultima e final parte do que significa ser “Ágil” é : Transparência.
A transparência acontece entre as pessoas. Não com o produto, o com o objetivo. A transparência é o ingrediente que permite que todos partilhem do mesmo objetivo e que enxerguem o mesmo objetivo e não uma face ou vertente dele. A transparência é um requisito fortemente humano. Ela requer qualidades como respeito e foco de maneira a que as interações entre as pessoas sejam simples mas proveitosas. Esta característica é vital em Ágil é a a causa de porquê as equipes ágeis gostam de pendurar tudo nas paredes , gostam de fazer reuniões, gostam de receber feedback do cliente e dos outros membros da equipe e gostam de demonstrar o que sabem fazer. Esta característica está presente no Manifesto como “Indivíduos e interações” e “Colaboração com o cliente“, está nos quadros afixados do Scrum e do Kanban e no conceito de Product Owner do Scrum e do XP.
Ser Ágil é Inspecionar Constantemente , Adaptar, ser Transparente e procurar acrescentar Valor sem desperdício. Se um destes ponto falhar, o grupo não é Ágil.
É fácil, mas redutor, dizer que Ágil é definido pelo Manifesto Ágil. É como dizer que Liberdade é definida pela Constituição. O Manifesto advém dos princípios ágeis, mas não é uma carta dos princípios ágeis. Para exemplificar, peguemos a prática de escrever testes unitários para o seu software. Não importa aqui como , quanto ou quem escreve esses testes. A comunidade ágil concordaria que testes são importantes e uma das características de ser ágil. Mas no Manifesto não está escrito “escreva testes”. No máximo você encontra um “Software funcionando, em vez de documentação extensa”. Poderíamos argumenta que os testes ajudam a manter o software funcionando, mas o software pode estar funcionando e não haver teste algum. O próximo passo seria a integração continua. No manifesto também não está escrito, “integre continuamente”. Todas estas práticas advém dos verdadeiros princípios ágeis. Em particular, o teste e a integração continua advém da Inspeção Constante. Aliás a integração continua é a implementação mais fiel deste principio. Um conjunto de testes que continuamente inspecionam o código procurando problemas. Tanto testes unitários como ferramentas de qualidade como o findbugs, por exemplo.
Testes e integração continua advêm da necessidade de inspecionar, assim como o Pair Programming do XP , o Sprint Review e a Respostectiva do Scrum e o TDD (Test Driven Development). A Adaptação nos dá o conceito de Refactoring, O Daily Scrum (Scrum), a reunião com o PO (XP e Scrum) e o TDD (o design é adaptado continuamente às necessidades). A Transparência nos dá o fator Humano da interação baseada em valores como Responsabilidade , Compromisso e Foco além de práticas como expôr todo o conhecimento e andamento dos trabalhos que levam aos quadros Kanban, ao Burndow Chart ao Feature Map e outras ferramentas semelhantes. Finalmente tudo isto é usado, posto em prática, e filtrado pelo conceito de que só vale a pena se acrescenta Valor. É por isso que se base na tecla de não sair especificando tudo no inicio e depois só executando cegamente. Isso não é iterativo, não é sujeito a inspeção, mas principalmente não agrega Valor. É simples criar uma equipe de documentadores, deixá-los criar um documento de 200 páginas e depois cobrar por isso. Afinal aquelas pessoas trabalharam. O ponto é que no momento que esse trabalho está completado, nada daquilo é mais verdade.E lá vamos nós revisar tudo o que foi escrito. Isto não significa que o software não terá um manual, um help integrado ou um forum de apoio. Significa que estas coisas serão construídas incrementalmente e em conjunto com o software que documentam. Ninguém acha que o javadoc do SDK é uma perda de tempo. Tem muita informação ali. Tal como as documentações de outras linguagens, bibliotecas e tecnologias em geral. Estas coisas têm valor. O que não tem valor é o retrabalho. Outro ponto é a arquitetura. Ha um mínimo que é necessário estabelecer para começar a programar. Ninguém é louco de sair programando profissionalmente sem estabelecer conceitos como quantidade de nodos (pois implica se ha operação remotas envolvidas), definição de camadas, uso de design patterns. Ninguém encontra valor em escrever um código ad doc e depois modificá-lo para usar padrões. É muito mais valioso usar os padrões para começo de conversa. Este conceito de diminuir o retrabalho, afinal o mais possível o código na primeira vez que se escreve que está presentes em principio como o DRY ( Don’t Repeat Yourself) é em si mesmo Ágil, pois procura maximizar o valor, para a menor possível unidade de esforço.
É fácil cair em tentações. Por exemplo, porque afixar o burndown chart se temos ele no software XPTO ? Porque nem todo o mundo tem acesso ao software pois ele requer uma senha e um perfil de usuário com restrições de acesso. A parede é publica. É mais transparente ? Ah! mas e se o resto da equipe está do outro lado do mundo ? Use o software para criar e manter um registro histórico do gráfico, mas use a parede para o demonstrar. Cada lado da equipe pode imprimir o gráfico e colocar na parede. E que tal fazer o scrum , mas não fazer as reuniões de Retrospectiva ? Isso significa não inspecionar o processo e não adaptá-lo. Logo, isso não é ágil ( e por consequência não é Scrum). E que tal não usar Pair Programming ? Desde que você assegure outras formas de inspeção, tudo bem. Mas saiba que está perdendo. Está transformando o que é realente inspeção continua em algo que é inspeção periódica. Além de que o Pair Programming ajuda a espalhar a informação ( ajudando à Transparência ) e a não cometer erros bobos (ajudando a diminuir o desperdício). E quando o programador não corrige aquele bug porque não foi ele que o criou ? A inspeção foi feita, mas não a Adaptação. O código continua com problemas, com defeito, e portanto alguém algum dia irá desperdiçar tempo resolvendo isso. Resolvendo o bug no momento em que se encontra, é ser ágil, porque se adapta o código a realizar o que queremos mantemos o incremento de valor. E que tal ter um PO que é um assistente do gerente de projeto ? Podemos conversar com ele e depois ele passa para o gerente. Sim, mas cadê a interação a transparência ? Parece mais um relatório do que uma conversa. Quais são as intenções desse PO em relação ao Produto ? Nenhumas. Ele não está interessado em agregar valor e sim em ver se a equipe está “performando” ( o que seja que isso significa). O mesmo se o gerente fosse o PO. Estes são exemplo de coisas gerais que podemos julgar fácilmente à luz destes principios mas que teríamos dificuldade em julgar dentro de um mecanismo ágil A ou B.
Ser Ágil não se resume a seguir a prática A ou B. Se resume a seguir estes 4 princípios : Inspeção Constante, Adaptação, Transparência e procura continua pelo incremento de Valor. É deles que todas as prática A ou B nascem. É baseado neles que sabemos se uma modificação da prática A a transforma em algo mais ágil ou menos. É com base nelas que podemos julgar se um grupo, uma empresa, uma metodologia é Ágil.
Inspeção Constante, Adaptação, Transparência e Incremento Continuo de Valor. Isto é o que significa ser Ágil
Olá Sergio, tudo bem?
Primeiro, obrigado por mais um belo post. É sempre muito interessante ler sobre métodos ágeis e cada vez descobrir mais sobre isso.
Agora, por falar nisso, estou trabalhando em uma empresa, de grande porte e tecnologia, mas apesar de ter sido implantado métodos ágeis, cada dia isso está ficando mais decadente.
Basicamente, a estrutura hierárquica da empresa é grande e os tais gerentes estão deturpando e corrompendo o processo. Achando que sabem mais do que todos, estão fazendo Scrum a sua maneira. E para isso, principalmente, eles converteram o papel de Scrum Master (que nada mais é do que um papel, de facilitador inclusive) em um capataz burocrata em que sua função se converteu em ler e-mails e encher o saco do time de desenvolvimento com cobranças de tempo e “bronquinhas” e PRINCIPALMENTE: querer dar as estimativas de tempo para as histórias ou querer revisar o prazo dado pela equipe. Enfim, se intrometer no que não deve e não fazer o que deve (cumprir o seu papel de verdade).
Ainda, esse scrum master não participa de desenvolvimento, seu esforço não é levado em conta no desenvolvimento das estórias.
Tudo isso, ao que indica, em nome da produtividade.
O que você tem a dizer a respeito disso? Como melhorar isso? Por exemplo, eu tenho a convicção de que o prazo é o próprio time de desenvolvedores que dá, não é? Já que são eles que vão fazer.
Primeiro um esclarecimento. O prazo é fixo. É um numero de semanas e é sempre o mesmo. 2 ou 3 conforme acordado entre todos. O que a equipe discute é a quantidade de pontos e quais as historias que dá para fazer nesse tempo. As estimativas nunca são de tempo, são de tamanho. Em pontos de historia. Além disso falta ai a figura do Product Owner. Sem ele não ha priorização. Não ha valor de negócio.
Mas no seu caso, e acredite que essa realmente não é a forma de fazer scrum, não importa muito o que o scrum fala porque esses senhores vão deturpar tudo. Eu já passei por isso várias vezes também, e infelizmente não sei a solução. Se poder saia daí, saia. Se poder fazer força, se conhece algum gerente ou tem alguma influencia tente mudar. Greve é uma opção, mas teria que ser bem administrado e no Brasil é bem perigoso. E eles sabem disso. Por isso que chitabam o pessoal.
Uma opção menos atravessada é chamar um Scrum Master de fora. Como consultor e deixar ele mostrar como se faz. Mas isso muito provavelmente será barrado tb. Os poderosos nunca querem ver seu poder desafiado. Uma opção menos moral é simplesmente desconectar de tudo e ir fazendo o trabalho como dá. Se alguma coisa der errado culpem o Scrum Master de mentirinha pois foi ele que prometeu as coisas e não vocês.
Infelizmente é uma patogenia esse tipo de gerencia que quer enganar (ou se engana) dizendo que faz scrum, mas nunca se deu ao trabalho de ler sobre isso ou fazer um curso. Não é difícil. Mas no Brasil as pessoas estão habituadas a uma hierarquia militar e tratar os trabalhadores como gado. Engenheiros de software não são gado e não se dão bem com autoritarismo. Então é receita para morrer.
Veja o que pode fazer, e se não poder fazer nada, simplesmente procurar um outro lugar onde as pessoas realmente tentem fazer direito, ou pelo menos tenham consciência de que não sabem e precisam aprender. Tentar forçar, não adianta. As pessoas são demasiado imbecis e estúpidas.
Muito obrigado pela resposta, Sergio.
Realmente esse não é um assunto simples de ser discutido nem fácil de ser tratado. É realmente muito difícil lidar com o ego humano e o sentimento de poder.
Certo, geralmente temos 3 semanas para desenvolvimento do sprint (com testes) e uma última semana para fazer as reuniões do scrum. Nós temos um product owner sim, ele priorizou as estórias e isso está correto. Eu só queria ter enfatizado o erro no papel do Scrum Master. O product owner acaba sendo meio passado por cima, é nesse sentido que eu disse que os gerentes estão arruinando o processo.
Eu gostaria que você me confirmasse qual exatamente é o papel do Scrum Master, o que ele deve fazer no dia-a-dia do Sprint, como ele deve se relacionar com a equipe etc.
Nós ainda vamos tentar mudar, existem outros gerentes que parecem entender tudo isso melhor, portanto há essa esperança.
A ideia do Scrum Master de fora é muito boa, na verdade em um outro setor da empresa, existe um rapaz excelente, ex-scrum master, o pessoal reconhece muito ele. Mas de fato, ele mesmo se diz desesperançoso em tentar mudar algo. Justamente porque existe uma pessoa que está “acima” dos Scrum Masters, algo como um Scrum Master of Scrum Masters. Então na prática, os scrum masters se tornaram lacaios desse cidadão. Eles obedecem esse cara e estão dentro das equipes para garantir que as ordens do sujeito sejam cumpridas e supervisionadas. Olha só a gravidade da situação. Isso é trágico, não acha?
Nós estimamos as estórias em pontos de estória, só que ocorre que no nosso planejamento tentamos dar um chute de quantos dias aquilo levaria para caber ou não nos 10 dias que desenvolvemos (2 semanas). Isso ocorreu pela dificuldade de conseguir calcular em pontos de estória como encaixar em um calendário. Confesso que não gosto da ideia mas entendo o ponto de vista. Como seria mais correto?
Para terminar, enfrentamos recentemente diversos problemas por atrasos. Planjavamos 2 semanas de desv. e uma de teste mas chegava no fim da 2a semana e não tinhamos acabado, aí adivinha? “Comiamos” a semana de teste para terminar o desenv. das estórias e isso tem implicações trágicas. Agora decidiram que no decorrer da semana de desenv., os atrasos e impedimentos tem que ser levantados para que atrasos não ocorram (imagino eu cancelando algum requisito ou outras estórias), isso é correto mesmo?
Obrigado!
O Product Owner é a pessoa que manda no projeto. Se ele é passado por cima, então, realmente algo está muito errado. O Product Owner não pertence no departamento de desenvolvimento, ele pertence num departamento próprio e não subjuga aos desenvolvedores, nem os desenvolvedores a ele. São dois departamentos paralelos. O Product Owner é totalmente responsável pelo sucesso ou fracasso do projeto e só responde perante os stakeholders. Entenda que ele tem o poder de parar o projeto a qualquer momento. Por isso que ele é o Dono do Produto. Sem ele não ha festa. O Scrum Master não manda nada. Ele está ali apenas para vigiar que o Scrum está sendo entendido e bem aplicado. É como um treinador e apenas exerce o papel de juiz quando ha que arbitrar conflitos entre o PO e a equipe. Ele também ajuda o PO a planejar as coisas e a demonstrar andamento aos stakeholders. Mas ele é um amigo do PO. Não é comandado por ele, nem o comanda. As figuras do PO, SM e equipe são como os três poderes ou a santissima trindade. Nenhum manda no outro e apenas os 3 juntos produzem o que é necessário. O Scrum Master serve como comunicador no daily meating. Ele ouve o que as pessoas tem a dizer e mostra o brundown do dia anterior. Fora do daily o papel do Scrum Master é remover os bloqueios da equipe. É isso que ele faz no resto do tempo: ajudar a equipe a ser mais produtiva removendo bloqueios. O Scrum Master serve a equipe e não ao contrário. É que o SM assim como o PO tem comunicação com os Stakholders e conhecimento sobre scrum. E é isto que acho que falta no seu. Um scrum mastar que não sabe scrum, não é um scrum master. Simples assim. O scrum Master é o terceiro poder, é o judiciário. Ele não manda, só ajuda e vigia que tudo está conforme as regras e arbitrar disputas quando ha duvidas. As regras são as do scrum.
Mesmo com uma pessoa interna que seria um bom SM, é melhor trazer alguém de fora para haver independência. Para que não digam que o cara está puxando a brasa à sua sardinha… depois, com o tempo, ele pode ser trazido para auxiliar o scrum master externo e depois pertencer à equipe de SM. Não existe uma pessoa acima do SM. Isso é uma imbecilidade. É Como haver um juiz dos juizes. Não. Cada juiz e casa SM é por si mesmo. O que pode haver é um colégio de SM que se conversam para levar aos stakeholders os mesmos problemas. Em uma organização é comum que mais do que uma equipe tenha os mesmos problemas. Cada Projeto tem um SM. Mas um Produto pode ter mais do que um Projeto. Então pode haver mais do que um SM por Produto. Contudo, porque os afazeres do SM não são assim tantos, uma mesma pessoa pode ser SM em mais do que um projeto. Não ha razão para ter um Scrum God que controla todos os Scrum Masters. Isso é uma falha grave na estrutura porque cria uma hierarquia. No Scrum não ha hierarquias. Ha pessoas no mesomo nível que colaboram. É trágico e é Ridiculo, porque essa pessoa arranjou uma forma de ser sobrepor aos PO e aos stakeholders. E muito provavelmente sem responsabilidade nenhuma se algo der errado. Isso é errado e acho que se for bem explicado aos PO, Gernetes e todos os outros Stakholders fica fácil de entender que esse cargo não deveria existir. Existe uma coisa chamada Scrum of Scrums, mas não tem nada que ver com isto. Não é uma hierarquia.
Acho que o seu caso é o típico caso das pessoas querem usar o scrum para controlar as equipes. O scrum não é uma ferramenta do Big Brother. Bem pelo contrário.
Estimativa se faz com pontos de tamanho. O vosso erro é querer adivinhar o tempo. Não façam isso. É por isso que não está funcionando. Existe um método dentro do scrum para estimar horas de tarefas , mas isso é depois do sprint estar declarado. O PO nunca vê essas estimativas e são inúteis para ele. As horas dependem das pessoas da equipe. Se as pessoas mudam, as horas mudam. Se um junior tem que fazer o trampo do sênior, as horas mudam. O inverso também. As horas dependem da equipe. Mas o tamanho não. O tamanho depende da historia. Ele é sempre o mesmo. Pense assim. A historia é uma vela e tem um tamanho. A equipe vai queimar essa vela. O quanto demora para queimar não depende para vela, depende do fogo que vc usar. Se vc usar um fosforo e aceder a vela irá demorar um tempo X, se vc usar um maçarico e puxar fogo na vela, vai ser muito mais rápido que X. A equipe irá decidir a ferramenta adequada. Mas o tamanho é da vela, da historia, não da equipe. Este conceito é muito importante interiorizar. Pois sem ele o scrum não faz sentido.
Um outro ponto errado que mencionou é fazer os testes no fim. Isso está errado. Lembre-se que o sprint backlog é uma pilha. Vc não pode avançar na pilha sem ter removido o que está em cima. Ou seja, para fazer a próxima historia, precisa acabar esta. Acabar significa fazer os testes. Se vc tem 10 desenvolvedores, vc coloca os 10 em uma historia só. Testes inclusos. E só depois que toda a historia está completa que vc avança para a próxima. Na prática se a historia precisa de 10 pessoas, ela é muito grande e o PO fez um mau trabalho no backlog. Isso é algo que pode ser avaliado nas meatings E o PO pode partir essas historias grandes em outras mais pequenas. Depois, na prática, vc coloca 2 pessoas numa historia e 3 noutra e 2 noutra e 2 noutra. Mas ninguem desses grupos pode pegar outra historia se aquela que estão trabalhando não está pronta. Lembre-se que “Pronto” é um conceito que inclui estar testado e correto.
Se vc usar este mecanismo, vc não irá ter problemas com “atraso”. Não existe “atraso” em scrum , porque o tempo é sempre constante. Agora entenda que se a sua equipe aceitou 4 historias a 5 pontos cada uma e só conseguiu completar 3, mas com testes e tudo. bonitinho. Então a sua velocidade é de 15 pontos. No próximo sprint a equipe não pode aceitar mais que 15 pontos de sprint backlog. Se a equipe trabalha de forma correta, ele irá conseguir realizar os próximo 15 pontos sem problema. O “atraso” que vcs estão sentido significa que o sprint backlog tem mais pontos do que deveria. E é por isso que estimar os pontos é vital. Voltando ao exemplo das velas, pense que tem 4 velas de 5 metros. vc sabe quanto tempo precisa para as queimar ? Não sabe. Então vc aceita 4 velas no sprint. Pense que apenas consegue queimar 1. Bom, sua velocidade é de 5 metros (que é o tamanho). Mas agora va aprendeu. No próximo sprint vc já sabe como queimar uma vela em um sprint, e vc pensou numa ideia que vai queimar mais depressa. Então vc aceita 1 vela para o próximo sprint (que é o resultado que vc obteve do sprint anterior) e vc deixa uma vela na reserva. Se der tempo, vc queima essa também. Agora vc começa o sprint e a sua ideia de queimar a vela mais depressa é excelente e vc queimar a vela inteira em metade do sprint, conseguindo assim queimar a vela de reserva. A sua velocidade é agora 10 metros. E assim vai. Vc vai melhorando seu modo de operar a queima das historias e vai tendo melhores resultados com o tempo. Mas chegará um momento que não ha mais o que fazer a sua velocidade ficará constante. A velocidade constante é de suma importancia para o PO porque é assim que ele consegue fazer promessas e dar expectativas aos stakholders. Lembre-se que o PO e a Equipe que fazem o produto. O SM só observa.
Você não tem que encaixar nada num calendário. O calendário está definido. É 3 semanas e pronto. E é sempre 3 semanas. Mas não é 2+1 é 3. 3 Semanas de desenvovimento com os testes sendo feitos no termino da historia e não no termino do sprint. Pois vc quer chegar ao fim com pelo menos uma historia ( a primeira que o PO deu prioridade) pronta. E “pronta” significa que está testado, finalizado, sem arestas para limar. Pronto é Pronto. E não ha vergonha em não estar pronto. É para isso que serve o daily meating para dizer ao SM os problemas, porque não consegue queimar mais rápido as historias. E se ele não fizer nada, então a reunião de retorspectiva serve para dizer “senhores, assim não está funcionando, porque isto, isto e isto…”
Então foque em estimar melhor o tamanho e em estimar melhor o orçamento do sprint. Essas são as ferramentas da equipe para ganhar o respeito do PO e de todo o mundo. Se vc promete X e faz X, é isso que interessa. Mas a promessa tem que vir da equipe, e não do SM. O SM não tem como ajudar a queimar as historias, então ele não tem palavra nas estimativas. Se vcs poderem fazer a reunião de plenejamento e o planking poker apenas com o PO seria o ideal. O SM só está lá para defender a equipe dos abusos do PO, porque obviamente o PO vai querer fazer todas as hitorias que ele imaginar em um só sprint. Mas isso não é realistico.
Pegue uma historia que a equipe já fez , uma de tamanho médio. Nem a maior, nem a menor. E estipule por convenção que essa historia é um 5. Novas historias são comparadas com essa. Ou elas são menores, ou maiores. Não importa o tempo. Importa o que ha para fazer. Pegue 3 ou 4 (ou mais , se tiver esses dados) últimos sprints e calcule a velocidade deles. Ou seja, quais estoiras foram realmente terminadas e quanto valiam os pontos delas. Estabeleça um orçamento que não é nem a mais baixa nem a mais alta. Use esse numero para o próximo sprint. E ajuste conforme o resultado que obteve. Converse com seus colegas para chegar a um consenso do orçamento. Obtenha o consenso, não a maioria, nem o que o líder diz. O consenso é obtido quando todo o mundo está confortável com o numero. A equipe tb tem que passar por este processo de aprender a estimar o que “não vê”. O PO só pode colocar historias até completar o orçamento. Simples assim. Não ha nenhuma consideração de tempo. Nenhuma. Ou as historias cabem no orçamento, ou não cabem. Crie uma reserva de historias. Esta reserva são historias que o PO irá escolher. normalmente mais pequenas de 1 ponto ou 2. Se a equipe acabar tudo o que está no sprint backlog, ela pega a primeira historia da reserva e assim sucessivamente na ordem. Lmebre-se que entre o PO e a equipe tem que haver um Gentlemens Agreement. Ninguem engana ninguém. E ha compromisso da equipe em completar o trabalho que ela mesma aceitou no sprint. Faça isto e irá ganhar a confiança do PO. Depois com a equipe alinhada com o PO, o SM fica cada vez menos necessário ( em XP não existe o SM, só o PO, e é suficiente).
O papel do SM é como as rodinhas na bicicleta, uma hora vc não precisa delas. Por isso que o SM não pode ser instituicionalizado nem formar uma hierarquia. Porque quando tudo estiver oleado, ele não é mais necessário.
Espero que vc consiga dar a volta. Tente fazer melhor o papel da equipe e ajudar o PO. E tente fazer ver à empresa como um todo que o scrum vale a pena quando é bem feito. Mas tem que ser bem feito. Para saber como seria “bem” seria bom receberem uma palestra ou um treinamento de um SM externo. Para que assim todos saibam o que é real e o que não é. E as pessoas que colocam as suas ideias como “é assim que o scrum funciona” sejam desmascaradas.
Sergio, muito obrigado novamente, vou ler novamente e pensar bastante a respeito. Depois posto aqui mais comentários. Valeu!
E quanto a daily meeting? Como você enxerga uma daily meeting ideal? Nós não ultrapassamos os 15 minutos mas muitas vezes se torna um status report em que cada um só fala o que fez como se tivesse se reportando a um superior.
Na daily é que se deve ter o feedback do andamento das estórias não é? E caso o time perceba um atraso deverá se replanejar. Também quando os membros do time se ajudam mutuamente para reordenar seus trabalhos para que o objetivo seja alcançado da melhor maneira.
E quanto a retrospectiva? O time deve discutir os pontos positivos e a melhorar do último sprint e discutir sobre eles (tanto como manter quanto como melhorar os pontos), mas existe algum ponto interessante que você possa dizer sobre retrospectivas? Ou como realmente fazer boas retrospectivas? Nós estamos sentindo que alguns pontos melhoram de um sprint pro outro mas ao longo do tempo, isso se perde.
Realmente o perigo de se tornar um status report é real. Já vi muitas vezes. O outro lado da moeda é virar um fórum de discussão técnica sobre as dificuldades enfrentadas. Mas isto só representa a imaturidade e incompreensão do papel da equipe no planejamento. As pessoas não estão habituadas. O daily meating diário é a fomosa resposta às três perguntas, mas o objetivo é saber se as historias estão sendo queimadas como a equipe previu. Afinal a equipe se comprometeu com o PO no inicio do Sprint é agora é a palavra dela que está em jogo. É sério. O scrum master deve já ter o burndowns chart atualizado quando começa a meating. É delineado uma tendencia, a equipe observa se o que planejou poderá ser cumprido ou não. Para saber isso, cada um fala do que fez e fará. Mas principalmente, e isto é o mais importante de tudo, ele fala dos bloqueios que tem. E quando se diz “bloqueios” não é não saber programar ou saber onde colocar o codigo que faz X. Bloqueio é uma coisa que para o desenvolvimento. Que ninguem na equipe tem o poder de resolver. Por exemplo, esclarecer o propósito de um requisito. Não ter recebido o documento Z da equipe X que está em outro lugar. Não ter a licença do software que permite fazer uma parte do trabalho, etc… Coisas que o scrum master terá que correr atrás ou a equipe irá parar no meio da historia. O burndown chart pode ser feito por historias ou por tarefas. O ideial é que seja por tarefas porque a historia é muito alto nivel neste momento. Como se chega nas tarefas ? depois que o PO já fechou o Sprint Backlog a equipe reune rápidamente e parte as historias em tarefas. Estas tarefas é assignado uma pessoa e um tempo estimado em horas (0.5, 1 ,2 ,3 ,4, 6, 8 e multiplos de 8 dai em frente). O objetivo é ter uma ideia clara, por um lado, das tarefas em si por outro, se o tempo realmente via caber no sprint como a equipe prometeu. Se o tempo explode o sprint a equipe tem que trabalhar com mais eficácia e para próxima, saber avaliar melhor. É um mecanismo trial-and-error. As pessoas aprender a estimar melhor, estimando errado e sentindo a pressão que elas mesmas criaram. O numero total de horas é o o topo do gráfio de burndown e isso vai caindo dia-a-dia. Por isso que cada um tem que dizer o que já completou, que é para o gráfico ser atualizado. E estamos falando de um papel preso na parede que o pessoal escreve com lápis. Muito simples. Este exercicio dá a visão real das tarefas, de quanto elas duram, e como a historia era ou não grande. Se as tarefas são complexas ou se falta informação sobre o que realmente fazer em concreto. O que for bloqueio o scrum master anota e resolve depois da meating acabar. Na próxima meating ele dará a solução. Ou antes, até se for urgente. Lembre-se que durante o sprint a equipe é isolada do PO, e o SM é o canal da equipe para o PO (nunca do PO para a equipe) de forma que a equipe não pare. às vezes o que faz equipe parar são situações politicas ou fisicas do espaço de trabalho, e o SM tb tem que resolver isso.
O processo é simples, e o objetivo é equipe medir o quanto está afastada da sua própria promessa. Não permitido conversa tecnica no meating. Problemas tecnicos devem ser resolvidos pela equipe sózinha. o SM não tem estar envolvido nisso. Logo, a equipe deve resolver depois da meating acabar. Mas na meating é válido a pessoa dizer ” não sei usa a API XYZ” Mas só isso. ninguem explica nada naquele momento. Só depois da meating. A meating é de gerencia, gerencia da equipe em si. É combinar o jogo.
O andamento das histórias é resolvido pelo andamento das tarefas correspondentes. E ninguém pode passar às tarefas da historia seguinte enquanto existirem tarefas na historia anterior.
Depois que o sprint acaba existem 2 reuniões. O sprint review, e a restrospectiva. O sprint review é relativo ao sprint que acabou. A retrospectiva é referente ao processo como um todo. Ao conjunto de todos os sprints e de todas as pessoas. Então quando vc fala em “melhorar do ultimo sprint” , não sei exatamente de que reunião está falando. O sprint não se melhora. O que se melhora é o processo como um todo. Tlv o SM não está fazendo o seu papel ( como v já falou que não está). Tlv o PO não está fazendo o seu. Ou a equipe. Ou tlv os stakholders estão se intrometendo demais com a equipe em vez de pedirem satisfaçam a quem devem ( ao SM e ao PO), ou tlv o sprint é muito curto. Ou muito longo. Ou tlv as historias não chegam bem definidas e se perde muito tempo indo e vindo no entendimento do que ha para fazer. Ou tlv as reuniões demoram muito. Ou tlv … etc… N problemas podem ser equacionados durante a Retrospectiva. O fluxo e o ciclo do scrum sempre será o mesmo. Mas a qualidade das partes e das pessoas pode ir aumentando com o tempo. É isso o objetivo da restrospectiva. Olha para trás e ver o que se pode mudar, e o que não se deve mudar porque está funcionando. Por exemplo, no seu caso um problema é o daily ser muito “status report”. Isso é o tipico assunto a ser discutido. Primeiro que não deve ser assim. Segundo porque o SM não pode deixar que seja assim. Se o SM diz que deve ser assim , ele não é SM. Na retrospectiva não se fala do projeto nem do software. Se fala do processo do scrum em si.
DO software se fala no Sprint Review. Aqui, logo a seguir ao final do sprint a equipe faz uma demo das historias que completou. Fala das que não completou e pq. Ha uma revisão rápida dos bloqueios que não poderam ser resolvidos. O PO vê tudo isto e baseado na demo ele declara as historias como prontas ou não ( tendo em consideração a definição de pronto que vc definiram no inicio). Ai os pontos das historias pontas são contados e é sabida a velocidade daquele sprint. A seguir o PO passa a falar como isso afeta o Release em que o Sprint está incluido e quais são os planos para futuro. Muito sucintamente. Isto especialmente se estiverem presentes os stakholders (que devem estar, mas é opcional). E é isso. Muito simples. Não deve durar mais de 4 horas. O objetivo disto é a equipe mostrar que realizou o que se comprometeu, e o que não consegui fazer existe uma razão. Não é simples preguiça. Serve também para o Po ganhar confiança nas estimativas e no trabalho da equipe. Repare que não ha nenhum tipo de control de qualidade muito especial. Nem demora muito. A historia deve declarar como ela irá ser demonstrada. Se foi com sucesso ela está pronta. Repare que isto não signfica que ela está perfeita o sistema não tem defeitos. Não é isso. É que a historia foi cumprida no nível de exigência do PO. Se ele quer aumentar o nível de exigência aumentando o conceito de “pronto” ele pode fazer isso no próximo sprint. Mas ai a equipe irá reagir com um orçamento menor. Tão simples quanto isso. O Sprint review é a reunião que fecha o sprint e contrabalança a reunião de Planejamento do Sprint. Podemos dizer que tecnicamente o sprint é o tempo entre essa duas reuniões.
Tudo o que vcs virem que é bom manter, vcs devem declarar na reunião de retrospectiva de forma a que os outros porcos e as galinhas tenha consciência desses pontos e os aceitam, ou refutem. Lembre-se que Visibilidade é um valor importante em scrum. Tudo às claras. Se vc sentem que não conseguem manter de uns sprints para os outros, falem isso também e esperem sugestões ou sugiram modificações no processo para que seja possível sempre fazer essas coisas que vcs viram que dá certo. O mais dificil de uma retrospectiva é as pessoas se lembrarem que não ha hierarquia e que estão todos no mesmo barco, sentados na mesma mesa, no mesmo nível. Ninguem é mais que ninguém nesta reunião porque os papels que cada um desempenha são irrelevantes nesta reunião. São apenas pessoas falando de como é possivel melhorar um processo que foi escolhido. Em tese o SM pode ajudar mais a guiar os temas e a organizar as falas, mas isso não significa que ele manda mais. O mesmo as galinhas. Não é porque o cara é o diretor comercial ou de marketing ou do RH que ele pode mais que outros. Este é que é o problema da restrospectiva. Se as pessoas não estão alinhadas com o scrum , passa a ser um jogo de poder ou uma festa de botar culpa nos outros. Isso não é objetivo. Uma boa retrospectiva é aquela onde as pessoas têm respeito umas pelas outras, independentmente dos seus papeis na organização e todas dão opinião para melhorar um bem comum que é o processo. As pessoas neste mesa forma um colegiado e o que for acordado por consenso ( não por maioria, nem pelo poder do diretor) vale. às vezes ha que fazer tentativa e erro, mas é ai que as pessoas aprendem. A retrospectiva serve também para tirar duvidas sobre o scrum e/ou como explorá-lo melhor. Todo e quaquer implamtação de scrum começa com uma retrospectiva.
Espero que esteja esclarecido. Leia mais material no blog sobre scrum (no menu ‘scrum’) onde eu explico estas coisas com mais detalhe.