Metodologias Ágeis de Desenvolvimento (Locaweb)

O Coding Dojo é uma prática muito interessante e divertida. O principal objetivo é praticar, aprender e ensinar técnicas de desenvolvimento de software.

Há algum tempo realizamos sessões internas de Dojo na Locaweb. Decidimos agora criar uma sessão aberta a qualquer desenvolvedor. Segue abaixo um vídeo explicando os principais conceitos do Coding Dojo.

Mantemos um projeto no github. Lá você poderá baixar os códigos e verificar o calendário das sessões. Para participar, basta enviar o nome completo para daniel.cukier  arroba locaweb.com.br ou adolfo.sousa arroba locaweb.com.br dizendo a data que você gostaria de participar.

O pessoal da ThoughtWorks fez um vídeo divertido sobre o mundo ágil, fazendo uma versão da canção “My Favourite Things” (via @paulocaroli):

Recentemente Dov Bigio, Gerente de Produtos de Telecom da Locaweb, postou em seu blog sobre “O triângulo dos projetos“, que explica que dadas as variáveis de um projeto (qualidade, custo e prazo) pode-se fixar no máximo duas delas, e a terceira irá variar. Ou seja, se fixarmos prazo e custo, a qualidade poderá ser menor do que a esperada. Ou se fixarmos a qualidade e o custo, o prazo poderá ser maior que o esperado. Nunca conseguiremos fixar as três variáveis de um projeto.

O pessoal da 37signals prefere manter a qualidade sempre fixa (num patamar alto) e substituiu a qualidade pelo escopo no triângulo dos projetos. Eles também recomendam que devemos sempre fixar prazo e custo de um projeto e sempre flexibilizar o escopo.

Vou explicar como isso faz sentido usando como exemplo um projeto recente que tivemos aqui na Locaweb, o projeto de reescrever o site.

site da Locaweb antes do projeto de reescrever o site

Em novembro de 2008 decidimos que já havia passado da hora de termos um novo site que estivesse mais em linha com tudo o que temos estudado sobre experiência do usuário, design centrado no usuário, arquitetura da informação, design de interação e conceitos de web 2.0 com maior participação do visitante do site. Decidimos também o prazo, na primeira quinzena de março de 2009 esse site deveria estar no ar. E o custo também estava fechado: não íamos contratar ou pegar empresatado de outra equipe ninguém a mais para tocar esse projeto.

Tomada a decisão, começamos a desenhar o escopo do projeto. Dentre os vários requisitos do projeto tivemos:

• navegação simples e intuitiva
• manter o código bem enxuto
• aplicar SEO em todo o site
• minimizar o uso de flash
• design visual leve, para dar importância à informação contida nas páginas
• rever a arquitetura de informação de todo o site, revendo todo o conteúdo

Fizemos o planejamento para 6 sprints de duas semanas cada. Numa determinada altura percebemos que não ia dar para fazer tudo para lançar na primeira quinzena de março. Ficamos então pensando se íamos aumentar o prazo ou se podíamos cortar algo do escopo desse projeto.

A entrega de uma projeto é muito importante, tanto para a equipe que trabalhou no projeto, que fica com a sensação de “dever cumprido”, quanto para o cliente do projeto, que irá usufruir dos benefícios de ter o projeto pronto. Com isso em mente, decidmos diminuir o escopo, descobrir alguma coisa que pudéssemos cortar do projeto a fim de entregá-lo no prazo. Dentre as opções de redução de escopo, escolhemos não rever a arquitetura de informação de todo o site, mas apenas das áreas mais importantes.

Com isso conseguimos entregar a tempo e os visitantes do site - principal “cliente” desse projeto - puderam usufruir de seu novo layout e de sua nova organização.

site da Locaweb depois do projeto de reescrever o site

De uma certa forma, redução de escopo e redução de qualidade são parecidos, mas têm uma diferença fundamental. Podemos reduzir qualidade de duas formas:

• fazer tudo o que foi planejado, só que fazer mal feito, ou;
• fazer menos do que foi planejado, só que bem feito.

Já quando falamos em redução de escopo, não damos margem para interpretação: é sempre fazer menos do que foi planejado, mantendo o trabalho bem feito. E muitas vezes quando fazemos e entregamos menos, percebemos que o menos que entregamos já é suficiente e que o produto final de nosso projeto ficou melhor com menos do que o que foi originalmente planejado.

Então da próxima vez que você pensar em reduzir a qualidade de seu projeto para poder entregá-lo no prazo e dentro do orçamento, pense se não seria melhor reduzir o escopo. Você e seu cliente poderão sair ganhando com a redução de escopo!

Há quase um ano atrás eu comentei sobre a mudança do papel do gerente em um time que resolveu adotar metodologias ágeis. Na London QCon 2009 foi apresentada a palestra Managers in Scrum de Roman Pichler, um consultor inglês especializado em gestão ágil de produtos.

A apresentação completa pode ser vista em:

