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
    • Não é aceitável que o pessoal de 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
    • O produto sempre sai mais cedo se usar um cronograma
• 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 e um mal sucedido

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 a diretoria (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 objetivos do projeto, fazer cronograma inicial
• Também não apresentado para diretoria (sem compromisso)
• Após terminar especificações externas e design de alto nível, 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
  • Serve para informar o cliente
• Nível intermediário
  • Descreve todas os milestones do projeto
  • Inclui os pontos de review das atividades (especificações, outros documentos, etc.)
  • Para acompanhamento macro pelo gerente de desenvolvimento
• 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

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 da equipe (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

• Escolhe o coordenador do cronograma
  • Num projeto relativamente grande, esta tarefa é full-time
• Identifica as ferramentas a usar para o acompanhamento do cronograma
  • Caso a ferramenta seja nova, tempo deve ser alocado para treinamento no seu uso
• Preparar um conjunto inicial de atividades para o projeto
  • Esta lista será completada/modificada durante a reunião descrita a seguir
• 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
• 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
• O coordenador do cronograma coleta o resultado da etapa anterior
  • 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
• O cronograma de dependências é construído com a ferramenta escolhida
• O cronograma resultante é modificado em função de restrições de pessoal
• 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
• 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
• O cronograma é distribuído para todos os envolvidos
  • Cada responsável recebe também sua checklist personalizada
• Com tempo, é possível que algumas datas sejam mudadas no cronograma
  • Neste caso, as datas originais devem permanecer visíveis
  • Não mude as datas do cronograma se os responsáveis tiverem mesmo que uma pequenina chance de cumprir o prometido
  • 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
  • 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