interview_ES.md

ID de la organización (asignación interna): ID

Todos los datos serán tratados confidencialmente y de forma anónima mediante la asignación de un ID.

Información Personal del Entrevistado

1. Nombre del participante
2. Posición/puesto de trabajo
3. Experiencia (años)
4. Experiencia en DevOps (años)

Información de la Empresa

5. Nombre de la empresa
6. Tamaño (microempresa, pequeña, mediana o grande )
7. Tamaño de la unidad/departamento de TI objeto de estudio
8. ¿A qué tipo de negocio está dedicada la empresa?
9. ¿Cuál es el alcance de la empresa (nacional/internacional)?
10. Año (aprox.) de formación de la empresa: de reciente creación (posterior 2010), entre 2000 y 2010, o anterior.

Proceso de adopción DevOps

11. ¿Qué problemas tenían o qué posibles causas motivaron a su empresa a iniciar una transformación hacia DevOps, su cultura y prácticas?

12. ¿Qué resultados esperaba obtener su empresa con la adopción de DevOps?

13. ¿Qué tipo de estrategia fue adoptada en este proceso de transformación: top-down, bottom-up o sándwich?

14. ¿Cómo valora la involucración de la alta dirección (alta, media, baja) en el proceso de transformación? Es decir ¿existe un apoyo para la cultura y prácticas DevOps?

15. El proceso de transformación ¿incluyó una fase previa de rediseño, optimización y/o estandarización de procesos de desarrollo, despliegue y entrega (ej. para reducir el número de aprobaciones fuera del equipo o el lead time) así como de stacks tecnológicos para todas las aplicaciones/servicios de la organización?

16. ¿Existe una medición o estimación aproximada de esfuerzo (en tiempo y personas) invertido en ese proceso de transformación “inicial”?

17. ¿Cuál es el alcance, a día de hoy, de la transformación? Topología DevOps (estructura del equipo).

18. La transformación DevOps ¿afecta a negocio/aplicaciones core de la organización, o más bien negocios secundarios (enfoque bimodal)?

19. ¿Podría afirmar que la cultura de la organización propicia el enfoque DevOps?

20. ¿Cuándo realizan selección de personal, buscan Ingenieros con habilidades DevOps?

Equipo DevOps (visión de un equipo en particular)

21. Tamaño del equipo DevOps:

22. ¿Cuál es la estructura del equipo DevOps (roles/capacidades)?

23. ¿Cuál es el rol (responsabilidades diarias) del entrevistado dentro del equipo DevOps?

24. ¿Hace cuánto tiempo que se formó el equipo DevOps?

25. ¿Qué metodología de desarrollo y/o gestión utilizan?

26. Si el proceso de desarrollo es iterativo ¿qué duración tienen las iteraciones/sprints? Si el proceso no es iterativo ¿tiene el equipo establecido el límite de Work in Progress (WIP)?

27. ¿Qué tipo de software desarrolla este equipo?

Practicas relacionadas con la Cultura

28. ¿Se promueve una cultura organizacional basada en la transparencia y la colaboración que permita romper silos?

29. ¿Se promueve una cultura basada en la experimentación continua y rápida que guíe el desarrollo y la innovación (experimental organizational culture)?

30. ¿Se promueve una cultura basada en el aprendizaje y mejora continua, tanto a nivel de producto y negocio como de proceso (ej. redefinir procesos, patrones de comunicación, etc.)?

31. ¿Se han promovido cambios culturales del tipo

     Disminución de la sobrecarga de la burocracia

     Reducción del número de aprobaciones fuera del equipo (construir confianza para acelerar determinadas aprobaciones)

     Empoderamiento del equipo (planificación, priorización, toma de decisiones)

Prácticas relacionadas con el Equipo

32. ¿Tanto desarrollo como operaciones se encuentran bajo la misma gestión/responsable?

33. ¿Tiene capacidad para auto-organizarse?

34. ¿El equipo es full-stack y multidisciplinario?

35. ¿El propietario del producto es parte del equipo? Si la respuesta es negativa ¿Quién especifica los requisitos y ‘features’?

36. ¿El equipo es autónomo? Es decir, ¿tiene alguna dependencia externa para acometer todas sus responsabilidades (hasta el despliegue y operación de la aplicación)?

37. ¿Se da formación al equipo en principios ágiles, DevOps, CI/CD? Escala de 1 (no existe oferta de aprendizaje) a 5 (oferta continua de aprendizaje).

38. ¿Existe coaching interno que ayude a identificar y atacar los impedimentos organizacionales que limitan la productividad y la calidad del equipo?

Prácticas orientadas a la Colaboración

