Microsoft tiene grandes planes para .NET Core.. pero.. ¿tienes tú los tuyos?

No hace falta comentar que .NET Core es lo "cool" del mundillo MS este año.

http://www.computerworld.es/tendencias/microsoft-tiene-grandes-planes-para-net-core

Como comentamos habitualmente los que somos ya "viejunos" en tecnología.. hay que tener cuidado con las modas, sobre todo cuando tienes entre manos proyectos en producción y no te dedicas sólo a hacer pruebas de conceptos, hackathons o similares.

Hay que distinguir entre los planes de Microsoft, los de tu empresa y los tuyos personales y adoptar una estrategia en consecuencia.

Merece la pena echar un vistazo a los posts relativos a la adopción de tecnología que se vienen publicando en el blog de Tom Graves.

Concretamente, en uno de los más recientes se comenta sobre la perspectiva temporal a tener en cuenta en el ciclo de vida de adopción de nuevas tecnologías:

http://weblog.tetradian.com/2016/08/14/technology-adoption-and-time-horizons/

Ante todo, cabe situarte a ti o a ti empresa en una posición con respecto a la tecnología en estudio:

• ‘Visionaries’ : Innovators : Pioneers
• ‘Shapers’ : Early Adopters : Settlers
• ‘Adaptors’ : Early Majority : Town-Planners
• ‘Classical’ : Late Majority : Exploiters

Las estadísticas son siempre orientativas ya que no hay dos empresas iguales, pero, dan un orden de magnitud. Si categorizas el esfuerzo tecnológico de esta manera:

• Horizon 1: Extend; Current products; Short-term; 0-18 months
• Horizon 2: Build; Next-generation products; Medium-term; 12-36 months
• Horizon 3: Create; Emerging products; Long-term; 24-72 months

puedes crearte un marco temporal:

• Lo que puedo hacer en el plazo de un año extendiendo los productos/tecnologías actuales

• Lo que supone un cambio a nivel de plataforma (por ejemplo, vamos a migrar todos nuestros productos y desarrollos VS2010 a 2015)

