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
- Os requisitos são agrupados em ordem decrescente de retorno para o negócio e são executados nesta ordem. Sempre.
- 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.
- Cada iteração tem um objetivo bem definido e deve produzir uma
versão "potencialmente entregável" do software (ou do "objeto" do
projeto).
- 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
|
0 comentários