Este é o primeiro artigo de uma série de 3, onde vou apresentar minha visão sobre agilidade no desenvolvimento de software. Espero que esta série sirva como porta de entrada para para você que está começando no mundo da agilidade assim como, uma chamada à reflexão para aqueles que já possuem alguma experiência.

Após anos trabalhando com métodos ágeis, inicialmente aplicados ao desenvolvimento de software e posteriormente à vida, observei que a busca por agilidade não pode ser vista apenas como um processo, mas sim, como cultura que é obtida com o equilíbrio e amadurecimento em 3 áreas: Pessoas, Processos e Tecnologias.

Dito isso, eu gostaria de compartilhar algumas observações, conclusões e sugestões nessas três áreas. Pessoalmente, acho que Extreme Programing é o estado da arte em termos de metodologias de desenvolvimento de software.

Extreme Programing preza por transparência, focando no mínimo necessário em termos de gestão, estimulando ampla comunicação e instrumentação no ferramental de desenvolvimento. Isso por sua vez possibilita que o time trabalhe próximo do seu cliente fazendo entregas pequenas e regulares. Essas entregas chamadas de ciclos acabam provendo bastante transparência do processo de desenvolvimento.

Agilidade é transparência... conforme as palavras do próprio mestre Kent Beck no livro Extreme Programming Explain: Embrace Change:

Sim! Transparência é exposição, se você está aplicando métodos ágeis e não provê transparência do seu processo de desenvolvimento, é por que não está se expondo o suficiente e sem se expor será muito mais difícil melhorar e amadurecer em termos de agilidade.

Processos

Para facilitar a argumentação vou classificar os processos em dois grandes grupos:

• Processos rígidos, com etapas pré-determinadas e ritos obrigatórios a serem seguidos, poucas atividades são executadas em paralelo, como exemplo podemos considerar o modelo em Cascata
• Processos Flexíveis, onde toda etapa gera valor para o cliente, muitas atividades são trabalhadas em paralelo, existe menor formalismo e muita automação. Como exemplo podemos citar o modelo Ágil

Apesar das duas categorias estarem bem definidas, é muito comum ocorrer uma mescla desses modelos de desenvolvimento gerando situações como as que são mostradas abaixo.

O uso de SCRUM, em um projeto com cronograma previsível, marcos bem definidos, entregas com longos intervalos já planejadas com requisitos previamente definidos.

Uma outra situação é um projeto com requisitos incompletos, mas com a empresa engajada, uma visão bem definida, um time com experiência no desenvolvimento ágil, mas no entanto é utilizado um modelo em cascata como o Processo Unificado burocratizando o processo de desenvolvimento desnecessáriamente.

Use a ferramenta certa para o trabalho, não tente adaptar a essência de um processo. Todos preveem pontos de modificação, mas a essência de cada um não pode ser ou não deve ser modificada, sendo assim:

Se o projeto já possui um escopo definido, data para entrega, não faz sentido perder tempo estimando parcialmente, seguir ritos como: retrospectivas, planejamento de sprint, blah, blah blah. Um projeto nessas condições deve ser planejado no início e acompanhado até a entrega.

Por outro lado, um projeto sem escopo claro ou com grande possibilidades de mudança, deve aderir a um planejamento progressívo com entregas regulares, o cliente deve ser puxado para mais perto do time, todo o ciclo deve gerar software e devem ser feitas reavaliações a ciclo executado.

É importante considerarmos que frameworks como SCRUM, foram desenhados com foco na incertezas e tolerância a mudanças de maneira a possibilitar o amadurecimento do time e rápidas entregas. Ele te provê ferramentas para lidar com gestão dos requisitos de maneira dinâmica e menos burocrática. Um ótimo livro sobre adoção de SCRUM é o Succeding With Agile

Problemas que terá com um processo rígido

Abaixo apresento alguns problemas advindos com uso da mescla de processos rígidos com elementos de agilidade, quando eles são feitos com o intuito de modificar a essência do modelo para se adequar ao grau de maturidade da empresa.

1. Estórias desatualizadas ou incompletas, manual de uso da aplicação que não contemplava as novas funções de telas já existentes;
2. Relatórios que só saem porque você produz e ninguém parece dar a mínima importância;
3. Mal uso das ferramentas de gestão, um exemplo seria: uma coleção de planilhas com totalizadores para dar visibilidade ao gestor;
4. Informação vital vinculada uma única pessoa dita "confiável";
5. Personificação dos papéis fazendo com que todos aguardarem pelo "encarregado" para fazer as definições necessárias.

Não tente implantar um processo ágil e manter o controle das coisas entre você e seus funcionários de confiança, agilidade vem da divisão de responsabilidades entre todos.

Processos Flexíveis (Ágil de verdade)

Seguem algumas características de processos ágeis de verdade, é fácil observar o fatores de adaptação, desenvolvimento pessoal e melhoria continuada.

