Em 2001, o Manifesto Ágil veio à tona com objetivo de estabelecer um novo paradigma para o processo de desenvolvimento de software. O manifesto tem quatro valores centrais, mas poucas pessoas sabem que também existem 12 Princípios Ágeis. Eles oferecem exemplos mais concretos de como o desenvolvimento ágil de software (mas não apenas limitado a softwares) deve ocorrer. De agora em diante, quase todas as organizações dirão que “praticam o Agile”, mas muitas delas apenas defendem os valores e princípios do Manifesto Ágil de forma superficial.
O mundo do desenvolvimento de software também mudou drasticamente. É interessante revisitar os princípios ágeis, ver o que eles significam e avaliar se eles ainda fazem sentido no contexto atual.
Primeiro Princípio – Fluxo contínuo de valor
Como diz o primeiro princípio, “Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de um software funcional”.
Normalmente desenvolvemos software com o tempo e dinheiro de outra pessoa para ajudá-la de alguma forma. Se esperarmos muito para entregar o produto, provavelmente não irá satisfazer o cliente. Isso é ainda mais verdadeiro agora do que em 2001. Não é apenas valioso ter feedback antecipado e continuado durante todo o projeto, os clientes esperam uma entrega rápida.
E cada entrega deve agregar algo de valor para o cliente. Por exemplo, o cliente não se importa se você recriou a página de login. Ele se preocupa com o fato de que agora, ele pode fazer login com sua conta do Google.
Os usuários estão usando cada vez mais, softwares e apps para todos os tipos de tarefas. E estes portanto, demandam atualizações frequentes. Então, quando os clientes pedem mudanças, eles não estarão dispostos a esperar meses antes de vê-las.
Segundo Princípio – Flexibilidade a mudanças
O segundo princípio afirma: “Bem-vindo a mudanças de requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para criar vantagem competitiva para o cliente. ”
Em um mundo que muda constantemente em um ritmo rápido, ninguém pode realmente prever quais serão os requisitos de uma parte de um software. No entanto, as empresas não gostam de surpresas. Mas o que eles gostam ainda menos é desperdiçar dinheiro em um produto que não é mais relevante. Se aceitarmos mudanças, o software pode fornecer ao cliente uma vantagem competitiva porque satisfaz as necessidades atuais e mais recentes, não as do ano passado, por exemplo.
O fato de que o mundo está em constante mudança é verdade há décadas. A sociedade muda, o mercado muda, nossas organizações mudam e as pessoas mudam. Em vez de tentar parar ou desacelerar esse processo, devemos adotá-lo e usá-lo para nossa vantagem e/ou para a vantagem de nosso cliente.
Terceiro Princípio – Entrega frequente
O próximo princípio é “Entregar software funcional com frequência, de algumas semanas a alguns meses, com preferência para a escala de tempo mais curta”.
Na verdade, esse princípio parece uma repetição do primeiro e, de certa forma, é. No entanto, o primeiro princípio indica que devemos começar a fornecer softwares funcionais desde o início. Esse princípio é um pouco mais detalhado sobre o que significa entrega contínua. Ele recomenda entregar uma nova versão do seu software em um curto espaço de tempo.
Isso significa versões menores, e versões menores significam menos chances de bugs serem detectados. Lançamentos mais frequentes também fornecem mais momentos de feedback do cliente. Se você só receber feedback sobre todas as suas alterações depois de vários meses, terá muito mais trabalho.
Este é um princípio que se tornou mais radical com o passar dos anos. Não consideramos mais um ciclo de lançamento de “alguns meses” como ágil. A indústria evoluiu para lançamentos diários ou semanais.
Quarto Princípio – Colaboração entre a esfera dos negócios e os desenvolvedores
Outro princípio afirma: “Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto”.
Os desenvolvedores geralmente estão separados ou longe dos empresários. Os analistas são colocados entre eles para “traduzir” a linguagem de negócios para uma linguagem que os desenvolvedores possam entender. Esse princípio ágil exige que as organizações removam essas barreiras e permitam que os desenvolvedores e a gestão interajam uns com os outros diariamente. Isso aumenta a compreensão e o respeito mútuos.
Se você já jogou o jogo do telefone sem fio quando criança, você sabe que cada passo extra na comunicação leva à perda de informações. Ter a empresa e os desenvolvedores trabalhando juntos reduz (mas não elimina) esse risco. Mesmo no mundo moderno de equipes distribuídas, deve-se tentar trabalhar junto diariamente. Detectar mal-entendidos o mais rápido possível e obter feedback regular uns dos outros ajuda a produzir resultados promissores.
Quinto Princípio – Indíviduos motivados
Há também “Construir projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte que precisam e confie neles para fazer o trabalho. ”
Uma equipe ágil é uma equipe madura e responsável o suficiente para produzir software de qualidade. Isso requer uma certa confiança. Mas se você não pode confiar em seus desenvolvedores, por que eles foram contratados? Com o treinamento, ambiente e ferramentas corretos, os desenvolvedores motivados se sentirão capacitados para fazer seu trabalho profissionalmente.
Se você construir seus projetos em torno de pessoas que não estão motivadas ou foram desmotivadas por falta de confiança ou apoio, seu projeto provavelmente não terá sucesso. Pior ainda, os desenvolvedores inteligentes não terão problemas para encontrar empregos melhores.
Sexto Princípio – Comunicação eficaz e eficiente
E há também o princípio que afirma: “O método mais eficiente e eficaz de comunicação é a conversa face a face.”
A tecnologia aumentou o número de maneiras pelas quais os humanos podem se comunicar. Mas nada disso é tão bom quanto uma conversa cara a cara. Nossos cérebros interpretam todos os tipos de sinais, não apenas as ondas sonoras de nossas vozes. A expressão facial e a linguagem corporal também são importantes. Não é incomum que a comunicação assíncrona cause mal-entendidos.
Desde 2001, a forma como trabalhamos mudou drasticamente. Muitas organizações têm pessoas que trabalham remotamente, mesmo em outros fusos horários. Tecnologias como rastreadores de problemas e Slack criam formas de comunicação assíncrona e ferramentas como Skype e Hangouts nos permitem ter conversas cara a cara remotas. Nunca será 100% como a interação na vida real, mas talvez seja bom o suficiente. Equipes em todo o mundo estão provando que ainda podem ser bem-sucedidas e ágeis sem se verem na vida real.
Sétimo Princípio – Software funcional
Um dos princípios diz: “O software funcional é a principal medida de progresso”.
Projetos de software podem levar muito tempo. Portanto, é absolutamente racional para as empresas medirem o progresso. Esse princípio ágil afirma que a principal forma de medir o progresso é o software em funcionamento. Análise finalizada, modelos completos ou belas maquetes têm pouco significado se não forem convertidos em um software funcional. Eles podem ser necessários, mas se você não colocou pelo menos uma pequena parte disso em um produto funcional, então você não criou valor para o seu cliente.
Hoje, muitas vezes damos um passo adiante. Se o software funcional não foi enviado, ele não foi concluído e nenhum progresso foi feito. O software não lançado é um inventário. E o estoque é um custo, não uma parte da receita ou valor.
Oitavo Princípio – Desenvolvimento sustentável
O oitavo princípio é o seguinte: “Processos ágeis promovem o desenvolvimento sustentável. Os sponsors, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. ”
Então, o que isso significa exatamente? Nossa visão é que as pessoas devem trabalhar em um ambiente onde experimentem pressões com as quais podem lidar. A pressão vem de diferentes maneiras. Pense em coisas como orçamento, prazos, política da empresa e respeito entre os colegas.
Cada uma dessas coisas pode ser uma fonte de estresse e fazer com que as pessoas se afastem ou podem ser coisas que estão presentes, mas não são uma preocupação.
Aqui está o ponto. Isso não significa que uma organização Agile não possa ter nenhum desses problemas acontecendo. Isso significa que eles não podem estar acontecendo o tempo todo. Por exemplo, uma equipe Agile pode lidar com um período intenso de trabalho de alto ritmo. Mas eles deveriam ter um período de descanso depois disso. Se a organização está sempre estressando a equipe ao seu limite, não é sustentável – a equipe não pode manter esse ritmo para sempre.
Observe como o princípio menciona “patrocinadores, desenvolvedores e usuários”. Portanto, todos devem ser capazes de manter o ritmo atual de desenvolvimento. Por exemplo, se os desenvolvedores estão lançando recursos muito rápido para os usuários, eles devem se adaptar. Uma maneira de fazer isso seria desacelerar. Outra seria investir mais tempo na documentação e educar os usuários sobre os novos recursos.
A ideia central desse princípio é que todos os envolvidos podem acompanhar o ritmo no qual o software está sendo desenvolvido.
Nono Princípio – Excelência técnica
Há outro ditado: “A atenção contínua à excelência técnica e um bom design aumentam a agilidade.”
Muitas empresas preferem time-to-market (tempo de colocação no mercado) em vez de um bom design técnico. E com toda a legitimidade, eles não podem ser culpados. Acabamos de mencionar que o software não lançado é um custo. O usuário final não se preocupa com a excelência técnica e isso não gera receita para o negócio.
Mas se as equipes negligenciarem um bom design técnico por muito tempo, sua velocidade e tempo de lançamento no mercado começarão a diminuir. Sua capacidade de mudar o produto como uma reação a um mercado em mudança diminuirá. Eles estão portanto, perdendo sua agilidade.
Este princípio ainda é muito relevante. Na minha visão, os gerentes e desenvolvedores não estão cientes (o suficiente) deste princípio. Em projetos pequenos, pode fazer sentido trabalhar rápido sem um olho para um bom design. Mas se o projeto é grande o suficiente, vale a pena prestar atenção à qualidade técnica. Martin Fowler criou um pseudo-gráfico para visualizar isso:
Isso não significa que precisamos de grandes projetos teóricos antes de começar a codificar. Bons designs podem surgir à medida que o software evolui. Mas os desenvolvedores precisam ter tempo e ser responsáveis o suficiente para fazer isso.
Décimo Princípio – Simplicidade
“Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial”, é outro princípio.
Maximizar a quantidade de trabalho não realizado pode ser feito em vários lugares: você pode remover procedimentos que não são mais relevantes, automatizar o trabalho manual, usar as bibliotecas existentes em vez de escrever as suas, etc. Tudo isso economiza tempo e dinheiro, dando-nos espaço para foco na entrega de mais valor.
Este é um esforço contínuo para todas as organizações. Mas requer algum trabalho para identificar onde e como podemos melhorar.
Décimo Primeiro Princípio – Equipes auto-organizadas ou auto-gerenciáveis
Um dos últimos princípios é que “As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizadas ou auto-gerenciáveis”.
Este princípio é uma combinação de alguns princípios anteriores. Se quisermos que a empresa e os desenvolvedores se comuniquem regularmente e de forma eficaz, se quisermos avaliar o progresso por software funcional e não por modelos teóricos, e se trabalharmos com os motivados, devemos ter equipes produzindo software de qualidade sem muito controle de cima.
As equipes devem aprender a se auto-organizar todos os aspectos do desenvolvimento de software: eles devem reunir os requisitos se comunicando com a empresa, escrever software de qualidade, organizar seu trabalho, etc. Isso leva a um software melhor, porque os desenvolvedores começarão a “possuir” o software.
Os desenvolvedores ainda são considerados trabalhadores da linha de fábrica que podem ser atendidos pelos requisitos. Mas o desenvolvimento de software é um trabalho que exige muito mais. A equipe precisa ter permissão para organizar para entregar.
O outro lado da história é que os desenvolvedores de software devem assumir essa responsabilidade. Uma equipe ágil exige que os desenvolvedores assumam responsabilidades além de escrever código.
Décimo Segundo Princípio – Reflexão, retrospectiva e ajuste de curso
Por fim, há o último princípio que diz: “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, então sintoniza e ajusta seu comportamento de acordo.”
Em intervalos regulares, as equipes auto-gerenciáveis devem reservar um tempo para observar a maneira como trabalham e se ajustar de acordo. Nenhuma equipe funciona perfeitamente. Uma equipe ágil madura pode identificar problemas de respeito mútuo e, então, tomar medidas para melhorar o processo.
Este princípio sempre fará diferença. É o que torna os indivíduos, as equipes e os negócios bem-sucedidos, não aceitando o status quo, mas sempre procurando melhorar a situação.
Na década inaugurada em 2021, podemos confirmar que esses princípios são relevantes e nortearão a gestão de projetos e negócios nas organizações
by Joel Junior
Você pode notar que todos os princípios ágeis ainda são relevantes hoje. Isso porque eles são baseados na realidade econômica e na natureza humana, duas coisas que realmente não mudam muito. No mínimo, alguns princípios se tornaram mais radicais do que deveriam ser.
Por exemplo, deveríamos implantar semanalmente ou mesmo diariamente e agora podemos automatizar mais do que imaginávamos em 2001. Por outro lado, alguns princípios receberam um significado diferente do que imaginávamos em 2001, por exemplo: os indivíduos não precisam mais estar no mesmo espaço para uma comunicação eficaz.
Portanto, vimos nesse artigo como os 12 princípios se convertem no dia das organizações. Embora todos os exemplos utilizados tenham sido relacionados a indústria de software, já temos cases de sucesso de implementações ágeis em diversos outras indústrias.
Se você está chegando agora, quer aprender mais sobre ágil, ou quer fazer a transformação do seu negócio, nós podemos te ajudar! Entre em contato conosco através dos nossos canais e nós iremos lhe atender!
Acompanhe-nos em todas as plataformas sociais
—- Sobre NX2IN (Joel C Junior) Joel Junior, MsC, PMP é um profissional da área de gestão com carreira desenvolvida em empresas multinacionais desde a posição de estagiário até a gerência.
Com mais de 19 anos de experiência, é apaixonado pela proposta de profissionais ACIMA DA MÉDIA com footprint de treinamento e mentoria para jovens e profissionais experientes do mercado.
A partir de 2021, se dedicando a compartilhar através da web suas ideias para profissionais que desejam experimentar uma carreira ACIMA DA MÉDIA.
—-
Você precisa fazer login para comentar.