Buenos productos digitales

Buenos productos digitales

Buenos productos digitales

A veces queremos tener lo último en nuestros software o, por decirlo de una forma más amistosa, productos digitales y no es más que un deseo, lo cual esta bien, aunque no se debe subestimar que es lo que conlleva.

Existen diversas técnicas, métodos o formulas, demás esta decir que ninguna es infalible o una bala de plata, el problema es que si bien es cierto no se puede completar una etapa (y se puede andar bien con ello) no significa que no se tenga un mínimo o lo básico de esta, para explicar un poco he puesto una pirámide para mostrar de que va.

XP (Agile), DevSecOps o SRE, Continuous Approach

Pues bien, estas definiciones se encuentran en este orden, una sostiene a la otra, por lo tanto define que, tan débil sea la base de una condicionará a la otra a ser igual o más débil aún.

XP (Agile)

Es una de las metodologías que puede ver de forma holística la buena elaboración de un software (o producto digital por si se desea ver de esta forma), están basados en 12 practicas para el desarrollo de software que se complementan muy bien entre sí incluso llevándolos a un nivel extremo de su uso (de ahí el nombre eXtreme Programming), y esto solo para empezar puesto que si en el uso descubren y añaden una practica (llevándola al extremo) y encaja con las demás pues excelente, de eso se trata, uno puede ajustar y utilizar las prácticas que crea conveniente.

¿Que tiene que ver esto con Agile? pues vamos al título de la definición del manifiesto: Manifiesto for Agile Software Development, quiere decir que fue elaborado para el desarrollo de software y pues tiene 4 valoraciones y 12 principios, influenciado fuertemente por XP con 12 prácticas y 4 valores (originalmente), XP se basa en el paradigma de la programación orientada a objetos por lo que se puede deducir donde es más efectivo y en donde se estaría haciendo un benchmarking.

¿Scrum?, pues bien XP tiene prácticas que, para explicar la magnitud de ellas podríamos hacer una comparación con el sistema solar, digamos que cada práctica de XP son planetas, Scrum viene a ser un continente dentro de uno y otro planeta, quiere decir, es una parte de un planeta y parte de otro (involucrando solo 2 planetas). Por ello empezar a usarlo esta muy bien. ¡Recordando que aún faltan 10 prácticas y solo tenemos unas partes de 2 de ellas!

¿Resulta muy técnico? No, a diferencia de la creencia popular, XP (y Agile) están basado en las personas. Si las personas no tienen el pensamiento correcto los resultados pueden ser muy costoso o nefastos. Fin del asunto. ¿Kanban? Lamentablemente, las ideas poderosas de Kanban no son Agile.

DevSecOps o SRE

Pues en este punto necesitamos una base la cual es Agile, si no tenemos lo mínimo básico de Agile lamentablemente condicionará por mucho este punto. Mientras más fuerte sea Agile más robusto será este punto.

DevSecOps

¿DevOps? Si, para empezar tanto las palabras DevOps y DevSecOps son en escencia un solo mensaje: Priorizaciones, pues porque si DevOps nos dice que se necesita romper el silo, el muro o barrera que se crea en los intereses del desarrollo (DEVelopment) como el de operaciones (OPerationS), DevSecOps le añade el mensaje de la importancia de seguridad (SECurity), y podríamos aumentar las siglas (¿añadimos legal?) y llegaríamos a tener una palabra difícil de pronunciar y quizás con un propósito muy difícil de realizar.

DevOps (DevSecOps o las siglas que gusten) nos ayuda a centrarnos, y lejos de lo que popularmente se piensa en Automatizaciones y Herramientas, está centrado principalmente en la conversación y comunicación para romper los silos que impiden extender Agile.

SRE

Site Reliability Engineering encontró su nacimiento en base a ayudar a la confiabilidad, basándose fuertemente en las personas y su comunicación, alineando los esfuerzos principalmente en encargarse de que el software pueda funcionar bien en la mayor parte de su vida. Si haces SRE estas haciendo DevOps.

A todo esto, ¿se imaginan lograr estos puntos sin ser Agile?¿Itil? El camino Agile es más amplio.

Continuous Approach

El enfoque continuo, basándonos en un buen SRE o DevOps y a su vez, estos en Agile, queda hacer una priorización más específica, dentro de ellas, la continuidad, donde podemos conocer mejor cómo está el software, que tan bueno está nuestro producto digital que deseamos dar a conocer y reducir constantemente todo lo que impida mejorarlo. Este enfoque continuo es un conjunto de varios puntos de continuidad, que luego pueden ser ampliados o reducidos según la necesidad.

Como se menciona al inicio de esta artículo, no se debe descuidar enfocarse en tener siempre la base cada vez más robusta, no impacientarse en tener lo último para evitar llevarse costosas y desagradables sorpresas más adelante. Finalmente recordar que cada organización es única al igual que sus problemas y soluciones, nadie conoce mejor el producto que aquellos que trabajan día a día en ello.

Daniel Antonio Núñez C.

Esta obra está bajo una Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

Cómo dato adicional, por si desean entrenamiento pueden contactar a Inception Consulting quienes gustosamente podrán ayudarlo.