Quatro maneiras de fazer as metodologias Waterfall e Agile trabalharem juntas

Quer se trate de um compromisso de consultoria ou um projeto de software interno, os departamentos de TI, como a flexibilidade e produtividade de um projeto ágil. Mas, em vender o projeto para a alta gerência e da organização de finanças, conceitos cachoeira quase sempre ser introduzida como requisitos. Se você pensar muito sobre isso, ágil e cascata são filosofias quase contraditórias. Então, como você levá-los a trabalhar juntos? Em muitos projetos de software, particularmente aqueles que envolvem consultores, é um casamento bastante desconfortável. Ao contrário da música, os opostos não se atraem.

Lidar Tática # 1: gerenciamento de contas Vigoroso

Desde cachoeira envolve uma especificação fixa, bem como um orçamento fixo e cronograma, as saídas flexíveis (ou apenas vagamente definidos) para sprints vai significar uma quantidade razoável de sapateado. No entanto, isso pode funcionar quando “especificação” da cachoeira está mal definida (porque o cliente não sabe o que eles realmente precisam) ou maleável (porque um executivo decide antecipar as coisas). Mas cuidado: essa tática só funciona quando vigilante e agressivamente aplicada, forçando conversas sobre de-priorizar resultados e evitando âmbito-fluência ao longo do projeto.

Melhor Prática: gerenciar explicitamente as expectativas, por escrito, no início e no final de cada sprint. Além disso, têm um signoff cliente para cada recurso entregue durante o sprint.

Pior Prática: comportamento Head-in-the-areia, na esperança de que o problema só vai cuidar de si mesmo.

Lidar Tática # 2: extravaganza Change-fim

Em projetos cachoeira, os clientes são usados ​​para a idéia de ordens de mudança (e, claro, o seu contrato estipula-los, certo?). Então, use esse mecanismo cedo e muitas vezes. Em um $ 700K projeto estávamos envolvidos com, mais de 50 pedidos de alteração foram emitidos (embora houvesse apenas uma pequena superação). Os pedidos de alteração devem ser incluídos como adendas formal às declarações de trabalho (porcas) e incluir uma assinatura do cliente para que eles tenham impacto contratual.

Melhores práticas: prontamente emitir uma ordem de alteração para cada item vagamente especificado quando a imprecisão fica resolvidos. Pedidos de alteração deve incluir tanto cronograma e os impactos de custos, bem como detalhes de recursos.

Pior prática: Atraso ou mesmo ignorar a emissão de ordens de mudança, deixando-a “um entendimento verbal” que será rapidamente esquecido.

Lidar Tática # 3: fechamento explícita da descoberta

Em projetos de software típicas, uma fase inicial de custo fixo (que compreende 10 por cento a 25 por cento do esforço total do projeto) é dedicado ao processo de requisitos de descoberta. A saída desse processo é a declaração de requisitos funcionais do projeto. Mesmo que seja comum a descobrir muitos detalhes após essa primeira fase, estes novos itens não são o problema do implementador do projeto: eles são o consumo ou o problema da organização do cliente. Eles não devem ser aceites como requisitos de ligação sem um pedido de alteração. Infelizmente, tenho visto projetos que ainda estavam na descoberta após a implantação.

Melhores práticas: O documento de requisitos de projeto produzido pelo processo de descoberta deve incluir verborragia indicando que o conteúdo é a totalidade dos requisitos obrigatórios para o contrato, e incluem uma assinatura VP de cada departamento principal no departamento de consumo ou cliente. 

Pior prática: Deixe-o deslizar, aceitando novas exigências em qualquer fase do projecto, sem uma ordem de alteração. 

Lidar Tática # 4: Estipular um não-to-exceder para cada grande área funcional

As táticas até agora se concentraram em mecanismos de enfrentamento durante o projeto, quando já é tarde demais. Em vez disso, essa tática incide sobre o palavreado da porca, em uma tentativa de fundir apenas um princípio ágil num quadro cachoeira. Na seção de entregas do SOW, cada seção principal (normalmente entre 5 e 10) precisa ter as seguintes palavras no final:

Não obstante, o esforço total envolvido na implementação e implantação dessa área funcional não deve exceder X horas. Quando o esforço para esta área atinge 25 por cento, 50 por cento, e 75 por cento desse limite, o consultor pode notificar o cliente que uma revisão tarefa reunião é necessária. Durante essa reunião, o consultor irá informar o cliente sobre as variações do projeto ou descobertas que põem em perigo as entregas, e um caminho recomendado para a frente. Após essa reunião, o cliente irá emitir um pedido de ordem de alteração indicando a modificação desejada com os requisitos, programação, ou orçamento. 

Prática recomendada: Tome as pequenas coisas no tranco, mas solicitar uma reunião de revisão tarefa para qualquer tarefa que entra em status vermelho ou está bloqueado por mais de algumas semanas. A falha para colocar tarefas em status vermelho é uma ofensa resistente a altas temperaturas para o líder de projeto.

Pior prática: Omita essa verborragia do SOW, e durante o projeto evitar toda a questão até UAT.

Mas então…

Apesar de todas as táticas acima funcionam, de certa forma, eles estão tentando superar uma contradição. É claro que eu defendo projectos verdadeira ágeis, mas muitos uma organização cliente ou a sua gestão apenas não pode lidar com flexibilidade e insiste em listas de verificação de entregas fixas. Se assim for, você precisa saber que antes de assinar o contrato. Você pode ser melhor fora apenas furando com cascata pura e administrar as coisas dessa forma. Claro, você vai precisar para fazer subir o lance e alongar o cronograma, mas pelo menos você será gerir o risco de forma coerente. 

A causa raiz

Na maioria dos projetos de software personalizados, os requisitos não são especificados com antecedência com detalhes suficientes para apoiar verdadeiramente lances Cachoeira e gerenciamento de projeto apertado. Para projetos de CRM de qualquer complexidade, eu estou indo para ir tão longe como a dizer que é uma impossibilidade. Por quê? Quais são as chances de que:

Os usuários deverão indicar os seus requisitos com tal rigor e precisão que você não vai entendê-las?

Os usuários não vão mudar as suas mentes sobre detalhes e prioridades durante o curso do projeto?

canais do cliente, ambiente competitivo e regras de negócios interna não vai mudar durante a vida do projeto de CRM?

O cliente entende os seus dados, processos de negócios e integrações entre sistemas tão bem que não haverá nenhuma surpresa durante o projeto?

O cliente é capaz de prever todas as regulamentações governamentais, clientes estipulações contratuais, litígios pendentes e padrões internos que você precisa para cumprir?

Consequentemente, algum nível de descoberta estará acontecendo durante todo o projeto … o que significa que o seu lance terá que ter algum estofo para lidar com a “matéria escura” que está espalhado por toda a lista de resultados.

Próximo ler este: recursos de software CRM essenciais: um guia de compras mais experiente