39. ¿Considera que se han roto los silos y que se promueve la colaboración entre todos los stakeholders involucrados en el desarrollo y entrega del software?

     Colaboración puntual para traspaso de trabajo

     Colaboración, pero no hay cultura de un solo equipo, debido a problemas relacionados con el tamaño u organización del departamento de TI, recursos humanos, convenios, barreras culturales, etc.

     Alto grado de colaboración. Cultura de equipo, no hay silos. Se trabaja como un equipo único excepto seguridad

     Alto grado de colaboración. Cultura de equipo, no hay silos. (DevSecOps)

     Otro ____________________________________________________________

40. ¿Qué mecanismos de feedback y transparencia se utilizan dentro del equipo (desarrollo y operación)?

41. ¿Se realizan reuniones diarias?

42. ¿Se realizan reuniones regulares para hacer retrospectivas, reviews, grooming sessions?

43. ¿El equipo DevOps comparte la responsabilidad de entrega de nuevas características y funcionalidad de una forma estable (propiedad colectiva)?

44. ¿El personal de desarrollo y operaciones trabajan juntos diariamente?

45. ¿El equipo de operaciones se involucra en el desarrollo para entender qué entorno es requerido para soportar la aplicación?

46. ¿Los desarrolladores prestan atención a requisitos no funcionales, así como información de configuración (ej. scripts de despliegue, archivos de configuración) y demás actividades relacionadas con operaciones?

47. ¿El Control de Versiones es utilizado como mecanismo integral de comunicación entre los miembros del equipo (no solo código sino también infraestructura)? ¿proporciona una visión compartida del sistema, así como del estado del pipeline de producción?

48. ¿Se realizan reuniones post-mortem después de la detección de errores y se comparten los resultados para evitar que ocurran de nuevo en un futuro?

49. ¿El equipo de seguridad está involucrado en el diseño y desarrollo?

Prácticas orientadas a la Compartición (Sharing)

50. ¿El equipo comparte el espacio de trabajo (Dev y Ops)?

51. ¿Se utiliza la documentación (formal) como principal medio para compartir información o más bien otros tipos de medios menos formales (aplicaciones de chats, wikis, etc.)?

52. ¿Se promueve el uso de interfaces públicas (es decir se comparte código con otros equipos y se reutiliza código de otros), se reutilizan patrones tanto de desarrollo, pruebas, o despliegue?

53. ¿Existe una cultura que promueva que los empleados compartan sus ideas de mejoras de producto y proceso (experiencia, lecciones aprendidas, etc.) tanto de forma interna a la organización como fuera de la organización (conferencias, meetups)?

Prácticas orientadas a la Automatización

54. ¿Con cuántos entornos trabajan?

55. ¿Se ha adoptado un enfoque de desarrollo basado en ramas (branching), es decir, los cambios son desarrollados, probados, desplegados y mantenidos en una rama separada de la rama principal de desarrollo?

56. ¿Se ha implementado un enfoque de integración continua (CI continuous integration)? Entendiendo CI como la práctica mediante la cual los desarrolladores fusionan sus cambios con la rama principal (master/trunk branch) o la rama de la versión actual (release branch) de forma frecuente (small batch development), al menos 1 vez al día.

57. Para tal fin ¿se han definido procesos automatizados de compilación, empaquetado y pruebas? ¿se utilizan entornos de desarrollo/pruebas similares a los entornos de producción?

58. ¿Las herramientas de CI están integradas?

59. ¿Se crean pruebas automáticas como parte del trabajo diario? ¿Se aplica Test-driven Develoment (TDD)?

60. ¿Se automatizan tantas pruebas manuales como sea posible?

61. ¿Se realizan pruebas en todos los niveles? Escala del 1-5, donde 5 significa que se realizan todas las pruebas indicadas a continuación:

     Pruebas unitarias, análisis de código estático, análisis de cobertura de pruebas, comprobación de estilos, bad smells.

     Pruebas de usabilidad y aceptación.

     Pruebas de integración.

     Pruebas de seguridad, rendimiento, etc.

     Otros requisitos no funcionales

62. ¿Las herramientas de prueba están integradas con el resto de las herramientas?

63. ¿Se ha implementado un enfoque de entrega continua (CD continuous delivery)? Entendiendo CD como la práctica que automatiza el proceso de release, mediante el cual cada cambio que se sube al control de versiones se despliega y valida en un entorno similar al de producción mediante las pruebas pertinentes, asegurando, por tanto, que el software se encuentra en todo momento en un estado desplegable (green build)

64. ¿Sobre qué tipo infraestructura se despliega?

     Entorno virtual (ej. Vmware, VitualBox), contenedores (Docker, etc.), automatización u orquestación de imágenes virtuales o contenedores (ej. Vagrant, Swarm, Kubernetes, Mesos, etc.)

     Nube pública (ej. AWS, GAE, Azure, etc.), nube privada, otros (ej. OpenStack, Cloud Foundry, etc.)

     Creación automática a partir de “bare metal”: PXE, herramientas de configuración automática de sistemas operativos (ej. Red Hat Kickstart)

