Para Agile, ou não para Agile, esta é a classe de perguntas=

Para Agile, ou não para Agile, essa é a questão

Posted on em Transformação Digital do Governo

Fortuna ultrajante dos processos de cascata no governo

"Se é mais nobre na mente sofrer
As fundas e flechas de uma fortuna ultrajante,
Ou para pegar em armas contra um mar de problemas,
E opondo-se a acabar com eles"... – Hamlet por William Shakespeare
Muitas iniciativas governamentais de TI funcionam como tragédias gregascada esforço para reduzir o risco do projeto acaba por aumentar o risco. E, altas taxas de falhas, especialmente quando adaptação do software de planejamento de recursos empresariais (ERP), originalmente desenvolvido para o setor privado, no governo.
Há também tons de tragédia shakespeareana na TI governamental. Os governos e os parceiros doadores muitas vezes impõem "melhores práticas" de gerenciamento de projetos a fornecedores como a FreeBalance. Uma dessas "melhores práticas" é a imposição de gerenciamento de projetos do tipo "waterfall- que pressupõe que os projetos de software são tão previsíveis quanto os projetos de construção. A construção se beneficia de restrições físicas como a resistência dos materiais. O software tem muito menos restrições, e maior oportunidade de personalização.
Projeto FreeBalance Waterfall Design
As práticas de cascata impostas aumentam a "fortuna ultrajante". A gestão ágil de projetos pode aumentar os índices de sucesso?

Batalhões de dores de cachoeira

"Quando as tristezas vêm, não vêm espiões solteiros. Mas em batalhões"! – Hamlet por William Shakespeare
Uma pesquisa recente realizada por Accenture e NASCIO (National Association of State Chief Information Officers) descobriu que "(...)quando questionados sobre os resultados que poderiam ser evitados com o uso de ágeis, 70% dos profissionais de TI acharam que ajudou a evitar o desperdício de dinheiro de projetos de TI ineficazes, 66% acharam que ajudou a evitar falhas em grandes projetos de TI e 58% disseram que ajudou a evitar programas que não atendem às necessidades comerciais.”
Técnicas ágeis, tais como lean, pensamento em design, Extremo, Kanbane Scrum têm sido frequentemente associados a pequenos projetos. O pensamento, entre os observadores tradicionais, é que o ágil não é apropriado para grandes projetos de TI. Como um Mitre estudo para o Departamento de Defesa dos Estados Unidos apontadoOs projetos de cascata assumem incorretamente requisitos bem definidos com mudanças limitadas. A realidade é que o ágil é muito mais resistente à mudança e à incerteza do que a queda d'água. Agile é ideal para iniciativas substanciais de Planejamento de Recursos Governamentais (GRP). Isso se deve aos conhecimentos adquiridos durante a implementação do projeto que podem alinhar melhor a funcionalidade com as necessidades reais do governo. A maior parte da implementação do sistema GRP segue a reforma e modernização do governo. Não é apenas TI, é transformação.
Aqui é onde a agilidade se sobressai.
Escalas ágeis. De pequenos a grandes projetos.

Para ágil, ou não para ágil? Uma lista de verificação ABCs

