De repente agile

Ametodologia ágil é um tema recorrente no meio de desenvolvimento de software. Tem objetivo satisfazer o cliente, tornar equipes mais motivadas e aumentar a qualidade do produto. Então, quais os obstáculos no caminho para se ter desenvolvedores com pensamento ágil? Quais obstáculos para fazer uma equipe ágil? E quais os obstáculos para alcançar uma empresa com uma cultura ágil?

O caminho para alcançar essa fluência permeia todo processo de desenvolvimento e em cada um destes passos pode ser feito algo para entregar valor adiantado para o cliente e ser mais agile.

Entrega adiantada e contínua de Valor

Voltando para a década de 1990 onde o planing mindset era a visão mais comum no desenvolvimento de software, o modelo em cascata deste mindset tinha o objetivo de produzir contratos para definir o que o cliente receberia e um prazo no qual ocorreria a entrega, que normalmente era dado em semanas ou meses. Apesar do modelo em cascata ainda ser utilizado hoje em dia, escolhi usar o futuro do pretérito para passar o feeling de prazos fantasiosos encontrados no histórico do planing mindset.

Mas o que ocorre com projetos em equipe que tem o mindset de planing para haver tantas falhas? A pergunta a ser feita é “no que a equipe está focando?”. Se a resposta é cumprir o contrato, isso acarretará na desconsideração das mudanças de contexto, de mercado e de visão do cliente ocorridas durante o processo de desenvolvimento e gerará a insatisfação do cliente e consequente falha do projeto.

Então a metodologia ágil reage a essas falhas, alterando o foco para a entrega software de valor para o cliente, e o pulo do gato é notar que há algumas conditios sini qua non.

Entregas continuas e frequentes

Os três primeiros princípios do manifesto ágil tem uma correlação forte, que pode ser traduzida por entregas incrementais.

Portanto, entregar software funcionando com frequência, aceitar a mudança de requisitos e consequentemente entregar valor de forma adiantada é fundamental para satisfação do cliente. Ou seja, sem entregas continuas e incrementais para obter uma entrega final adiantada, o risco de frustração cresce por não ouvirmos nossos clientes. Note como isso lembra uma das falhas do planing.

Logo vemos que pequenas entregas de valor no menor período de tempo possível possibilita:

• feedback do cliente, product owner e outros interessados;
• acolhimento de novos requisitos e re-priorização do backlog a partir do feedback recebido;
• avaliação da sustentabilidade do projeto do ponto de vista de mercado e retorno financeiro;
• a real compreensão do andamento do desenvolvimento do produto, visto que é possível mensurar a velocidade da equipe e a qualidade da entrega;

Ou seja, continuous delivery é uma poderosíssima ferramenta não só do ponto de vista técnico, mas também do ponto de vista de negócios.

Ter uma equipe que decida como trabalha, nivelada e multifuncional

Partindo para prática e aplicando a metodologia ágil, logo ficará claro que as equipes nem sempre respondem da mesma forma às mudanças para o ágil e modificar a forma de visualizar o mundo do desenvolvimento de software para ágil também não terá resultados instantâneos. Isto acontece em decorrência da natureza dos problemas em desenvolvimento de software e da natureza das pessoas envolvidas no desenvolvimento de software.

But why? Diferentes problemas exigem diferentes formas de resolvê-los e os times necessitam da liberdade e a capacidade de decidir como resolvê-los. Isto implica a desconstrução da visão da definição de um plano de como cada um irá trabalhar, na desconstrução da hierarquia dentro das equipes e resultante construção de um time multifuncional conforme Suttherland (2014, p.50).

Então, joguem fora os crachás!

Tenha em mente uma escala gradual, citada por Martin Fowler em sua palestra sobre Agile Essence and Fluency, onde são elencados os estágios e a estimativa de absorção da cultura ágil em uma organização. Foco no valor, entrega de valor, otimização do valor e alinhamento com a cultura da empresa. Cada uma delas tem seu tempo, variando de alguns meses à cinco anos para se obter fluência em cada estágio.

Por fim, deixo uma reflexão: ter uma equipe com profissionais T-Shaped pode ser um facilitador para este processo?

Tudo isto parece ser um desafio e tanto para se alcançar. Então por onde começar? Isto é um assunto que irei abordar no próximo artigo.

Espero que tenham gostado e que esse compartilhamento de experiência tenha te acrescentado algo de bom. Ficarei muito feliz com as críticas positivas ou negativas. Forte abraço!

Agradecimentos

Fico grato por todo conhecimento obtido nos diálogos e convivência com os membros da minha atual equipe, assim como demais amigos da Ignição Digital, que tem sido uma grande fonte de renovação e conhecimento. Em especial agradeço a Thomas Alvarenga e Vitor Nogueira pelas longas conversas sobre assuntos ligados a metodologia ágil, assim como opiniões sobre este artigo; agradeço também a Marcus Lucas, Bruno Quaresma e Dayvson Lima por seus olhares críticos, revisão e consequentes melhorias e a Dayanne Lima pela revisão gramatical.

Referências

Agile Manifesto — <http://agilemanifesto.org/principles.html>

Martin Fowler — Agile Essence and Fluency <https://youtu.be/URlnxbaHhTs>

Martin Fowler — Continuous Delivery <https://youtu.be/aoMfbgF2D_4>

Martin Fowler — Making Architecture Matter <https://youtu.be/DngAZyWMGR0>

Diego Eis — O perfil T-Shaped e o dev full-stack — <http://bit.ly/2fpKI4T>