Planejamento de Cronogramas de Desenvolvimento

A Importância do Cronograma

O cronograma é importantíssimo no desenvolvimento de software por três motivos básicos:

• É a única forma de estabelecer uma data final para a entrega do produto. A data de entrega deve ser informada pelo desenvolvimento ao resto da empresa, já que outros setores da empresa devem fazer planos sobre o produto em função desta data. Esses outros setores incluem o marketing, a área de vendas e a área financeira e a área de produção, primordialmente. Essas áreas não podem ficar às cegas com respeito ao lançamento do produto. A data final de disponibilidade do produto informada ao cliente é de primordial importância e a não entrega do produto nesta data pode implicar em sérias dificuldades para a empresa. Não é aceitável para o resto da empresa que o desenvolvimento tenha a atitude: "O produto estará pronto quando terminarmos".
• É a única forma de manter controle sobre o andamento do projeto de desenvolvimento. O progresso do desenvolvimento não pode ser acompanhado se não tiver um plano (cronograma) contra o qual medir o progresso. Durante o desenvolvimento, o cronograma é a alma do acompanhamento e permite vislumbrar áreas problemáticas com antecedência e tomar atitudes para resolver tais problemas.
• O compromisso do pessoal de desenvolvimento com o cronograma formal aumenta a produtividade dos envolvidos.

Resumindo, o cronograma do projeto diz respeito a obter o controle do projeto. Sem cronograma, não há controle possível. O cronograma faz a diferença entre um projeto bem sucedido (com lucro) e um mal sucedido (com prejuízo).

Algumas Regras e Dicas sobre Cronogramas

O cronograma deve

• Ser muito bem pensado (não feito "nas coxas")
• Obter o compromisso dos participantes
• Ser agressivo mas factível

Quando fazer o cronograma?

• Estabelecer um cronograma de alto nível desde o início
  • Não apresentado para o cliente (sem compromisso)
  • Ajuda a manter o ritmo
  • Cronograma de curto prazo (4 semanas) sempre deve existir, mesmo que não haja cronograma completo definitivo
• Após terminar os requisitos do projeto, fazer cronograma inicial
  • Também não apresentado para o cliente (sem compromisso)
• Após terminar o design de alto nível (design arquitetural), apresentar cronograma definitivo
  • Deve receber aprovação de todos os envolvidos, no que diz respeito à parte de cada um
• Nunca apresentar cronograma detalhado final até que a definição do que deve ser feito esteja completa e bem definida. Se chegar à conclusão de que não se consegue fazer um cronograma detalhado, é porque ainda não se sabe o que deve ser construído.

Níveis de detalhamento de cronogramas

• Alto nível
  • Uma única página, mostrando major milestones para o cliente
• Nível intermediário
  • Descreve todas as atividades do projeto (Requisitos, Análise, Projeto, etc.) para cada componente
  • Inclui os pontos de review das atividades (através dos artefatos)
  • Para acompanhamento macro pelo gerente.
• Baixo nível
  • Para acompanhamento detalhado pelo gerente e pelos membros da equipe
  • Deve descer a nível de dias. Atividades de mais de uma semana são quebradas

Cronograma para documentos

• Para documentos, incluir as seguintes etapas no cronograma: preparação, revisão, update, approval. Durante o update de documentos, usar marcas de revisão para facilitar a etapa de approval.
• Documentos sujeitos a cronogramação: Requisitos, Modelos conceituais, Design arquitetural, plano dos manuais, os manuais.

Como estimar a duração de uma atividade

• Quebre as tarefas em pedaços pequenos, exibindo a Work Breakdown Structure (WBS) e estime a duração de cada pedaço.
• Os pedaços devem ter, no máximo, 1 semana de duração.
• Utilize dados históricos de produtividade nas várias fases de projeto para estimar as durações.
• Discuta suas estimativas com outras pessoas experientes.
• Não planeje em usar horas extras.
• Levante os feriados e férias que ocorrerão durante as atividades.
• Especifique a duração em dias de trabalho (não semanas).
• Lembre que a produtividade de pessoas menos experientes é menor.
• Inclua tempo de treinamento para a aquisição de conceitos novos.
• Lembre que certas atividades paralelas levam tempo e deverão ser feitas pelas pessoas do time (reviews de design, auditorias de código, reuniões de acompanhamento).
• Lembre de incluir tempo para viagens.
• Lembre que certas tarefas "burocráticas" precisam ser feitas (check-in/check-out de código na ferramenta de controle de versão, etc.)
• Inclua tempo de interrupção para suporte pós-venda deste ou de outros produtos.
• Dê uma segunda olhada demorada nas atividades que estiverem no caminho crítico. São elas que determinam o prazo final de entrega.
• Inclua um buffer de contingência em cada atividade. Sugere-se 20% para atividades normais e 50% para atividades com conteúdo tecnológico novo e aparentemente complexo.

