12.0 Cachoeira vs. Gestão de Projetos Cíclicos (Parte 5) – Condições de Gestão de Projetos Cíclicos

Os utilizadores/clientes participam ativamente #

Cada ciclo de gestão de projetos cíclicos envolve o desenvolvimento de requisitos, design, execução e testes. Isto implica que muitas escolhas devem ser feitas ao longo de um ciclo. Para que o programa represente com precisão os desejos do cliente, o cliente deve ser um membro ativo da equipa do projeto.

Os clientes devem comunicar os seus requisitos aos programadores e designers tão claramente quanto possível. Isto implica frequentemente a participação semanal (ou, no mínimo, quinzenal) na equipa do projeto.

No âmbito de um projeto, os consumidores contribuem para a definição das características necessárias e do planeamento do ciclo. Cooperam em testes de aceitação, aprovam ou rejeitam conclusões provisórias e contribuem para a direção global do projeto. Além disso, o envolvimento ativo do cliente resulta em melhores resultados ao utilizar o método cascata.

A equipa tem autoridade para fazer escolhas. #

Dentro de um ciclo, a equipa do projeto deve ter poderes para tomar as suas próprias decisões. Se a equipa do projeto não tiver essa autoridade, o modelo cíclico de gestão do projeto deixará de funcionar. Se for necessária uma aprovação constante dos superiores ao longo de um ciclo, isso pode resultar em estagnação. Além disso, os estrangeiros desconhecem frequentemente o que está a acontecer porque não estão ativamente envolvidos na equipa do projeto; isto dificulta-lhes a tomada de decisões racionais.

A produção do projeto (software) pode ser decomposta em componentes menores. #

A gestão de projetos cíclicos é um método de gestão de projetos em que partes do projeto são concluídas numa série de ciclos. Isto só é possível se o software que está a ser desenvolvido for decompor-se em vários componentes mais ou menos distintos.

Os requisitos de gestão para software de gestão de projetos são principalmente globais; a gestão não impõe requisitos diretos, concretos ou específicos. Uma das vantagens da gestão de projetos cíclicos é a estreita colaboração entre o cliente, designers, programadores e quaisquer testadores durante os ciclos. Se forem estabelecidos requisitos específicos e concretos no início de um projeto, isso limita a capacidade da equipa do projeto de usar o seu melhor juízo ao fazer escolhas de design. Revela-se que, no início, são apresentados numerosos requisitos relativos a um projeto que necessitam de adaptação e, por conseguinte, não devem ser (demasiado) firmemente estabelecidos no início.

O cliente entende as atividades. #

Se um trabalho técnico significativo que é difícil para o cliente compreender deve ocorrer dentro de um ciclo, existe o risco de o cliente não ser capaz de contribuir eficazmente para a equipa. Numa situação destas, o cliente tem muito pouco a dizer sobre as decisões de design que devem ser tomadas.

Existe um risco semelhante quando o cliente desconhece o progresso. Por exemplo, grande parte do trabalho pode ser dedicado à codificação, com pouca atenção dada à interface do utilizador. É fundamental que os clientes tenham uma visão suficiente da substância e da progressão de um ciclo, a fim de evitar serem empurrados para as linhas laterais.

Deve ser possível refazer os passos. #

Mesmo na gestão cíclica de projetos, as equipas ocasionalmente perseguem caminhos que acabam por ser incorretos. Deveria ser possível dar um passo atrás neste caso. Se um novo módulo criado durante um ciclo for considerado insuficiente, deve ser possível retomar o trabalho com o módulo anterior. Isto impõe requisitos, nomeadamente para o arquivamento e documentação dos materiais do projeto. CVS e Subversão são duas ferramentas úteis para estas tarefas (ver apêndice 3 para obter uma lista completa de ferramentas).

Juntamente com as competências de programação, os programadores devem poder interagir eficazmente com os clientes e vice-versa. Os membros da equipa devem ser pensadores intelectuais. A disciplina é necessária para continuar com o trabalho.

