Ágil é um adjetivo. Ele descreve uma característica de algo. Mas Ágil não pode vir sozinho, pois seu uso se refere a uma comparação. Um ninja é mais ágil que um lutador de sumô.

Quando falamos de Ágil no mundo do Desenvolvimento de Software estamos falando de um movimento que veio em resposta aos modelos gerenciais predominantes até 2001.

Porque 2001? Porque foi em 2001 que Kent Back reuniu um pessoal, que muitos não se gostam publicamente hoje, para discutir os Modelos de Desenvolvimento de Software. De lá saiu um manifesto que se você não o conhece… Bom, ele define o que é Ágil.

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

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

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Eu vou falar sobre cada item desse manifesto, mas antes precisamos entender como é a gerência de projetos não-ágil e qual a ideia por trás do ágil.

Antes do Ágil havia o PMBOK

A disciplina de Gerência de Projetos é bastante complexa e precisamos ter em mente que não há certo e errado. Há padrões e esses padrões podem ser aplicados em contextos. O PMBOK, Project Management Body of Knowledge, é bastante útil e é largamente utilizado na indústria e governos. Ele consiste em uma série práticas que vão definir como um projeto deve ser gerenciado. Temos os processos, documentos que devem ser gerados, reuniões que deve ser feitas, etc..

Antes do Ágil, o padrão PMBOK era imposto dentro da empresa. Todos os projetos tinha que seguir exatamente o que estava definido lá. E é lá que temos o famoso Cascata, em que entre a definição do que será entregue e a entrega temos meses onde não há comunicação entre Equipe de Desenvolvimento e Cliente.

Vale ressaltar que esse modelo é muito bom e funciona para outros tipos de projetos. Pensa bem, o que pode dar errado no meio do caminha da construção de um prédio? Muito diferente da construção de um software.

Ideias por trás do Ágil

Antes que você pense que o Ágil foi uma revolução, não. Nos anos 90, o que aconteceu foi que ideias que já existiam de administração começaram a ser aplicada em Desenvolvimento de Software.

LEAN

Um das ideias bem óbvias no Ágil e que passa despercebido por quem não conhece é a influencia do livro Toyota Kata: Gerenciando Pessoas para Melhoria, Adaptabilidade e Resultados Excepcionais (nunca li). Observe o que é dito nos apendices do livro O Projeto Fênix:

As liçoes do Sr. Rother foram codificadas no livro Toyota Kata, que estrutura o processo de planejamento e cultura que deve existir para permitir o ciclo PDCA Lean (Planejar, Fazer, Verificar, Agir). Acredito que essa seja uma das contribuições mais extraordinárias para o mundo da melhoria dos processos. A manifestação mais óbvia do Toyota Kata é o ciclo de melhoria de duas semanas, no qual cada supervisor de centro de trabalho deve melhorar algo (qualquer coisa!) a cada duas semanas. Para citar o Sr. Rother, “A prática do kata é o ato de praticar um padrão para que ele se torne uma segunda natureza. Em sua gestão diária, a Toyota ensina uma maneira de trabalhar - um kata - que tem ajudado a torná-la muito bem-sucedida nas últimas décadas.

Podemos ver claramente dois pontos aqui óbvios:

• Ciclo de duas semanas
• Para cada letra do LEAN (PDCA em Português), tem uma reunião no SCRUM.

Gestão da Equipe

A Gestão de uma Equipe também é baseada em ideias que vem de livros influentes. O SCRUM vai tentar resolver os problemas levantados no livro Os 5 desafios das equipes (não li também). Observe o que é dito nos apendices do livro O Projeto Fênix:

Em seu modelo, as cincos disfunções são descritas como:

• Ausência de confiança - relutância em ser vulnerável dentro do grupo
• Medo de conflito - buscando harmonia artificial sobre debate fervoroso construtivo
• Falta de comprometimento - fingir comprar as decisões do grupo cria uma ambiguidade na organização
• Evitação de responsabilidade - desviar da responsabilidade para chamar a atenção dos colegas sobre comportamento contraprodutivo, que estabelece padrões baixos
• Desatenção aos resultados - focar no sucesso pessoal, status e ego antes do sucesso da equipe

Cada ponto desse é direcionado por alguma prática do SCRUM ou XP. Em uma simples descrição da equipe desejada pelo SCRUM, há muita teoria de administração de equipes.

O Manifesto

Para se por em prática o Manifesto Ágil, é preciso ser um gestor e ter poder sobre os processo da empresa. PONTO FINAL. Não é possível uma equipe decidir ser ágil, sem contar com a boa vontade da empresa, mesmo que a empresa ganhe com essa mudança cultura.

O Manifesto Ágil na verdade propõe uma inversão de valores corporativos. Ao invês de seguir os processos da empresa, cada equipe vai decidir o que fazer com a intenção de entregar mais valor mais rapidamente. Isso é uma resposta ao engessado PMBOK. Quando se assina um contrato para um projeto, todos os requisitos propostos DEVEM ser entregues. Isso pode implicar muitas horas extras caso haja algum imprevisto. Ou pode levar a não aceitação do produto pelo cliente, muitas vezes o cliente percebe que o que foi pedido não é o que se realmente deseja. Isso é comum, sem estresses.

