Cronograma PAL (Liderança Ágil Planejada)

Ao adquirir um pacote de software, que fornece as satisfaz as soluções do negócio, e é uma solução melhor do que tentar escrever um código personalizado. Baseado nos negócios, foi encontrado uma ótima data para implementar o pacote. Esta data foi baseada no melhor período para os negócios. Por exemplo, em uma fábrica de doces, a implementação dos pacotes não será feita antes do dia dos namorados ou da páscoa.

O fornecedor do pacote estima quanto tempo normalmente o pacote leva para ser implementado na empresa. Nesta etapa, pode haver ou não uma ideia clara do que será necessário para a implementação do pacote. Não se sabe exatamente o que será requerido. A expectativa é que o pacote certamente será ideal e pouco complicado para ser implementado, além disso, está claro que deve ser implementado de uma só vez, não se pode implementar em pequenas partes. Pode ser possível alguma conversão de dados antes, mas a nova e principal funcionalidade deve ser implementada em apenas uma etapa e não em um período de diversas semanas.

O gerente sênior normalmente está entusiasmado com relação ao pacote e ansioso para utilizar as novas e melhores funcionalidades. Eles analisam a necessidades do negócio e definem o melhor período para colocar o sistema em produção (Go Live), a data é comunicada aos profissionais experientes (Subject Matter Experts - SME) e ao pessoal de TI. Sob uma breve investigação comum, os SMEs devolvem ao gerente sênior um relatório reportando que a data é impossível.

Estas são as pessoas que sabem especificamente o que deve ser feito. Elas são especialistas experientes e não podem ser ignoradas. Neste ponto, o gerente sênior pergunta: "O que deve ser feito?". Os SMEs são desafiados a dar um resumo de alto nível claro e conciso de como o pacote será implementado. O gerente sênior não está interessado em detalhes, eles precisam entender superficialmente as maiores atividades do projeto, como quem realizará e quanto tempo será consumido para concluir a tarefa.

A equipe se deparou com três desafios:

1. Encontrar uma estimativa razoável e com base no que deve ser feito e quanto tempo levará;
2. Estabelecer controles de implementação dos pacotes de software baseados em práticas ágeis, para fornecer um feedback se o cronograma pode ser atendido;
3. Harmonizar a implementação do pacote de software com as práticas ágeis estabelecidas.

O cronograma PAL (Liderança Ágil Planejada) pode mostrar claramente grupos de alto nível de esforço que pode ser entendido por todos. Observe a ilustração a seguir:

Cronograma PAL

Conflito de metodologias

No desenvolvimento do cronograma as equipes enfrentam um desafio: após trabalhar duro para converter em processos ágeis, a implementação dos pacotes são normalmente cascata. Cascata e ágil são parecidos como água e óleo, eles não se misturam. Como conciliar os dois modelos de processos? O objetivo é manter os processos ágeis, mas existe um prazo de entrega específico do Go Live para produção.

Conciliando as metodologias: Ágil vs cascata

A equipe de implementação é formada por SMEs que avaliam a existência de novas funcionalidades, especialistas de TI responsáveis pela infraestrutura e outros especialistas que podem ser indispensáveis pela natureza específica dos negócios. Esse pessoal deve reunir-se para determinar o que deve ser feito para conversão de um novo pacote de software. Expor as grandes atividades que devem ser realizadas por cada grupo e estimar o tempo ideal para que possam ser concluídas. Aqui o importante não é ter planos específicos, a ideia é manter em um nível superficial. Organizar em uma linha do tempo baseada nas datas fornecidas pelo gerente sênior. Para quem nunca implementou pacotes de TI, os fornecedores podem auxiliar a identificar componentes de alto nível que precisam ser considerados.

Comunicar ao gerente sênior que as datas podem ser definidas SOMENTE se o cronograma puder ser seguido. Caso tenha sido perdido o primeiro estágio de decisão para proceder para a próxima grande área, é possível saber rapidamente e, assim demonstrar o porquê a data não é alcançável.

Vamos especificar os aspectos deste planejamento.

Ele não é:

