Um pouco de história, o desenvolvimento de software sempre foi complexo e custoso e algumas coisas contribuíam para o aumento desses custos.

A gestão de projetos vem sendo aprimorada, formal ou informalmente, há milênios. As técnicas desenvolvidas em construção civil se tornaram a base da sequencia de atividades, iniciando com planejamento, previsão de custos e antecipação de problemas feita por engenheiros e na produção da "planta" a ser seguida fielmente e cegamente, por um time de construção habilidosos. - Eric Ries - Lean Startup

Imagina isso sendo aplicado à ambientes em que precisamos de mudanças e incertezas, como vemos no ambiente do desenvolvimento de software?

Levantamento de requisitos, criação do planejamento técnico e design de software, desenvolvimento e testes de acordo com a documentação e e no final a aprovação do cliente sobre o software construído. Esses seriam os passos de um software construído usam essa metodologia conhecida como waterfall ou cascata.

Para gerenciar tudo isso logo no começo do projeto é montado um lindo diagrama de Gantt, você já deve ter visto um desses em algum lugar.

Com tudo planejado nos mínimos detalhes e uma boa documentação de tudo que tinha de ser desenvolvido, tudo o que podemos esperar é o sucesso e satisfação do cliente. Afinal temos um plano super certo e que não vai falhar. Aí que mora o perigo e erro.

Os softwares desenvolvidos assim geralmente acabam inadequados, cheios de falhas, obsoletos em pouco tempo, com os prazos e expectativas raramente sendo atendidas.

Movimento ágil de desenvolvimento de software

Para resolver esse problema percebeu-se que era mais importante, que a construção através de interações e indivíduos era mais importante do que processos e ferramentas. Que o software funcionando é melhor do que uma boa e extensa documentação sobre os requisitos. Que a colaboração com o cliente era melhor do que a negociação do contrato e responder as mudanças mais do que seguir o plano.

Com isso surgiu o movimento ágil de desenvolvimento de software. Inclusive o paragrafo anterior menciona em negrito os pontos do manifesto ágil.

Postura em um time ágil

Mas o que muda para alguém que desenvolve software quando trocamos a metodologia?

1. Senso de time

Esse ponto se torna uma das bases do desenvolvimento ágil. Pessoas de negócios e o time de desenvolvimento trabalham em conjunto. Através de times auto-organizáveis que surgem melhores requisitos, designs e arquiteturas que atenda as necessidades do projeto.

2. Coragem/Empoderamento

No modelo tradicional de trabalhadores "habilidosos", recebem um plano para executar e sem questionamentos, afinal engenheiros de software já traçaram o plano do que deve ser feito. Então mesmo quando problemas são encontrados não é possível modificar.

Dentro de times ágeis a interação e pessoas são o mais importante, ao detectar um problema o time de desenvolvimento tem a autonomia para apontar e a responsabilidade sobre o plano. Afinal estamos falando de pessoas habilidosas.

O cliente e desenvolvedor precisam estar próximos para que tracem e mudem os planos de acordo com novas necessidades. Isso trás uma mudança na forma de agir, precisa-se ouvir melhor as necessidades do cliente e também defender com coragem suas ideias com base no conhecimento adquirido quando algo não faz sentido.

3. Aprendizado

Para responder as mudanças, precisamos da entrega consistente de software e funcionando.

Para entregar software funcionando e constantemente a pessoa desenvolvedora em um time ágil precisa gostar de aprender. No projeto, dentro das interações curtas e fora dele são aprendizados constantes. Isso é essencial para que a contínua atenção à excelência técnica e bom design, aumentem a agilidade.

A pessoa em um time ágil, precisa se preocupar com as suas entregas e melhores práticas. É fundamental estar atento aos ciclos de feedbacks e também ao estudar melhores formas de se desenvolver software.

4. Humildade

A humildade é uma das características mais importantes em um time ágil. O foco na melhoria constante depende de feedbacks e momentos em que o time reflete como ficar mais efetivo, se ajustam e otimizam seu comportamento de acordo com os pontos levantados.

O ciclo de feedback é sempre em busca de processos ruins, não de pessoas ruins, mas, as vezes pode ser apontado coisas que o próprio desenvolvedor precisa de uma grande humildade para aceitar e não ficar na defensiva ou achar que o time tem algo contra ele.

A humildade também ajuda no sentimento de time, para que todas as pessoas do time cresçam em conjunto.

5. Simplicidade

Se puder evitar escrever código, evite, a simplicidade vem de resolver problemas sem necessariamente precisar escrever código. Quando precisar escrever código lembre que menos é mais e entregar software funcionando com menos código ou código menos complexo é sempre melhor. A arte de maximizar a quantidade de trabalho que não precisou ser feito.

Boas práticas e ferramentas

Mas quais ferramentas e técnicas uma pessoa desenvolvedora em um time ágil precisa saber?

Para desenvolver dentro de times ágeis precisamos ter em mente o desenvolvimento sustentável e não o desenvolvimento heroico. Um sinal claro de disfuncionalidade em um time ágil é quando existem heróis nele.

Logo boas estimativas, ter o hábito escrever testes unitários, preocupação com o código limpo, versionamento de código, conhecimento de integração continua e code review são alguns dos hábitos muitos importantes em times ágeis.

Ao desenvolver em um time ágil é essencial também que o desenvolvedor tenha uma conhecimento das ferramentas ágeis e o que elas pretendem resolver, não precisa se especialista em ágil, mas é importante saber o que o XP, Scrum e Kanban pretendem resolver. Afinal o como você vai usar uma ferramenta sem saber o que ela resolve?

Esse texto foi escrito em preparação para uma talk na Concrete Solutions, feita em conjunto com o Celso e se quiser ver os slides da talk use o link. https://docs.google.com/presentation/d/1JwwPiPeb54hVvpy2R5cfiPVEm7xB8q3wGwnvQAIsAiw/edit?usp=sharing