A organização em que o projeto é conduzido deve também prestar apoio suficiente a este modo de funcionamento. O rastreio de tempo, o arquivamento e os sistemas de agendamento são necessários para apoiar os projetos. Estes sistemas de registo proporcionam a abertura essencial para garantir uma repartição equitativa dos recursos através de projetos e períodos de tempo.

Priorização #

Os projetos devem ser devidamente importantes e os membros da equipa devem ser disponibilizados para eles. Exigir que os membros da equipa trabalhem em demasiadas tarefas simultaneamente é ineficaz. Se uma organização não estiver adequadamente adaptada ao trabalho baseado em projetos, a flexibilidade cíclica de gestão dos projetos poderá resultar num caos. Adicionalmente, a técnica de cascata beneficia de uma abordagem organizada à gestão do projeto (ver Wijnen, 2004, p. 111).

O diretor de uma empresa de desenvolvimento de software, que era mais visionário do que gerente, tinha uma grande ideia quase todos os meses e estava constantemente a iniciar novas iniciativas na sua empresa. Como resultado, os projetos mais antigos nunca foram concluídos e os trabalhadores trabalharam em até cinco projetos em simultâneo. O diretor carismático tinha acabado de ler um livro sobre o rápido desenvolvimento de aplicações (RAD) e estava muito entusiasmado com isso – especialmente o elemento ‘rápido’. Ele gravou as ideias fundamentais do RAD à fotocopiadora e depois esperava que todos começassem a trabalhar com estas noções. Afinal, foi uma excelente técnica.

Riscos de gestão de projetos cíclicos #

As técnicas cíclicas de gestão de projetos às vezes deixam tempo inadequado para executar as características necessárias. Como a duração do projeto é fixada, serão certamente adicionadas menos funções do que inicialmente previsto.

Embora esta seja uma preocupação legítima, também é inerente à abordagem da cascata. O passo decisivo da abordagem da cascata implica um exame aprofundado dos requisitos. Esta análise é suscetível de resultar numa melhor gestão do tempo. Muitas vezes, não é o caso na realidade, pelas razões acima referidas.

Além disso, as funcionalidades são omitidas nesta abordagem devido à falta de fundos para as desenvolver.

Os requisitos são tratados de forma pragmática nas abordagens de ciclo. Por exemplo, as necessidades nos ciclos podem ser classificadas utilizando os critérios MoSCoW (Stapleton, 2003) da seguinte forma:

  • Must Have: requisitos críticos do sistema
  • Deve ter: necessidades críticas que os utilizadores desejam verdadeiramente
  • Poderia Ter: necessidades desejáveis que podem ser facilmente ignoradas
  • Want to Have: requisitos que não serão cumpridos desta vez: requisitos que podem esperar até mais tarde

Independentemente de certas capacidades já não estarem disponíveis, os gestores de projetos DANS acreditam que o trabalho cíclico resulta numa maior satisfação do cliente do que a abordagem da cascata. Em todo o caso, as expectativas são regularmente controladas de forma mais eficaz, e os projetos produzem, rotineiramente, resultados que funcionam, mesmo que sejam menos complexos do que inicialmente previstos.

Compreender potenciais inconvenientes #

Uma desvantagem comumente citada do XP é que o poder significativo é transferido para programadores. Se abusar desta autoridade, poderão explorar a falta de conhecimento técnico do cliente a seu favor. Evitar este cenário precisa de um líder de projeto que possa cuidar dos interesses dos programadores e do cliente. Estes líderes de projeto ajudam os seus clientes na seleção e planeamento de ciclos, na compreensível compreensível sustentação técnica das suas seleções e na prestação de relatórios e administração.

Por último, outra desvantagem do XP é que a implementação do método requer uma curva de aprendizagem elevada para programadores, gestores e consumidores.