Não é um cronograma no MS Project, isto é improdutivo! Nem todas as tarefas são aplicadas, somente os principais grupos de atividades. A equipe deve identificar as tarefas para completar o agrupamento dentro do cronograma com alguma ferramenta como o Jira. Cada sprint é definida com tarefas a serem realizadas. Para a equipe de testes, os períodos de testes são definidos com os testes para serem realizados e completos naquela etapa. Isso deveria estar em uma ferramenta como Jira, Jama ou HP ALM.

Exemplo Microsoft Project

Todas as tarefas são identificadas na ferramenta. Isto é ágil.

Prazo de entrega

O cronograma não deveria ser um "caminho para a morte". É chocante a quantidade de vezes em que o cronograma é planejado, mesmo sabendo que é impossível ou até mesmo muito difícil para a equipe completa-lo. A proposta do cronograma é estimar de forma realista o quê, quando e quem deveria completar a entrega do projeto. A estimativa do cronograma é baseado na melhor sugestão da equipe.

Isto é: Uma representação visual requerida para do progresso do projeto.

Um dos elementos mais básicos da metodologia Ágil e 6 Sigma é que, sempre que possível, representações visuais são boas dicas para a equipe. Essa é uma característica do cronograma PAL, ser uma representação visual do que deve ser feito ao longo do processo de implementação, do início ao fim.

O que faz o cronograma tão poderoso é que ele mantém um sólido relacionamento entre as maiores atividades do projeto e quando elas devem estar finalizadas. A conclusão está relacionada às atividades documentadas que estão sendo monitoradas em ferramentas de projeto ágil. Além de monitorar individualmente as atividades em ferramentas selecionadas, os agrupamentos das atividades também são monitoradas no cronograma.

As equipes são codificadas por cores, existindo assim um reconhecimento imediato dos elementos do cronograma pelos próprios membros da equipe. Para terminar o cronograma com êxito, as equipes devem estar prontas para a próxima fase iterativa e incremental.

Cada fase está relacionada a critérios que devem ser apoiados por medidas e estatísticas identificáveis geradas nas ferramentas. Se as estatísticas não apoiam o movimento para a próxima fase o gerente sênior e a equipe saberão imediatamente que o cronograma pode estar em risco. Isso possibilita tomar decisões mais rápida do que o usual. Correções podem ocorrer imediatamente para avançar no cronograma ou voltar ao planejamento inicial.

O recurso que cria o planejamento de cada equipe, deve trabalhar cuidadosamente para fazer cronograma fácil de ler e entender. Isso envolve colocar somente as necessidades para conhecer as informações do cronograma. Em diversos pontos do projeto, quando necessário, um cronograma com informações mais detalhadas é publicado para a equipe. Ele é entregue quando necessidades específicas surgem, mas até lá, informações detalhadas não precisam ser consideradas.

Tempo da tarefa

Dono da tarefa: o cronograma pertence a toda equipe

Este é um princípio básico da metodologia ágil. Toda a equipe deve estar comprometida e se esforçar para terminar o trabalho no limite do cronograma, além de ser auto-organizada para apoiar e alcançar os objetivos do cronograma. É interessante que haja uma reunião formal para a adesão do cronograma. Se algum membro da equipe está preocupado com a hipótese do cronograma não ser realista, estas dúvidas devem ser abordadas. Se a equipe decide continuar com o cronograma em questão, seria uma boa ideia incluir os critérios que estão em dúvida nos critérios de prontidão que são especificados para cada grupo principal, possibilitando a gerência e a equipe avaliarem a questão no período específico se o critério não foi atingido e determinar um requisito de correção.

Proteção: o cronograma é um escudo para processos ágeis mal realizados

O processo ágil é composto por sprints com entregas específicas. Sprints específicas são mapeadas no cronograma e não existe segredo sobre o que é esperado em sua conclusão. Ao contrário do monitoramento comum das sprints, o cronograma possibilita que a equipe acompanhe o que foi planejado para o período a partir da perspectiva do projeto. Isso permite que a equipe acompanhe o status da sprint e do projeto.