1. Separação entre papéis e cargos, responsabilidades podem mudar a cada ciclo;

   Você tem ciclo, não tem Sprint, não tem rituais, mas tem uma visão, um objetivo e o time busca as ferramentas necessárias para atingí-lo. Em Agile Everything do Fewell, J. tem uma bela visão sobre isso.

2. As atividades são entregues ao time e este se organiza para atendê-las;

   Auto-organização do time precisa ser incentivada, dessa maneira o time ganha confiança e sente-se confortável em prover mais transparência a cerca do funcionamento interno.

   Um exemplo disso seria: Aquela "Margem de segurança" tornar-se de conhecimento comum a todos inclusive do Product Owner e até mesmo do Gerente

3. Recebimento de feedbacks em relação ao processo;

   Como os vários membros estarão compartilhando responsabilidades maiores, ficarão confortáveis para propor melhorias a partir da própria experiência.

   Isso é interessante, pois permite o teste de escalabilidade do seu processo. Quando há muita centralização em uma pessoa, o processo não irá escalar, será bem difícil executar atividades em paralelo.

4. Reuniões de retrospectiva tratadas como reuniões de melhoria;

   Não leve problemas sem solução e ajude na proposição de soluções para tudo o que levar.

   Reuniões de melhoria são feitas para se chegar a um consenso, não existe agilidade sem consenso.

Sobre as etapas de um processo ágil

Toda etapa do processo deve fazer sentido para o time, para saber isso, verifique se informações que ela depende estão sendo consumidas e se o produto gerado por ela está sendo usado.

Toda etapa deve produzir um resultado útil para o projeto.

Alguns exemplos de produtos de valor que podem ser gerados

1. Planejamento macro gera uma lista para o backlog inicial

   Como parte da visão do projeto deve-se buscar o quanto antes o valor mínimo entregável, este será a sua base possibilitando que você planeje os próximos marcos do projeto;

2. Análise de requisitos geram Especificações usadas no desenvolvimento

   Envolver um ou mais membros do time técnico na evolução dos requisitos é muito interessante, pois eles podem complementar a visão. O livro BDD in Action apresenta uma maneira de se definir requisitos em forma de cenários.

3. Análise da especificação geram as soluções para o desenvolvimento

   De posse dos requisitos e critérios de aceitação o time de desenvolvimento assume a análise e tenta propor a solução.

Em certo grau o uso de BDD ajuda bastante o time no momento de projetar as soluções, pois a visão em forma de cenários é mais próxima da linguagem de trabalho do desenvolvedor.

Exemplos de resultados práticos

Abaixo seguem alguns artefatos que podem ser produções produzidos e como eles são usados dentro de um ciclo de desenvolvimento gerando software.

Documentos

• Manuais
• Atas de reuniões (ações, atividades, prazos)
• Requisitos

Software

• Código-fonte
• Executável

Relatórios

• Execução de testes

• Progresso de Atividades

Considero resultado prático e de valor algo seja útil e de uso recorrente. Qualquer outra coisa produzida não acho que deva fazer parte do processo, mas sim ser tratado como uma excepcionalidade.

Suporte fronteira de Processo

Uma coisa muito importante principalmente se você trabalha com serviços de desenvolvimento que é a fronteira de processo, que é nada mais que a capacidade de se adequar ao processo do cliente sem prejuízo do seu próprio processo.

Sempre deixe um "espaço" no seu processo para integração com o processo do seu cliente. Tentar unificar os dois em um único grande processo nunca vai funcionar. O seu cliente sempre tem objetivos diferentes do seu.

Por mais que você pense que ambos estão no mesmo barco, ele sempre poderá pegar um bote e ir para margem, você não!

Você precisa entregar o projeto e ele precisa que o projeto lhe agregue valor.

Agilidade

Ok! Essa foi a primeira parte, optei por iniciar por processo, pois é muito comum definir o processo antes do time e projeto. Após isso, tentamos corrigir os desalinhamentos das pessoas incluindo atividades ou rituais no processo, quando na verdade deveríamos deixar o processo emergir a partir do time.

Cada um tem seu tempo e caminho, sua percepção de como as coisas devem seguir. Tudo está sempre mudando e se renovando, mas em linhas gerais é possível trabalhar de maneira a abstrair os detalhes tecnológicos de cada momento e seguir evoluindo.

É importante estarmos prontos como agilistas para pegar as oportunidades tão logo elas apareçam de maneira a:

Seguirmos na estrada para a agilidade

Que esse artigo sirva de breve referência para os seus estudos em agilidade e melhoria continuada, você está por aqui já é meio caminho andado, parabéns.

Tags: agile | agilidade | agility | desenvolvimento ágil | desenvolvimento ágil de software | extremeprogramming | metodos | processos | tecnologia | xp