Mas e o Agile com Isso? (Episode I - 2nd)
“Ok, viagens espaciais, perigos intergalácticos, dicas de sobrevivência ao cruzar o espaço profundo, mas e aí,… aonde está o ágil nisso tudo?”
Se você leu o post que eu escrevi anteriormente, talvez esta seja exatamente a sua dúvida. Para compreender o ágil, talvez tenhamos que mergulhar um pouco mais profundo nos ensinamentos deixados pelos mestres da força. Avançar um pouco mais no limiar entre luz e sombras, para compreender alguns caminhos equivocados que temos trilhado, e finalmente retornar para a luz e para a força.
“Patience you must have, my young padawan!” (Yoda, Jedi Master)
Eu venho percebendo um crescente despertar na adoção de métodos ágeis, e isso tem se mostrado bastante interessante e intrigante. Por toda Galáxia, equipes vem se levantando para discutir sobre como melhorar seus processos de entrega, bem como diversas iniciativas de qualidade de software tem surgido nas negociações de comercio da Federação, culminando com o fato de que os métodos ágeis vem se tornando um requisito e aspiração para a maioria organizações e empresas de software ao longo da República.
Entretanto ainda vejo muitos abordando sobre cerimônias aplicadas, terminologias adotadas, cartilhas e receitas prontas, como se os métodos ágeis fossem meramente rituais mágicos para “controlar pessoas e levitar coisas”. É óbvio que sem botar o conceito em prática não dá pra chegar a lugar algum, mas sem uma mudança de mentalidade e paradigma, bem como transformação de cultura, princípios e comportamentos da equipe, é impossível criar um ambiente favorável para o despertar da verdadeira Força.
"I sense much fear [of change] in you. […] The dark side I sense in you." (Yoda, Jedi Master; grifo meu)
Assim como em Star Wars, existem comportamentos em equipes ágeis, que são verdadeiros caminhos para o lado sombrio da força, pois nos guiam para a raiva, que nos guia para o ódio, que por sua vez nos guia para o sofrimento. Existem alguns sinais bastante comuns, mas às vezes pouco perceptíveis, aos quais precisamos estar atentos, para evitar o caminho sombrio e seguir usufruindo da Força de maneira saudável.
1º Sinal: A equipe gasta mais tempo mantendo seus aparatos, ferramentas e cerimônias ágeis do que em uma interação e comunicação saudável entre os indivíduos da equipe.
Apesar da expressão “métodos ágeis” implicar em algo bastante prático e aplicável, é possível que estejamos empregando as recomendações, adotando as cerimônias e rotinas sugeridas pela literatura, mas ainda sem entende o que e porque realmente estamos fazendo isso. É possível que estejamos executando todas essas práticas, sem compreender exatamente os fundamentos básicos do desenvolvimento ágil, desconhecendo os seus verdadeiros ganhos e resultados para as entregas.
Há quem pense em métodos ágeis como um conjunto “super-cool” de recursos e ferramentas, capazes de potencializar (não importa como) os resultados da equipe. Também há quem veja toda essa parafernalha, como um “overhead” desnecessário e sem sentido, um amontoado de atividades de controle, adicionadas no meio de tudo aquilo que já precisa ser feito para entregar um software.
“Much to learn, you still have.” (Yoda, Jedi Master)
Não há nenhuma Midi-chlorian implícita nisso. Métodos ágeis por si só não tem o poder de entregar software, muito menos entregar mais rápido e melhor. No final das contas, são práticas adotadas e realizadas por seres humanos. Relembrando aquele antigo fundamento ágil: "Indivíduos e interações mais que processos e ferramentas", antes de começarmos a modificar e acrescentar atividades e cerimônias nos processos de desenvolvimento, precisamos melhorar a nossa comunicação e as interações orgânicas entre os membros da equipe.
Isso inclui desde compartilhar conhecimento, até mesmo sinalizar problemas, falhas na aplicação e nos processos, parear na resolução dos impedimentos e demandas mais críticas, colaboração no design das soluções e melhorias, promover diálogo constantemente e chamar o time para o foco sempre que necessário. Eu sinceramente não creio que responsabilidades tão cruciais como essas, devam ser atribuídas apenas a indivíduos específicos como um dev lead, scrum master, coach, manager ou o que quer que seja. São responsabilidades que toda a equipe precisa ter, mas que individualmente cada um precisa assumir para si próprio, garantindo que a entrega aconteça, enquanto desempenha o seu papel nas iterações de desenvolvimento.
2º Sinal: A equipe gasta tempo suficiente para fazer uma entrega funcional, porém não o suficiente para entregar um software que funcione continuamente.
Parece óbvio demais fazer essa pergunta mas, existe algum sentido em entregar um produto que funcione apenas em uma determinada parte do tempo? Você compraria algo assim? Se eu decidisse fazer uma viagem, com o objetivo de cruzar o sistema solar ou migrar para uma galáxia distante, de que me adiantaria comprar uma nave espacial, que não me ofereça uma garantia de funcionar corretamente até o final da viagem? Ou mesmo uma nave que não me assegure chegar vivo e em segurança, ou pelo menos minimamente confortável ao meu destino final? Descobrir a existência de um mal funcionamento em qualquer dispositivo de navegação ou suporte à vida, mesmo que eventualmente, poria em risco tudo o que foi planejado, investido e preparado, talvez até antecipando o fim da jornada de forma trágica.
“In a dark place we find ourselves, and a little more knowledge lights our way.” (Yoda, Jedi Master)
Falar da necessidade de se testar software, chega a ser clichê de tão obvio. Afinal quem não sabe que os testes são a maior ferramenta de garantia da qualidade de um produto? Você pode fazer os cálculos, levantar toda uma especificação de funcionamento, documentar tudo, pensar em tudo, mas é no momento em que apertamos o botão de ligar, e usamos o produto, que nós realmente temos certeza dos resultados do nosso trabalho.
Entretanto, qual é a qualidade nisso, se continuarmos deixando para testar a espaço-nave apenas depois que todos os botões e componentes estiverem integrados? Será que eu posso garantir a qualidade dos testes realizados com ela, se eu não houver testado cada um de seus componentes individualmente e incessantemente, durante todo o processo de montagem e construção da nave? Será que ela voa simplesmente pelo fato de que está voando, ou porque cada um de seus milhares de componentes testados também garantem que ela vai continuar voando lá na frente, ainda que há milhares de anos-luz daqui?
“No! Try Not! Do [tests] or not do [nothing], there is no try.” (Yoda, Jedi Master; grifo meu)
Existe uma interpretação bastante equivocada a respeito do princípio: "Software em funcionamento mais que documentação abrangente". Muitos tentam entendê-lo como um enfoque e um convite inicial e prioritário às práticas de design e codificação de software. O objetivo se torna, mais do que qualquer coisa, levantar uma aplicação funcional, mesmo que um simples MVP, em vez de ficar elaborando especificações massantes, sujeitas a mudanças e que nem sempre são úteis para o projeto no futuro.
Entretanto se não há testes que possam garantir que tudo aquilo que foi desenvolvido até o momento esteja funcionando, será que o meu código-fonte não passa de apenas outra documentação abrangente, massante, sujeita a mudanças e que talvez nem seja tão útil para o projeto no futuro? Iniciar um desenvolvimento sem testes, é o mesmo que apostar numa loteria. Mesmo que o resultado seja uma simples operação, componente ou funcionalidade, não há nenhuma garantia de que funcione, menos chance ainda, de que seguirá funcionando ao sofrer todas as futuras avarias e adaptações que estão por vir.
“Train yourself to let go of everything you fear to lose.” (Yoda, Jedi Master)
O princípio de “software em funcionamento” sugere um certo nível de qualidade na entrega, que implica em durabilidade e resiliência. Ele precisa ser funcional em todas as fases do desenvolvimento. E isso continuamente, após a entrega e também nas próximas entregas. A aplicação com certeza tem um prazo de validade, mas é preciso trabalhar para estender o prazo o máximo possível. Mas se o código fonte é confuso, induz ao erro e não é melhorado com frequência, se a aplicação não tem testes unitários o suficiente, se é difícil de validar as suas funcionalidades e a aplicação é recorrentemente publicada com bugs em produção, há um forte e triste indício de que a aplicação não permaneça como um software em funcionamento, pelo menos não por muito tempo.
Seja corajoso, implemente mais testes nos seus componentes, adapte o código se for necessário. Comece com passos pequenos, mas comece! Não é responsabilidade sua resolver todos os problemas da sua aplicação. Mas com certeza é sua responsabilidade garantir que tudo aquilo que você alterou ou acrescentou no código foi bem testado, que está funcionando, e que vai continuar funcionando por um longo futuro.
To be continued…
Leia também:
- A apresentação completa do Episódio I - Sobrevivendo à Vida na Selva
- O primeiro post da série Guia de Sobrevivência do Agilista das Galáxias: As Primeiras Impressões do Agilista das Galáxias (Episode I - 1st)