O molho secreto: O planejamento é baseado em frequentes concessões de entregáveis completos que são quantificáveis e mensuráveis.

O segredo é que o cronograma é preenchido por entregas frequentes que são quantificáveis e mensuráveis. Todas as sprints e períodos de testes são listados com entregas específicas incluindo, no mínimo, todos os componentes da sprint atual além de todos os testes do período com os defeitos relacionados. No contexto, os períodos estão com círculos vermelhos. Este é o trabalho que deve ser completo durante este breve período.

Perceba que o trabalho a ser realizado é especificado, contudo, nem todos os componentes são detalhados e identificados no cronograma, ao invés disso, uma descrição em alto nível dos grupos é exibida. Por exemplo, na lista do primeiro período a equipe está concentrada na validação de funcionalidades relacionadas aos clientes, trabalhos, administração, contabilidade, mensagens e defeitos relacionados. Entregando uma descrição de alto nível, toda a equipe conhecerá a área de foco, além de estarem aptos a identificar o que deve, o que pode ser feito e o que esperar para a próxima iteração. Se existir alguma área incompleta, ela será documentada e então a equipe saberá que deverá retornar e fazer o que for preciso naquela funcionalidade. Fazendo estes agrupamentos, a equipe pode garantir que todas as áreas estão abordadas. Selecionando as áreas importantes e identificando cada uma, a equipe pode programar com confiança justificável que o período de tempo serão suportados. O último benefício é que as áreas não são perdidas inadvertidamente, todos os membros da equipe podem revisar o que foi listado. É incrível como às vezes algumas áreas ou componentes de áreas críticas são perdidos no primeiro esboço do cronograma.

As entregas são atendidas, ou não, pela data indicada. Monitorando essas entregas a equipe e o gerente sênior saberão se o cronograma está sendo seguido, além disso os dados estatísticos devem ser publicados diariamente e avaliados ao final de cada período. Se as entregas são constantemente perdidas ou entregas críticas estão incompletas a equipe terá um alerta de que o projeto não está no caminho certo.

Cooperação: A equipe está trabalhando colaborativamente

O projeto só pode seguir em frente caso todos os membros da equipe avançarem juntos. Este é um foco para atividades de equipe e da coordenação. Se um membro da equipe falha em realizar a entrega especificada para sua área, todo o projeto pode ser atrasado. Um exemplo é o de construção de sistemas de testes pela equipe de TI. Se o sistema não é construído corretamente e no prazo, os próximos períodos de teste e as sprints não podem começar. Se a infraestrutura da TI para integração não está posicionada e funcionando, os testes relacionados não podem ser feitos. Se a sprint com o desenvolvimento de entregáveis está incompleta, os testes relacionados atrasam.

Se os dados do sistema legado não são convertidos para serem utilizados nos testes, todo o projeto pode atrasar. Podemos verificar na imagem a seguir que o Core Billing Validation (Núcleo de validação de contas) não pode iniciar sem a conversão dos dados.

Diagrama de marcos lógicos

Diagrama de marcos lógicos: Critérios nos marcos do projeto monitoram a finalização em alto nível

O plano mostra marcos lógicos (milestones) frequentes. Esses marcos são pontos coordenados e existem como pontos específicos no tempo do cronograma. Grande parte dos marcos lógicos representam estágios com critérios relacionados. Se estes critérios não são alcançados a discrepância deve ser resolvida e corrigida.

Os critérios são aprovados pelas estatísticas geradas nas ferramentas utilizadas e em seguida mensurados e verificados para que os estágios sejam alcançados. A única diferença entre a sprint e os entregáveis do período de testes é que nos marcos os entregáveis são de níveis mais alto e compreensíveis.

Normalmente os estágios são pontos de decisão em que as equipes determinam se o projeto pode seguir para a próxima fase. A seguir vemos um exemplo de estágios prontos para produção (Go Live).

