Ser ágil é uma questão de princípios
Parte 1 - Entrega de valor
A gente já destrinchou os quatro valores do Manifesto Ágil. Já explicou, com riqueza de detalhes, os motivos para usar modelos iterativos de desenvolvimento. Agora, vamos nos aprofundar um pouco mais nos princípios ágeis.
Por mais que a gente use processos e práticas ágeis a todo momento, às vezes é preciso revisitar os valores e princípios para entender por que escolhemos essa forma de desenvolver e descobrir, com a troca de ideias, o que poderíamos fazer diferente para melhorar nossos processos e desempenho.
Criado há 14 anos, o Manifesto Ágil instituiu uma nova forma de entender projetos que lidam diariamente com imprecisão e imprevisibilidade. Por isso, ele ainda é o documento mais importante para quem quer ser ágil e o melhor guia para quem já trabalha com metodologias ágeis.
Quando acessamos a página do Manifesto, damos de cara com os quatro valores que sustentam o documento. Essa é apenas a porta de entrada. É na página seguinte, dos Princípios Ágeis, que encontramos frases mais específicas e mais fáceis de entender para colocar os conceitos em prática.
Ainda que os Princípios Ágeis nos tragam informações um pouco mais profundas, o Manifesto como um todo é um material muito sintético, que pode ser interpretado e aplicado de diversas formas.
Pensando nisso, criamos uma série de posts para desembaraçar esse novelo, citando exemplos de aplicação e algumas práticas associadas a eles. Os 12 princípios foram divididos em três partes para deixar a leitura agradável e, ao mesmo tempo, substancial.
Optamos por dividir os princípios de acordo com a aplicação. Hoje, veremos os que abordam entrega de valor. Vamos lá?
Nossa maior prioridade é satisfazer o cliente com entregas frequentes de software em funcionamento
Lembra do conceito de desenvolvimento iterativo e incremental, que abordamos na semana passada? Ele se aplica bem aqui, no primeiro princípio, ao priorizar a satisfação do cliente com entregas regulares de pequenos pedaços do software em funcionamento.
É importante ressaltar que o software não deve estar funcionando de qualquer jeito, como um protótipo. O ideal é que, já no início, ele entregue valor para que o cliente compreenda melhor as etapas seguintes. Até porque, alguns detalhes importantes para a experiência do usuário só são percebidos quando acessamos o software e conseguimos enxergar com clareza o que faltou e o que não precisaria estar ali.
Aqui na Aerochimps, seguimos as três etapas de entrega. Quando finalizamos uma tarefa, testamos o que foi feito em um servidor local. Se estiver tudo certo, evoluímos para a homologação, etapa em que rodamos a parte do software que foi construída em um ambiente igual ao que será acessado pelo usuário após a implantação (deploy).
Os sprints são sempre baseados em entregas funcionais em homologação. Às vezes, é preciso dois ou três sprints para que aconteça um deploy. Só depois de concluir e aprovar todas as etapas com o cliente é que colocamos a atualização no ar, para que o usuário acesse.
Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente
Criamos expectativas com as coisas o tempo inteiro: desde a hora em que acordamos e imaginamos como será o dia até o momento em que sentamos para projetar um software e sonhamos acordados com o quão maravilhoso ele será quando estiver completo.
Mas nada impede que soluções diferentes e melhores do que aquelas que foram pensadas lá no início do projeto apareçam durante o desenvolvimento. E quando isso acontece, o que a gente deve fazer? Deixar de implantar um projeto por não ser compatível com a realidade não é uma opção. Então, o que nos resta é abraçar as novas ideias e chamá-las de “miga”.
Essa proposta de “abraçar as mudanças” é muito forte por aqui. O cliente e o usuário validam o software a todo momento. A gente leva as opiniões, críticas e sugestões deles muito a sério. Sempre estudamos o que pode ser feito para melhorar. Se a sugestão beneficiar o software ou o usuário, ela ganha um abraço de urso (metafórico) do time de desenvolvimento.
Mas a gente sabe que, ao receber novos requisitos, alguns times têm dificuldade de lidar com a necessidade de esticar os prazos ou aumentar o custo do projeto. Uma dica legal é manter um product backlog para facilitar a troca de requisitos e dar visibilidade ao que será removido do projeto com a entrada de novos quesitos.
Entregue software funcionando com frequência, em intervalos de semanas ou meses, dando preferência para períodos mais curtos.
A gente já abordou isso nos tópicos acima, mas é importante destacar que as entregas e implementações frequentes ajudam o time a saber se está indo no rumo certo. Não há como saber se o software atende às expectativas se não existirem usuários reais.
Além do mais, mudanças constantes mantém os usuários fiéis ao produto. Se falta alguma funcionalidade que o usuário acha importante, mas ele percebe que o software é sempre atualizado, que a opinião dele importa, que o suporte faz o melhor para satisfazê-lo, é muito provável que ele continue usando a ferramenta enquanto aguarda sua necessidade ser sanada.
Software funcionando é a primeira medida do progresso
Apesar de simples, esse princípio toca em um assunto delicado. Ele desafia as medidas tradicionais de desenvolvimento, que acreditam na produção de documentos, relatórios e análises como formas de medir o progresso do time.
Aqui na Aerochimps, a gente não entrega nada além do software funcionando. Isso porque acreditamos e defendemos a cultura de que essa é a melhor forma de avaliar o avanço do desenvolvimento. Como o cliente acompanha e participa de todo o processo, tende a funcionar muito bem.
Porém, ao contrário do que algumas pessoas imaginam, o Manifesto Ágil não condena a documentação. O que ele propõe é que essa documentação e as fases pré-desenvolvimento não sejam consideradas como evidências de que o projeto vai “muito bem, obrigado”.
Ainda que a documentação tenha alguma utilidade, só o produto em desenvolvimento serve de medidor de rendimento e qualidade.
Dicas de leitura
Continuaremos esmiuçando os princípios ágeis nas próximas semanas. Se você quiser que abordemos alguma prática em especial, é só pedir aqui nos comentários, que faremos o possível para tirar suas dúvidas.
Enquanto os próximos posts não vêm, que tal continuar lendo sobre agilidade no desenvolvimento de softwares? Separamos alguns textos que você pode gostar:
- A segunda parte da série, que aborda os quatro primeiros princípios ágeis;
- Este texto, que aborda o surgimento do Manifesto Ágil e explica, tim-tim por tim-tim cada um dos valores que sustentam o documento e;
- Este artigo completinho sobre desenvolvimento iterativo.