http://www.infoq.com/presentations/managers-in-scrum

Quem quiser ver só os slides, pode baixá-los aqui.

Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:

Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:

Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:

E, por último, um resumo:

Vale conferir essa apresentação.

Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:

• Agile development is more culture than process
• Creating The Culture For An Agile Environment

Pesquisando na Wikipedia, encontrei as definições abaixo:

• Cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.
• Processo é um cojunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.

Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.

Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.

É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.

E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …

A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/

Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.

Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.

Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.

Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:

• por que esses princípios são importantes para nosso time?
• o que tem sido feito para seguir esses princípios?
• onde não seguimos esses princípios e por que?

Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.

Algumas semanas atrás a InfoQ publicou um post divulgando uma pesquisa chamada Assess Your Agility, do site ABetterTeam.org. Fizemos essa pesquisa na Locaweb e chegamos a resultados bem interessantes. O resultado inclui algumas dicas de como agir para melhorar os itens com pontuação baixa (ex: Some practices that can help you get there: Ten-Minute Build; ‘Done Done’; Version Control; Pair Programming).

Um detalhe interessante é que fazendo 100 pontos você ganha um “You’re awesome! No further improvement needed“, sendo que a pontuação máxima de cada item é 99 pontos (”improvement possible“). E isso em Agile faz todo o sentido

Link para a pesquisa: http://www.abetterteam.org/new

Em um post antigo, de 2007, um dos pais das metodologias ágeis, o Alistair Cockburn, enumera 10 formas de saber se um time NÃO está sendo ágil.

Acho que vale refletir sobre essa lista. Por um lado, é provável que vários itens dessa lista seu time já tenha resolvido, mas pode ser que ainda falte um ou outro item:

In no particular order, you know you’re not doing agile if:

1. The team is co-located, but people are not sitting within the length of a school bus to each other.
2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.
3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.
4. If no user has seen real running software inside the last month.
5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.
6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.
7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.
8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.
9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.
10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Apresentação interessante sobre métodologias ágeis. Pode ser útil quando você precisar apresentar o tema em algum lugar:

Texto muito interessante sobre “deploy contínuo”. Seria o próximo passo depois de se alcançar a “integração contínua”.

http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html

A idéia é bem simples (o destaque é meu):

The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass deploy to the cluster. If the deploy succeeds, repeat.

Our tests suite takes nine minutes to run (distributed across 30-40 machines). Our code pushes take another six minutes. Since these two steps are pipelined that means at peak we’re pushing a new revision of the code to the website every nine minutes. That’s 6 deploys an hour. Even at that pace we’re often batching multiple commits into a single test/push cycle. On average we deploy new code fifty times a day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

No ano passado vimos o movimento ágil crescer e se alastrar por todo país. Muita gente tomou contato pela primeira vez com Scrum, XP, Lean. Vamos recapitular tudo que aconteceu e fazer uma breve reflexão sobre o que vem por aí no mundo ágil.

O Passado

No final de 2006, a equipe que desenvolve o Pabx Virtual começou a usar Programação Extrema como metodologia de desenvolvimento. Por ser uma equipe pequena, nova e independente das outras, todas as práticas da metodologia puderam ser adotadas gradualmente e o produto foi um sucesso.

Em agosto de 2007, a Locaweb resolveu estender as práticas ágeis para todas as equipes de desenvolvimento e promoveu um treinamento para todos os 80 programadores da época. A partir daí todos adotaram Scrum. Depois de 6 meses de adoção, já pôde ser percebida o aumento de produtividade da nossa área de tecnologia.

Em maio de 2008 o Joca inaugurou o blog ágil com o objetivo de compartilhar nossa experiência com todos os clientes. Escrevemos vários posts no ano de 2008, muitos deles introdutórios e básicos:

• Como tudo começou - uma pequena introdução aos primórdios dos M.A.
• Scrum - os primeiros ensinamentos sobre a metodologia que virou moda em 2008.
• Histórias de Usuários, como escrevê-las de várias maneiras.
• Fizemos WebCasts sobre Métodos Ágeis, Scrum e XP.
• Falamos das práticas de XP, refatoração.
• Como estimar de forma ágil, estimar jogando e acompanhar os resultados do sprint.

No meio do ano de 2008, por volta de agosto, percebemos que nosso público já havia entendido os princípios dos Métodos Ágeis e começamos a abordar temas mais avançados. Participamos da conferência internacional Agile 2008 e resumimos os melhores momentos. Além desse evento, o final do ano foi marcado por uma maratona de encontros da comunidade ágil.