• Toda as funcionalidades são "ajustadas" para o negócio;
• Defeitos fora dos padrões são aceitos. Eles são maquiados ou são trabalhados;
• Todas os dados são convertidos e limpos;
• Critérios de desempenho são atingidos;
• Requisitos de segurança e conformidade são atingidos;
• Treinamentos está completo;
• Planos de transição são testados e prontos.

Todos os critérios prontos deveriam ser apoiados pelas estatísticas demonstráveis.

Comunicação: todas as comunicações necessárias deveriam ser incluídas

O cronograma é rico em comunicação. Tudo o que a equipe precisa saber para seguir em frente deve ser incluído.

Equipes são normalmente globais e diversificadas, transformando o cronograma em uma ferramenta valiosa para todos os recursos. Isso significa que cada membro da equipe, assim como o gerente sênior, entendem e apoiam o cronograma.

Nunca trabalhei em um projeto em que o cronograma não se transformasse na ferramenta de maior valor para toda a equipe.

Manter esta comunicação enriquece e agiliza o suporte.

Às vezes a comunicação específica deve ser publicada, então a equipe saberá exatamente o que e quando irá acontecer. Uma estrela pode ser vista antes do início do teste integração, teste paralelo e teste final de aceitação do usuário.

Estes três grupos de atividades são alcançados por uma diversidade de equipes. Na maioria dos projetos, este é um verdadeiro esforço global. A TI é responsável por construir sistemas e integrações; os especialistas da área são responsáveis pela validação da funcionalidade e os usuários finais (que normalmente são novos no projeto) são responsáveis pela validação da funcionalidade em seu espaço. Os recursos precisam ser bem conhecidos antes do início desta atividade.

Coordenação da equipe

Está validação normalmente é realizada em um dia inteiro de trabalho. Por causa da demanda de negócios conflitantes com o cronograma do projeto às vezes é necessário adicionar recursos ou até reorganizar o próprio cronograma. O ponto é que a representação visual, o núcleo da equipe poderá ter a certeza que a comunicação será amplamente distribuída, a fim de evitar eventos inesperados.

Na imagem a seguir, o dono das atividades do projeto mudou de uma equipe para a outra, então um cronograma detalhado deveria ser publicado para a equipe. É possível verificar o momento exato em que a transferência de propriedade foi feita, sendo assim um ponto crítico para a equipe portanto é religiosamente seguido. Esta é somente uma maneira oportuna de enviar, em outras palavras, não existem preocupações com este nível de detalhes até este momento. A equipe deve concordar antes do cronograma final detalhado ser enviado, na maior parte do tempo existem muitas negociações. Cada equipe é muito cuidadosa para garantir que possam alcançar isso. O recurso listado é a pessoa responsável por confirmar para a equipe que o planejamento detalhado está sendo iniciado. A equipe também precisa saber quem é o membro com os direitos de transformar isso em processo. Pelo fato da comunicação ser crítica, raramente foram observados desvios, uma vez que o final é publicado. Normalmente equipes são preparadas para este plano e desvios são um tanto disruptivos para outras atividades que já foram planejadas para este período. Por exemplo, mesmo que as atividades sejam completadas relativamente cedo, atividades subsequentes não são adiantadas.

Perceba que nenhum trabalho detalhado é fornecido para este cronograma. Novamente, uma abordagem pobre. Não fornece mais informações do que necessário. O trabalho que deve ser feito para auxiliar o cronograma é detalhado por equipes individuais. Por ser tão crítico para muitos recursos, normalmente uma aposta segura de que o trabalho detalhado foi cuidadosamente revisado. Nenhuma equipe deseja ficar constrangida pelos que falharam em fazer o cronograma. Nos preparativos para uma reunião de detalhamento das atividades, as equipes podem explicar sua intenção em completar o cronograma.

Transferência de propriedade

Como criar um cronograma PAL:

O nome do cronograma é Cronograma PAL (Liderança Ágil Planejada). Em uma simples explicação de como é realizado considere as atividades a seguir:

