Quando os rótulos não atendem às suas necessidades

ler-rotuloAntes de começar esse artigo, eu preciso esclarecer. Eu não pretendo que esse seja o compêndio definitivo tal qual um comparativo entre os principais métodos (ou frameworks, ou práticas) ágeis disponíveis hoje. Nem tampouco quer determinar se existe uma resposta definitiva para as suas preces em decidir qual é a melhor, ou ainda, qual dessas visões está correta. O objetivo aqui é mostrar o quanto queremos adaptar as soluções às nossas realidades, políticas e culturas, sem ao menos entender o porque de cada uma das propostas.

Para entendermos o mundo ágil, a nossa maneira de pensar, precisamos entender que o movimento ágil não nasceu do nada. Houve uma necessidade, uma crescente necessidade, marcada pela insatisfação em nossas entregas. Nós já éramos profissionais, no sentido de que éramos muito bem treinados, sabíamos fazer o nosso trabalho como poucos profissionais em suas áreas são capazes de fazer. Desde de muito tempo, os programadores são consideradas pessoas completas, capazes de entregar projetos inteiros sem a necessidade de outros profissionais. Mas em algum momento os projetos se tornaram maiores. Os projetos cresceram a ponto de que apenas um profissional sozinho não seria capaz de fazê-lo. De fato, seriam necessários muitos profissionais para que esse tipo de projeto seja realizado.

O Waterfall

Assim surgiu um artigo, escrito pelo Dr Winston Royce chamado Managing The Development of Large Software Systems, ou seja, Gerenciando o desenvolvimento de grandes sistemas de software. Perceba que estamos falando de GRANDES sistemas de software. Não se aplica a pequenas equipes, em pequenas empresas. Aplica-se a empresas que talvez trabalhem de maneira distribuída, com a análise sendo feita nos Estados Unidos, o desenvolvimento sendo feito na Índia, o teste sendo realizado no Brasil e a implantação sendo feita em qualquer outro local. Ou seja, isso não se aplica a grande maioria dos cenários das empresas que eu conheço ou trabalhei. Assim, quem falou que o Cascata (ou Waterfall) é ruim, não leu nem mesmo o título do artigo. Na verdade não leu absolutamente nada do artigo, só viu a figura da página um. Nas páginas seguintes, Royce fala coisas importantes, como as fases atuais tendo impacto em uma ou mais fases anteriores. Em verdade, ele recomenda que o ciclo todo seja executado ao menos duas vezes, para que tudo o que não foi previsto seja finalmente avaliado. Lá no final do artigo, ele recomenda que se envolva o cliente, coisa que sinceramente eu duvido que a maioria leu. Aplicando no ambiente ao qual ele se propõe provavelmente Waterfall funcione. Enfim, para podermos criticar um método devemos conhecê-lo bem o suficiente para podermos negar suas premissas e é claro, não passar vergonha no processo.

O legado do Waterfall

Como eu disse anteriormente, Waterfall foi ruim por si só, mas certamente mau aplicado. O grande problema desse modelo foi o seu legado. O legado do cascata foi que os profissionais de desenvolvimento de software passaram a cada um se preocupar com a sua parte, ou seja, o analista entende que seu trabalho termina quando a fase de desenvolvimento começar. O desenvolvedor entende que seu trabalho é receber a análise pronta e, quando entregar para os testes, está concluído. Assim, as pessoas passaram a pensar em silos, cada um no seu quadrado. As pessoas se “especializaram” em seu trabalho e esqueceram de toda a cadeia de valor que se presta a entregar software. Isso criou uma distância entre desenvolvimento e cliente, um problema que foi se agravando com os anos, que foi levando dezenas de desenvolvedores a ficarem decepcionados com seus trabalhos e culminou com o surgimento do Manifesto Ágil.

E com o manifesto surgiram diversas interpretações. Tal qual a palavra de Cristo foi interpretada por pessoas distintas criando religiões distintas quando cada enxergou somente uma parte de suas palavras. O manifesto passou pelo mesmo processo. Passemos agora a algumas dessas visões, aos menos as principais, segundo a minha própria opinião.

Kanban

Organizado por David Anderson, esse método tem se mostrado muito eficiente no processo de melhoria contínua. Isso se dá através de uma coisa muito simples, exposição. Expõe-se o processo através de um quadro no qual a cadeia de valor fica demonstrada, bem como todos os itens que estão sendo trabalhados em cada uma das fases. É muito simples e ao mesmo tempo muito poderoso.

