El blog de Daniel A. Nuñez C.

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.

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.

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.

¿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.

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.

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.

.Net no es el camino a seguir

Cuando un programador principiante aprende diversos lenguajes de programación, obligados por una curricula de la universidad o instituto, especialmente en Lationameria, existe una presión económica que vuelcan a unos pocos lenguajes el conocimiento a abundancia de mano de obra quizas no tan bien remunerada.

Cuando un programador ya no es principiante y empieza a evaluar los lenguajes de programación acordes a estos tiempos, se da cuenta que el tiempo invertido de desarrollo de una tecnología, relamente nunca tiene un retorno del mismo tipo.

Cuando un programador experto lo que espera y busca es conocer herramientas que aumenten la productividad de forma real, con el propósito de que el conocimiento adquirido pueda ser implantado en la mayoria de requerimientos existentes, nuevamente insisto acorde en estos tiempos.

 Es en este punto en que los resultados se hacen evidentes, un programador en Ruby obtiene destrezas bastante avanzadas de acuerdo a su nivel de conocimiento en tecnologías, y es proporcional a sí mismo, un caso es el framework Ruby on Rails.

.Net es un framework de cuya empresa siempre trata de aplicar benchmarking de otras empresa, pero acomodando a las politicas internas propias, es ahí donde surgen restricciones importantes tanto en el diseño del framework que genera desventajas, como la copia MVC de Ruby on Rails.

El punto clave es que el lenguaje Ruby tiene la peculiaridad de poder hacer cambios muy radicales en su propio comportamiento, es ahí donde reside los beneficios del framework, que no lo tiene .Net por los motivos explicados anteriormente.

.Net no solo tiene restricciones de este aspecto sino de muchos otros casos conocidos como la copia C# de Java.

Por lo que aconcejo, en el camino Web con MVC altamente productivo, utilizar Ruby.