• Mapear os meses e semanas no cabeçalho do cronograma;
• Selecione uma data;
• Trabalhar no sentido contrário a partir desta data;
• Identificar as maiores áreas e equipes requeridas para a implementação. Colorir o código das equipes;
• Mapear os maiores esforços no caminho crítico. O caminho crítico é normalmente composto de áreas que são dedicadas pela funcionalidade dos especialistas;
• Estimar a duração de cada;
• Algumas áreas podem ser feitas em paralelo, outras requerem esforço sequencial;

• Mapear esforços paralelos, é uma atividade normalmente requerida para a conversão de dados, desempenho, infraestrutura, configuração e segurança;
• Garantir que as dependências sejam percebidas e levadas em consideração. Por exemplo, teste de integração não pode ser iniciado até que a infraestrutura esteja pronta;
• Estabelecer marcos históricos. Os marcos são normalmente o final ou início de uma próxima grande interação;
• Identificar os critérios para considerar cada marco como pronto ou completo. E assim que as equipes medem o que deve estar completo antes da próxima etapa sequencial iniciar. Isso mantém o objetivo claro e mensurável;
• Quase todos os esforços são iterativos e incrementais.

Mapa da equipe lean para o cronograma PAL:

• Mapear as sprints;
• Todas as sprints encaixam-se no cronograma "protegido" como identificado anteriormente;
• Identificar os pontos de coordenação ou marcos;
• O cronograma pertence a todas as equipes, elas monitoram os esforços para alinhamento do cronograma;
• Todas as equipes assinam o cronograma como "doável" se o critério dos marcos é atingido;
• Dados claros e mensuráveis devem apoiar a conclusão dos critérios de prontidão;
• Métricas são publicadas e revisadas diariamente.

Cada equipe controla seus próprios processos (sprints, plano de projeto, atividades de tarefas, testes, etc.) Os pontos de integração da equipe são amplamente identificados e o tempo é publicado por todos os membros da equipe, o tempo é identificado por dias e horas. A publicação da conclusão das atividades e transferências de propriedades de tarefas pertencem a uma pessoa.

Mais sobre "Identificar as áreas principais":

1. Configuração e testes iniciais (Iteração 1): Os especialistas da área (SMEs) podem revisar a estrutura do menu do pacote. Os especialistas responsáveis por cada área podem revisar a estrutura do menu das áreas pela qual são responsáveis. Somente após conhecer as funcionalidades legadas e enxergar o número de opções no menu, os especialistas podem dar uma estimativa aproximada para o tempo gasto para configurar e testar aquela área. Está é uma abordagem ultrapassada de iteragir e incrementar. Neste ponto é comum somente os principais clientes, produtos, etc. serem abordados, as áreas funcionais aqui são consideradas separadamente. Não existe integração de módulos considerados, os dados utilizados são criados pelo especialista da área, além disso, não são convertidos dados legados.
2. Validação de migração de dados (Iteração 1.1): Este esforço é frequentemente subestimado, a migração deveria estar entre os maiores esforços no cronograma. Isso significa que os dados deveriam ser migrados por testes funcionais, sistemas de testes, testes de integração e testes de aceitação pelo usuário final. O tempo para estas transferências deveriam ser considerados. Alguns desafios são:

1. Um para muitos: um elemento de dado legado é convertido para múltiplos elementos;
2. Muitos para um: muitos elementos de dados legado são convertidos para um elemento;
3. Novos dados: dados requeridos no novo sistema não existem no sistema legado;
4. Dados 'sujos': dados do sistema legado devem ser refinados antes da conversão;
5. Dados que estão em um arquivo legado são um elemento de configuração em um novo sistema.

