Un contratista aeroespacial y de defensa en una empresa pública puede tener entre 400 y 500 proyectos de desarrollo de software que deben pasar de
cascada
La respuesta – llamar a consultores – puede parecer obvia y, quizás, insuficiente. Pero el equipo de Sodo, o Ship On Day One, no es el equipo promedio de cabezas parlantes. Los cofundadores Eric Schoonover y Robert Duffy diseñaron un plan de 15 puntos que, según dicen, puede ayudar a cualquier organización, sin importar cuán inmersa esté en la cultura heredada, con el espinoso problema de cómo comenzar con DevOps. Duffy trae su experiencia de Amazon y Time a la mesa, mientras que Schoonover viene de Microsoft, Netflix
y
Debido a que ambos supervisaron las transformaciones de DevOps en empresas de tecnología no tradicionales como Time y el DOD, Duffy dijo que su perspectiva es única. De hecho, se apresura a señalar que él y su socio ni siquiera usaron el término «DevOps» durante su tiempo respectivo en Amazon y Netflix.
«Fue simplemente la forma en que hicimos la ingeniería de software», dijo.
¿Cómo empezar con DevOps? Los planes pequeños funcionan mejor
No se trata del nombre, sino de cómo ocurre el proceso.
«Hoy en día, existe una desconexión entre las nuevas empresas y las empresas más antiguas en lo que respecta a la ingeniería de software», dijo. «Muchas empresas todavía están realizando entregas de ingeniería como se hizo la fabricación del siglo XIX. Es un sistema basado en manualidades, que analiza el trabajo para diferentes equipos. Queremos ayudar a las empresas no tecnológicas a pensar en la transformación cultural. No se trata solo de mudarse a la nube y la instalación de Docker «. Para elaborar un plan sólido y repetible sobre cómo comenzar con DevOps, Duffy y Schoonover se reunieron con 150 equipos de desarrollo de software de «alto rendimiento» y escribieron sus observaciones en notas adhesivas. Redujeron sus notas a 15 capacidades, cada una con cuatro etapas, dijo Duffy. La idea no es abrumar a una organización, sino obtener claridad sobre lo que más importa y luego seguir adelante.
«Tratamos de llegar a un pequeño conjunto de elementos muy prácticos que ayudamos a seleccionar y que justifican los cálculos de ROI y los estudios de caso», dijo Duffy. «Ayudamos a las empresas a reconocer el tamaño del problema y atacarlo en pequeños fragmentos identificados para ganar credibilidad en el negocio».
DevOps como un continuo
Hablando con un gerente senior de ingeniería de un contratista de defensa que pidió no ser identificado,
El grande
Rob DuffyCEO y cofundador de Ship On Day One
«Queremos ver el desarrollo de software como un continuo. Pero en un espectro, tenemos la fruta madura en la que es fácil ver cómo hacer cambios, y en el otro espectro tenemos hardware y software personalizados que no son bajos. -Colgar fruta «, explicó el gerente. «Queremos tener el mismo tipo de sistemas para ambos, de modo que podamos tener CI y CD funcionando. Esa es el área que nos preocupa un poco».
Pero hasta ahora, ese proceso de «cómo comenzar con DevOps» ha funcionado, dijo el gerente senior de ingeniería, porque el equipo de Sodo no solo señala los problemas, sino que trabaja junto con el equipo para resolverlos.
«Nuestro CTO se ha dado cuenta de que realmente puede obtener algunas ganancias rápidas, con la administración, utilizando la terminología que usa Sodo», dijo. «Nuestros desarrolladores pueden ser quisquillosos y críticos, pero aceptaron al equipo de Sodo de inmediato. No vienen con la idea de saberlo todo».
Ya se le ha preguntado varias veces al equipo de Sodo: «¿Puede entregar este proyecto?» pero Duffy enfatizó que él y su socio están más interesados en enseñar a las empresas cómo comenzar con DevOps. «La paciencia es importante, pero también lo es el impulso», explicó. «Algo enviado por la puerta es realmente lo que predicamos».