De um tradutor: este é o DIB Guide: Detecting Agile BS (versão 0.4) , publicado pelo Comitê de Inovação do Departamento de Defesa dos EUA (DIB) em 9 de outubro de 2018.

Agile é uma palavra da moda no desenvolvimento de software, portanto todos os projetos de software do Ministério da Defesa agora são quase "flexíveis" por padrão. Este documento ajudará os gerentes de programas e especialistas do Ministério da Defesa a distinguir projetos de software com uma metodologia verdadeiramente flexível de projetos que simplesmente usam "cascata" ou "espiral" ("agile-scrum-fall") sob o pretexto de Agile.

Princípios, valores e ferramentas

Especialistas e entusiastas ágeis identificam as principais métricas que caracterizam essa cultura e abordagem para o desenvolvimento ágil. Em seu trabalho, o DIB desenvolveu suas próprias diretrizes que refletem aproximadamente os verdadeiros valores do Agile:

Valor ágil	Princípio DIB
Indivíduos e interações são mais importantes que processos e ferramentas	“Competência é mais importante que processo”
A execução de software é mais importante que a documentação completa	“Reduza o tempo desde o início do projeto até a implantação da funcionalidade básica mais simples”
Colaboração com um cliente para acordar um contrato	“Implementação da cultura DevSecOps para sistemas de software”
Respondendo à mudança sobre o plano	"Os programas devem começar pequenos, ser iterativos e aumentar o sucesso - ou são rapidamente revertidos."

Principais sinais de que o projeto não é muito flexível:

• Nenhuma equipe de desenvolvimento se comunica com os usuários ou rastreia o software em ação; queremos dizer usuários reais de código real . (O departamento de avaliação do programa não é considerado um usuário real, como um oficial sênior, a menos que ele use o programa em seu trabalho). Alternativas aceitáveis ​​à comunicação com os usuários: monitorando seu trabalho, passando protótipos para eles para feedback e outros métodos de pesquisa que não envolvem muita comunicação verbal.
• Não há feedback constante dos usuários para a equipe de desenvolvimento (relatórios de erros, classificações). Não basta falar uma vez no início do projeto para verificar os requisitos!
• A conformidade é considerada mais importante do que obter o resultado menos útil o mais rápido possível.
• As partes interessadas (desenvolvimento, teste, DevOps, segurança, prestadores de serviços, usuários finais etc.) operam de maneira mais ou menos autônoma (por exemplo, “esse não é o meu negócio”).
• Os usuários finais não estão envolvidos no desenvolvimento; no mínimo, eles devem estar presentes durante o planejamento da liberação e os testes de aceitação.
• Não há cultura DevSecOps suficiente quando processos que podem e devem ser automatizados são executados manualmente (por exemplo, teste, integração contínua, entrega contínua).

Algumas ferramentas típicas de desenvolvimento ágil (elas mudam conforme
a aparência dos melhores):

• Git, ClearCase ou Subversion é um sistema de controle de versão para rastrear alterações no código fonte. Git é o padrão de fato no desenvolvimento moderno.
• BitBucket ou GitHub - hospedando repositórios. Ele também rastreia tickets, possui "aplicativos" para integração contínua e outras ferramentas para melhorar a produtividade. Amplamente utilizado pela comunidade de código aberto.
• Jenkins, Circle CI ou Travis CI é um serviço de integração contínua para criar e testar projetos Bitbucket e GitHub.
• Chef, Ansible ou Puppet - software para criar “receitas” para tarefas de configuração e difusão e suporte a vários servidores.
• O Docker é um programa de computador que executa virtualização no nível do sistema operacional, também conhecido como contêiner.
• Kubernetes ou Docker Swarm para orquestração de contêineres.
• Jira ou Pivotal Tracker - tickets, monitoramento e gerenciamento.

Versão gráfica:

Perguntas para desenvolvedores

• Como você testa o código? (Respostas erradas: “Temos uma organização especial para testes”, “O departamento de testes e avaliação de produtos é responsável pelos testes”)
  
  • Versão estendida: que conjunto de ferramentas você usa para testes de unidade, testes de regressão, testes funcionais, verificações de segurança e certificação de implantação?
• Quão automatizados são os pipelines de desenvolvimento, teste, segurança e implantação?
  
  • Versão estendida: que conjunto de ferramentas você usa para integração contínua (IC), entrega contínua (CD), teste de regressão, documentação do programa; Sua infraestrutura é orientada por código?
• Quem são seus usuários e como você interage com eles?
  
  • Versão estendida: quais mecanismos você usa para obter feedback direto dos usuários? Que conjunto de ferramentas você usa para criar relatórios de erros e rastrear tickets? Como você distribui o trabalho de correção de bugs entre as equipes? Como você informa aos usuários que seus problemas estão sendo resolvidos e / ou já resolvidos?
• Qual é o prazo para os ciclos de lançamento atuais e futuros?
  
  • Versão estendida: quais plataformas de software você suporta? Você usa contêineres? Quais são as suas ferramentas de gerenciamento de configuração?

Perguntas para gerentes de projeto

• Quantos programadores fazem parte da organização que aloca o orçamento e quais são os principais estágios do programa? (Respostas erradas: "Não sabemos", "Zero", "Depende da definição de programador")
• O que são métricas de gerenciamento para desenvolvimento e operação; como eles são usados ​​para comunicar prioridades, identificar problemas; com que frequência eles visualizam e usam o manual?
• O que você aprendeu nos últimos três sprints e como aplicar o novo conhecimento? (Respostas erradas: “O que é um sprint?”, “Estamos aguardando a aprovação da liderança”)
• Quem são os usuários que se beneficiam de cada ciclo de sprint? Posso falar com eles? (Respostas erradas: “Não implantamos o código diretamente para os usuários”)

Perguntas para clientes e usuários

• Como você se comunica com os desenvolvedores? Eles supervisionam seu trabalho e fazem perguntas relevantes que indicam uma compreensão profunda de suas necessidades? Quando foi a última vez que eles se sentaram por perto e discutiram os recursos que você deseja ver?
• Como envio sugestões para novos recursos ou relato problemas ou bugs no código? Que feedback você recebe por suas consultas / relatórios? Você já foi solicitado a experimentar protótipos de novos recursos de software e observou como os utiliza?
• Quanto tempo leva para implementar a função solicitada no aplicativo?

Perguntas para orientação

• Uma versão funcional do software é entregue a pelo menos uma pequena amostra de usuários reais a cada iteração (incluindo a primeira) e as revisões são coletadas? (dica: a cada duas semanas)
• Existe uma carta de produtos que define a missão e os objetivos estratégicos? Todos os membros da equipe entendem os dois? Eles vêem como o trabalho deles contribui para o alcance de metas?
• As análises de usuários se transformam em tarefas específicas para equipes de sprint com prazo inferior a um mês?
• As equipes estão autorizadas a alterar os requisitos com base no feedback do usuário?
• As equipes têm o direito de mudar seu processo com base no que aprenderam durante o desenvolvimento?
• Todo o ecossistema do seu projeto é flexível? (Se o desenvolvimento ágil for seguido por um processo de implementação burocrático linear, isso é uma falha.)

Para equipes ágeis, a resposta para todas essas perguntas deve ser sim.

Versão gráfica:



Informações mais detalhadas sobre algumas funções dos programas do Ministério da Defesa estão contidas no Apêndice A ( Dez Requisitos de Software ), Apêndice B ( Métricas para Desenvolvimento de Software ) e Apêndice C (Regras e Erros de Software [link será adicionado posteriormente] )