Agilizar ou não agilizar, essa é a questão de classe=

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

Posted on em Transformação Digital do Governo

Fortuna escandalosa dos processos em cascata no governo

"Se é mais nobre para a mente sofrer
Os golpes e flechas da fortuna escandalosa,
Ou para pegar em armas contra um mar de problemas,
E por que se opor a eles?" - Hamlet por William Shakespeare
Muitas iniciativas de TI do governo funcionam como tragédias gregas: todos o esforço para reduzir o risco do projeto acaba aumentando o risco. E as altas taxas de falha, especialmente quando adaptação do software Enterprise Resource Planning (ERP), originalmente desenvolvido para o setor privado, no governo.
A TI governamental também tem tons de tragédia shakespeariana. Os governos e os parceiros doadores geralmente impõem "práticas recomendadas" de gerenciamento de projetos a fornecedores como a FreeBalance. Uma dessas "práticas recomendadas" é a imposição de gerenciamento de projetos do tipo cascata 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 mais oportunidades de personalização.
Desenho de projeto em cascata do FreeBalance
A imposição de práticas em cascata aumenta a "fortuna escandalosa". O gerenciamento ágil de projetos pode aumentar as taxas de sucesso?

Batalhões de cachoeiras de tristezas

"Quando as tristezas chegam, elas não vêm sozinhas. Mas em batalhões!" - Hamlet por William Shakespeare
Uma pesquisa recente da Accenture e NASCIO (National Association of State Chief Information Officers) constatou que "Quando perguntados sobre os resultados que poderiam ser evitados com o uso da metodologia ágil, 70% dos profissionais de TI consideraram que ela ajudava a evitar o desperdício de dinheiro em projetos de TI ineficazes, 66% consideraram que ela ajudava a evitar grandes falhas em projetos de TI e 58% disseram que ela ajudava a evitar programas que não atendiam às necessidades dos negócios.”
Técnicas ágeis, como enxuto, pensamento em design, Extremo, Kanbane Scrum têm sido frequentemente associados a pequenos projetos. O pensamento, entre os observadores tradicionais, é que o Agile não é apropriado para grandes projetos de TI. Como um Mitre estudo para o Departamento de Defesa dos Estados Unidos apontouEm muitos casos, os projetos em cascata assumem incorretamente requisitos bem definidos com mudanças limitadas. A realidade é que o Agile é muito mais resistente a mudanças e incertezas do que o Waterfall. O Agile é ideal para iniciativas substanciais de Planejamento de Recursos Governamentais (GRP). Isso se deve aos insights obtidos durante a implementação do projeto, que podem alinhar melhor a funcionalidade às necessidades reais do governo. A maioria das implementações de sistemas de GRP segue a reforma e a modernização do governo. Não se trata apenas de TI, mas de transformação.
É nesse ponto que o ágil se destaca.
Escalas ágeis. De projetos pequenos a grandes.

Agilizar ou não agilizar? Uma lista de verificação de ABCs