"Há mais coisas no céu e na terra, Horatio",
do que são sonhados em sua filosofia". – Hamlet por William Shakespeare
Nem todos os projetos de cataratas fracassam. Nem todos os projetos ágeis são bem sucedidos. (Para ser justo, o foco ágil é o aprendizado, portanto falhando rapidamente é muitas vezes um fator de sucesso).
O FreeBalance Strategy and Innovation Group tem analisado a literatura do projeto e nossas experiências governamentais. (Ao contrário dos fornecedores de software empresarial legados, a FreeBalance participa de todas as implementações para ajudar a impulsionar melhorias em produtos e serviços). Esta análise levou ao nosso A-i3+qM metodologia. Também levou a uma revalorização significativa das práticas tradicionais, e da filosofia destas práticas.
Também criamos uma classificação de 26 pontos de verificação de fatores. Os fatores são classificados entre baixo e alto. Seu contexto pode ser diferente.
Fatores que favorecem a queda de água A-F
Lista de verificação do PRFV Ágil ou Cascata
Fatores que favorecem o G-Z ágil
Fatores que favorecem o G-Z ágil

  1. Complexidade Arquitetônica: a necessidade de desenvolver arquiteturas de software a partir do zero tende a exigir longos períodos de projeto além de múltiplas iterações - embora isso não se aplique a arquiteturas disponíveis comercialmente como a Plataforma FreeBalance Accountability
  2. Problemas bem entendidos: uma visão profunda dos problemas reduz a necessidade de obter insights adicionais a partir de uma visão ágil - embora muitos (a maioria?) grandes projetos governamentais de TI sejam focados em soluções que raramente abordam problemas reais sem mudanças
  3. Experiência em Circunstâncias Semelhantes: a experiência da organização governamental implementando iniciativas similares torna os projetos mais previsíveis - embora, muitas organizações governamentais assumam a experiência do fornecedor fora do contexto, como a experiência do fornecedor em outros contextos
  4. Número de funcionárioságil opera bem com pequenas equipes motivadas que operam eficientemente - embora se deva notar que os projetos de cascata exigem mais pessoal para as comunicações, coordenação e documentação do que ágeis
  5. Âmbito de aplicaçãoO escopo do projeto totalmente articulado, e um foco no tempo de condução do escopo e nos recursos, se presta a controles em cascata que reduzem o "rastejamento do escopo" - embora, muitos projetos falhem por causa de mudanças de escopo inflexíveis que favorecem as disposições contratuais em detrimento das necessidades reais do governo
  6. Capacidade humana: alta capacidade humana governamental em tecnologia, gestão de projetos e Gestão Financeira Pública (GFP) mitiga muitos dos riscos associados à queda d'água - embora a alta capacidade esteja freqüentemente associada ao excesso de confiança
  7. Complexidade do projeto: agile ajuda a decompor a complexidade e estruturar atividades com base em prioridades através de protótipos, entrada de usuários e análise de projeto
  8. Incerteza do projeto: ágil é ideal quando há alta incerteza no projeto
  9. Taxas de falha de TIagile fornece ferramentas de sucesso para equipes de TI que experimentaram um histórico de resultados abaixo do esperado
  10. Funções inter-domínios: a cascata funciona melhor em silos, envolvendo especialistas de domínio, e funções ágeis quando funções cruzam silos como finanças, compras, folha de pagamento e administração tributária
  11. OutcomeFocused: projetos concebidos para ter resultados se beneficiam de processos ágeis porque os projetos de cascata se concentram na conformidade contratual
  12. Mudança transformacional: projetos que seguem modernização, reforma ou reorganização se beneficiam de processos ágeis que são mais transparentes, comunicativos e flexíveis do que a cachoeira
  13. Desenvolvimento personalizado: expectativa de desenvolvimento customizado (como desenvolvimento customizado utilizando uma plataforma técnica, desenvolvimento customizado utilizando um plataforma de governançaou desenvolvimento personalizado usando ERP) se beneficia de uma agilidade que identifica valor para cada elemento personalizado
  14. Nível atual de tecnologia legada: organização governamental que utiliza tecnologia antiga (mainframes, COBOL, 4GLs), ou tecnologia legada (a maioria dos sistemas ERP proprietários, incluindo o Tier 1), se beneficiam dos novos olhos associados à ágil
  15. Envolvimento do usuário: ágil se sobressai quando os usuários são obrigados a articular problemas, identificar soluções, testar funcionalidades e defender novos sistemas
  16. Mudança de Funcionalidade: ágil se sobressai quando há muitas funções novas em comparação com o sistema antigo
  17. Implementação Greenfield: atualizações de sistemas existentes podem ser implementadas em cascata, enquanto a implementação de software novo se beneficia de uma
  18. Mudança de requisitos: a cascata espera muito pouca mudança nas exigências, enquanto que a ágil é resistente a mudanças, identificando as mudanças de especificação cedo para reduzir custos em comparação com a identificação das mudanças necessárias mais tarde nos projetos
  19. Dependências do sistema: os processos de cascata se beneficiam de menos dependências do sistema, tais como pontos de integração com outros sistemas, enquanto o ágil é mais capaz de se integrar em múltiplos domínios governamentais e tecnologias subjacentes
  20. Novidade do produto: o ágil é ideal quando os projetos estão implementando conjuntos de produtos relativamente novos
  21. Resistência à mudança: a cascata não é eficaz em situações onde a resistência do usuário e da gerência à mudança é alta, enquanto que o ágil tem processos mais incorporados que facilitam e integram a gestão da mudança (a gestão de mudanças em projetos de cascata é freqüentemente ineficaz)
  22. Foco na qualidade: os processos de cascata colocam testes e garantia de qualidade tardiamente na metodologia, enquanto o foco ágil na qualidade em cada "história de usuário" resulta na melhoria precoce da qualidade
  23. Extensibilidade do sistema: o ágil se sobressai quando o software existente ou novo precisa se estender a funções adicionais através da reutilização
  24. Relatórios e Painéis Personalizados: a articulação de relatórios incluindo a replicação de relatórios estatutários em novos softwares, e a criação de novos relatórios, dashboards e análises se beneficiam de iterações ágeis porque os usuários frequentemente reconhecem melhorias uma vez que vêem os resultados dos relatórios
  25. Velocidade de implementação: agile excede a velocidade de implementação, e fornece informações de desempenho mais eficazes ("cadência") do que cascata, para prever o tempo de conclusão do projeto
  26. Transparência do projeto: cachoeira assume equipes separadas que reportam em torno de marcos, enquanto ágil assume a transparência constante do projeto através dos conselhos Kanban, Scrum ou Srumban, e o envolvimento frequente com usuários e partes interessadas

Notas importantes

  • Os diagramas acima mostram que o ágil é preferível nas duas primeiras colunas da lista de verificação. Isso não é um erro.
  • Sua lista de verificação provavelmente mostrará itens em todas as 3 colunas. Use isto como um risco

Metodologias "ágeis" lideradas por fornecedores

"Enigmática a vontade". – Hamlet por William Shakespeare
Muitos fornecedores de software empresarial estabelecidos, incluindo os fornecedores de ERP Tier 1, estão fazendo processos ágeis. Os integradores de sistemas precisam dar suporte a esses processos orientados pelos fornecedores para obter a certificação. É surpreendente como esses chamados processos ágeis são inagiláveis.
Agile é muitas vezes aparafusada na cascata acrescentando complexidade ao processo. Ou, descrevendo as apresentações de comunicação de marcos como ágeis. Muitos destes processos impõem "melhores práticas" em funções que raramente são as melhores, ou apropriadas. A aceleração do projeto nestas metodologias se concentra na execução do que está no software sem mudanças, em vez de corresponder às necessidades reais do governo. (As implementações de "baunilha" raramente atendem às necessidades do governo.)

Uma rosa ágil?

"Uma rosa com qualquer outro nome teria um cheiro tão doce" - Romeu e Julieta por William Shakespeare
Muitos fornecedores tentam redefinir a queda d'água como ágil. Isto não vai mudar a natureza do processo. Não terá um cheiro tão doce quanto ágil.

Fontes Adicionais

Referências específicas do governo

Referências gerais

Tópicos

Contato