O quadro (em japonês, kanban), aliado à várias políticas explícitas, tem como foco fazer com que as tarefas fluam suavemente pelo fluxo, gerando a mais alta previsibilidade do processo. Quadros, cartazes, painéis ou o que mais você adicionar para a gestão visual do seu processo vão lhe dar exatamente isso, visibilidade. As pessoas podem literalmente em um piscar de olhos identificar problemas dentro de um fluxo de atividades. Outra prática muito adotada é limitar a quantidade de trabalho em progresso (ou Work In Progress, abreviando WIP), com a finalidade de tratar os gargalos em seu processo, nivelando a capacidade produtiva e conseguindo uma melhor vazão das atividades. Medições como tempo de ciclo e do trabalho em progresso somam ao pacote de que Kanban é um método com foco no processo. Essa é a visão do Kanban.

Scrum

Organizado por Ken Schwaber e outros, esse framework é mais prescritivo que Kanban, por exemplo. Nele o foco principal é transformar equipes em times de alto desempenho e para isso se vale de um processo regrado por timeboxes. O conceito de timebox é bem simples: qualquer atividade tem um tempo definido para ser executada. Assim, existem nesse framework algumas atividades (ou cerimônias) propostas, bem como papéis (ScrumMaster, Product Owner e Time) e alguns artefatos que devem ser gerados com o intuito de atingir essa meta. O principal timebox do Scrum se chama Sprint. Ele representa um pedaço de tempo que varia entre uma a quatro semanas e é dentro dele que as atividades devem ser desenvolvidas. Dessa maneira, o time de desenvolvimento deve estabelecer um limite de capacidade para ser executado dentro de um ciclo. Durante o período em que o sprint corre, são feitas reuniões diárias, em pé, de no máximo 15 minutos para sincronização e acompanhamento do sprint. Perceba que essas reuniões são do time para o time, ou seja, não é um controle externo, o próprio time é responsável por cumprir aquilo que estabeleceu no seu planejamento.

Ao final do sprint acontecem duas cerimônias distintas, mas com função semelhante. A primeira, é a de Revisão (Review) no qual o time apresenta aquilo que foi realizado durante o sprint ao Product Owner, representante do cliente dentro do projeto. Nesse momento ele pode aceitar ou rejeitar as atividades, baseado nos critérios que estabeleceu previamente junto ao time. Atividades rejeitadas voltam para o backlog, fonte de requisitos do projeto, para serem repriorizadas pelo PO como candidatas para sprints futuros, se o mesmo julgar pertinente. A outra cerimônia é a Retrospectiva, na qual o time reflete sobre o seu processo, sobre os acontecimentos do último sprint e determinam ações de melhoria para serem executadas imediatamente no próximo sprint.

Em todas as fases desse processo, cabe ao ScrumMaster garantir que tudo flua com perfeição, que as cerimônias ocorram sem nenhum impedimento e que a equipe possa ter um bom desempenho, executando o seu trabalho da melhor maneira possível. De fato, podemos dizer que o objetivo do Scrum no final das contas é transformar uma equipe de trabalho em um time de alta performance, conforme Takeuchi e Nonaka descreveram em um dos documentos que foi usado para desenvolver o Scrum.

Extreme Programming

Diversas regras e práticas, todas com foco muito baseado no desenvolvimento de software. Interessante as pessoas chamarem esse conjunto de práticas como um método ágil, tendo ele nascido antes da escrita do manifesto. Ainda assim, é mais ágil que muitos. É composto de diversos princípios e papéis, dos quais destaco os mais importantes (de novo, do meu ponto de vista) a seguir.

Fases pequenas (Small Releases) – quanto mais cedo se tem o feedback de um ação feita errada, mais cedo se pode corrigir e continuar com o desenvolvimento, é disso que trata esse princípio.

Design Simples (Simple Design) – a solução mais simples (não confundir com simplista) é sempre a melhor para o seu problema atual. Nada de criar todo um framework para Strings quando o que se realmente precisava era simplesmente adicionar uma quebra de linha.

Time Coeso (Whole Team) – o time deve trabalhar unido, buscando todos o mesmo objetivo. Heróis devem ser desincentivados.

