Metodologias Ágeis de Desenvolvimento (Locaweb)

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas” a se conhecer: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software e, consequentemente, qualidade de maneiras bem distintas.

Para os adeptos das metodologias tradicionais, que encaram o processo como uma cascata (primeiro alguém tem a visão do produto, depois algumas pessoas especificam o software, outras implementam, umas outras testam, a próxima coloca tudo isto em produção de uma vez para que então uma outra equipe não possa manter o software vivo, gerando algum tipo de valor), o conceito de qualidade se assemelha ao usado em processos de produção industrial: conformidade com requerimentos definidos na fase de design ou em alguma “receita”. A palavra chave que define qualidade neste cenário é conformidade. Espera-se que haja uma pré-definição clara do que é qualidade, do que é esperado, e se o software estiver “conforme” é possível dizer que o usuário dele estará lidando com um software de qualidade. Como é possível notar, variabilidade e diversificação não são desejáveis aqui.

Já os adeptos das metodologias ágeis tendem a enxergar qualidade de forma parecida com a qual prestadores de serviços a enxergam. O cliente de um software não sabe o que é ou não está preocupado com a qualidade, pelo menos não de uma forma definida, exata e clara. Ele pode estar em busca uma boa experiência ou esperando que o software lhe ajude a resolver algum problema. Talvez queira que o sistema lhe entregue algum valor mas também pode ser que diversão ou experimentação/inovação sejam o seu fim. Aqui, nenhum requerimento, documento ou receita definida previamente serve para atestar a qualidade do software. Então se não podemos definir, quer dizer que não há qualidade? De forma alguma. Neste cenário, qualidade não precisa ser exata, imutável, não precisa ter uma definição clara, não é possível lhe darmos um nome. O que buscamos, na verdade, é Qualidade Sem Nome, ou QWAN (Quality Without a Name).

Neste contexto, em que tratamos qualidade de forma não determinística, em que as expectativas mudam de usuário para usuário, alguns cuidados devem ser tomados para que, quando perguntarmos a um deles se determinado software tem qualidade, tenhamos como resposta algo do tipo: “hum, deixe-me ver… eu sinto que sim. Ele me ajuda, gosto dele, sinto confiança, ele é, como posso dizer, consistente”. Tarefa difícil, não? Difícil porém possível se entendermos dois conceitos extremamente importantes [1]:

1. Integridade Percebida - o produto como um todo alcança um equilíbrio entre funcionalidades, usabilidade, confiabilidade e economia que agrada os clientes.
2. Integridade Conceitual - os conceitos e partes centrais do sistema trabalham harmonicamente, de forma coesa, como um todo. Os componentes ou módulos se integram e trabalham bem conjuntamente.

Como você pôde notar, a Integridade Percebida e a Conceitual estão intimamente ligadas e têm papel fundamental na qualidade do software desenvolvido. Por esta razão, vou dedicar o próximo post desta série para discuti-las mais a fundo.

Até a próxima.

[1] - Os conceitos de Integridade Percebida e Integridade Conceitual foram extraídos do excelente livro Lean Software Development - An Agile Toolkit da Mary e do Tom Poppendieck. Eles, por sua vez, adaptaram os conceitos de “Internal Integrity” e “External Integrity” contidos no livro Product Development Performance de Kim Clark e Takahiro Fujimoto

Qualidade de software é um assunto pouco discutido por nós, profissionais da área. Já ouvi repetidas vezes o argumento de que este fenômeno acontece porque se trata de uma “indústria” ainda muito nova. Pode ser nova se comparada com outras como a têxtil ou a automobilística. Entretanto, não podemos aceitar argumentos conformistas como este e nem tampouco encarar desenvolvimento de software como indústria, sob pena de nos colocarmos num ambiente pouco adaptável, repetitível, prescritivo e de inovação lenta e cara. Não acredito que esta seja a natureza dos projetos de software.

Independentemente da maturidade deste nosso ofício, ou melhor, arte, qualidade deve fazer parte do seu processo de desenvolvimento e, portanto, não há motivo algum para não discuti-la com a mesma frequência que discutimos outros assuntos como linguagens, frameworks, metodologias, arquiteturas, etc.

Pretendo iniciar uma série de posts para falar de qualidade de software. Sejam bem-vindos e sintam-se livres para fazer parte da discussão.

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):

O segundo semestre está repleto de eventos ágeis, todos com excelente qualidade, inclusive com participação de grandes personalidades internacionais.

Dias 10 e 11 de Outubro teremos o Encontro Ágil, organizado pela Agilcoop. O evento teve sua primeira edição ano passado. Este ano serão dois dias de evento, durante os quais irão se reunir vários dos principais nomes da Comunidade Ágil brasileira, além das presenças de Alistair Cockburn (um dos autores do Manifesto Ágil) e Jutta Eckstein.

Logo na sequencia, dias 13 e 14 de outubro, teremos o Rails Summit, promovido pela Locaweb. A última edição reuniu mais de 550 participantes e neste ano espera um público ainda maior. Serão dois dias inteiros de palestras informativas e você terá a oportunidade de encontrar com grandes profissionais de todo o mundo, como Chad Fowler, Obie Fernandez, David Chelimksy, Fabio Kung, Fabia Akita, entre tantos outros.

Outro evento  de grande importância será a Agiles, 2a. Conferência Latino Americana sobre Metodologias Ágeis, com a presença de Brian Marick, outro autor no Manifesto Ágil, e outras personalidades, como  Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Kerievsky, David Hussman e Alexandre Magno.

Com certeza vamos nos encontrar nesses eventos e trocar experiências, tanto em matéria de metodologias quanto em técnicas de desenvolvimento de software. Nos vemos lá!

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.

Há algum tempo fiz um post sobre Padrões para Introduzir Novas Ideias. Recentemente montei um vídeo que mostra como esse padrões poderia ser aplicados de verdade para convencer as pessoas a adotarem métodos ágeis. Divirtam-se!

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.

Aconteceu entre os dias 06 e 09 de abril a Semana da Tecnologia da FATEC de Jundiaí, onde estou cursando Informática para Gestão de Negócios. No dia 09/04, a convite do Prof. Demerval (Teoria da Administração) , fiz uma apresentação sobre desenvolvimento ágil com Scrum e XP num dos mini cursos que faziam parte do evento.

A participação dos alunos foi muito legal e, o melhor de tudo, acredito ter conseguido despertar no pessoal o interesse pelo desenvolvimento ágil.

No mesmo dia, o Fernando, fez a apresentação com o tema “Introdução a TDD“. Na terça, 07/04, o Reinaldo, nosso gerente na área de comércio eletrônico da Locaweb, mostrou como é fácil criar uma loja ou um site de sucesso utilizando boas ferramentas disponíveis no mercado, com destaque para a Loja Pronta e o Pagamento Certo, com o tema “Não reinvente a roda, pegue uma pronta”.

Estamos procurando fazer nossa parte para disseminar o conhecimento e tentar tornar o mundo do desenvolvimento de software um lugar melhor

Os slides da apresentação de Desenvolvimento ágil com Scrum e XP para ver ou baixar: