Ambos exigem a adopção de uma filosofia baseada em prática, consistência e foco não no processo, mas no valor que pode proporcionar ao público ou, no nosso caso, ao cliente.
Sergio Pozzetti, Agile Coach @SISCOG | 7 min leitura
___________
Os bailarinos necessitam de anos de prática, força, graciosidade e de uma dose incrível de coordenação e controlo para se tornarem tecnicamente bons. O que os torna grandiosos? É, acima de tudo, ser tecnicamente consistentes ao longo do tempo, de modo a que a expressividade humana flua naturalmente enquanto dança, e a ligação é estabelecida não através dos movimentos coordenados do corpo, mas sim através da emoção e expressividade desses mesmos movimentos.
Tomemos como exemplo o Grand Jeté. Pode-se dizer que significa realizar uma espargata no ar. No entanto, talvez uma descrição melhor seja realizar uma espargata lembrando-se de atingir a sua máxima amplitude no auge do salto, com o peso do corpo inclinado levemente para a frente. Existem descrições mais detalhadas e passo-a-passo, mas são praticamente inúteis para o nosso ponto: o grande bailarino executá-lo-á como uma segunda natureza. A consistência e a realização de milhares desses saltos abrirão o caminho para moldar os pensamentos do bailarino no sentido de voar, superar um precipício ou expressar felicidade. O processo deixará de ser o foco.
Agile como filosofia
Praticamente qualquer pessoa consegue adoptar um processo, e aplicá-lo com, talvez, um toque de “isso não é realmente necessário” aqui, uma pitada de anti-padrão ali, misturar tudo num caldeirão com bastante “sempre fizemos isto assim” e… afirmar que é Agile. Como numa receita, se seguirmos diligentemente as etapas necessárias, o nosso resultado final está garantido. Ou na música. Ao escolher um instrumento, se alguém aprende notação musical, entende matematicamente o tempo e compasso, o tom e todos os outros elementos escritos na pauta, além de como mapeá-los nos movimentos mecânicos necessários para produzir o som, não há teoricamente motivo para que não se torne num grande músico. Excepto pelo facto de que as artes culinárias e a música têm algo em comum: a dependência central de factores humanos. Com toda a probabilidade, o seu primeiro coq-au-vin acabará desenxabido, cozido demais, fibroso e pegajoso. Muito provavelmente, e com perseverança suficiente, aprenderá a tocar um instrumento, mas soará monótono, sem emoção e mecânico. Previsivelmente, passa-se o mesmo com as metodologias pertencentes ao espectro Agile. É por isso que tornar-se Agile deve ser, desde o início, considerado primeiramente um desafio centrado no ser humano. É por isso que é considerado essencialmente uma filosofia que envolve uma maneira diferente de pensar. É por isso que na SISCOG não estamos preocupados em adicionar num plano um marco para nos tornarmos Agile, e que precisa de ser verificado a dada altura. Mas, em vez disso, reconhecemos que cada passo que damos é uma evolução no sentido de poder consistentemente executar o Grand Jeté e concentrarmo-nos no valor que construímos, e não na receita que seguimos.
O Manifesto Agile
O famoso manifesto Agile é composto por quatro valores fundamentais e doze princípios de apoio que se revelam leituras muito interessantes, considerando que todas as metodologias do espectro Agile as aplicam de diferentes maneiras com rumo a um objectivo comum. Este objectivo pode ser resumido por: oferecer iterativamente software de alta qualidade e centrado no utilizador através de equipas altamente produtivas e motivadas envolvidas na sua melhoria contínua.
Por mais interessante que pareça, e por mais que todos esses preceitos se devam tornar no mantra de um praticante de Agile, usaremos histórias situacionais e arquétipos para ilustrar a filosofia que estamos a adoptar. Na fase inicial, é imperativo que olhemos primeiro para as pessoas, equipas e princípios, e depois para as metodologias.
História 1: Uma conversa informal junto ao dispensador de água:
"- Então… estamos a tentar com que o cliente adopte realmente a nova ferramenta o mais rápido possível, porque acreditamos que, no final, será benéfico para todos.
- Excelente, então dada essa urgência já contactaste o cliente?
- Não, precisamos de marcar uma reunião para isso, mas já que o vamos fazer talvez tenhamos que preparar a reunião um pouco melhor.
- Isso pode fazer sentido, precisas de ajuda para preparar uma demonstração?
- Estava agora a pensar que precisamos da presença do arquitecto sénior, e talvez alguém da qualidade por precaução. Além disso, a versão que temos não é estável. Prefiro mostrar apenas PowerPoints. E isto pode demorar. Não tenho a certeza se temos um cartão Jira para isso. E agora que penso nisso: o arquitecto sénior está de férias. ”
E através da mentalidade errada, a oportunidade esvoaçou em segundos. Tornou-se mais importante ter um cartão com o trabalho de preparação necessário, ter mais pessoas presentes do que o estritamente necessário e construir PowerPoints inexpressivos, em vez de juntar o que fosse necessário para tornar a versão demo estável. Em resumo, processos e ferramentas prevaleceram sobre indivíduos e interacções. Este é um anti-padrão Agile clássico. Não que uma preparação adequada não seja importante, mas esta nunca deve triunfar sobre a conclusão do trabalho, o qual pode estar à distância de uma videochamada.
História 2: Mudemos para o desenvolvimento de uma funcionalidade de software crítica para o negócio. Está a passar pelas últimas iterações e parece genericamente promissora. A cada pequena iteração é entregue software, mas de repente, na última demonstração, o cliente informa sobre uma mudança estrutural nas suas regras de negócio. No entanto, o gestor de projecto decide suspender a entrega dessa alteração até que toda a documentação de suporte, incluindo o contrato, esteja actualizada com a alteração solicitada. Não é que a documentação de suporte e a negociação de contrato não sejam importantes. No entanto, nunca devem ser uma prioridade que se sobreponha à colaboração com o cliente que, num mundo centrado no utilizador, é o caminho mais rápido para entender completamente e antes de mais as suas necessidades. Por analogia, suspender entregas por causa de uma disrupção no plano oblitera completamente a capacidade de resposta à mudança, que não é apenas essencial, mas expectável nesta nova era. Levando a metáfora para outro nível, o planeamento é vital se estiver disposto a deitar fora o plano logo em seguida. O seu plano é tão bom quanto a sua capacidade de alterá-lo.
História 3: “Software funcional prioritário face a documentação completa” é na verdade fácil de entender se pensarmos nos três princípios mencionados acima. Vamos resumir: queremos favorecer as interacções pessoais, colaborar e co-criar com o cliente e responder à mudança, porque a mudança é inevitável. Então, chegamos ao ponto em que estamos a entregar um importante incremento de software. Este abrange funcionalidades que são cruciais para a entrada em produção. Somos surpreendidos por um telefonema do cliente:
“- Precisamos das especificações técnicas, da matriz de responsabilidades actualizada dada a nova classe de utilizadores que usará a funcionalidade, dos manuais do utilizador, de guias rápidos actualizados e dos documentos de concepção detalhados para esta actualização.
- Sim, essas entregas foram consideradas não críticas para a entrada em produção, portanto, e para cumprir o prazo, mesmo que isso signifique que a actualização seja executada num ambiente de testes, decidimos aceitá-la como dívida técnica para as iterações seguintes.
- Infelizmente, a empresa exige esses documentos antes de a disponibilizar em qualquer ambiente.”
E mergulhámos de cabeça noutro conhecido anti-padrão Agile: a visão de túnel assente em picar cada caixinha da lista, em vez de avaliar o que pode ser feito primeiro para obter feedback e exposição antecipados.
Ser Agile para nos tornarmos Agile
A indústria global está a viver a era do cliente. Não há mais espaço para especificações detalhadas e planos antecipadamente escritos na pedra, a menos que os requisitos sejam totalmente claros e imutáveis para todas as partes envolvidas, o que no desenvolvimento de software é quase utópico. Não há mais espaço para a miopia no desenvolvimento de soluções unilaterais. A colaboração e a co-criação com o cliente são instrumentais para responder às expectativas dos utilizadores, pois são fundamentais para identificar necessidades não correspondidas e, na qualidade de equipa conjunta, categorizar e priorizar as frentes de desenvolvimento identificando, assim, produtos mínimos viáveis (minimum viable products), ou mais genericamente, desenvolvimentos mínimos viáveis sobre os quais iteramos. Não há mais espaço para ter medo de experimentar, a mudança é a melhor defesa para garantir a satisfação constante do cliente.
Tornarmo-nos Agile é um esforço colectivo dentro da empresa e com os nossos clientes. E embora saibamos que temos um longo caminho pela frente, na SISCOG não estamos a apressar a adopção de nenhuma metodologia específica, mas estamos a ser mais Agile em nos tornarmos Agile: inspeccionando e adaptando constantemente. E embora os nossos Grand Jetés não sejam ainda perfeitos, já realizámos alguns e continuaremos a fazê-lo.