Semana de 40 horas (Sustainable Pace) – um princípio que pode gerar diversas interpretações. O que esse princípio prega é que devemos manter um ritmo que possamos manter indefinidamente para que estejamos sempre aptos a programar em nossa melhor forma. É claro que se uma hora extra ou outra acontecer não é o fim do mundo ou deixamos de ser ágeis, mas certamente é uma situação que deve ser evitada.

Reuniões em pé (Stand-up Meeting) – como as do Scrum, para que gerem incômodo suficiente para serem rápidas.

Propriedade Coletiva (Collective Ownership) – o único dono do código-fonte é a equipe de desenvolvimento. Aqui entram diversos valores que devem ser prezados no desenvolvimento, tantos que poderíamos escrever um artigo todo só sobre esse tema. O código deve ser escrito sobre certos padrões, seguindo as regras da equipe, de modo que um outro membro do time olhe e não seja capaz de reconhecer quem o escreveu.

Programação Pareada (Pair Programming) – duas cabeças pensam melhor que uma e nisso não há dúvida. Embora seja uma das práticas mais bem sucedidas dentro do XP é também uma das mais difíceis de se convencer os gestores, de que dois desenvolvedores, em um único terminal, gerarão mais produtividade do que se trabalhassem isoladamente.

Desenvolvimento Orientado a Testes (Test Driven Development), Refatoração (Refactoring) e Integração Contínua (Continuous Integration) – se você ainda não leu algo sobre isso, corra. Esse é o kit básico para qualquer desenvolvedor ágil.

A parte mais legal é que os conceitos de XP, por terem essa característica do foco no desenvolvimento de software, podem muito bem casar com quase todas as outras práticas com um mínimo de conflito, se houver. Uma última dica sobre essas práticas, leiam a versão em inglês, pois quem traduz “Sustainable Pace” para “Semana de 40 horas” é workaholic, com certeza!

Lean Software Development

Outra metodologia extremamente focada no processo, valorizando a remoção de atividades inúteis ou, de maneira mais abrangente, de tudo aquilo que não agregue valor ao produto, ou que não gere valor ao cliente. Consiste de 7 princípios, mas não se engane, até você encaixar sua cabeça no “Lean Thinking” leva um tempo e invariavelmente se comete muitos erros no processo de aprendizado, o que é bem esperado. São eles:

  • Elimine Desperdícios
  • Inclua a Qualidade no Processo
  • Crie Conhecimento
  • Adie Decisões e Comprometimentos
  • Entregue o quanto antes
  • Respeite as Pessoas e “Empower” a equipe
  • Otimize o Todo

Idealizado por Mary e Tom Poppendieck, suas práticas podem ser aplicadas em diversos ambientes, não somente em software, o que torna a sua importância maior ainda.

Como as pessoas no mundo real usam?

Vamos falar de alguns exemplos aqui, de equipes que souberam observar o manifesto e não simplesmente copiar uma aplicação ou metodologia. A primeira empresa é a VertexSoft. No começo, logo ao abrir a empresa, escolheram Scrum como sendo o modelo que seria aplicado ao seu desenvolvimento de software, sem adaptações. Algumas particularidades sobre essa empresa incluem que o time era distribuído, eram três desenvolvedores, todos trabalhando em home office, duas profissionais de marketing nos EUA e o Product Owner na Suíça. Uma coisa boa, foi que logo de cara já começaram usando TDD e integração continua.

Olhando assim parece que foi uma história de sucesso, correto? Infelizmente não, ao menos não ainda nesse ponto. No começo, os sprints falharam, o time não conseguia entregar tudo aquilo com que se comprometia no início da iteração. A principal queixa era a quantidade de histórias quase acabadas, histórias de usuário que o Product Owner até achava que estavam boas, mas que faltavam algum ponto ou outro para serem realmente aceitas como “done”. O time trabalhava para entregar a quantidade acordada no começo da iteração e por consequência de tentar atingir essa meta, se esquecia de algo importante, a qualidade.

É óbvio que nesse cenário o cliente ficou insatisfeito. As mesmas histórias iam e vinham, sprint após sprint, demorando várias semanas para chegar no estado ideal para serem finalizadas. Além disso, outra parte importante ficou insatisfeita, o time. Afinal, é muito frustrante trabalhar duro e ver que isso não gerou os resultados esperados e isso claro, gerou uma certa desmotivação na equipe.