Cronogramas de dependências versus cronogramas de recursos

•  Inicie com um cronograma de dependências de tarefas, sem incluir restrições de pessoal disponível.
• Quando o cronograma de dependências está pronto, inclua as restrições de recursos para obter o cronograma final. Isso pode ser delicado e difícil, já que as produtividades de pessoas não são iguais e a realocação de pessoas de uma atividade para outra pode mudar as durações da atividades.

Buffers de contingência

• Inclua buffers planejados de contingência. Não coloque o buffer de contingência total no final do projeto. Distribua-o ao longo das atividades.
• Fins de semana são um outro tipo de buffer de contingência. Fazer com que uma atividade termine na sexta-feira é preferível, quando possível, já que o fim de semana age como buffer de contingência natural. Não se espera que o fim de semana seja usado com frequência, mas pode ser necessário para atividades que estão no caminho crítico.
• Não planeje em usar horas extras: elas acontecerão de qualquer forma. Cuidado com burnout.
• Só use feriados e férias como buffer de contingência em casos muito críticos envolvendo grandes contas.

Checklist de projeto

• A ferramenta usada no acompanhamento do cronograma deve gerar uma checklist individualizada para cada membro da equipe. Essa checklist é útil durante as reuniões de acompanhamento do projeto.
• A checklist deve incluir:
  • A pessoa responsável pelas atividades da checklist
  • A lista de atividades
  • As atividades predecessoras (dependências) de cada atividade
  • Datas planejadas de início e fim de cada atividade
  • Datas realizadas de início e fim de cada atividade

As Etapas na Elaboração de um Cronograma

1. Escolhe o coordenador do cronograma. Num projeto relativamente grande, esta tarefa é full-time.
2. Identifica as ferramentas a usar para o acompanhamento do cronograma. Caso a ferramenta seja nova, tempo deve ser alocado para treinamento no seu uso.
3. Preparar um conjunto inicial de atividades para o projeto. Esta lista será completada/modificada durante a reunião da etapa 4.
4. Reunião de planejamento de cronograma. Nesta reunião, as atividades da lista inicial é completada num nível alto e um dono é atribuído a cada atividade. Os donos de atividades recebem a incumbência de identificar mais detalhadamente todas as sub-atividades envolvidas, a duração de cada atividade, as dependências (predecessores) de cada atividade. Para cada atividade, as suposições (taxas de produtividade, por exemplo) usadas para chegar à duração prevista devem ser listadas. Finalmente, o dono de cada atividade sugere quem deve ser o reviewer da atividade. Uma outra tarefa importante a ser realizada nesta reunião é de escolher os percentuais de buffers de contingência a usar.
5. Cada dono de atividades deve realizar as tarefas mencionadas acima. Os donos de atividades devem entender que o planejamento do cronograma é uma tarefa de alta prioridade.
6. O coordenador do cronograma coleta o resultado da etapa 5. Os resultados são examinados e criticados com respeito a dependências, suposições nas quais a duração foi estabelecida, recursos especiais necessários. É importante que o nível de detalhamento permita estabelecer atividades de não mais do que 1 semana de duração. Caso a equipe de desenvolvimento seja relativamente pequena, pode-se juntar todos numa sala para juntar e examinar esta informação.
7. O cronograma de dependências é construído com a ferramenta escolhida.
8. O cronograma resultante é modificado em função de restrições de pessoal
9. O cronograma resultante frequentemente será demasiado extenso. Os caminhos críticos são examinados na tentativa de encurtar a data final de entrega do produto.
10. O cronograma final é examinado e aprovado por todas as pessoas envolvidas numa reunião geral. Nenhum cronograma deve ser aceito que não tenha a aprovação (commitment) dos responsáveis.
11. O cronograma é distribuído para todos os envolvidos. Cada responsável recebe também sua checklist personalizada.
12. Com tempo, é possível que algumas datas sejam mudadas no cronograma. Neste caso, as datas originais devem permanecer visíveis.
13. Não mude as datas do cronograma se os responsáveis tiverem mesmo que uma pequenina chance de cumprir o prometido.
14. Não mude a data final de entrega do produto com frequência. Uma única mudança por ano é melhor do que a cada 3 meses.
15. Só mude uma data no cronograma se todas as condições abaixo forem satisfeitas:
     
    • O cronograma original realmente não é mais factível;
    • Os problemas que causaram o desvio do cronograma são conhecidos e soluções razoáveis são conhecidas;
    • O novo cronograma proposto é factível;
    • O novo cronograma proposto tem o commitment dos envolvidos.