jueves, 28 de abril de 2016
Implementando paradigma ágil a nivel de arquitectura
Para permitir el desarrollo flexible y adaptable de aplicaciones corporativas, además de adecuar la gestión y las tareas de desarrollo debe adaptarse la forma de diseñar, implementar y distribuir el sistema.
La metodología debe disponer de infraestructura y medios de automatización para asegurar la disponibilidad del sistema y la trazabilidad del proceso.
Para ser ágil se debe poder ver fácilmente el impacto de un cambio funcional o técnico en el sistema.
Manolo, el albañil filósofo
Dicen los expertos que hoy en día los niños tienen dificultades para leer un libro entero .. que se les desvía la atención, que leen entre líneas.. pero que por contra han desarrollado una gran habilidad para filtrar grandes volúmenes de información, relacionarla y saber dónde y cómo buscarla.
Desde ese punto, es normal que te cueste leer mucha información seguida.. su mente está acostumbrada a pensar "vale.. ya sé dónde está, ya sé de qué va, pero ahora mismo no me hace falta leerlo todo".
Esto es así.. o no.. dependiendo de qué tipo de información sea.Porque hayinformación que justamente es la que te ayuda a pensar y construir nuevas herramientas mentales.
Buscando por internet de forma autodidacta difícilmente se adquirirán los conocimientos equivalentes a un doctorado en Matemáticas.
Pero por otro lado, si tienes un objetivo definido tienes acceso a la información necesaria.
Por tanto, la información puede que sean los ladrillos.. pero, hace falta el cemento.. y.. muchas más cosas.. por ejemplo, saber qué quieres construir.
El conjunto de conocimientos "saber construir edificios" incorpora además de procedimientos, basados en ciencia, información operativasobre "cómo obtener los recursos, dónde, etc".. En mi carpeta de proyectos estárá también los teléfonos y tarifas de los proveedores.. eso también es información, pero no es del mismo tipo que las fórmulas de cálculo de resistencia de materiales.
Aún así, el conocimiento de "saber construir edificios" no incluye de por sí, el "saber hacer negocio construyendo edificios".
Pero, todavía hay más.. "saber hacer negocio construyendo edificios" no incluye el conocimiento de "saber tener una vida equilibrada cuando tu negocio es construir edificios".
De hecho, este conocimiento a priori requiere otro más genérico que es "autoconocimiento para determinar qué tipo de negocios es más acorde con tu personalidad, entorno y expectativas de forma que puedas tener un equilibrio entre expectativas personales y profesionales".. lo cual requiere un análisis previo para evaluar lo que son "expectativas" de lo que son "necesidades reales"..
A partir de aquí podemos seguir sumergiéndonos más y más en el estudio de las ciencias y LAS filosofías, porque igual que podemos diferenciar entre diversas ciencias, podemos diferenciar entre diferentes tipos de conocimiento.
"¿QUIERES MOVER EL CULOOO O QUE? ¡¡¡QUE LLEVAS UNA HORA Y NO HAS PUESTO NI DOS LADRILLOS!!"
Buscando por internet de forma autodidacta difícilmente se adquirirán los conocimientos equivalentes a un doctorado en Matemáticas.
Pero por otro lado, si tienes un objetivo definido tienes acceso a la información necesaria.
Por tanto, la información puede que sean los ladrillos.. pero, hace falta el cemento.. y.. muchas más cosas.. por ejemplo, saber qué quieres construir.
El conjunto de conocimientos "saber construir edificios" incorpora además de procedimientos, basados en ciencia, información operativasobre "cómo obtener los recursos, dónde, etc".. En mi carpeta de proyectos estárá también los teléfonos y tarifas de los proveedores.. eso también es información, pero no es del mismo tipo que las fórmulas de cálculo de resistencia de materiales.
Aún así, el conocimiento de "saber construir edificios" no incluye de por sí, el "saber hacer negocio construyendo edificios".
Pero, todavía hay más.. "saber hacer negocio construyendo edificios" no incluye el conocimiento de "saber tener una vida equilibrada cuando tu negocio es construir edificios".
De hecho, este conocimiento a priori requiere otro más genérico que es "autoconocimiento para determinar qué tipo de negocios es más acorde con tu personalidad, entorno y expectativas de forma que puedas tener un equilibrio entre expectativas personales y profesionales".. lo cual requiere un análisis previo para evaluar lo que son "expectativas" de lo que son "necesidades reales"..
A partir de aquí podemos seguir sumergiéndonos más y más en el estudio de las ciencias y LAS filosofías, porque igual que podemos diferenciar entre diversas ciencias, podemos diferenciar entre diferentes tipos de conocimiento.
"¿QUIERES MOVER EL CULOOO O QUE? ¡¡¡QUE LLEVAS UNA HORA Y NO HAS PUESTO NI DOS LADRILLOS!!"
Puff.. ya está mi capataz chillando..
Hay que decir que mi jefe se cree que soy un vago.. de hecho creo que cuando se acabe la obra me despedirá.Lo que él no entiende es que yo cuando veo un bloque de ladrillos estoy viendo la entropía del universo.
Ese es otro tipo de conocimiento "gestión de expectativas divergentes"
Hay que decir que mi jefe se cree que soy un vago.. de hecho creo que cuando se acabe la obra me despedirá.Lo que él no entiende es que yo cuando veo un bloque de ladrillos estoy viendo la entropía del universo.
Ese es otro tipo de conocimiento "gestión de expectativas divergentes"
Tu sistema está en riesgo: Necesitas un plan
Empezaste un sistema sencillo y ha crecido por encima de las previsiones.
Quisiste o te impusieron probar una tecnología y te das cuenta que te está complicando la vida o simplemente no cumple los requerimientos.
Aparecen requerimientos técnicos y no técnicos nuevos, las planificaciones no se cumplen, el equipo empieza a ir desbordado y la información comienza a disgregarse en silos (cada uno se parapeta en "lo suyo".. lo mío va.. aunque nadie sabe muy bien qué es "lo suyo").
La presión aumenta, se intenta mantener las planificaciones a base de horas extras y la facilidad casi mágica e infinita de las tareas de paralelizarse, al menos en un diagrama de Gantt.
No está bien claro quién es el responsable del proyecto, hay muchos interlocutores pero no está claro quién tiene que decidir qué y a medida que el proyecto se tuerce, muchos de ellos desaparecen o buscan perfiles más planos..
Los motivos pueden ser múltiples
pero la cosa no pinta bien.
No puedes hacer estimaciones fiables, porque tampoco tienes controlado lo que se está desplegando.. la urgencia te obliga a hacer entrega casi continua pero sin los medios para poder hacer pruebas unitarias, de integración, de regresión..
Primero.. necesitas valor para no ignorar los síntomas y escalar el problema.
Y segundo.. necesitas un plan para enfocar los problemas y sus vías de resolución.
Seguro que cuando salgas del hoyo tendrás muchas cosas que debatir, mejorar, herramientas que necesitabas y no tienes, cultura de empresa y organización, cómo reforzar el equipo para desterrar malas prácticas, quizás cambios en el proceso para facilitar la entrega continua, etc. pero en medio de la crisis no es el momento.
Hay que coger el toro por los cuernos con lo que tengas en ese momento.
Lo imprescindible:
1: Detener el desarrollo: Te va a costar, va a ser duro de negociar, pero, por eso necesitas un plan.. para ti y para comunicarlo.
No es lo mismo decir "tenemos problemas técnicos y necesitamos 1 mes".. sin más.. que especificar en detalle lo que se quiere hacer, por qué es necesario y qué problemas actuales y futuros soluciona.
Aunque la gestión de esta replanificación corresponde al Project Leader, es tarea del Responsable Técnico o Arquitecto, hacer un diagnóstico claro y transparente de la situación y el plan de estabilización.
2: Identificar y aislar los componentes / partes de código problemáticas.
En la estabilización se irán refinando pero hay que hacer una propuesta inicial de compartimentación.
3: Definir e implantar un mínimo plan de testing a nivel de estosgrandes componentes. Si no puedo probar todas las clases e interfícies, por lo menos que un problema generado en la ficha del cliente no me aparezca en el momento de guardar una factura.. etc.
4: Refactorización continua: El proceso de estabilización enfocado iterativamente permitirá ir reduciendo el tamaño y complejidad de los puntos oscuros del sistema, que inicialmente hemos encapsulado en cajas negras.
La encapsulación aqui nos permite ir eliminando/sustituyendo código y componentes de forma controlada.
Cuando ya tenemos el roadmap en marcha:
A partir del aislamiento de las partes problemáticas y la planificación de las prioridades de resolución es momento de contemplar (no antes) si puede ser productivo incorporar más gente al equipo, por volumen de trabajoo por necesidad de conocimiento experto específico.
Análisis post-mortem:
Es una buena práctica porque permite aprender de los problemas y mejorar en conjunto, aunque no siempre se hace y menos en los proyectos que han sido problemáticos.. ya que en caliente se corre el riesgo de caer en personalismos no del todo profesionales.
Más que un careo debería ser una fuente valiosa de propuestas de mejora.
Es momento de recuperar la wish list que querías plantear en medio de la crisis y debatirla con espíritu constructivo.
La calidad de un equipo también se consolida iterativamente.
Etiquetas:
ALM,
Deuda técnica,
Metodología,
Refactoring
Dev Ops y Entrega Contínua
Uno de los principales problemas de los equipos de desarrollo "ágiles" es la dificultad de serlo cuando el resto de la organización no.
Desarrollo iterativo, Pruebas automatizadas, integración contínua.. agilidad en desarrollo pero no en el traspaso de entornos, distribución, etc.
La propia estructura operativa de las grandes empresas crea esta división interpretando que sistemas /operación y desarrollo son dos compartimentos estancos con procedimientos e intereses diferentes.
Esto nunca ha funcionado, justamente porque el producto final para el usuario lo es todo.. es el software en la plataforma que corre.. le da igual que "en tu máquina funcione" o "en mis logs no sale nada.. por lo tanto .. todo está correcto".
Y como no funciona, al tener departamentos independientes.. aparecen las eternas "guerras" entre sistemas y desarrollo..
A nivel individual a veces se crean dinámicas colaborativas pero la situación no lo propicia.. muchos técnicos son recriminados por ser proactivos y mirar por qué puede fallar una aplicación o desde el otro lado, revisar la configuración de seguridad junto con el administrador.
El problema no es de los técnicos.. es el concepto de departamentos con la mentalidad de "no les vamos a hacer nosotros su trabajo".. "si esto depende de nosotros que nos lo demuestren".. etc.
Pero la demanda real es cada vez más fuerte y más exigente.
En un entorno profesionalizado tus procedimientos, metodologías, equipos e infraestructura deben estar preparados para poder proporcionar entrega contínua.. y la entrega engloba todo el ciclo de vida del producto.
Esta demanda actualmente se está etiquetando como "DevOps", que como cualquier "tag" con tendencia siempre corre el peligro de verse más como una moda que como algo sólido y coherente, pero independientemente de ello la necesidad de que el paradigma ágil se aplique transversalmente a todo el ALM incluyendo la infraestructura y despliegue subyace.
La tecnología ayuda pero como siempre el éxito o no depende de que haya la cultura apropiada.
https://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf
Release management: Indicadores y mejora contínua
Share on Twitter
La Ingeniería de Software en la actualidad plantea muchos paralelismos con la Ingeniería Automovílística de competición.
En el momento en que una escudería se plantea la creación de un nuevo modelo se abre una fase de investigación y diseño: cuáles serán las nuevas prestaciones y características, diseños, componentes, proveedores, costes, alianzas estratégicas, sponsors, etc.
Una vez el proyecto está en marcha se producen muchos prototipajes, pruebas en túneles de viento, etc.
Algunas de las decisiones críticas en esta fase es determinar en que momento se cierra el diseño y en que grado soportará actualizaciones y desarrollos a lo largo de la temporada.
Después de un proceso tan complejo llega el momento de las pruebas reales y la entrada en competición.
A partir de aquí el uso de la telemetría y todos los indicadores objetivos de los que se pueda disponer es crucial para un control efectivo de la evolución del producto.
En el caso de productos de software si recolectamos los indicadores de Release Management de la metodología ITIL podemos obtener información muy útil para hacer un seguimiento de la calidad del proceso y del producto.
Relativas a plataforma, software base y gestión de la configuración:
- % de instalaciones con éxito
- % de actualizaciones de software con éxito
Disponibilidad / Fiabilidad
- Promedio de tiempo entre entregas urgentes
- Costes y eficiencia
- Coste promedio por entrega
- Coste promedio de despliegue
Calidad de la entrega
- % de entregas con éxito
- % de entregas que han causado incidentes
- % de entregas que se han tenido que cancelar y restaurar a la versión anterior
Calidad de los métodos de prueba
- Número de defectos detectados en producción
- Número de entregas no testadas
- Número de entregas urgentes
- Número de incidencias originadas por la instalación de una nueva versión
- % errores detectados en entregas urgentes testadas vs entregas urgentes no testadas
Interpretando los indicadores:
Dado que los indicadores se van alimentando con cada entrega nos puede dar una visión dinámica de la evolución del sistema.
El aumento o decremento de un indicador en concreto puede ser predecible según la fase del proyecto.
En general es normal que en las primeras instalaciones hayan más problemas de integración y despliegue.
Un aumento de problemas en un momento concreto del ciclo de vida del sistema nos indica que es probable que haya habido un cambio en el software base, gestión de la configuración/políticas o se hayan desplegado componentes nuevos.
Cuando el indicador es creciente nos revela que no tenemos control sobre la plataforma o configuración. Es recomendable revisar si esto se está gestionando y se están documentando los cambios.
Superando los problemas iniciales de integración, los indicadores de Disponibilidad/Fiabilidad, Calidad de la Entrega y Calidad de los métodos de prueba nos ayudan a detectar si el sistema se está degradando.
Si los costes por entrega van en aumento es posible que empecemos a tener problemas de mantenibilidad. Cada modificación cuesta más, se tarda más, es difícil de probar, surgen más errores y las entregas se retrasan.
Aquí estamos en un punto muy peligroso si no se interviene de forma efectiva:
Cuanto más se retrasan las entregas más presión existe con lo cual se incrementa el número de peticiones de actualización urgente.
Si no existe un procedimiento test y conciliación a posteriori de los cambios introducidos en el sistema de una manera poco controlada se incrementa el nivel de desinformación / desactualización que provoca más fallos o que los sistemas de test sean cada vez más ineficaces al no estar actualizados.
Una vez detectados los parámetros en los que nuestro proceso se mantiene estable (por ejemplo, cada entrega necesitamos un mes, una actualización urgente nos supone la pérdida de una semana de trabajo, cada despliegue son dos días, etc), tenemos dimensionada nuestra capacidad de producción.
Si se determina que el proceso de desarrollo no tiene la eficiencia esperada hay que revisar el ALM (Application Lifetime Management) para detectar dónde están los cuellos de botella: ausencia de herramientas de diagnóstico y pruebas, herramientas/entorno de desarrollo precario, problemas de falta de información sobre los requerimientos / incidencias reportados, mal funcionamiento de componentes o productos de terceros, necesidad de capacitación del equipo de desarrollo, etc.
A partir de aquí en función de la información obtenida hay que realizar un plan de acción para reforzar los puntos débiles detectados.
Dependiendo del tipo de acciones necesarias esto no podrá realizarse siguiendo el ciclo de vida ordinario del proyecto ya que, por ejemplo, un cambio de tecnología o la refactorización de procesos clave pueden requerir undesarrollo en paralelo con los sobrecostes de la integración futura.
Otro punto clave llegados a este caso es decidir si seguir evolucionando el modelo de este año.. o dejar de evolucionar este motor e invertir los recursos en uno nuevo.
Esta es una decisión estratégica ante la cual hay que tener el compromiso de todos los actores implicados ya que se tiene que tener claro que al menos en dos años no se puede optar al podium
Suscribirse a:
Entradas (Atom)