Ser ágil ou não ser?

Explicando os quatro valores do Manifesto Ágil

Se a razão deste artigo existir fosse apenas para responder ao questionamento do título, o texto terminaria no primeiro parágrafo, logo depois de afirmarmos que: desenvolvimento ágil é, sim, a melhor escolha.

Mas a verdade é que queremos mais do que isso. Queremos responder às suas perguntas, dizendo por que adotar metodologias ágeis na sua rotina de desenvolvimento. Queremos te explicar, sem letras miúdas, os quatro valores que sustentam o Manifesto Ágil.

Por isso, quem ainda não sabe o que é o Manifesto Ágil, será apresentado a ele. Quem já conhece o Manifesto Ágil, mas nunca se dedicou a entendê-lo, fará isso agora. E aqueles que já conhecem o documento de trás para frente e fez dele uma bíblia, terá a chance de manter o conteúdo fresco na cabeça.

Aí, se você gostar da nossa abordagem, a gente continua discutindo o tema em outras postagens. Ficamos combinados assim?

Manifesto Ágil: o que é, de onde veio e o que eu tenho a ver com isso

Não dá para falar de métodos ágeis sem, primeiro, entender o que é esse tal de Manifesto Ágil. Por que não?

Primeiramente porque os métodos ágeis têm seus valores e princípios fundamentais descritos no Manifesto para o Desenvolvimento Ágil de Software, ou, para os íntimos, só Manifesto Ágil.

Segundamente porque se você queimar etapas e correr para aplicar metologias ágeis sem entender o conceito, pode cometer erros graves.

Sendo assim, um breve resumo sobre a criação desse manifesto que a gente considera pacas:

O Manifesto Ágil surgiu em Fevereiro de 2001, em Utah, EUA. O texto foi rascunhado por 17 desenvolvedores, entre eles Kent Beck, Martin Fowler e Ken Schwaber, que mais tarde vieram a se tornar grandes defensores das metologias ágeis.

O documento instituiu uma nova forma de entender projetos que lidam diariamente com imprecisão e imprevisibilidade, características comuns ao processo de desenvolvimento de software.

Embora cada um dos autores tivesse suas próprias práticas e teorias preferidas, todos concordavam que os projetos de sucesso tinham um conjunto de princípios em comum. E esses princípios eram embasados por alguns valores. E é sobre isso que vamos falar agora.

Os quatro valores do Manifesto Ágil

“Mas, Chimps, tô olhando aqui o quadro e entendi que o desenvolvimento ágil descarta os valores mais à direita. Confere?” Na verdade, não. O que esse quadro diz é que, mesmo existindo valor aos itens da direita, no movimento ágil, os itens à esquerda são mais valorizados.

Como assim? A gente te explica.

Interação entre indivíduos

Para as metodologias ágeis, a qualidade da interação entre os membros do time é um fator importantíssimo. A boa comunicação e feedbacks constantes são práticas essenciais para o bom desenvolvimento do projeto.

Aqui na Aerochimps, por exemplo, a gente conversa sobre as tarefas o tempo todo. Os designers validam requisitos e apresentam propostas de soluções para os desenvolvedores antes mesmo de começarem a projetar.

Dessa conversa, surgem feedbacks importantes, como sugestões, opiniões e questionamentos. Além, é claro, de ser um método eficiente para evitar retrabalhos. Fazendo dessa forma, dificilmente uma tarefa aprovada pelo time retornará à mão do designer.

Os desenvolvedores também fazem a mesma coisa. Quando encontram qualquer problema ou têm alguma dúvida que não foi abordada em um primeiro momento, o time se reúne para avaliar a melhor forma de contornar os bloqueios, defender um plano de ação ou apenas para explicar os motivos de escolher o caminho A ao invés de B.

Isso porque a gente acredita que são os processos que devem se adaptar às pessoas, e não o contrário.