3. Testes funcionais (Iteração 2): O núcleo das validações do novo sistema. Para cada área, todas as funcionalidades devem ser consideradas. É onde as equipes normalmente iniciam o "caminho feliz". Começando pelo início e prosseguindo por meio das funcionalidades até o final. O pessoal da TI normalmente deve ajudar nesta etapa, como a integração não é completa, então eles podem ter que pegar os dados de um ponto para o outro e assim estar hábil para completar todo o "caminho feliz". Os especialistas normalmente tem acesso universal, contudo, eles testam a funcionalidade e não a segurança. É aqui que a equipe identifica as regras e transações relacionadas. Conclusão e validação é apoiada por ferramentas estatísticas.
4. Sistema de testes de integração (Iteração 2.1): O novo pacote deve ser integrado com outro sistema. É importante identificar todas as integrações no cronograma PAL, assim como os testes relacionados que devem ser trabalhados para validar se a integração está funcionando. É um erro terrível não identificar todas as integrações no cronograma, a validação é apoiada pelas ferramentas estatísticas.
5. Teste de desempenho (Iteração 2.2): Como os especialistas prosseguem por meio dos testes funcionais, problemas de desempenho deveriam ser inserido nos testes de software como um defeito. Estes defeitos devem ser abordados. Os especialistas devem especificar qual o desempenho é necessário. Ferramentas de software para medir o desempenho deveriam ser utilizadas para provar que os critérios de performance foram alcançados. As estatísticas são apoiadas pela ferramenta e são publicadas diariamente.
6. Integração de sistema (Iteração 2.3): Este é o trabalho que a TI deve completar para habilitar a execução dos testes de integração. Todos os testes de integração deveriam ser "caixas pretas", e os especialistas da TI não deveriam fazer nada de excepcional para fazer o trabalho de integração. O sistema deveria funcionar sem qualquer ajuste solicitado pela equipe da TI. Está etapa é apoiada por atividades identificadas nas ferramentas.
7. Segurança (Iteração 1-4): Esta é outra área frequentemente subestimada. Após identificadas as funções requeridas e as transações anexadas a estas funções os usuários são alocados às funções. Isso é iterativo e incremental, a chave é que com cada grupo de iteração no cronograma a segurança é finalizada mais especificamente e globalmente. O progresso a partir das definições de alto nível de funções com transações relacionadas para a definição de funções no sistema e testados pelos especialistas para o usuário final, os quais estão sendo testados com suas funções específicas. A equipe de segurança precisa estar à frente dos usuários que serão testados. Isso também é apoiado por atividades requeridas para conclusões inseridas nas ferramentas. As estatísticas apoiam as conclusões.
8. Teste de aceitação do usuário final (Iteração 4): Usuários finais podem ser pessoas que estão em diferentes lugares ao redor do país ou do globo, trabalhando pela empresa. Eles não são especialistas, eles são as pessoas que atualmente fazem a empresa funcionar. Este teste é crítico, ele atinge dois objetivos: a funcionalidade é validada por lugares específicos e o usuário final recebe conhecimento inestimável sobre como o sistema funciona. Contudo, isso não deve ser confundido com treinamento, que é separado.
9. Plano de corte e execução (Iteração 1-4): Enquanto a equipe procede com a migração de dados, eles podem iniciar a construção de um plano de corte. Fazendo isso eles praticam o planejamento muitas vezes. Quando finalizado, a TI e os especialistas de negócios podem construir esforços adicionais requeridos pelo atual plano de corte.

Com experiência em gerenciamento de projetos, eles podem desenhar frequentemente rascunhos do cronograma PAL com uma pequena ajuda. Os líderes especialistas podem materializar o esforço e a duração. A equipe de TI também é responsável pela área de TI.

Depois de fazer o primeiro rascunho, as equipes podem se reunir com o gerente sênior, discutir o cronograma e concordarem se a data é ou não razoável.

Uma palavra de cuidado

O cronograma PAL é iterativo e incremental. Cada fase do cronograma é construída baseada na fase anterior. Cada área do processo identifica tarefas que são incrementalmente mais difíceis.

• Conhecer o princípio 80/20. A ideia é não ser enganado pela ideia de ter completado mais trabalho do que realmente foi feito. Ao final 20% das validações funcionais são normalmente mais complicadas e levam mais tempo para completar do que as primeiras 80%.

• Implementar o "Caminho Feliz" o mais rápido possível. Isso significa mover do início do processo de negócio para o final do novo pacote. Como funciona se está tudo certo? Quando se pode avançar na funcionalidade do início ao fim, e então trabalhar incrementalmente nas validações adicionais da funcionalidade.

