Desafios à abordagem ágil em projetos governamentais

Uma discussão anterior sobre o Agile aqui teve boas respostas, especificando o que é crítico para o sucesso da implementação da metodologia Agile no desenvolvimento de software. A maioria dos pontos foram os desafios organizacionais e de gerenciamento típicos, mas um ponto me preocupa e é que o cliente deve estar envolvido durante todo o processo.

O cliente é a única coisa que você não pode controlar de forma realista; talvez seu modelo de negócios o direcione para o trabalho contratado pelo governo, por exemplo, onde um contrato intensamente restrito obriga a empresa a:

• Forneça recursos X exatamente como solicitado

• Os pedidos de recursos serão lançados sobre um muro, não nos incomode, não queremos ouvi-lo.

• Não há um conceito de prioridade de recurso na mente do cliente, todos são importantes ou não teríamos pedido por eles.

• O projeto custará nem mais nem menos que Y, independentemente de excedentes ou prazos.

• Prazo absoluto, rigoroso, final e inegociável para a entrega completa de todo o trabalho.

Nunca trabalhamos com esse cliente antes, mas o dinheiro do projeto é bom demais para deixar passar. Nós precisamos deste trabalho.

Eu vim aqui e trabalhei HARD para alterar processos internos para avançar em direção ao desenvolvimento ágil e aqui não sei como conciliar onde esse projeto se encaixa em nosso novo processo. Eu nunca tive o luxo de um gerenciamento aberto de mente aberta, que confiava em mim para liderar a equipe de desenvolvimento e os processos por esse caminho, e agora que estamos aqui, não posso dizer honestamente a mim mesmo que esse projeto será realmente realizado de uma maneira diferente. Maneira ágil. Sinto que a gerência confiou em mim para liderar esse caminho e que os decepcionei porque essa situação em que estamos agora exige claramente o Waterfall. Tenho medo de perder a confiança deles se voltar agora.

Outras respostas como a aqui dizem que Agile é impossível com esse tipo de cliente, você concorda? Algum de vocês já passou por uma situação semelhante e fez funcionar? Quais estratégias você implementou para fazer o Agile acontecer com sucesso?

Acho que a primeira coisa a perceber é que há uma diferença entre ser ágil e ser ágil. A implantação lenta de técnicas e características ágeis - equipes multifuncionais, planejamento adaptativo, entrega evolutiva / incremental, iterações com intervalos de tempo e até a introdução de conceitos do Lean são muito diferentes de introduzir a Programação Extrema, Scrum ou Crystal.

Você mencionou explicitamente o envolvimento do cliente. Sim, muitas das metodologias ágeis exigem o envolvimento do cliente, mas não é necessário ser ágil. Em todos os programas relacionados ao governo / defesa, sempre tive um gerente de programa ou projeto que era o ponto de contato com o cliente. Essa pessoa se torna a "voz do cliente". Pode ser mais lento quando eles teleconferem, enviam e-mails ou telefonam e esclarecem, mas você pode ter uma única pessoa (ou um grupo, se também tiver vice-diretores), que é o representante do cliente da sua equipe. É certo que não é exatamente o mesmo. Mas não é ser ágil sobre ser flexível e responder às mudanças?

Você também menciona alguns conceitos-chave: requisitos predefinidos, solicitações de recursos "descartadas", falta de priorização porque "todas são importantes" e projetos de custo fixo e / ou cronograma fixo. Cada um deles pode ser tratado de maneiras diferentes.

Se você acha que tem todos os seus requisitos antecipadamente, é provável que não tenha. Os requisitos mudam. Só porque você tem uma especificação "finalizada e desconectada" não significa que ela esteja definida. Dado o documento de requisitos que você possui, capture-os como se sentir confortável e / ou da maneira especificada no contrato e entregue os requisitos, o design e a arquitetura. Além disso, veja se você pode tratar esses documentos vivos (um documento de design que vi hoje no trabalho é rotulado como Revisão G, o que significa que está na 8ª atualização). Pergunte sobre o quanto você pode deixar como TBD em qualquer iteração e quanto precisa ser corrigido agora - pode haver alguma coisa para dar e receber.

