O que √Āgil significa 

Nov/12
7

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

7 comentários para “O que √Āgil significa”

  1. 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.

  2. 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.

  3. 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!

  4. 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.

  5. Sergio, muito obrigado novamente, vou ler novamente e pensar bastante a respeito. Depois posto aqui mais coment√°rios. Valeu!

  6. 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.

  7. 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.

Comente

Artigos