Algumas mudanças se fizeram necessárias para mudar esse quadro. A primeira: adoção de Pair Programming. Como se tratava de uma equipe distribuída, foi necessário o uso de algumas ferramentas para que isso fosse possível, além de claro, muito disciplina. Foi utilizado TeamViewer e Skype, além do Google Hangout. Com isso tínhamos agora duas pessoas em cada história, focadas em tentar entregar aquela parte da solução de maneira total e sem se preocupar com as demais histórias na fila.

Outra mudança importante foi a adoção de entrega contínua. Não colocando cada parte da solução direto na mão do cliente final, mas a cada novo commit, o Product Owner recebia um beta para poder avaliar aquela história. Isso foi fundamental. O P.O. não precisava mais esperar até o final da iteração para poder dar o seu feedback sobre aquela parte do produto, mas podia fazer isso “on demand”. Histórias que levavam antes semanas agora, dentro do mesmo sprint, com um ou dois feedbacks a mesma era aceita, sem maiores problemas. Essa prática teve tanto impacto positivo que a cerimônia de Revisão (Review), aquela na qual o time apresenta as histórias, que antes levavam de duas até quatro horas, passaram a levar apenas 30 minutos em média.

O comprometimento também mudou. Se antes o foco da equipe era na entrega de um determinado lote acordado na reunião de planejamento, agora o time trabalha para concluir uma tarefa, no máximo duas, e após ter concluído aquela pode passar a trabalhar na próxima. Tivemos então um foco mudando de quantidade para qualidade daquelas histórias. Isso levou a outras mudanças, mesmo que não planejadas, deu um pouco mais de agilidade àquela equipe. A principal foi que, visto que o time não precisava mais se comprometer em entregar um determinado lote e sim uma história por vez com a melhor qualidade que se podia fazer, não havia razão para que aquela equipe estimasse as histórias. Isso economizou um tempo valioso da equipe, que manteve as reuniões de planejamento, mas com o foco na elicitação dos requisitos. Obviamente outros contatos entre em desenvolvedores e PO ainda poderiam (e deveriam) existir, mas essa mudança já gerou excelentes resultados.

No cenário atual, o cliente (que também é o Product Owner) está muito satisfeito, mesmo a equipe entregando, quando muito, umas 5 histórias por sprint, já que as que são entregues o são apenas uma vez e não se volta a falar delas, a não ser por melhorias baseadas no feedback e que não caberiam dentro daquele sprint corrente. Ou seja, o cliente tem seu pedido atendido no menor tempo possível, podendo validá-lo imediatamente, com a maior qualidade que o time consegue entregar.

Outra história interessante é a da Objective Solutions, unidade de Maringá. No começo de suas atividades eles começaram usando Scrum, também sem adaptações, usando o que foi possível usar de XP, user stories, estimando em story points e tudo o mais em que a literatura apontava como sendo uma boa prática. Após algumas observações, foi percebido uma certa sobrecarga de cerimônias devido ao fluxo de como as atividades chegavam até essa unidade. Como demandas ditas urgentes aconteciam com uma boa frequência, mesmo com sprints curtos de uma semana, logo após o início do sprint já haviam novas histórias que precisavam ser estimadas e planejadas, muitas vezes resultando no cancelamento do sprint todo. Isso também gerava um descontentamento do time, ao ver todo um trabalho de planejamento não funcionar pelas urgências. A solução foi que não havia espaço naquele ambiente para se trabalhar em lotes ou mesmo em iterações. Assim, as histórias iam sendo trabalhadas de acordo com sua chegada.

Adicionalmente à troca de iterações para fluxo contínua, outras ações foram feitas. O overhead que existia em se planejar histórias se mostrou desnecessário, pois a unidade ali em questão é somente para desenvolvimento, todas as atividades correlatas (atendimento à cliente, orçamento e outros) era feito pelas demais unidades. Já que comercialmente o cliente já recebia uma estimativa, baseada na estatística história do lead/cicle time, não fazia sentido onerar o tempo do time com mais essa atividade. Assim, passaram a não estimar novamente o que já estava definido.

A aplicação do Pair Programming também tinha lá suas peculiaridades. Existiam alguns personagens como o “forever alone”, com quem ninguém queria parear, o “herói”, com quem todos queriam parear e os “amigos para sempre”, duplas viciadas que sempre pareavam juntas. O defeito de um cenário assim é que isso não promove a distribuição do conhecimento, além de gerar desmotivação em membros da equipe que se sentiam prejudicados pelo rodízio. Isso foi tratado adotando uma tabela simples, cruzando todos developers com todos e estabelecendo como regra que os pares deveriam ser montados seguindo esse algoritmo. Em outras palavras, pair programming exige mais que disciplina, exige que tenha um método estabelecendo as regras do jogo.