Seja ágil com sua documentação. Não duplique esforços entre "o que sua equipe deseja" e "o que o cliente deseja". Por exemplo, se seu cliente deseja uma especificação de requisitos de software tradicional e sua equipe deseja usar histórias de usuário, tente se adaptar a um SRS tradicional e use itens de ação e uma lista de itens de ação contínua em vez de histórias de usuário para que você não perca tempo formular "o sistema deve ..." e "deve poder fazê-lo porque". Isso exige disciplina da equipe, no entanto, para se adaptar às diferenças entre os projetos. Capture problemas nas reflexões.

Após o desenvolvimento, você pode executar 5 ou 6 iterações e convidar seu cliente para o seu estabelecimento para ver um subconjunto de sua implementação. Enxágue e repita esse processo. Não é o envolvimento constante exigido por algumas metodologias, mas você tem a vantagem da alta visibilidade. Se o seu cliente recusar, pelo menos você tentou. Se eles dizem que sim, você pode esclarecê-los sobre a agilidade. Em um projeto em que participei, o cliente visitava o site a cada poucos meses (3-5 meses, geralmente). Eles nos assistiam ao teste de controle de qualidade, discutiam preocupações com engenheiros e negociavam com o escritório do programa / projeto. Foi uma oportunidade para todos chegarem à mesma página.

Testes e manutenção acontecem da mesma forma que em outros projetos ágeis. Crie seus procedimentos de teste e documente defeitos da maneira apropriada, acompanhe métricas por obrigações contratuais e documente os resultados dos testes. Se você deseja seguir o TDD, vá em frente. A integração contínua é outra boa ideia. Durante as reuniões de status do projeto, seu gerente de projeto pode usar essas informações para dizer "implementamos requisitos de N, temos testes M, testes X aprovados" e atualizamos a saúde e o status do projeto para as pessoas com o dinheiro.

Falando em dinheiro, temos o problema de custo fixo e / ou horário fixo.

Lidar com um horário fixo é bastante simples. Dado seus requisitos, você sabe quantas iterações pode ser concluída. Sua carga de trabalho para cada iteração é praticamente definida em termos de recursos para implementar, testar e integrar. Pode ser difícil, mas não é impossível interromper os recursos e atribuí-los às iterações com antecedência. Isso remonta ao meu argumento sobre convidar o cliente - se você tiver um ano e estiver usando iterações de duas semanas, talvez convide o cliente trimestralmente (e convide-o a cada trimestre) e mostre a eles os resultados do trabalho anterior. Deixe que eles vejam sua priorização de requisitos, seus planos futuros e como você está agendando.

Lidar com um orçamento fixo é semelhante. Você sabe quanto tempo tem, quantos recursos possui para o projeto, quanto custam e, portanto, quantas horas todos podem trabalhar por iteração. É apenas uma questão de garantir que todos os acompanhem com cuidado. Se sua empresa pode consumir o custo de horas extras, faça isso. Caso contrário, certifique-se de que todos trabalhem por um período de tempo apropriado e use boas habilidades de gerenciamento de tempo e tempo para manter todos produtivos. Horas mais produtivas é o que você precisa para manter os custos baixos - entregue mais documentos e software de valor agregado, sem o custo de reuniões e despesas gerais.

Por fim, não se trata necessariamente de ser ágil, mas de aplicar as coisas que tornam o ágil bom e ser ágil. Seja capaz de responder a mudanças nos requisitos, seja capaz de fornecer software frequente, mesmo que o cliente não o deseje, apenas produza documentação de agregação de valor (junto com o que você é contratualmente obrigado a produzir) e assim por diante.