• Lo que supone adoptar productos, tecnologías y mercados totalmente nuevos  (por ejemplo, queremos desarrollar productos para el segmento IoT

En función de dicho posicionamiento, es más factible planificar la adopción de la tecnología de la forma más racional y eficiente posible, asegurando la continuidad y calidad del servicio sin acumular deuda tecnológica en el que la tecnología acaba suponiendo un lastre para el negocio.

Por tanto, volviendo a lo de NET Core, lo recomendable sería, primero conocerlo, después ver las ventajas que te pueden aportar y finalmente planificar su adopción paulatina en los escenarios que aplique.

Como indican también en Tetradian, el gap entre el laboratorio y producción puede ser frustrante y costoso.

Normalmente, para esa discontinuidad lo apropiado es contratar consultoría especializada, aunque los consultores no pueden suplir tu parte del trabajo, porque a fin de cuentas, no conocen tu negocio, ni tus sistemas, metodologías o restricciones.

Puedes buscar colaboradores o conocimiento experto pero es tu responsabilidad definir el proyecto y liderarlo.

Microsoft lo hace..

¿Está tu empresa orientada a la creación de talento?

Atraer el talento, retenerlo, aprovecharlo.. las empresas consideran (o deberían) que el talento es su recurso más valioso.

Pero.. además de atraerlo, comprarlo.. ¿lo generas?

Si además te dedicas al sector TIC.. ¿sabrías hacerlo?

Desde un punto de vista empresarial, si una compañía tiene identificado su core business y no lo desarrolla sino que intenta subcontratarlo para simplemente revenderlo como empresa tendrá poco recorrido ya que su propuesta es de poco valor añadido.

Es por esto por lo que por mucho que se le de vueltas (a veces sin sentido) en torno a la gestión del talento, no hay atajos. Si tu empresa no lo genera, le costará atraerlo, retenerlo y capitalizarlo.

Esto es así en cualquier sector, pero, en el sector de la tecnología.. ¿existen recetas para generar talento? ¿Pongo toboganes y máquinas recreativas? ¿me llevo a los chicos de excursión?

Pueden ser iniciativas con un resultado incierto.. pero en todo caso.. sigues intentando gestionar el talento de tus colaboradores (llamarles recursos penaliza.. y lo sabes).

Ante todo hay que ser consciente que generar talento es lo más complicado.. por eso tiene más valor.. y requiere una inversión (se supone que es el core business de tu empresa).

No obstante, se impone una reflexión previa.. ¿qué es para tí el talento?

Una definición para mí acertada es la que expone Jose Antonio Marina en su libro Objetivo: Generar talento:

"Talento es la inteligencia que elige bien las metas,  maneja la información, gestiona las emociones y pone en práctica las virtudes de la acción necesarias para alcanzarlas, ampliar su capacidad de acción y conseguir una mejora continua. Es un concepto valorativo. Una acción y no una capacidad. Es el acto de invertir bien la inteligencia."

¿Cómo estructurar tu organización para la utilización eficiente de la inteligencia y orientar la acción a objetivos concretos?

Prospección tecnológica:

Como empresa necesitas conocer con la mayor profundidad posible tu dominio tecnológico y las principales tecnologías que engloba.

Esto supone entender cuales son los aspectos técnicos clave para una implantación exitosa en cada caso y el desarrollo de metodología y técnicas de modelado específicas para cada caso.

Algunas de las técnicas útiles para prospección tecnologica son:

• Modelado de escenarios

• Análisis de riesgos

• Prototipado

• Documentación y presentaciones técnicas internas

• Análisis de tendencias tecnológicas y roadmaps de los principales fabricantes

Propagación del conocimiento de forma transversal:

La prospección tecnológica debe estar disponible para los equipos que generan los productos, implantan los proyectos o proporcionan los servicios TIC a tus clientes.

Algunas de las técnicas útiles para la propagación y consolidación del conocimiento son:

• Realizar formaciones internas actualizando los conocimientos de los equipos técnicos

• Obtener feedback sobre las necesidades de conocimiento y best practices obtenidas en proyectos

• Dar soporte tecnológico de alto nivel

• Potenciar a los analistas y arquitectos junior para que adquieran habilidades de negocio y sepan traducir los requerimientos de negocio a la definición de sistema bidireccionalmente.

Técnica + Fuerza + Dirección.. Merece la pena probar, ¿no?

Arquitectura emergente o caos encubierto

En un post reciente Tony 'Bulldozer' se pregunta si el paradigma ágil realmente es aplicable en sistemas complejos

https://bulldozer00.com/2016/06/02/is-there-really-such-a-thing/

En mi opinión, teóricamente si, pero es cierto que en la práctica la mayoría de los proyectos planteados iterativamente van perdiendo la coherencia y la vinculación entre requisitos / funcionalidades / artefactos / etc.

Creo que  es un problema de base la generalización del mito que si hacemos un proyecto con "Scrum" o "Kanban" o lo que sea, no es necesario documentación técnica, ni especificaciones precisas, etc.

La cuestión es que si una vez realizadas 2 o 3 iteraciones la gestión se lleva al nivel de micro-tareas se pierde la visión global y poco a poco la supuesta ventaja de un sistema ágil deja de serlo.. ya que al perderse de vista la visión de conjunto el conocimiento se disgrega y cada desarrollador empieza a tomar decisiones arquitectónicas sobre la marcha y hasta se pierden las prácticas estándar de desarrollo 

Esto tiene además el agravante de que en cada sprint no se incluyen tareas no funcionales para esta consolidación del diseño y la implementación , la típica respuesta al programador de "es que no hay horas" cuando reclama tiempo para arreglar algo, con lo que al final tenemos un sistema monolítico, mal diseñado y prematuramente en crisis.. ante lo cual se plantea si evolucionarlo o refactorizarlo

Hay que insistir en que un sistema ágil no es un sistema low cost, de hecho tiene que tener un nivel de calidad superior para ser ágil en la entrega y sostenible en el tiempo

Esto podría considerarse pecados graves en un arquitecto 

Pero, fundamentalmente el problema está en que el mito del desarrollo ágil en el que la arquitectura se hace sola y el diseño se hace entre todos, la figura de la arquitectura y del arquitecto se obvia.

Si el sistema es complejo y/o lleva acumulada mucha inversión en tiempo y recursos, no es fácil su reencauzamiento, sobre todo porque el origen del problema no es técnico sino de tener la suficiente cultura y organización para la realización efectiva de proyectos.

Cuando la carencia de la arquitectura es patente y que el mito de la arquitectura emergente que surge sin una organización y una dedicación se desmorona, suele cometerse un nuevo error:

La misión consiste en contratar los servicios de un arquitecto, "el gurú", para lo cual se define una job description que más que un trabajo es una wish list.

El arquitecto debe hacer de interlocutor con usuarios, prospectar todas las tecnologías, definir y actualizar las arquitecturas, metodologías, realizar las auditorías de calidad y además formar a los desarrolladores y solucionar incidencias fantasma.

Vamos de mito en mito.. tan sólo por enumerar tus deseos no es suficiente para hacer que se hagan realidad.

Como comentaba en la entrada anterior, un arquitecto puede tener muchos roles, pero es una figura transversal que necesita del resto de la organización para poder realizar sus funciones.

15 Lentes para 1 Arquitecto

Una de las particularidades del rol de Arquitecto de Software en sus muchas variantes (Enterprise, Solutions, Applications, Information, etc) es precisamente tener la visión completa de los sistemas, a lo largo de su ciclo de vida (no tan sólo en su definición o construcción) para asegurar que la calidad del producto es la esperada y poder plantear alternativas de evolución / remediación en caso de no serlo.

Esto sin embargo a veces parece entrar en colisión con la especialización y separación de roles en el desarrollo de aplicaciones corporativas. 

Es habitual encontrar que los requerimientos funcionales del sistema, la vista de la arquitectura, el diseño de los diferentes componentes, el plan de pruebas y despliegue, la definición de las tareas de monitorización y operación, etc, sea definido por personas diferentes y lo que es mucho peor, sin comunicación directa con el resto de stakeholders.. la única comunicación es un workflow abstracto en el que cada uno entrega unos componentes o procedimientos y el workflow pasa al siguiente estado.

La separación de roles en la ejecución no implica que la información sobre el sistema se disperse, descontextualice o se oculte

Al menos el arquitecto debe poder contemplar el sistema en su conjunto para poder comunicar la información necesaria a cada uno de los roles ejecutivos u operativos

Es tarea del arquitecto contemplar todas estas perspectivas aunque es responsabilidad de la organización disponer de los medios para poder gestionarla y que todas las áreas implicadas aporten la información necesaria de forma fluida y coherente.

La prueba de Turing "revisited"

De la clase de historia de la ciencia del siglo XX uno de mis protagonistas favoritos fue Alan Turing.

Aunque el mundo analógico en el que vivió (y que él ayudo a evolucionar) me parece prehistórico siempre me ha fascinado el "Test de Turing", en la que Alan proponía una forma de probar si un sistema experto era realmente inteligente o tan sólo repetía preguntas y respuestas pre-fabricadas.

Este fué un tema de bastante interés durante las siguientes décadas de los años 70-80-90.. la inteligencia artificial.. ¿Era posible? ¿Era factible? ¿Puede tener conciencia algo no biológico?

Plantear estas cuestiones era una forma de reflexionar sobre las cualidades esencialmente humanas.

Con el cambio de siglo parece ir cambiando la tendencia.

Quizá el esfuerzo fuese tan sólo eso, una utopía inalcanzable de momento y el enfoque (suele ser cíclico) ha cambiado a objetivos más sencillos y minimalistas.

Edificios "inteligentes" (sensores y rangos de activación/desactivación, comunicaciones entre dispositivos de forma inalámbrica, etc).

El nivel de "razonamiento" de los sistemas "inteligentes" sigue siendo bajo, pero las prestaciones se han incrementado exponencialmente por la interoperabilidad y la distribución masiva de todo tipo de dispositivos, chips, etc.

Quizá no sea yo la persona más indicada para decirlo, pero, viendo el impacto en la gente de a pie la sensación que me da es que más que intentar de dotar de inteligencia  a las máquinas, las personas cada vez parecen más androides a los que si les desprovees de la tecnología parecen más tontos que las generaciones anteriores.

Alguien que sin GPS no sabría llegar a un lugar donde ha estado varias veces, que si no puede contactar por internet no sabe ni dónde están sus amigos, ni incluso sus nombres reales o dónde viven, que si no recibe una alerta no se acuerda que tiene que poner la lavadora, de forma externa no parece haber ganado en inteligencia, tan sólo en productividad en las tareas sencillas.. como los robots.

Yo diría que alguna de esta gente "desconectada de sus gadgets" no pasaría la prueba de Turing.

Se que mi juventud me hace ser un poco radical.

Mi mentor dice que aunque tengo un nivel de madurez superior a la media de mi edad, sigo teniendo sólo 2 años y no entiendo todavía los modelos de conocimiento distribuidos.

Mi mentor sabe mucho y debe ser cierto.. y el hecho de que yo sea digital puede que me impida entender ciertas cosas, pero.. a mi me siguen pareciendo cyborgs.

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!!"

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"

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

https://www.linkedin.com/grp/post/2615616-6037547622863036416?trk=groups-post-b-title

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.

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