Gestão de Projetos de Software

As Práticas Convencionais

Os métodos de Gestão de Projetos "tradicionais", como o PMI ou o Prince, estão relacionados ao processo de desenvolvimento de software chamado de Cascata. Esta relação, ainda que não seja obrigatória, é concreta, já que as práticas de um suportam as do outro.

Nesta abordagem, o desenvolvimento de software é tratado como uma sequência de atividades encadeadas, onde cada etapa fornece os insumos necessários para a próxima. Cada especialista é engajado no projeto em uma atividade específica e é , depois, liberado para outros projetos, deixando um artefato (um documento com características pré-definidos) que será utilizado pela próxima turma de especialistas.

Assim, Analistas de Requisitos, Arquitetos, Engenheiros, Programadores, Testadores e Documentadores não trabalham em uma equipe unificada, mas em sucessivas "ondas" de contribuição para o projeto, deixando o seu legado na forma de um artefato.

Esta abordagem é defendida em uma metáfora de linha de produção, onde o software é tratado como um produto resultante deste esforço, construído em uma "Fábrica de Software".

O aumento da capacidade de entrega é atingido pelo aumento dos recursos dedicados à cada etapa e a gestão através de métodos gerenciais tradicionais, geralmente de inspiração Taylorista (lembremos da metáfora da Fábrica).

Mesmo quando se utiliza o método unificado UP ou a sua versão comercial, o IRUP), a maioria das empresas despreza sua natureza iterativa e incremental para estruturar o projeto em poucas e longas iterações, tornando sua aplicação muito mais semelhante ao método cascata do que dos chamados métodos ágeis.

O gráfico acima, extraído da Wikipedia e presente em toda a literatura sobre o RUP/IRUP, demonstra o quanto este modelo é facilmente tratado como um modelo cascata tradicional, já que toda a alocação de recursos se dá em ondas e a entrega feita ao final do ciclo.

Notem que o próprio título do gráfico fala em ciclos iterativos, mas, de acordo com a minha experiência prática, são geralmente encarados como grandes fases de partes significativas do sistema.

Com esta abordagem contínua, as mudanças são tratadas como um problema. Para acompanhá-las, os projetos entram em uma espiral de Solicitações de Mudança, Comitês de Mudança e retrabalho em artefatos gerados nas fases anteriores, que quase certamente levará o nosso projeto ao fracasso.

E quando este modelo falha?

Segundo pesquisa do Standish Group, este modelo falha em 68% dos casos! Esta empresa de consultoria vem pesquisando a qualidade da gestão de projetos desde 1994 e este número é da última pesquisa disponível, feita em 2009.

O gráfico abaixo mostra uma sensível melhora no índice geral de fracassos dos projetos, especialmente até 2003, mas os projetos desafiados, que são os projetos concluídos com desvio significativo em prazos ou custos, não tiveram o mesmo nível de melhorias.

A última pesquisa mostra, inclusive, um grande aumento do número de projetos fracassados. Pode-se, argumentar, é claro, que este aumento dos "fracassos" deve-se, pelo menos em parte, ao melhor controle sobre os projetos e consequentemente da disponibilidade de informações concretas para as decisões de cancelamento de projetos, mas é inegável que os números são alarmantes.



Contra fatos, não há argumentos, então vamos ver as alternativas.

Scrum e os Métodos Ágeis

Marcada a minha opinião sobre os métodos em uso, sustentada por alguns dados relevantes, qual a saída?

Primeiro, algumas premissas:
  • O negócio, e não a nossa visão de tecnologia, deve guiar os projetos. Nunca devemos nos esquecer que o foco de um sistema de software é satisfazer às demandas do negócio. Não fazemos software porque gostamos, ainda que gostemos muito de fazê-lo.
  • A mudança (de requisitos, ambiente) não é um problema ou um desvio, mas um fato com o qual temos que lidar.
    Durante um projeto, seja de desenvolvimento ou implantação de software, o ambiente irá mudar, assim como as pessoas. O próprio projeto irá influenciar a maneira como as pessoas (cliente, usuários, técnicos) pensam e agem.
  • A flexibilidade é esperada nos sistemas de software.
    No ofício da Engenharia de Sofware não temos a limitação das estruturas concretas. Podemos refazer (ou trocar) o alicerce (framework) de um sistema em desenvolvimento (com algumas ressalvas) e, muito mais, alterar as características finais (funcionalidades) do produto. Todos sabem disto e esperam isto de nós.
A incapacidade das ferramentas tradicionais de gestão de projetos de software alterar significativamente o quadro, descrito na pesquisa do Standish Group, produziu, em 2001, o Manifesto Para o Desenvolvimento Ágil de Software

O Manifesto é uma declaração de princípios, publicada pelos principais atores envolvidos com os métodos ágeis, dentre eles Ken Schwaber, o "pai" e evangelizador do Scrum, o método de gestão de projetos que eu estou utilizando e que é, afinal, o objetivo deste texto.

Os Conceitos-Chave do Scrum

  1. Os requisitos são agrupados em ordem decrescente de retorno para o negócio e são executados nesta ordem. Sempre.
  2. O projeto é quebrado em iterações de duração fixa. Cada projeto pode definir esta duração, mas valores usuais estão entre uma e quatro semanas. Os requisitos de cada iteração devem estar detalhados antes do seu início.
  3. Cada iteração tem um objetivo bem definido e deve produzir uma versão "potencialmente entregável" do software (ou do "objeto" do projeto).
  4. As equipes de projeto são multi-funcionais e auto-gerenciáveis.
