De un traductor: esta es la Guía DIB: Detectando Agile BS (versión 0.4) , que el Comité de Innovación del Departamento de Defensa de los Estados Unidos (DIB) publicó públicamente el 9 de octubre de 2018.

Ágil es una palabra de moda en el desarrollo de software, por lo que todos los proyectos de software del Ministerio de Defensa ahora son casi "flexibles" por defecto. Este documento ayudará a los administradores de programas y especialistas del Ministerio de Defensa a distinguir proyectos de software con una metodología verdaderamente flexible de proyectos que simplemente usan "cascada" o "espiral" ("agile-scrum-fall") bajo la apariencia de Agile.

Principios, valores y herramientas

Los expertos y entusiastas ágiles identifican métricas clave que caracterizan esta cultura y enfoque para el desarrollo ágil. En su trabajo, DIB ha desarrollado sus propias pautas que reflejan aproximadamente los verdaderos valores de Agile:

Valor ágil	Principio DIB
Las personas y las interacciones son más importantes que los procesos y las herramientas.	"La competencia es más importante que el proceso"
Ejecutar software es más importante que la documentación completa	"Reduzca el tiempo desde el inicio del proyecto hasta la implementación de la funcionalidad básica más simple"
Colaboración con un cliente para acordar un contrato.	"Implementación de la cultura DevSecOps para sistemas de software"
Responder al cambio sobre el plan	"Los programas deberían comenzar con poco, ser iterativos y basarse en el éxito, o se revierten rápidamente".

Señales clave de que el proyecto no es muy flexible:

• Ninguno de los equipos de desarrollo se comunica con los usuarios o rastrea el software en acción; nos referimos a usuarios reales de código real . (El departamento de evaluación del programa no se considera un usuario real, al igual que un oficial superior, a menos que use el programa en su trabajo). Alternativas aceptables a la comunicación con los usuarios: monitorear su trabajo, pasarles prototipos para recibir comentarios y otros métodos de investigación que no involucren mucha comunicación verbal.
• No hay comentarios constantes de los usuarios para el equipo de desarrollo (informes de errores, clasificaciones). ¡No es suficiente hablar una vez al comienzo del proyecto para verificar los requisitos!
• El cumplimiento se considera más importante que obtener el resultado menos útil lo más rápido posible.
• Las partes interesadas (desarrollo, pruebas, DevOps, seguridad, contratistas, usuarios finales, etc.) operan de manera más o menos autónoma (por ejemplo, "este no es mi negocio").
• Los usuarios finales no están involucrados en el desarrollo; como mínimo, deben estar presentes durante la planificación de lanzamiento y las pruebas de aceptación.
• No hay suficiente cultura DevSecOps cuando los procesos que pueden y deben automatizarse se ejecutan manualmente (por ejemplo, pruebas, integración continua, entrega continua).

Algunas herramientas de desarrollo ágiles típicas (cambian según
la apariencia de los mejores):

• Git, ClearCase o Subversion es un sistema de control de versiones para rastrear cambios en el código fuente. Git es el estándar de facto en el desarrollo moderno.
• BitBucket o GitHub: repositorios de alojamiento. También rastrea tickets, tiene "aplicaciones" para la integración continua y otras herramientas para mejorar la productividad. Ampliamente utilizado por la comunidad de código abierto.
• Jenkins, Circle CI o Travis CI es un servicio de integración continua para construir y probar proyectos Bitbucket y GitHub.
• Chef, Ansible o Puppet: software para crear "recetas" para tareas de configuración de configuración y difusión y soporte para varios servidores.
• Docker es un programa informático que realiza la virtualización a nivel del sistema operativo, también conocido como contenedorización.
• Kubernetes o Docker Swarm para orquestación de contenedores.
• Jira o Pivotal Tracker - tickets, monitoreo y gestión.

Versión gráfica:

Preguntas para desarrolladores

