Das muitas definições sobre agilidade que podemos encontrar em livros, revistas e na internet, uma das que mais gosto é: “Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com estabilidade”. (Highsmith, Jim. Agile Project Management, 2002)

Agilidade é uma proposta de desenvolver projetos com uma estrutura e organização “suficientes”. Muita estrutura e organização reduz a criatividade e a flexibilidade de suportar mudanças, pouca estrutura e organização permeia a ineficiência e resulta em esforços maiores que os necessários.

A diferença entre caos e agilidade pode ser verificada nos produtos resultantes. Considerando o mesmo cenário turbulento de negócios, nas equipes que convivem com o caos verificamos atrasos constantes, baixíssima qualidade dos sistemas, problemas com estimativas e estouro de orçamento. Nas equipes que utilizam-se de métodos ágeis percebemos entregas parciais constantes, interação com clientes para revisão de estimativas e orçamento conjuntamente com antecedência salutar ao projeto e principalmente dois pontos fundamentais: compromisso com a satisfação do cliente e responsabilidade com o resultado financeiro do projeto.

Empresas procuram métodos ágeis

As metodologias ágeis estão disponíveis desde a década passada, porém foi no ano de 2001 que houve a formalização com a assinatura do manifesto ágil (Manifesto for Agile Software Development – http://agilemanifesto.org/).

Inicialmente houve uma desconfiança geral por parte da indústria de software, certamente impulsionada pelas diferenças aos métodos tradicionais e as questões das dificuldades de quebra de paradigmas por parte das pessoas. Nesta época tornou-se bastante famosa a metodologia XP (eXtreme Programming), pois propunha sem hipocrisia uma série de métodos polêmicos, muitos deles questionáveis até hoje como por exemplo a programação em pares e o cliente ao lado do desenvolvedor durante o projeto.

Lentamente, a indústria de software, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, verificou que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.

Alguns destes métodos, compreendidos de forma inadequada, causavam uma dificuldade de percepção dos resultados. Um ótimo exemplo disto é a iteração. Iteração (iteration), que em tradução simples quer dizer repetição, é confundido com “interação” ou compreendido como processos repetíveis. Na verdadeira definição ágil, iteração está mais para processos confiáveis do que processos repetíveis. Na língua inglesa também verificamos este desentendimento quando estudamos em textos ágeis as palavras “repeatable” e “reliable”.

A confusão entre confiável e repetível acontece porque muitos gestores de empresas gostam de formalizar processos muito estruturados e precisos (repetíveis) no lugar de formalizar processos suficientemente estruturados e flexíveis (confiáveis). Processos repetíveis focam na entrada das atividades, processos confiáveis focam no resultado das atividades.

Outros métodos, por oferecerem propostas mais simples de compreensão e apuração de resultado, começaram a chamar a atenção positivamente da indústria de software. Face a isso, iniciou-se um movimento liderado pelas universidades no Brasil (hoje sou consultor de metodologias ágeis da USP) que objetiva esclarecer os métodos e gerar conteúdos práticos que facilitem a implantação de tais propostas metodológicas.

Certificadas de que estes métodos funcionam, as empresas de software começaram a estudar uma proposta de metodologia classificada como ágil, que propõe novos métodos em substituição aos métodos praticados tradicionalmente. Este critério de escolha, que em minha opinião está suficientemente maduro, buscou primeiramente resolver as questões acerca da organização, distribuição e controle das atividades de um projeto de software. Eis a explicação da escolha da metodologia SCRUM pelo mercado de empresas desenvolvedoras de software.

SCRUM, muito simples de usar

A metodologia SCRUM está entrando na moda aqui no Brasil, após já haver conquistados inúmeras empresas da indústria de software na América do Norte.

Particularmente, eu considero o SCRUM uma proposta extremamente prática e honesta. Defino por prática neste contexto a facilidade de compreensão e aplicação em nosso ambiente de desenvolvimento de software. Defino por honesta a fidelidade entre a proposta do método e o resultado que podemos obter após aplicá-lo.

SCRUM, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão.Também o nome SCRUM foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.

Para explicar SCRUM, utilizarei uma estratégia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM. Na minha leitura, este é o melhor livro disponível lançado até a presente data.

Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia / infra-estrutura. Esta lista é denominada Product Backlog.

Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.

O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de SCRUM Teams. A preparação dos trabalhos é denominada SPRINT Planning.

SPRINT Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são SPRINT Goal e SPRINT.

O SCRUM Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado SPRINT. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada SPRINT Backlog, será de total responsabilidade do SCRUM Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico SPRINT.

É permitido ter mais de um SCRUM Team trabalhando no mesmo Product Backlog, por isso os requisitos são devidamente separados em SPRINT Backlog distintos por equipe. Uma idéia deste ciclo é verificada na imagem abaixo.

Figura 1 – Ciclo demonstrando SPRINT

A liderança destas equipes é exercida por um papel denominado SCRUM Master. O SCRUM Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este papel deve garantir a correta utilização das práticas de SCRUM, deve ajudar a equipe a tomar decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do produto.

Este método de liderança é exercido através de 3 recorrentes tipos de reunião: SCRUM Daily Meeting, SPRINT Review e Retrospective. Começando pelo SPRINT Review que é a reunião típica de final de SPRINT (alguns SCRUM Team também a fazem no meio do SPRINT) para validar o produto executável que a equipe conseguiu incrementar.

Explicando a Retrospective, é uma reunião que também acontece ao final do SPRINT com o objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas com seriedade por todos os membros do SCRUM Team:

• O que você fez e gostou neste SPRINT?
• O que você fez e não gostou neste SPRINT?
• O que você vai fazer diferente no próximo SPRINT?

O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. SCRUM Daily Meeting é a resposta para promover a comunicação da equipe.

Todos os dias, obrigatoriamente, todo o SCRUM Team irá se reunir por 15 minutos aproximadamente para responder a 3 importantes perguntas. Sugerimos que está reunião seja de pé, pois temos verificado bons resultados em nossas práticas.

As perguntas são:

• O que eu fiz desde a última SCRUM Daily Meeting até agora?
• O que eu vou fazer hoje?
• O que pode me impedir?

Adicionalmente as técnicas apresentadas neste artigo, temos observado que a utilização de KANBAN (ver figura abaixo) ajuda a maximizar o comprometimento da equipe e a comunicação de todos os comprometidos e envolvidos com o projeto.

Figura 2 – Nossa implementação de KANBAN na empresa REPOM dirigida pelo SCRUM Master Marcelo Martins.

As cores amarela e laranja representam diferentes complexidades das atividades. A cor pink representa atividades não planejadas no SPRINT que foram incluídas por motivo de força maior.

Por se tratar de um extenso assunto, abordaremos detalhes explicativos sobre o que é KANBAN e como se utiliza em projetos de software no nosso próximo artigo técnico.

Para saber mais recomendamos os livros:

Agile Project Management by Jim Highsmith.

Agile Software Development with SCRUM by Ken Schwaber e Mike Beedle.

Agile Project Management with SCRUM by Ken Schwaber.

Treinamento MSF Agile + SCRUM + Agile Methods em http://www.fcamara.com.br

Considerações Finais

Nós, praticantes das metodologias ágeis, acreditamos que todos os projetos são diferentes. As tecnologias destes projetos são diferentes. As pessoas, os requisitos, idem. Nós não queremos ser indivíduos críticos do que existe há muito tempo na engenharia de software, nós queremos sugerir, proporcionar e fundamentar alternativas novas para resolver problemas antigos.

Na grande maioria das consultorias que ministro sob a titulação de “coaching” para fins de crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de software, encontro pessoas que, utilizando-se de métodos tradicionais ou simplesmente de improviso diário (também denominado “ausência de métodos”), revelam-me uma estranha e frustrante sensação – A Síndrome do Trabalho Vazio.

A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos e de atividades urgentes, quando percebe-se que, no final, todas as atividades planejadas para aquele dia não puderam ser implementadas. É uma constatação que é uma espécie de marionete do tempo, da empresa e dos clientes.

A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos pelas metodologias ágeis, mudaram minha vida profissional perante o cenário anteriormente descrito. Eu consigo fazer atividades planejadas, consigo priorizar atividades importantes e tenho um pequeno índice de atividades urgentes no meu dia-a-dia. Eu me sinto protagonista do meu dia.

As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os resultados proporcionados por “waterfall approach to software development” ou pela ausência de métodos. Para iniciantes em metodologias ágeis, eu recomendo o SCRUM. Para praticantes de métodos ágeis que não conhecem o SCRUM, permitam-se mais uma evolução.

Sucesso em seus projetos.