65. El equipo ¿ha automatizado la creación y configuración de infraestructura para entornos? (Infrastructure as Code, IaC) ¿Se utilizan herramientas para la gestión de la configuración de la infraestructura (e.j., Puppet, Chef, Ansible, etc.)

66. ¿Es posible crear y configurar entornos de desarrollo, pruebas, (pre)producción bajo demanda (environment self-service, on-demand)? Por ej. un desarrollador podría crear su propio entorno de pruebas sin tickets ni esperas.

67. ¿Los scripts de configuración para gestionar la infraestructura son versionados, validados (testing infrastructure changes), y repetibles?

68. ¿Cuál es la práctica habitual ante un cambio en la configuración?

     Configurar y reparar el entorno ya existente

     Es más fácil crear uno nuevo y tirar el entorno existente (principio de estructura inmutable)

69. La automatización de la infraestructura ¿permite en todo momento mantener la consistencia de los entornos por ej. los cambios son replicados en todos los entornos automáticamente?

70. ¿Se ha implementado un enfoque de despliegue continuo (CD continuous deployment)? Entendiendo CD como la práctica que automatiza el despliegue en producción, es decir cada commit/cambio que pasa todas las etapas del pipeline de despliegue se despliega automáticamente en producción sin ningún paso manual

71. ¿Las herramientas de automatización del proceso de release y despliegue (pipeline de despliegue) están integradas con el resto de las herramientas?

72. ¿Se han implementado mecanismos automáticos de rollback (andor cords & pull andor cords) para volver a un estado de código desplegable (build green) cuando el pipeline de despliegue se rompe?

73. ¿El pipeline de despliegue ha sido configurado para rechazar un commit que no lleve al software a un estado desplegable (build green)?

74. ¿Se hace visible si el pipeline de despliegue se rompe?

75. ¿Existe la cultura de parar el desarrollo cuando el pipeline de despliegue se rompe?

76. ¿Se utiliza algún patrón para desacoplar los despliegues de las entregas y reducir el riesgo de las entregas? Canary releasing, Blue/Green, Dark launching, Feature flags, A/B Testing, etc.

77. ¿Se ha automatizado la configuración de las políticas de seguridad?

Prácticas relacionadas con la Medición y la Monitorización

78. ¿Se implementan ciclos rápidos y continuos de feedback para producir las métricas suficientes para detectar y solucionar rápidamente problemas mucho antes de que los clientes sean impactados por dichos problemas?

79. ¿Se ha implementado una infraestructura de métricas centralizada tanto para desarrollo como para operaciones?

80. ¿Resulta fácil recuperar información de la infraestructura de métricas (mediante radiadores de información o self-service APIs)? Es decir, ¿son las métricas accesibles por todos los stakeholders relevantes: negocio, desarrollo y operación?

81. ¿Se crean métricas como parte del trabajo diario a todos los niveles?

82. Tipos de métricas

     Comportamiento de los usuarios

     Negocio (e.g., sales transactions, revenue of sales transactions, user signups, A/B testing results, etc.)

     Aplicación (e.g., transaction times, user response times, application faults, etc.)

     Entornos (e.g., server traffic, CPU load, disk usage, etc.)

     Pipeline de despliegue (e.g. code build/test/deployment history, lead times, deployment frequencies, test coverage, etc.)

83. Cuantitativamente, en una escala del 1-5 donde 1 (<10), 2 (10-20), 3 (20-30), 4 (30-40) to 5 (>40) ¿Cuántas métricas se generan?

84. ¿Se realiza análisis de anomalías sobre las métricas o se ha implementado algún sistema de alertas ante algún tipo de anomalías?

85. Lead time (cuánto tiempo tardaría tu equipo en desplegar un cambio sobre una línea de código y ponerla en producción en cliente)

86. MeanTimeToRecovery (MTTR).

87. Frecuencia de despliegues

88. Desarrollo y Operaciones ¿son incentivados por las mismas métricas?

89. ¿Se utiliza algún framework específico para medir el progreso de las métricas?

90. El equipo ¿puede definir sus propios criterios de monitorización y alerta?

91. ¿Se monitoriza el estado del software (salud, SLAs, rendimiento, disponibilidad del sistema)?

92. ¿Se monitoriza el proceso a i) qué pruebas fueron ejecutas en qué compilación, ii) cuáles fueron los resultados de las pruebas, iii) qué compilaciones han sido desplegadas y en qué entornos?

93. ¿Se monitoriza cómo los usuarios utilizan los sistemas y servicios con el fin de retroalimentar la planificación de negocio? (customer involvement).

94. Las herramientas utilizadas para monitorización ¿están integradas con el resto de las herramientas? Barreras

95. ¿Qué barreras se encontraron entre los empleados, la empresa y tecnologías para implantar DevOps?

96. ¿Se ha observa algún inconveniente derivado de adoptar DevOps? Resultados

97. ¿Cuáles son los resultados que se están obteniendo con la adopción de DevOps? Si los resultados obtenidos hasta el momento han satisfecho las expectativas