Então para se colocar em prática um framework Ágil, deve-se primeiro mudar a forma de se assinar os contratos. Não se pode vender um produto com homens/hora, escopo fechado. Tem que se vender um projeto com iterações e escopo aberto. Vamos começar a desenvolver o projeto X que inicialmente está previsto para 5 Sprints. Todos os documentos assinado entre Empresa e Cliente deve ser completamente diferentes.

Indivíduos e interações mais que processos e ferramentas

Em um ambiente Ágil, a equipe terá mais autonomia que em outros contextos. Os membros dessa equipe decidirão se vão executar o framework proposto (viu que não falei processo?) ou se vão adaptar. O próprio Framework Scrum não se denomina processo por esse motivo, caso a equipe decida que alguma prática deve ser alterada, sem estresse!

Muito das reuniões propostas pelo Scrum são denominadas rituais, porque eles devem ser executados como rotina, serem inseridos na cultura. Eles tem valores inseridos nele. Por exemplo, a Retrospectiva deve ser para reavaliar se o próximo Sprint deve ter melhorias. Lembra do processo de melhoria continua do LEAN?

Obviamente que a equipe deverá seguir alguns padrões da empresa. Não dá pra simplesmente jogar fora a ferramenta de Solicitação de Mudança da empresa e usar uma nova. Mas a maneira de se usar deve ser menos impositiva.

Software em funcionamento mais que documentação abrangente

Em projetos PMBOK havia muito tempo gasto em escrita de documentação. Havia o documento de Requisitos, Arquitetura e Testes. Cada um era escrito e validado antes do desenvolvimento e deviam ser validados de acordo com a entrega.

Em um contexto Ágil, o Software em funcionamento tem mais valor. No SCRUM, uma reunião de Review vale mais do que um documento de Requisito. E provavelmente é mais barato fazer um reunião de Review a cada 2 semanas do que escrever um documento de requisitos gigantesco a cada 3 meses.

Que fique claro uma coisa, o software deve ser documentado, o que pode não ser documentado é os contratos de requisitos com o cliente. Caso seu projeto não use uma Wiki interna (ou coloca no repositório de código mesmo) para documentar arquitetura, vamos começar agora! Abre um README.md e coloca todos os pressupostos arquiteturais agora!

O mais claro desse ponto é dizer: mais vale um teste automático do que um documento de testes em .docx.

Colaboração com o cliente mais que negociação de contratos

O Cliente deve ser envolvido em todo o processo de desenvolvimento. Se não puder participar das reuniões diárias (nem é bom participar… 😳), deve participar das reuniões de Review! Cada requisito tem que ser validado com o cliente, mostrado e discutido. A decisão é dele e as vezes a opinião dele muda muito rapidamente.

O que acontecia com o PMBOK é que todo o projeto estava detalhado na documentação e deveria ser entregue conforme a documentação. Era esse o contrato. A comunicação com o cliente se dava somente para informar se o projeto está em dia ou atrasado, e muitas vezes as horas extras eram escondidas do cliente. Vamos fazer uma banco de horas que próximo mês nós tiramos. Em meu primeiro projeto acumulei 72hs em apenas 2 meses e acabei tirando todas essas horas nos 2 meses seguintes.

No contexto Ágil, o projeto não deve ser encarado como algo fechado que é contratado e deve ser entregue. Isso pode ser válido para construção de um prédio, mas para construção de software não é possível. Há muito mais volatilidade dos requisitos. O cliente deve ser envolvido em todo o processo.

Responder a mudanças mais que seguir um plano

Mudanças vão ocorrer! Toda a disciplina de Engenharia de Software já leva em conta que o Cliente não sabe o que quer, ou se sabe, pode ser que sua necessidade mude.

É comum ver desenvolvedores reclamando que o cliente nunca sabe o que querem. É por isso que são chamado de desenvolvedores e não engenheiros de software! 😏

Por isso que uma equipe ágil deve ter um backlog e deve gerenciar esse backlog muito bem! Ele deve ser repriorizado a cada iteração. Lembre-se o foco deve ser entregar valor ao cliente!

Mas muito cuidado! Deve ser feito um Gerenciamento de Débito Técnico! Não é possível construir um software respondendo a mudanças rapidamente, mas deixando muita sujeira pra trás… O nome disso não é Ágil! É eXtreme Go Horse (XGH)!

Conclusão

Acabei de apresentar quais são os principios do Ágil. Agora cabe a você usar bem esses conceitos. Os Frameworks Ágeis são baseados em Times autogerenciaveis, isso é uma das bases.

Eu nunca tive contato com um agilista, mas caso você tenha veja se ele está aplicando esses conceitos. Caso não esteja, é hora de ter uma conversa séria com o gerente! É muito complicado se criar uma função para garantir o ágil… Parece contraditório.

Há outros temas que o Ágil habilitou, porém são temas completamente diferentes. Você viu que todas as citações usadas foram de um livro de DevOps? Pois é, o Ágil possibilitou o DevOps. E este é nada mais nada menos do que a aplicação de conceitos ágil no suporte. Outro tema foi Microsserviços… Mas é muito tema para pouca letra…

Desejo que você aplique esse conhecimento no seu projeto e que ele seja um sucesso! 😉

Leituras Recomendadas

• O Projeto Fênix: um Romance Sobre TI, DevOps e Sobre Ajudar o seu Negócio a Vencer
• Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software

Foto de Essow Kedelina no Pexels