Sim, o ágil não é apropriado para esse projeto, porque parece que os requisitos já foram feitos e fixados em pedra, provavelmente o resultado de anos de análise por consultores caros, reuniões de comitês e compromissos políticos. O Waterfall funciona bem se o cliente é tão disciplinado que pode lhe dizer por escrito exatamente o que deseja. Eles podem estar errados, mas pelo menos você o tem por escrito, e você será pago se o entregar. (Isso não diz nada sobre a satisfação do cliente, é claro. É provável que você entregue algo que ele realmente não precisa.)

O Agile foi criado para resolver um problema que você não tem: risco devido à incerteza nos requisitos.

É verdade que o cliente pode solicitar solicitações de alteração, mas você segue um dos dois caminhos:

1. O dinheiro foi tão bom que você sabe que pode absorver uma quantidade X de novos recursos em várias etapas do projeto e ainda sair sem perder a camisa ou
2. Você deixa claro para o cliente desde o início que, devido à negociação de um preço apertado, cada solicitação de novo recurso gerará uma requisição de mudança com um preço que precisará ser aprovado por ele, com um pedido de compra em anexo (ou alteração de o pedido de compra original) para que você possa implementá-lo. A requisição de mudança explicitará todos os impactos na funcionalidade ou no cronograma. Se eles disserem que o prazo não pode ser mudado, os pedidos de alteração se tornam exponencialmente mais caros à medida que o projeto avança, porque é mais caro mudar as coisas mais tarde.

O relacionamento parece muito mais amigável na situação 1, mas o fato é que é muito raro encontrar departamentos de compras que não o pressionem pelo preço, então na maioria das vezes você está na situação 2. Isso significa que o relacionamento é conflituoso, mas se você deseja sobreviver nos negócios, é preciso ser bom em gerenciar o relacionamento, mantendo-se firme. Essa é uma grande parte do trabalho do gerente de projetos.

Parece que você pode estar na situação 1, o que é bom. Eu imagino que os contratos do governo sejam o único lugar onde eles não se importam com dinheiro, porque, afinal, eles não estão gastando seu dinheiro, estão gastando seu dinheiro.

... trabalho contratado pelo governo, por exemplo, onde um contrato intensamente rígido obriga a empresa a:

Primeiro. É estrito. Mas não é inflexível. Simplesmente requer atenção aos detalhes e uma longa e longa sequência de pedidos de alteração.

As agências governamentais são realmente ágeis de maneira lenta e ineficiente. Você precisa escrever (e negociar) requisições de mudança formais e detalhadas o tempo todo.

Forneça recursos X exatamente como solicitado

Até modificado por uma requisição de mudança.

Os pedidos de recursos serão lançados sobre um muro, não nos incomode, não queremos ouvi-lo.

O canal de comunicação é a requisição de mudança. Impacto do orçamento e cronograma.

Não há um conceito de prioridade de recurso na mente do cliente, todos são importantes ou não teríamos pedido por eles.

É difícil contornar isso. Mesmo empresas não-governamentais que gastam muito dinheiro em "análise de requisitos" não querem saber que uma grande e achatada pilha de requisitos não sobrecarregada por informações de prioridade e troca está incompleta. Eles pagaram um bom dinheiro para obter todos os requisitos. Como você pode querer mais informações?

Este é um problema difícil.

O projeto custará nem mais nem menos que Y, independentemente de excedentes ou prazos.

Exceto pelos pedidos de alteração. Que modificam Y e o prazo.

Prazo absoluto, rigoroso, final e inegociável para a entrega completa de todo o trabalho.

"inegociável" geralmente não é verdadeiro. É negociável. É apenas doloroso negociar.

A parte importante da negociação com agências governamentais é o fato de que você precisa de "evidências em nível de advogado" para suas alterações de custo e cronograma. Algumas apresentações técnicas cuidadosas com um bom slide em power point não são "evidências". Você precisa de muita documentação para defender seu caso.

O pessoal do governo precisa fornecer evidências inatacáveis ​​de que eles fizeram tudo ao seu alcance para tornar isso o mais barato e eficaz possível. Eles sabem que toda decisão é repetida na imprensa pública e examinada em retrospectiva.