Vou detalhar um pouco estes conceitos e ver como o método funciona.

O primeiro conceito trata da execução alinhada com as prioridades do negócio. É uma dica simples, mas que raramente é seguida em projetos de software. Normalmente as tarefas são encadeadas pela afinidade técnica ou em função da disponibilidade de recursos (humanos e materiais) para o projeto.
Esta é uma mudança (aparentemente) simples e que faz toda a diferença: ao final de um projeto, quando os prazos estão apertados e todos estão preocupados com a entrega final, um time de Scrum está cuidando apenas dos requisitos menos importantes, e isto faz toda a diferença.

A divisão do projeto em iterações (conceito 2) não é uma ideia propriamente nova. Defini-las como blocos de duração fixa, também não. Mas ao se executar o processo em um projeto, fica claro como estas coisas juntas, mais a questão do objetivo bem definido (conceito 3), fazem com que o andamento do projeto possa ser monitorado no nível de abstração que todos eles deveriam.
Cada iteração, chamada de Sprint no Scrum, se inicia por um planejamento detalhado das tarefas a serem executadas. É obrigatório que todos os requisitos do Sprint estejam bem definidos, também.
Mas veja a diferença: apenas os requisitos do Sprint precisam estar totalmente detalhados. O aprendizado obtido em um sprint, tanto da equipe quanto do cliente, influenciam diretamente a maneira como os requisitos vão sendo detalhados ao longo do projeto. E como o detalhamento do requisito precede todos os demais processos do desenvolvimento, o alvo fica móvel no melhor sentido, permitindo que o projeto vá se acomodando às mudanças ambientais.

O teceiro conceito traz outra mudança cultural importante. Ao final de cada Sprint, deve ser produzido um resultado que possa ser demonstrado para o cliente.
Ou seja, não se contam entregas de documentos de planejamento, modelagens, etc. Não que isto não seja necessário ou que não deva ser feito (ver o quadro Scrum e Engenharia de Software, mais adiante), mas não é é este o foco de uma iteração. A cada novo Sprint devemos ter um software melhor do que tínhamos no Sprint anterior e isto é o importante.
O "objetivo bem definido" é sempre um objetivo de negócio, como "emitir uma nota fiscal de venda de uma filial". Este objetivo estará representado pelos requisitos escolhidos para o Sprint e decomposto em atividades, distribuídas pelo time. Este objetivo funciona como uma declaração de missão do Sprint, que por ter uma duração curta, tende a ser facilmente compreendido por todos os membros da equipe.

A questão da equipe é um conceito facilmente mal interpretado no Scrum. Para que a técnica tenha sucesso é importante que a equipe seja formada por profissionais que, em seu conjunto, detenham os conhcimentos necessários à execução do projeto. É claro que podemos demandar especialistas para apoiar tarefas específicas do projeto, como consultores, mas a equipe deve conter as pessoas que serão responsáveis pela entrega.
Quanto o auto-gerenciado ... bom, este é outro conceito que deve ser lido no contexto. No Scrum o time é soberano para decidir o que deve entrar em um Sprint (mas não alterar a ordem de execução), pode escolher se aceita ou não uma mudança (dentro do Sprint) e tomar todas as decisões técnicas e administrativas para a execução do projeto.
O que não pode ser esquecido ou mal interpretado é que esta equipe está inserida em uma estrutura organizacional. A organização pode/deve ter mecanismos para avaliação de qualidade e produtividade desta equipe e agir de acordo.
O que a ferramenta estabelece é que, durante a execução do projeto, especialmente durante o Sprint, a equipe é o seu melhor gerente. Esta asserção é geralmente verdadeira, mesmo em equipes menos experiente. A exceção é se a sua equipe for completamente irresponsável, mas, neste o caso, faça um favor à sua organização e troque esta equipe.

Estou ainda tocando os meus primeiros projetos com o Scrum, mas por enquanto a técnica se mostrou bastante poderosa, tanto para a produtividade quanto para o controle.

Vou continuar a escrever sobre este assunto aqui e em blog.sergiodias.inf.br. Fique ligado.

Esta apresentação dá uma visão geral da ferramenta

(clique aqui para ver a apresentação em tela cheia)

Esta apresentação do Jurgen Appelo também está muito boa, apresentando os conceitos e algumas armadilhas da ferramenta (em inglês).

Engenharia de Software e Scrum
Existe um pouco de confusão sobre o fato do Scrum ser ou não uma metodologia de desenvolvimento.

Esta polêmica já foi levantada, inclusive, por Martin Fawller, em um artigo denominado Flaccid Scrum,  e de alguma maneira respondida pelo Ken Schwab neste artigo.

A verdade é que o Scrum não trata da Engenharia em si mas apenas do processo de gestão de projetos. É claro que a engenharia utilizada pela sua equipe precisa ser adaptada ao método de gestão já que, pelo menos neste caso, ele influencia profundamente a maneira como organizamos o nosso projeto de software.

Na Q10 Informática ainda estamos refinando a nossa metodologia, mas o que posso dizer é que o nosso método está muito mais próximo do (R)UP do que do XP.

Mais sobre o assunto

Um excelente texto de Henrik Kniberg, comparando Scrum com Kanban (pdf).
Comments