Programadores são seres extremamente otimistas. Se você perguntar para um em quantos por cento uma determinada história na qual ele vem trabalhando a algum tempo está a resposta quase que invariavelmente é 80%. Programadores gostam de desafios e sentem que sempre estão a um passo de atingir a solução do desafio atual. É da natureza dos mesmos. Programadores assim dificilmente pedem ajuda, mesmo que em duplas, a dupla pode se tornar cúmplice no otimismo e achar degradante solicitar ajuda de alguém mais experiente. Isso leva a problemas de que esses programadores ficaram com a mesma atividade por longos períodos e a previsão dada pelo comercial pode ir por água abaixo. A situação oposta também é perigosa e tinha exemplos por ali. Existiam também aqueles desenvolvedores que sempre se sentiam perdidos e estavam solicitando a atenção do coordenador com frequência tal que não lhe sobrava tempo para atender os do primeiro exemplo. Depois de tentarem algumas coisas como bandeirolas para identificar as duplas que precisavam de dificuldade, finalmente criaram a Ronda Ativa, que nada mais é do que o supervisor (ou algum programador mais experiente) passar em cada uma das mesas verificando com cada um dos desenvolvedores suas dificuldades e auxiliando como podia, independente de terem pedido ou não ajuda. Ou seja, mesmo times maduros, precisam de ajuda e certo controle.

Enfim, muitas metodologias surgiram de um momento inicial, tal como o Big Bang gerou diversas galáxias, planetas e seres. Isso me lembra uma lenda que ouvi alguns anos atrás. Segue a sua transcrição:

Certo dia, um príncipe indiano mandou chamar um grupo de cegos de nascença e os reuniu no pátio do palácio. Ao mesmo tempo, mandou trazer um elefante e o colocou diante do grupo. Em seguida, conduzindo-os pela mão, foi levando os cegos até o elefante para que o apalpassem. Um apalpava a barriga, outro a cauda, outro a orelha, outro a tromba, outro uma das pernas…

Quando todos os cegos tinham apalpado o paquiderme, o príncipe ordenou que cada um explicasse aos outros como era o elefante. Então, o que tinha apalpado a barriga disse que o elefante era como uma enorme panela. O que tinha apalpado a cauda até os pelos da extremidade, discordou e disse que o elefante se parecia mais com uma vassoura.

“Nada disso”, interrompeu o que tinha apalpado a orelha. “Se ele se parece com alguma coisa é com um grande leque aberto.”.

O que apalpara a tromba deu uma risada e interferiu:

“Vocês estão por fora. O elefante tem a forma, as ondulações e a flexibilidade de uma mangueira de água…”

“Essa não”, replicou o que apalpara a perna, “ele é redondo como uma grande mangueira, mas não tem nada de ondulações nem de flexibilidade, é rígido como um poste…”

Os cegos se envolveram numa discussão sem fim, cada um querendo provar que os outros estavam errados, e que o certo era o que ele dizia. Evidentemente cada um se apoiava na sua própria experiência e não conseguia entender como os demais podiam afirmar o que afirmavam. O príncipe deixou-os falar para ver se chegavam a um acordo, mas quando percebeu que eram incapazes de aceitar que os outros podiam ter tido outras experiências, ordenou que se calassem.

“O elefante é tudo isso que vocês falaram, explicou. Tudo isso que cada um de vocês percebeu é só uma parte do elefante. Não devem negar o que os outros perceberam. Deveriam juntar as experiências de todos e tentar imaginar como a parte que cada um apalpou se une com as outras para formar esse todo que é o elefante.”.

Considerações Finais
Desenvolvimento ágil é isso caro leitor. Não é uma metodologia, limitada pela visão (mesmo que brilhante) de um determinado autor. Agilidade é compreender que todas as metodologias têm sua função, sua aplicabilidade e com certeza, após conhecer algumas com bastante propriedade, você poderá customizá-las para chegar no processo que mais se adequar a sua realidade. Pois no próprio manifesto, um trecho muito ignorado é o cabeçalho:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo…

Ou seja, algumas pessoas, no longínquo 2001, descobriram maneiras melhores de fazer software. Será que nós não somos capazes de também fazê-lo?

Posted on: 3 de julho de 2014, by :

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *