O Manifesto Ágil é uma declaração de valores e princípios que nasceu na indústria de software para fundamentar o desenvolvimento desenvolvimento ágil de softwares.
Apesar da sua origem ser na TI, o desenvolvimento e a gestão ágil de projetos, processos e rotina se difundiu para outras áreas além da TI como, Recursos Humanos, Marketing, Vendas, Financeiro, entre outras.
Existem vários métodos ou frameworks de trabalho vinculados as metodologias ágeis e, independente de qual deles você utiliza ou utilizará, todos têm em comum um mindset que deve refletir como pensamos e nos comportamos no presente. Para alinhar esse mindset, foi criado o Manifesto Ágil.
Origem do Manifesto Ágil
O Manifesto para o desenvolvimento de software Agile, mais comumente conhecido como o Agile Manifesto, foi criado em 2001 por um grupo de 17 líderes da indústria de sotwar com ideias semelhantes que vieram juntos no The Lodge at Snowbird, um resort de esqui em Utah, nos Estados Unidos.
Naquela época, havia muita preocupação com a direção que desenvolvimento de software estava se movendo. Havia um movimento da indústria em direção a processos pesados de desenvolvimento de software que ninguém estava gostando. Isso foi o que motivou todos a se unirem e buscar algo melhor.
Os 17 profissionais já praticavam métodos ágeis como XP, DSDM, Scrum, FDD, por exemplo, e, embora utilizassem abordagens e métodos diferentes, eles compartilhavam dos mesmos fundamentos.
Durante o encontro, cada um dos profissinais teve a chance de falar sobre suas próprias ideias e o que estavam fazendo e percebeu-se um consenso sobre aspectos importantes em desenvolvimento de software.
Para registrar isso, decidiram escrever um documento que se transformou em algo muito maior do que poderiam imaginar, um documento que serviria de “guia” para os novos processos de desenvolvimento de software, o Manifesto Ágil ou Agile Manifesto.
Quem são os 17 autores do Manifesto Ágil?
- Ken Schwaber, co-criador e fundador da Scrum.org
- Jeff Sutherland, co-criador do Scrum e fundador da Scrum Inc
- Mike Beedle, co-autor de Desenvolvimento Ágil de Software com Scrum
- Kent Back, co-criador da eXtreme Programming (XP)
- Ward Cunningham, criador do conceito de wiki
- Ron Jeffries, co-criador da eXtreme Programming (XP)
- Martin Fowler, desenvolvedor da Thoughtworks
- Andrew Hunt, co-autor de O Programador Pragmático
- Dave Thomas, co-autor de O Programador Pragmático
- Robert C. Martin, o “Uncle Bob”
- James Grenning, autor de Test Driven Development
- Jim Highsmith, criador do Adaptive Software Development (ASD)
- Steve Mellor, cientista da computação e desenvolvedor do método Shlaer-Mellor e UML executável
- Alistair Cockburn, criador da Metodologia Ágil Crystal
- Arie van Bennekum, autor do livro Lean Agile Marketing
- Brian Marick, autor de vários livros sobre programação
- Jon Kern, autor do livro Java Design
Por que Manifesto Ágil (Agile Manifesto)?
Durante o primeiro dia de encontro, os autores decidiram chegar a um consenso sobre o nome, pois todos se referiam aos processos de desenvolvimento que estavam utilizando com o termo “processos leves” e eles sabiam que não era o melhor termo para motivar e engajar todos.
Terminaram o primeiro dia com uma série de nomes em um flip-chart e chamar isso de “Agile (ágil)” foi ideia de Mike Beedle. “Agile” representava o ponto de vista em comum de todos.
A próxima parte foi escrever o documento. Durante o segundo dia, criaram os 4 valores e 12 princípios do Manifesto Ágil. Chamaram de manifesto, pois era uma declaração das crenças daquele grupo de 17 líderes.
Os 4 valores do Manifesto Ágil
O Manifesto Ágil possui 4 valores para guiar o desenvolvimento de projetos ágeis. Eles são como crenças para uma empresa ou time quem buscam desenvolver esse mindset ágil.
- Indivíduos e interações mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano
Vamos olhar cada valor de forma individual:
Indivíduos e interações mais que processos e ferramentas
Quando o desenvolvimento é orientado pelo processo ou pelas ferramentas, a equipe é menos responsiva às mudanças e menos propensa a atender às necessidades do cliente.
As pessoas podem errar quando seguem cegamente um processo. Uma ótima ferramenta às vezes pode ajudá-lo a fazer a coisa errada mais rápido.
É crucial valorizar as pessoas, as necessidades do cliente mais do que processos ou ferramentas. São os clientes, internos ou externos, que direcionam todo o desenvolvimento do produto, serviço ou processo.
Software em funcionamento mais que documentação abrangente
Tradicionalmente, documentar todo o produto ou serviço inicialmente para desenvolvimento e para entrega final exigia muito tempo. Requisitos técnicos, especificações, prospecto, planos de teste, documentos de design de interface e diferentes validações eram necessárias para cada etapa.
O desenvolvimento Ágil foca em gerar valor para o cliente. Ele não elimina a documentação, ele apenas não se prende à burocracia, só documento o que é essencial e principalmente o que já foi validado.
Colaboração com o cliente mais que negociação de contratos
O maior objetivo de um time ágil é entregar algo que gere valor para o seu cliente. Contratos são necessários mas geralmente são muito engessados e protecionistas, diminuindo as chances de colaboração com o cliente ao longo do processo de desenvolvimento da solução.
Portanto, os métodos ágeis buscam incluir o cliente durante todo o processo de desenvolvimento da solução, muitas vezes o cliente final faz parte da equipe, incluindo demonstrações, testes e validações periódicas para colher feedback, ajudando a equipe a desenvolver soluções que agreguem valor para o cliente.
Os contratos devem se manter abertos o suficiente para que seja possível realizar adaptações do projeto quando necessário.
Responder a mudanças mais que seguir um plano
O desenvolvimento tradicional desenvolve planos detalhados no início do projeto e considera a mudança algo que deve ser evitado.
Adaptação é a essência dos times ágeis. Planejar é muito importante e necessário, mas não o planejamento não pode ser um rígido, ele pode e deve ser corrigido, ajustado e refeito a medida que o time ágil aprende mais sobre o problema e cliente.
Os 12 princípios do Manifesto Ágil
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
O maior foco no desenvolvimento de um produto ou serviço é entregar valor para o cliente. Desde o início do projeto deve-se entregar um produto minimamente funcional que já gere valor para o cliente e a cada iteração, de forma contínua e sustentável, com o feedback do seu cliente, ir incrementando o produto com o objetivo de gerar mais valor para o cliente final.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
As mudanças devem ser um processo natural no desenvolvimento de produtos e serviços. A medida que o time ágil aprende mais sobre o cliente, – construindo algo de valor, validando, colhendo feedback e entender cada vez mais o seu usuário – mudar e se adaptar deve ser um caminho normal para evoluir o seu produto/serviço e atender as necessidades do cliente final.
A medida que as empresas e os times resolvem de uma melhor forma cada vezes mais problemas do seus clientes, isso se torna um diferencial competitivo, pois isso vai atrair e reter cada vez mais clientes.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
A entrega do seu produto ou serviço funcionando de forma frequente para o seu cliente, permite não só que o cliente já obtenha valor de forma adiantada, como permite a obtenção de feedback sobre o que foi feito.
A preferência pela menor escala de tempo é realizar iterações cada vez mais rápidas com o objetivo de colher mais cada vez mais feedbacks, aprender cada vez mais sobre o cliente com ele mesmo e reduzir o risco do projeto, pois os incrementos serão ada vez mais direcionados as necessidades do cliente final.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Esse princípio se opõe a uma divisão comum nas empresas em silos e áreas que possuem objetivos nem sempre alinhados com que importa, gerar valor para o cliente. A divisão entre “planejamento” e “execução” gera uma rivalidade, falta de comunicação e perda de foco do time no que é essencial.
Pessoas de negócio e desenvolvedores (time de execução e operação) devem trabalhar em conjunto para garantir que todos estejam alinhados com o objetivo de gerar o maior valor possível para o cliente. Quando as pessoas de negócio e operação trabalham juntas, – de preferência de forma literal, em uma mesma sala, setor, andar – o projeto flui de maneira mais dinâmica, melhorando a comunicação, gerando maior transparência do projeto, permitindo a inspeção e adaptação do time e facilitando a tomada de decisão.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
Empresas, times, processos, serviços e produtos são construídos e conduzidos por pessoas. Ambientes saudáveis, que confiam e dão autonomia aos seus colaboradores, fornecem todo suporte necessário para as pessoas trabalharem da melhor maneira e exercerem todo seu potencial, tendem a performarem melhor e construírem melhor produtos e serviços.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
A comunicação face a face permite que as pessoas vejam a outra parte em uma conversa. Essa forma de comunicação permite uma melhor troca de informações pois, tanto quem fala como quem ouve são capazes de ver e interpretar não só a fala, mas as expressões faciais e linguagem corporal.
Sendo maior parte da nossa comunicação é não verbal, tom de voz e linguagem corporal, quando nos comunicamos por e-mail, mensagens de texto e outros meios que não nos permitem ver e/ou ouvir as pessoas, estamos ignorando boa parte da nossa comunicação, gerando problemas como falta de alinhamento, entendimento e interpretação, por exemplo, que causam a maior parte dos problemas em projetos.
A comunicação face a face não precisa ser necessariamente física, ela também pode ser obtida por meio de ligação por vídeo para a realidade home-office que as empresas vivem atualmente.
Software funcionando é a medida primária de progresso.
Este princípio se opõe a forma como metodologias tradicionais avaliam o progresso. Elaborar documentos com especificações detalhadas do projeto, construir um cronograma do início ao fim do projeto, construir protótipos internos e não funcionais, não são medidas de progresso.
O progresso para times ágeis ocorre quando o time entrega produtos/serviços funcionais mostrando exatamente o que a equipe fez. Diferente de um status report confuso e detalhado de especificações que ninguém entende, uma demonstração real do produto é quase impossível de ser mal interpretada e mantém todos atualizados da evolução.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
Uma equipe de projetos a trabalhar horas insanas para cumprir um prazo rígido e irreal é a principal ferramenta na a caixa de ferramentas do gerente de projeto “comando e controle”. Sempre que um prazo se aproximando, todos buscam trabalhar de noite e nos finais de semana como o primeiro recurso. No entanto, isso não funciona no longo prazo.
Uma equipe pode trabalhar muito por algumas semanas e fazer mais trabalho, mas depois disso sua produtividade geralmente cai de um penhasco. Isso faz sentido: as pessoas ficam cansadas e desmotivadas, e a fadiga começa a se estabelecer.
Times ágeis devem procurar um ritmo constante e sustentável de trabalho, alinhado com as expectativas dos stakeholders. A medida que o time vai ficando mais maduro, ele vai se tornado mais produtivo e evoluindo o seu ritmo de trabalho.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
O termo agilidade é normalmente associado a rapidez que por sua vez é associada a um trabalho de péssima qualidade, criando-se um conceito errado de que para ser ágil deveria se sacrificar a qualidade.
A realidade de times ágeis é justamente o oposto disso. Times ágeis buscam desenvolver produtos e serviços com excelência técnica pois isso permite que o time faça mudanças facilmente no produto a cada iteração. Portanto a qualidade é essencial para se manter a agilidade.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
É muito comum no desenvolvimento de produtos e serviços desenvolver funcionalidades que não geram valor para o cliente, soluções complexas e caras sem validar se é o que o cliente realmente precisa.
Usando iteração e construindo o mínimo documentação no início do projeto ajuda a equipe a evitar entregas desnecessárias e o desperdício de dinheiro e tempo no desenvolvimento do produto ao não se realizar o que não é necessário.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Equipes auto-organizáveis trabalham juntos para planejar as entregas que agregam mais valor para empresa e clientes, têm liberdade para decidir qual a melhor forma de realizar o trabalho, trabalham em direção a metas acordadas com todo o time e são responsáveis pelos resultados.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Uma equipe não é ágil até que esteja constantemente melhorando a maneira como desenvolve seu produto ou serviço. Equipes ágeis constantemente inspecionam e adaptam seus processos e sua forma de trabalho – elas observam como seus projetos foram executados, e elas usam esse conhecimento para melhorar no futuro.
As equipes ágeis não fazem isso apenas no fim do projeto, essa melhoria contínua da equipe é constante, regularmente elas procuram maneiras de melhorar e avaliar se o trabalho que estão fazendo atualmente faz sentido.
Conclusão
O Manifesto Ágil foi sem dúvida um grande marco para o desenvolvimento ágil de software, produtos e serviços.
Ele foi uma quebra de paradgma, consolidando toda uma mentalidade de gestão de projetos que já existia mas estava muito dispersa e deslinhada.
Essa mentalidade foi serviu como base para as metodologia, métodos e frameworks já existem e os que surgiram posteriormente.
Uma excelente forma de começar na agilidade é compreendendo esses valores e princípios praticando no dia a dia da sua empresa. É muito difiícil ler esse manifesto e “se torna ágil”. Entenda os valores e princípios, ponha em prática regularmente de forma consciente, e aos poucos a agilidade será algo natural para você, para o seu time e para a sua empresa.