O documento discute o desenvolvimento ágil no governo, destacando como a metodologia ágil pode ajudar a reduzir riscos em projetos de software governamentais ao permitir entregas frequentes e adaptação às mudanças. Apesar de desafios como exigências legais e burocracia, a abordagem ágil pode gerar mais valor com menos custos se houver confiança mútua entre o órgão e fornecedor capacitado. A empresa Dextra tem aplicado com sucesso essas técnicas em projet
3. Soluções de Software
Projetos de software complexos Resolução de problemas tecnologicamente
e de alta criticidade para desafiadores e implementação de
os negócios melhorias de forma prática
Transferência de conhecimento
e aprimoramento de competências
5. Desafios no desenvolvimento de Software
Por que tantos projetos falham?
Plano de projeto não realista
Mau gerenciamento das expectativas do cliente
Entendimento incorreto dos requisitos iniciais
Impossibilidade de estimativas precisas
Mudanças gerenciadas com pouca agilidade e flexibilidade
Inabilidade de gerenciar riscos
Progresso não é monitorado e controlado
Inabilidade para lidar com a complexidade do projeto
Falta de envolvimento dos usuários
Comunicação ineficiente entre clientes, equipe e usuários
Falta de apoio executivo
6. Falsas premissas sobre projetos de software
É possível...
Prever com precisão todo o escopo do
projeto...
Antecipar e mitigar todos os riscos...
Lidar com toda a complexidade e incerteza
do projeto...
Acertar precisamente as estimativas no
começo...
Fazer funcionar com o cliente ausente...
A minha preferida:
“Falta só testar...”
7. O que é a metodologia ágil?
Desenvolvimento iterativo e incremental
Entrega frequente de produtos completos (valor de negócio!)
Gestão ágil e adaptativa
Reflexão e melhoria contínua
Abordagem colaborativa
Integração da equipe
Estratégia de equilíbrio preferida é pelo escopo
8.
9. Manifesto Ágil
Adaptação a mudanças é mais importante do que seguir o plano inicial.
Colaboração com o cliente é mais importante do que negociação de contratos.
Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e
detalhada.
Maior valor de negócio no menor tempo
10. Manisfesto Ágil
Nossa maior prioridade é satisfazer os clientes através de rápidas e contínuas entregas
de software com valor agregado.
Mudanças de requisitos são bem vindas, até mesmo tarde no desenvolvimento.
Processos ágeis assumem a mudança como parte da vantagem competitiva de seus
clientes.
Entregar software funcionando frequentemente, em algumas semanas ou meses, com
a preferência ao menor tempo possível.
Pessoas de negócios e desenvolvedores devem trabalhar juntos durante todo o
projeto.
Construa projetos através de indivíduos motivados. Dê à equipe um ambiente que
atenda suas necessidades, e confie em sua capacidade para realizar o trabalho.
A forma mais eficiente e efetiva de transmitir a informação para a equipe e entre a
equipe de desenvolvimento é através da comunicação cara-a-cara.
12. Mas Ágil funciona para governo?
Dificuldades
Exigências da Lei 8.666/93
Pregão
Órgãos de auditoria
Entraves burocráticos
Dependência de documentação
Aventureiros
13. Por que Ágil no governo?
Por que não?
Redução de risco
Menor diferença entre o que se precisa e o produto entregue
“Overengineering”
Custos e prazos
Visibilidade e governança
Melhor uso do dinheiro público
Gerar mais valor
Entregar mais cedo e frequentemente
Fazer somente o necessário
Adaptação à mudança
14. Como tipicamente era (e ainda é)?
Contratação por escopo fechado
Preço, prazo e entregas pré-definidas
Maior quantidade possível de funcionalidades no termo de referência
Dificuldades
Requisitos pouco amadurecidos
Funcionalidades desnecessárias
Mudanças durante o caminho
Cabo de guerra entre fornecedores e órgão
Renegociações contratuais
Energia gasta fora do objetivo principal
Desgaste Estratégia CYA
15. E para funcionar?
Criar cultura ágil
Fornecedor capacitado e idôneo
Órgão interessado em fazer
Envolvimento dos superiores
Alinhamento com negócio
Confiança mútua
Disposição para mudança
“Como assim não sei o quanto pagarei por esta ordem
de serviço?”
“Pode ser que o projeto acabe sem ter todo objeto
desenvolvido?”
Documentação é software bem estruturado e
funcionando
Um bom contrato
16. Contratação
Ponto de função ou outra métrica melhor
Exigências técnicas apropriadas
Forma detalhada de trabalho
Divisão do projeto em ordens de serviço
Priorização no que é mais importante
Ordens de serviço de 3 a 6 meses
17. Fale mais sobre isto!
Execução
Engajamento do cliente
Entregas a cada duas semanas
Metodologia de desenvolvimento
Equipes de 3 a 10 pessoas
Dono do produto também no fornecedor
Padronização de tecnologias e ferramentas
TDD: testes, testes, testes
Colocar em produção ASAP
18. Fale mais sobre isto!
Medição
Estimativa inicial
Recontagem na entrega do software
funcionando
Especialista para divergências
Pagamento da ordem de serviço
Um percentual no início
Uma parcela significativa na entrega do
software funcionando
O restante na homologação
19. Mas nem tudo são flores
O cliente
Precisa conhecer o negócio
“O olho do dono que engorda o boi”
Ferramentas são importantes, mas...
Pessoas, cultura e metodologia são muito mais
Pontos de função não medem tudo
Webdesign
Implantações
Mudanças que não afetam funcionalidade
Algoritmos complexos
…
Aventureiros à prova de tudo