• Para funcionalidades muito complicadas, escrever detalhadamente testes compreensíveis antes de codificar. Também é necessário estabilizar os dados para estes testes, é comum as equipes cometerem este erro. Tenho ouvido em quase todos os projetos: "É uma forma muito complicada de se explicar…", baseando-se em explicações verbais de como a funcionalidade deveria funcionar é comum. Uma abordagem muito melhor seria configurar testes com dados esperados, realizar ações específicas para a funcionalidade testada e prover resultados esperados. Isso pode ser feito efetivamente em uma planilha. Existem muitos benefícios nesta abordagem. Muitas vezes, especialistas em assuntos diferente podem ter expectativas diferentes de como o sistema deveria funcionar. O acordo seguido na planilha elimina o mau entendido. Se os dados não estão estáveis eles podem afetar os resultados esperados. Além disso, criando ou "consertando" elementos de dados para um número específico, especialistas e desenvolvedores aprendem sobre o impacto dos dados e das funcionalidades. É muito comum que elementos adicionais sejam adicionados para estabilização das rotinas porque as equipes não sabem como considerar a criação da planilha de testes neste período. Contudo, é claro que a planilha é um artifício ágil suportado na ferramenta.

• Publicar ferramentas estatísticas diariamente. Dar significado, informações acionáveis nas estatísticas. O que está ou não feito. Neste ponto as atividades de baixo nível são associadas com o cronograma PAL. Todas as atividades deveriam ser apoiadas na ferramenta. Se as atividades de baixo nível na ferramenta não estão completas, o cronograma PAL está em risco. As melhores estatísticas são normalmente visuais, então é interessante incluir dicas visuais nas estatísticas (Gráficos burn-down, de barra e pizza). Todas as ferramentas têm característica que possibilitam a equipe se direcionar com detalhes por trás dos gráficos. Isso possibilita a equipe saber facilmente o que, exatamente, foi feito.

• Muitas ferramentas tem painel de controle, no qual as equipes podem monitorar o progresso. Garantindo um painel de entrega a as informações que a equipe precisa para se manter no caminho correto.
• Não use o e-mail para descrever ou ajudar as atividades das equipes como: juntar os requisitos, testes ou monitoramento de defeitos. Quase sem exceção, e-mail é um problema para toda a equipe de implementação. Logo no início do projeto, os membros da equipe devem ser educados no que será aceito por e-mail e quem deve ser copiado, membros da equipe devem entrar em acordo nessas definições. As diretrizes devem ser postas de forma consistente, requerimentos devem ser especificados no desenvolvimento do software e não no e-mail. Testes devem ser especificados nos testes de software e não no e-mail. Este software normalmente é robusto e fornece recursos de documentação e monitoramento fantásticos, além de fornecer estatísticas para exibir o status do projeto. E-mails podem paralisar a equipe de cima para baixo, use o e-mail com moderação.
• Testar o software é essencial. As métricas para o status do projeto vem do software. Se o requisito, atividade, teste, etc. não estiver representado, o software não será válido. É preciso que as métricas sejam observáveis para validar a conclusão. Atividades da Sprint são documentadas. Testes são documentados. Quando a equipe demonstra que as métricas suportam uma provável conclusão de critérios prontos a gerência pode ver que o cronograma PAL pode ser dependente.

Palavra final

Para concluir, juntar as pessoas, fazer um plano, apoiar todas as atividades da equipe com demonstrações estatísticas, olhar as estatísticas diariamente para garantir que o plano está sendo aderido. O que foi alcançado sem surpresas. É claramente perceptível estar no prazo e entrar em produção (Go Live) na data prevista.

Sobre a autora

Leigh Koetter é Six Sigma Master Black Belt e Certificada em Gerenciamento de Projeto com +25 anos em funções de liderança para a Fortune 500 implementações de software global. Especialidades: Gerenciamento de Programas, Processos Ágeis e Metodologias, Gestão da Qualidade, Gerenciamento de Testes SAP, Integração SAP HP ALM, Gerente de projetos SAP, Gerente de Testes Workday e Testes Automatizados.