As técnicas existem para guiar e apoiar o desenvolvimento de software. E as ferramentas para melhorar a eficiência do trabalho. Mas é com a capacidade, o conhecimento e a experiência dos integrantes do time que contamos na hora de tomar as decisões críticas sobre o projeto.

Produto funcionando

A documentação não substitui a interação. Ela pode até facilitar esse processo, funcionando como um subproduto na forma de rascunho, desenhos e anotações. Mas, obviamente, não tem o mesmo efeito do software em funcionamento. Nem para o time, nem para o cliente.

A entrega iterativa, ou "entrega evolutiva" de versões do software em funcionamento facilita a obtenção de feedbacks sobre o que foi entregue, de forma que os sprints sejam planejados dinamicamente, baseados nesses feedbacks.

A gente já abriu mão da documentação faz tempo. A nossa forma de trabalhar já é o próprio registro.

Mas… como?

Antes de projetar uma tela, por exemplo, descrevemos os cenários ou construímos mapas mentais para entender as ações do usuário dentro do software. Ao acessar esses registros, o time entende a proposta rapidamente.

E no Photoshop, sempre nomeamos layers e pastas de maneira que qualquer pessoa consiga entender quando abrir o arquivo.

O mesmo acontece com os códigos. A gente os constrói com nomes que fazem sentido. E quando é preciso explicar algo, comentamos dentro do próprio código.

Não existe “meu desenho”, “meu projeto”, “meu código”. Tudo é construído para todos terem acesso. Isso evita que, mais tarde, a gente precise fazer um .pdf gigante para explicar cada comportamento da interface, cada pedacinho de código.

Colaboração com o cliente

A divisão entre “nós” e “eles” para tratar os clientes e o time de desenvolvimento é uma linha tão tênue que, praticamente, não existe mais.

O cliente faz parte do time. Mais que isso: geralmente, ele conhece melhor o mercado e os usuários do que qualquer outro membro da equipe. Por isso, pode tomar decisões muito mais acertadas e de forma mais rápida.

Ao contrário das metodologias tradicionais, que possuem escopo fechado, a metodologia ágil propõe que o cliente participe de todo o processo.

E isso pode resultar até na mudança de rumo do projeto. Muitas vezes porque, ao acompanhar de perto, o cliente percebe, por exemplo, que o esforço necessário para desempenhar uma tarefa que não irá interferir tanto no resultado final pode simplesmente não valer a pena.

Essa proximidade entre cliente e time gera bastante valor ao projeto. A equipe aprende com o cliente. E o cliente, além de entender como a equipe trabalha, participa ativamente da construção do software.

Responder a mudanças

Iterações curtas permitem mudanças mais rápidas, que atendam às novas necessidades dos clientes.

O nosso sprint, por exemplo, tem o tamanho de duas semanas. E o planejamento ocorre em cada um deles. O que é encontrado no sprint anterior pode afetar os seguintes.

Cada situação pede uma conduta diferente. Às vezes o projeto segue o planejamento, às vezes sofre pequenas ou grandes alterações. As mudanças que podem ocorrer em cada sprint influenciam não só o desenvolvimento, mas também podem impactar o modelo de negócio como um todo.

Conclusão

Esse assunto ainda dá pano pra manga e muita conversa de bar. Este texto não responde todas as dúvidas e nem tem a intenção de esgotar o assunto. Na verdade, a nossa proposta é muito mais humilde.

O que nós fizemos foi apresentar o conceito e mostrar para você um pouco da nossa experiência com os métodos ágeis. Isso porque acreditamos que exemplos ajudam a compreender e assimilar os conceitos.

Além do mais, depois de aprofundar nos valores, fica mais fácil processar os 12 princípios do Manifesto Ágil. Mas isso é assunto para outro artigo. A gente se vê? ;)

Gostou do texto? Que tal recomendá-lo? Você também pode seguir a gente no Facebook e no Twitter e ficar por dentro das nossas atualizações semanais. (: