Há tempos se discute no mercado como garantir o alinhamento dos investimentos de TI à estratégia de negócios da empresa, como obter retornos mais rápidos e como reduzir os riscos da área de informática. Muito trabalho e estudo foram desenvolvidos com esse foco e nos acostumamos com uma vasta gama de siglas e conceitos, sempre lançados com a promessa de trazer o tão sonhado alinhamento: Cobit, ITIL, PMI e outros.
Na área de desenvolvimento, as metodologias baseadas no Rational Unified Process (RUP) em conjunto com as certificações baseadas no CMMI buscaram reduzir os riscos dos projetos de software através da implantação de processos pesados e complexos, com a geração de diversos subprodutos (chamados de artefatos) e controles. Infelizmente, uma análise da evolução da qualidade dos projetos de software mostra que, apesar dos enormes esforços aplicados nesta área, não houve melhorias significativas nos resultados.
Nos últimos anos, porém, um conjunto de novas metodologias e processos tem sido desenvolvido e traz uma proposta diferente para o desenvolvimento de software. Conjuntamente chamados de metodologias ágeis, essas abordagens tentam resolver os problemas de projetos de desenvolvimento não por meio de mais controles e rigidez. Ao contrário, aceitando algumas das incertezas inerentes aos projetos de desenvolvimento e integração de sistemas, elas encontraram uma forma de otimizar o retorno do investimento e obter um maior envolvimento das equipes e dos clientes finais. Neste artigo é analisada uma metodologia ágil de gerenciamento de projetos chamada Scrum.
Para compreender o benefício dessa nova metodologia é importante verificar quais têm sido as maiores dificuldades das abordagens tradicionais. Além dos obstáculos causados pelos próprios processos em si, é possível listar como os principais problemas enfrentados nos projetos:
• A dificuldade de elaborar estimativas confiáveis para as tarefas de desenvolvimento;
• A complexidade envolvida no levantamento e documentação de requisitos para os projetos de software;
• As mudanças nos projetos de software, que são uma realidade constante, porém dificilmente tratadas de forma satisfatória.
Dificuldade com as estimativas
A dificuldade para se fazer estimativas em projetos de software é bastante conhecida por todos. Basta perguntar a três desenvolvedores diferentes qual é o esforço necessário para criar um módulo para se obter três respostas diferentes, e haverá uma única certeza: efetivamente não sabemos estimar com precisão. Mesmo com diversas metodologias desenvolvidas (como pontos de função, por exemplo), a tarefa não foi resolvida a contento. E como as metodologias ágeis abordam este assunto? Primeiro com uma constatação simples: é muito difícil estimar. E se a questão é difícil, como podemos tratá-la?
Primeiro, temos de utilizar o que o nosso cérebro tem de melhor, e estimar as coisas por comparação (apenas pense para ver se é mais fácil estimar o tamanho de um animal em centímetros ou comparar dois animais para ver qual é maior). Segundo, comece a utilizar software funcional, ou seja, partes ou módulos de um sistema já implementados e testados, como sua principal medida de produtividade. E terceiro, para obter resultados confiáveis, fixe as outras variáveis do processo. Assim, o Scrum define um prazo fixo para as etapas do projeto (que são chamadas de sprints, e tem duração de 1 a 4 semanas) e pede que a equipe seja mantida fixa durante este período. Cada ítem a ser desenvolvido é estimado de forma comparativa em relação a uma funcionalidade escolhida como base em pontos. Ao fim de uma etapa, o resultado final pode ser medido e vai servir como base para avaliar a produtividade da equipe e, consequentemente, o prazo para o projeto. Podemos não ter um prazo definido no início do projeto, mas após poucas etapas temos uma medida real e bastante confiável de como a equipe está produzindo, e poderemos tomar medidas gerenciais caso a situação exija.
Mudanças e complexidade do levantamento de requisitos
A maioria dos projetos parte de uma definição completa do escopo do projeto, afinal isto é a base de tudo, certo? Mas sabemos que os requisitos do projeto certamente vão mudar ao longo do tempo. Novas idéias vão surgir, o cenário competitivo vai mudar, as necessidades da empresa vai evoluir. Além disso, o próprio usuário final (ou cliente) tem, no início do projeto, apenas uma visão abstrata do produto final a ser desenvolvido. Por mais que tente descrever seu funcionamento e suas regras de negócio através de casos de uso, diagramas, e atestar as funcionalidades através de protótipos, é praticamente impossível assegurar que todos os detalhes do negócio foram mapeados antes do usuário ter de fato contato com o sistema acabado (visão concreta do produto). Esse descasamento entre o que foi produzido e o que era "esperado" pelo usuário leva a uma gestão de mudanças reativa e desgastante e, quase sempre, geradora de conflitos entre as partes. Mais crítico ainda, tende a gerar um produto final não totalmente alinhado às necessidades de negócio. Para que tentar engessar o projeto então com uma definição de escopo que sabemos que vai mudar? Não seria possível trabalhar de uma forma diferente, aceitando as mudanças ao invés de lutar contra elas?
O Scrum já parte do pressuposto que o escopo vai mudar. Ele não obriga, portanto, que o cliente defina, logo no início, exatamente tudo que precisará ser feito. Ele parte de uma visão geral e de uma lista das funcionalidades desejadas para o sistema, e pede para que o cliente priorize esta lista, de acordo com o valor de negócio esperado para cada funcionalidade. A partir disso, a cada etapa (ou sprint) do projeto vamos selecionar um conjunto de itens do topo da lista e a equipe vai desenvolvê-los e testá-los, entregando no final um sistema funcional (mesmo que bastante limitado, por não ter todas as funcionalidades necessárias). Ao término de uma etapa, o cliente pode repriorizar os ítens restantes na lista ou mesmo incluir novos ítens. Com isso, todo o tempo (e custo) gastos normalmente no início dos projetos podem ser poupados, e o desenvolvimento efetivo pode ser antecipado. E como o desenvolvimento passa a ser priorizado pelo valor de negócio das funcionalidades, pode-se geralmente conseguir uma versão inicial do sistema em um prazo bem mais reduzido, e que já pode começar a trazer benefícios reais ao cliente, melhorando sensivelmente o ROI do projeto. Sem esquecer que acabamos com os recorrentes problemas de negociações de mudança de escopo, que tanta energia costumam tirar dos projetos.
Ao evitar uma abordagem de detalhamento completo do projeto logo no início, o Scrum ajuda a resolver também os problemas advindos da complexidade do levantamento de requisitos. No Scrum, a própria equipe vai fazer o detalhamento com o cliente e, a cada etapa, vai estar interessada em uma pequena parte do projeto. O processo antecipa a experiência do usuário no uso do sistema (lembre-se que ele vai ter acesso a partes funcionais do sistema ao longo de todo o projeto) tornando o processo de definição de requisitos muito mais preciso e objetivo, através dos feedbacks constantes para a equipe de desenvolvimento. Assim várias dificuldades advindas de problemas de comunicação são minimizados (diminuem os intermediários no processo), e o envolvimento e a motivação do grupo aumentam, pois a equipe se torna mais envolvida com o projeto.
Estes são apenas alguns dos motivos que tem feito as metodologias ágeis, e em particular o Scrum, bem aceito nos projetos de diversas empresas. Ao reorientar a forma de organização dos projetos, o Scrum tem conseguido reduzir significativamente os riscos dos projetos, aumentar o alinhamento da área de desenvolvimento com as necessidades de negócio e ainda melhorar significativamente o retorno do investimento. Isso tudo ao mesmo tempo que aumenta a motivação das equipes e a satisfação dos clientes. Parece até uma solução mágica, mas não é nada mais do que a orientação do foco e da energia para aquilo que é realmente importante.
*José Fernando Guedes é engenheiro da computação pela Unicamp e gerente da fábrica de software Dextra Sistemas.
- José Fernando Guedes*