• ¿Cómo se prueba el código? (Respuestas incorrectas: "Tenemos una organización especial para pruebas", "El departamento de pruebas y evaluación de productos es responsable de las pruebas")
  
  • Versión extendida: ¿qué conjunto de herramientas utiliza para pruebas unitarias, pruebas de regresión, pruebas funcionales, escaneos de seguridad y certificación de implementación?
• ¿Cuán automatizados son los canales de desarrollo, prueba, seguridad e implementación?
  
  • Versión extendida: qué conjunto de herramientas utiliza para la integración continua (CI), entrega continua (CD), pruebas de regresión, documentación del programa; ¿Su infraestructura está basada en códigos?
• ¿Quiénes son sus usuarios y cómo interactúa con ellos?
  
  • Versión extendida: ¿qué mecanismos utiliza para obtener comentarios directos de los usuarios? ¿Qué conjunto de herramientas utiliza para crear informes de errores y rastrear tickets? ¿Cómo distribuye el trabajo de corrección de errores entre los equipos? ¿Cómo informa a los usuarios que sus problemas se están resolviendo o ya se han resuelto?
• ¿Cuál es la fecha límite para los ciclos de lanzamiento actuales y futuros?
  
  • Versión extendida: ¿qué plataformas de software son compatibles? ¿Usas contenedores? ¿Cuáles son sus herramientas de gestión de configuración?

Preguntas para gerentes de proyecto

• ¿Cuántos programadores forman parte de la organización que asigna el presupuesto y cuáles son las etapas principales del programa? (Respuestas incorrectas: "No sabemos", "Cero", "Depende de la definición de programador")
• ¿Cuáles son las métricas de gestión para el desarrollo y la operación? cómo se utilizan para comunicar prioridades, identificar problemas; ¿con qué frecuencia ven y usan el manual?
• ¿Qué has aprendido en los últimos tres sprints y cómo aplicar el nuevo conocimiento? (Respuestas incorrectas: "¿Qué es un sprint?", "Estamos esperando la aprobación del liderazgo")
• ¿Quiénes son los usuarios que se benefician de cada ciclo de sprint? ¿Puedo hablar con ellos? (Respuestas incorrectas: "No implementamos el código directamente para los usuarios")

Preguntas para clientes y usuarios.

• ¿Cómo te comunicas con los desarrolladores? ¿Supervisan su trabajo y le hacen preguntas relevantes que indican una comprensión profunda de sus necesidades? ¿Cuándo fue la última vez que se sentaron cerca y discutieron las características que quieres ver?
• ¿Cómo envío sugerencias para nuevas funciones o reporto problemas o errores en el código? ¿Qué comentarios recibe por sus consultas / informes? ¿Alguna vez le han pedido que pruebe prototipos de nuevas funciones de software y ha visto cómo las usa?
• ¿Cuánto tiempo lleva implementar la función solicitada en la aplicación?

Preguntas de orientación

• ¿Se entrega una versión funcional del software a al menos una pequeña muestra de usuarios reales en cada iteración (incluida la primera) y se recopilan las revisiones? (pista: cada dos semanas)
• ¿Existe una carta de producto que establece la misión y los objetivos estratégicos? ¿Todos los miembros del equipo entienden ambos? ¿Ven cómo su trabajo contribuye al logro de los objetivos?
• ¿Las revisiones de los usuarios se convierten en tareas específicas para los equipos de sprint con un plazo de menos de un mes?
• ¿Los equipos están autorizados a cambiar los requisitos en función de los comentarios de los usuarios?
• ¿Los equipos tienen derecho a cambiar su proceso en función de lo que aprendieron durante el desarrollo?
• ¿Es flexible todo el ecosistema de su proyecto? (Si el desarrollo ágil es seguido por un proceso de implementación lineal y burocrático, esto es un fracaso).

Para los equipos ágiles, la respuesta a todas estas preguntas debería ser sí.

Versión gráfica:



Se incluye información más detallada sobre algunas funciones de los programas del Ministerio de Defensa en el Apéndice A ( Diez requisitos de software ), el Apéndice B ( Métricas para el desarrollo de software ) y el Apéndice C (Errores y reglas de software [el enlace se agregará más adelante] )