Em outubro tivemos o Encontro Ágil, promovido pela Agilcoop da USP. Foi um evento de muita qualidade, principalmente pelos debates e discussões, com nomes importantes como Fabio Kon, Dairton Bassi Juan Bernabó. No mesmo mês ainda tivemos o Rails Summit Latin America promovido pela Locaweb, com vários membros da comunidade rails e ágil internacional, como Chad Fowler, Fábio Akita, Danilo Sato, Fábio Kung. E no final de outubro ainda tivemos o Falando em Agile, organizado pela Caelum, onde Daniel Cukier fez uma palestra contando das técnicas que usou para ajudar a introduzir métodos ágeis na Locaweb. Foi realmente uma maratona, mas valeu muito a pena, não só para aprimorar os conhecimentos em assuntos Ágeis, como para conhecer melhor quem são as pessoas que estão fazendo a diferença em matéria de desenvolvimento de software, no Brasil e no mundo.

Mais para o final do ano começamos a falar de Lean, introduzindo alguns conceitos como Teoria das Restrições, Investimento em Opções, e voltamos ao XP falando de pareamento e tópicos de como integrar Ágil com UX.

A adoção de Métodos Ágeis na Locaweb não foi feita do dia para a noite e o processo foi demorado e muito suado. Para conseguir convencer as pessoas de que Ágil era uma boa idéia, usamos Padrões para Introduzir Novas Idéias. Apresentamos alguns padrões para que nossos leitores pudessem usá-los e facilitar a adoção de Ágil em suas empresas.

Em novembro, participamos da QCON em São Francisco, uma das maiores e melhores conferências de software do mundo. Fizemos alguns artigos sobre o evento:

• BDD Behaviour Driven Design com Dan North
• Agilistas e Arquitetos: aliados, não adversários
• Como montar um time a qualquer hora
• Programação poliglota e multi-paradigmas

Em dezembro iniciamos uma série de vídeos sobre vários assuntos ágeis como Integração Contínua, Refatoração, e Padrões para Introduzir Novas Idéias e terminamos o ano com um post sobre bíblia dos sistemas, outro sobre o case AG2 e mais outro sobre a análise da causa raíz.

O Futuro

Apesar de termos caminhado bastante, sabemos que desenvolver software é um processo de melhoria contínua. Isso significa que sempre teremos coisas novas para aprender. Enquanto os Métodos Ágeis estavam restritos ao pequeno grupo que criou as metodologias, era fácil manter os conceitos claros e bem entendidos por todos. Na medida em que mais e mais gente começa a tomar conhecimento do assunto, bifurcações começam a acontecer e algumas vezes as pessoas acabam esquecendo dos princípios. É muito possível que hoje já exista gente dizendo que é ágil, mas que não segue o Manifesto Ágil.

Se formos pensar em todo universo de desenvolvedores de software, ainda tem muita gente que nunca ouviu falar de XP ou Scrum. Talvez alguns estejam mais antenado, quem lê blogs, quem acompanha a InfoQ, essas pessoas como você, que são uma minoria. Temos que lembrar que temos uma massa de programadores que ainda seguem os métodos antigos ou não seguem método nenhum. São pessoas que não tiveram acesso ao conhecimento e nosso papel é ajudá-los.

Vamos contar nossas experiências, nossos casos de sucesso, nossos casos de fracasso. Vamos ensinar à massa como se desenvolve software de qualidade, como se elimina desperdício, como se garante um custo de manutenção baixo e constante ao longo do tempo.

Vamos lembrar que pessoas e as interações entre elas são mais importantes que processos e ferramentas. Isso significa que, não é a linguagem de programação que você usa, o sistema operacional que você gosta, NÃO é isso que MAIS importa. Vamos valorizar as pessoas, fazer com que elas interajam de forma saudável, que trabalhem bem e em paz. Que sejam produtivas, mas que sejam felizes também e se divirtam, que possam crescer profissionalmente. Quem defende a bandeira ágil, defende o interesse das pessoas, todas elas em harmonia: os clientes, os programadores, os gerentes, os designers, os times operacionais e de suporte e todos que fazem parte de um grupo de pessoas interessadas em criar e usar bons produtos de software.

O próximo ano será não só de muitos desafios, mas também de oportunidades. A crise do ano passado serviu para avaliarmos nossa posição. Fizemos a reflexão. O que foi ruim e precisamos melhorar? O que foi bom e desejamos manter? Agora que a reflexão foi feita é hora de agir. Tem muito software para ser escrito e muito legado para receber manutenção e melhoria. Vamos escrever muitos testes automatizados, vamos continuar refatorando nosso código antigo, continuar fazendo nossos planejamentos cíclicos, entregando antes o que é mais importante, entregando com qualidade e de forma incremental, trabalhando juntos e pareados, ao lado do cliente.

Por último, vamos lembrar da verdade sobre a qual os Métodos Ágeis se baseiam: MUDANÇA! Tudo está o tempo todo mudando, nada é permanente. Ser ágil é se adaptar o mais rápido possível às mudanças. Kent Beck já disse isso desde o título do primeiro livro de XP (Embrace Change). Com certeza em 2009 teremos muitas mudanças e se somos realmente ágeis, vamos saber lidar com todas elas de forma positiva. Que esse ano seja cheio de agilidade, mudanças e sucessos para todos!