A complexidade do desenvolvimento de software e o aspecto "trabalho de segunda-feira da manhã" do trabalho do governo, depois do fato, os deixam relutantes em fazer alterações no contrato sem evidências esmagadoras.

Isso dificulta uma abordagem adequadamente ágil.

"Indivíduos e interações sobre processos e ferramentas" é difícil. Você não está trabalhando com um indivíduo, mas com um representante do governo cujo trabalho é limitado pelo processo.

Em um projeto como esse, eles amarraram suas mãos no escopo, nos recursos e no tempo. A única coisa que resta para gerenciar é a qualidade. Tão...

Você não obterá a maior parte dos benefícios de uma abordagem ágil que poderia, mas pode fazer o possível para mitigar os riscos de qualidade e poder informar o cliente sobre os problemas mais cedo ou mais tarde.

Portanto, seja o mais ágil possível:

1. Siga os requisitos e priorize-os melhor em risco técnico. Defina os requisitos priorizados como sua lista de pendências.
2. Trabalhe no backlog em sprints - projete, teste e codifique os recursos do sprint. Está faltando interação com o cliente, portanto, o documento de requisitos deve representar o cliente para esta atividade.
3. Convide o cliente para cada revisão do sprint - eles podem dizer não, mas podem dizer que sim. E você receberá feedback mais cedo ou mais tarde.

Se você começar a correr contra o prazo, poderá mostrar o que está feito, e talvez nesse momento o cliente, sabendo que ele não vai conseguir tudo, priorize o suficiente para lhe dizer o que ele quer. Você também deve fazer as coisas mais arriscadas, o que significa que as tarefas no prazo final são as mais fáceis de realizar em horas extras.

Eu acho que esse tipo de cliente não é a norma. Você está lidando com um grupo que já havia solicitado projetos semelhantes antes, para que eles saibam exatamente o que desejam. Você nunca menciona que suas especificações serão alteradas.

Forneça recursos X exatamente como solicitado

Tenho sorte se eu fornecer o recurso X vagamente, conforme sugerido, e estar pronto para alterá-lo a qualquer momento.

Os pedidos de recursos serão lançados sobre um muro, não nos incomode, não queremos ouvi-lo.

Se você sabe o que eles querem, vá construí-lo.

Não há um conceito de prioridade de recurso na mente do cliente, todos são importantes ou não teríamos pedido por eles.

Você não pode perder neste. Construa-os como achar melhor.

O projeto custará nem mais nem menos que Y, independentemente de excedentes ou prazos. Prazo absoluto, rigoroso, final e inegociável para a entrega completa de todo o trabalho.

Isso é difícil, se você nunca construiu um projeto para o governo. Se você tiver algum histórico, poderá determinar se pode entregar. Isso não significa que eles não pagam bem (são famosos por pagar US $ 50 por um martelo de US $ 10) ou têm expectativas irracionais. Com essas especificações, alguém da sua equipe deve agir como cliente e aprovar o trabalho em comparação com as especificações. Mesmo se você encontrar uma falha e implorar para que eles alterem os requisitos, eles provavelmente não o farão.

Infelizmente, o que você descreveu é a visão típica do cliente de como um projeto de software deve ser abordado. Isso não quer dizer que o cliente esteja sendo irracional; afinal - não é assim que alguém executaria a construção de qualquer outra coisa (uma casa, por exemplo?). Dito isto, porém, não estou oferecendo nada além do que todos já sabemos. O que você está perguntando é ... a aplicação de práticas ágeis é viável nessa situação?

Tenho o benefício de ter acabado de terminar um projeto que é semelhante em muitos aspectos à situação que você descreve, ou seja,

1. Prazo fixo (em pedra, água do inferno ou água alta).
2. Documento de Requisitos Funcionais ("a Bíblia"). Sem surpresa, inadequada.
3. Funções tradicionais: Gerente de Projetos, Analista de Negócios.
4. Usuários de negócios pouco envolvidos (você pode dizer "nenhum patrocinador de produto"?).

... e, claro, a equipe de desenvolvimento com visão de futuro está tentando trabalhar de maneira ágil, apesar do acima:

1. Iterações de 2 semanas;
2. Stand-ups;
3. Retrospectivas;
4. Programação em pares;
5. TDD;
6. Integração contínua.

Mas isso é remotamente significativo para os negócios? Não. Dois meses antes do prazo, as iterações e reuniões de planejamento cuidadosamente observadas até então foram abandonadas em um frenesi de galinhas sem cabeça.

As respostas que outras pessoas forneceram acima são em maior ou menor grau comprometimentos. Na minha opinião, o ágil (seja "ágil" ou "ágil") é "feito" de uma maneira perniciosa quando comprometemos. Na minha opinião:

Não há compromisso ou não há agilidade.

O próprio espírito do ágil é ir direto ao ponto, remover o desperdício, ser brutalmente honesto consigo mesmo. Agora é um fato bem documentado e inegável que a estimativa de software em grandes projetos é uma aposta na melhor das hipóteses. Não é nosso dever, como profissionais de software, educar possíveis clientes sobre isso? Se os clientes não estão dispostos a aceitar que somos os especialistas, não é nosso dever profissional ir embora?

Quando comecei a trabalhar onde estou agora, me peguei fazendo a mesma pergunta que você fazia bastante. Há algo a ser dito para a cachoeira com contratação do governo. Ironicamente, o ágil agora se tornou um chavão com os clientes do governo (que trabalham realisticamente de maneira cascata), então agora nos resta tentar ainda mais implementar um processo ágil com um cliente basicamente inflexível.

Temos um sistema que foi descrito como "Scrummerfall" "Agilefall" ou "A mess", mas em muitos aspectos, lentamente fomos capazes de adotar um processo cada vez mais ágil, à medida que esse projeto (gigantesco) avançava ao longo dos anos . Uma das maneiras que fizemos isso é basicamente encontrar canais de comunicação com os USUÁRIOS do nosso sistema, em oposição aos nossos CLIENTES. Nossos clientes são um departamento abafado, chefiado por funcionários nomeados que nunca tocarão nosso software em suas vidas profissionais e não querem entender. Nossos usuários são funcionários regulares do governo em campo tentando realizar uma tarefa importante. Para nós, a chave para estabelecer um ciclo de feedback de comunicação que nos permitiu ser tão ágeis como nós era a necessidade do UAT (Teste de aceitação do usuário).

No início de nosso projeto, foi decidido que um grupo representativo de USUÁRIOS ATUAIS de vários escritórios de nosso vasto cliente do governo seria reunido no local AQUI e teríamos algumas semanas de tempo de contato com eles, enquanto executam uma série de scripts de teste para testar nosso software. Por uma questão informal, a equipe de requisitos transformou esse tempo em uma maneira inestimável de obter feedback dos usuários finais reais. Enquanto isso, a equipe de teste do UAT dentro do governo trabalhava com sua burocracia para ter cada vez mais influência sobre o processo formal de requisitos, incluindo pedidos de alteração. O resultado final é que os BAs, como eu, atuam como proprietários de produtos integrados em equipes de scrum e são capazes de obter um tempo inestimável com clientes reais que nos permitem funcionar de uma maneira muito ágil.

Obviamente, existem muitas questões e ainda não somos realmente ágeis, mas somos ágeis o suficiente para termos sido sustentados como exemplo de um grande projeto ágil que realmente usa essa metodologia no setor de contratação governamental.

Resumindo: use sua experiência como evangelista ágil em sua própria organização para se infiltrar em seu cliente. Passe por um processo de aprendizado com eles, estabeleça uma parceria baseada na confiança com as pessoas-chave do seu lado e trabalhe em torno do processo formal e ossificado de requisitos que eles inevitavelmente possuem. Você será agradecido pelos caras no local que realmente precisam usar o que está desenvolvendo!

Você está assumindo que os requisitos estão bem escritos e acha que eles querem dizer o que pensam que querem dizer. A alternância entre o processo ágil ajudará a garantir que eles estão conseguindo o que queriam, além do que pediram.