"Há mais coisas no céu e na terra, Horatio,
do que o sonhado em sua filosofia." - Hamlet por William Shakespeare
Nem todos os projetos em cascata fracassam. Nem todos os projetos ágeis são bem-sucedidos. (Para ser justo, o ágil se concentra no aprendizado, portanto falhando rapidamente costuma ser um fator de sucesso).
O Grupo de Estratégia e Inovação FreeBalance analisou a literatura sobre projetos e nossas experiências governamentais. (Ao contrário dos fornecedores de software corporativo legado, a FreeBalance participa de todas as implementações para ajudar a promover melhorias nos produtos e serviços). Essa análise levou ao nosso A-i3+qM metodologia. Isso também levou a uma reavaliação significativa das práticas tradicionais e da filosofia dessas práticas.
Também criamos uma lista de verificação com 26 pontos de classificação dos fatores. Os fatores são classificados entre baixo e alto. Seu contexto pode ser diferente.
Fatores que favorecem a cachoeira A-F
Lista de verificação de Agile ou Waterfall no GRP
Fatores que favorecem o Agile G-Z
Fatores que favorecem o Agile G-Z

  1. Complexidade arquitetônicaA necessidade de desenvolver arquiteturas de software a partir do zero tende a exigir longos períodos de projeto, além de várias iterações. Embora isso não se aplique a arquiteturas disponíveis comercialmente, como o Plataforma FreeBalance Accountability
  2. Problemas bem compreendidosO conhecimento profundo dos problemas reduz a necessidade de obter informações adicionais dos ágeis. Embora muitos (a maioria?) dos grandes projetos de TI do governo sejam focados em soluções que raramente abordam problemas reais sem mudanças
  3. Experiência em circunstâncias semelhantesA experiência da organização governamental na implementação de iniciativas semelhantes torna os projetos mais previsíveis. No entanto, muitas organizações governamentais consideram a experiência do fornecedor fora de contexto, como a experiência do fornecedor em outros contextos
  4. Número de funcionários: o Agile funciona bem com equipes pequenas e motivadas que operam de forma eficiente Embora deva ser observado que os projetos em cascata exigem mais pessoal para comunicação, coordenação e documentação do que os ágeis
  5. Foco no escopoO escopo do projeto: escopo totalmente articulado e foco no escopo que direciona o tempo e os recursos, o que se presta a controles em cascata que reduzem o "desvio de escopo". Embora muitos projetos fracassem devido a mudanças de escopo inflexíveis que privilegiam as cláusulas contratuais em detrimento das necessidades reais do governo
  6. Capacidade humanaA alta capacidade humana do governo em tecnologia, gerenciamento de projetos e Gestão Financeira Pública (GFP) atenua muitos dos riscos associados à cascata. embora a alta capacidade esteja frequentemente associada ao excesso de confiança
  7. Complexidade do projeto: o ágil ajuda a decompor a complexidade e a estruturar as atividades com base em prioridades por meio de protótipos, entrada do usuário e análise do projeto
  8. Incerteza do projeto: o Agile é ideal quando há muita incerteza no projeto
  9. Taxas de falha de TI: o Agile fornece ferramentas de sucesso para as equipes de TI que tiveram um histórico de resultados insatisfatórios
  10. Funções entre domíniosO método cascata funciona melhor em silos, envolvendo especialistas de domínio, e o método ágil funciona melhor quando as funções cruzam silos, como finanças, compras, folha de pagamento e administração tributária
  11. Focado em resultadosprojetos concebidos para obter resultados se beneficiam dos processos ágeis porque os projetos em cascata se concentram na conformidade contratual
  12. Mudança transformacionalProjetos que seguem modernização, reforma ou reorganização se beneficiam de processos ágeis que são mais transparentes, comunicativos e flexíveis do que os de cascata
  13. Desenvolvimento personalizado: expectativa de desenvolvimento personalizado (por exemplo, desenvolvimento personalizado usando uma plataforma técnica, desenvolvimento personalizado usando uma plataforma de desenvolvimento) plataforma de governançaO desenvolvimento personalizado usando ERP) se beneficia da agilidade que identifica o valor de cada elemento personalizado
  14. Nível atual da tecnologia legadaA organização governamental que usa tecnologia antiga (mainframes, COBOL, 4GLs) ou tecnologia legada (a maioria dos sistemas ERP proprietários, incluindo o Tier 1) se beneficia dos novos olhares associados à agilidade
  15. Envolvimento do usuário: o Agile se destaca quando os usuários precisam articular problemas, identificar soluções, testar a funcionalidade e defender novos sistemas
  16. Mudança de funcionalidade: o Agile é excelente quando há muitas funções novas a serem introduzidas em comparação com o sistema legado
  17. Implementação GreenfieldA implementação de atualizações em sistemas existentes pode ser feita em cascata, enquanto a implementação de software novo em rede se beneficia do método ágil
  18. Mudança de requisitosO método cascata espera pouquíssimas mudanças nos requisitos, enquanto o método ágil é resiliente a mudanças, identificando as alterações de especificação antecipadamente para reduzir os custos, em comparação com a identificação das mudanças necessárias posteriormente nos projetos
  19. Dependências do sistemaProcessos em cascata se beneficiam de menos dependências do sistema, como pontos de integração com outros sistemas, enquanto o ágil é mais capaz de se integrar em vários domínios governamentais e tecnologias subjacentes
  20. Novidade do produtoO método ágil é ideal quando os projetos estão implementando conjuntos de produtos relativamente novos
  21. Resistência à mudançaO método cascata não é eficaz em situações em que a resistência do usuário e da gerência à mudança é alta, enquanto o método ágil tem mais processos embutidos que facilitam e integram o gerenciamento de mudanças (o gerenciamento de mudanças em projetos cascata costuma ser ineficaz)
  22. Foco na qualidadeOs processos em cascata colocam os testes e a garantia de qualidade no final da metodologia, enquanto os ágeis se concentram na qualidade em cada "história do usuário", o que resulta em melhoria da qualidade desde o início
  23. Extensibilidade do sistema: o Agile é excelente quando o software existente ou novo precisa ser estendido a funções adicionais por meio da reutilização
  24. Relatórios e painéis personalizadosA articulação de relatórios, incluindo a replicação de relatórios estatutários em um novo software e a criação de novos relatórios, painéis e análises, se beneficia das iterações ágeis, pois os usuários geralmente reconhecem as melhorias quando veem os resultados dos relatórios
  25. Velocidade de implementação: o Agile se destaca pela velocidade de implementação e fornece informações de desempenho mais eficazes ("cadência") do que o Waterfall, para prever o tempo de conclusão do projeto
  26. Transparência do projetoO método em cascata pressupõe equipes separadas que se reportam em torno de marcos, enquanto o método ágil pressupõe transparência constante do projeto por meio de quadros Kanban, Scrum ou Srumban e envolvimento frequente com usuários e partes interessadas

Observações 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 isso como um risco

Metodologias "ágeis" intrigantes conduzidas por fornecedores

"Isso confunde a vontade." - Hamlet por William Shakespeare
Muitos fornecedores de software empresarial estabelecidos, inclusive fornecedores de ERP de nível 1, estão promovendo processos ágeis. Os integradores de sistemas precisam dar suporte a esses processos orientados pelo fornecedor para obter a certificação. É surpreendente como esses chamados processos ágeis não são ágeis.
O método ágil é frequentemente incorporado ao método cascata, acrescentando complexidade ao processo. Ou descrevendo apresentações de comunicação de marcos como ágeis. Muitos desses processos impõem "práticas recomendadas" em funções que raramente são melhores ou apropriadas. A aceleração de projetos nessas metodologias se concentra em executar o que está no software sem mudanças, em vez de se adequar às necessidades reais do governo. (As implementações "Vanilla" raramente satisfazem as necessidades do governo.)

Uma rosa ágil?

"Uma rosa com qualquer outro nome teria o mesmo cheiro doce" - Romeu e Julieta por William Shakespeare
Muitos provedores tentam redefinir a cascata como ágil. Isso não mudará a natureza do processo. Ele não terá o cheiro doce do ágil.

Fontes adicionais

Referências específicas do governo

Referências gerais

Tópicos

Contato