Luego de mi última publicación y de algunas conversaciones al respecto, confirmé que:

1. Un post no cubre todo lo que puede pasar por nuestras cabezas
2. No hay verdades absolutas
3. Siguen –y seguirán– existiendo los dueños de la verdad

Lo que también me quedó claro es que de cierta forma hemos perdido sentido o peor aún, hemos olvidado la naturaleza de un proyecto de desarrollo de software.

Sí, es cierto que hace mucho escribí sobre lo que se entrega al finalizar un proyecto, pero luego de reflexionar sobre ello, creo que vale la pena aclarar que las soluciones o productos que se entregan, respetan un ciclo de vida, el cual desde mi punto de vista se descompone en actores, procesos y actividades.

Para esto, consideré las siguientes premisas:

1. Todo proceso conlleva a un conjunto de actividades.
2. Un actor puede estar involucrado de manera general a un proceso o de forma particular a una o más actividades.
3. Para efectos prácticos, aplicación, sistema, producto y solución representarán lo mismo 🙂

Hasta el momento, mi propuesta se refleja en este diagrama:

En este diagrama, encontramos actores:

1. Usuario: Además del analista de negocio, se incluye al que trabajará día a día con el sistema. La experiencia indica que de él depende que este siga vigente.
2. Software Team: Principalmente el equipo de proyecto (jefe de proyecto, programación, pruebas) y el equipo operaciones, quien es el que administra u opera el sistema cuando este se libera en producción (mejora continua, redes e infraestructura)
3. Otros interesados: Incluye a aquellos que se benefician directa o indirectamente con el éxito del proyecto o con la rentabilidad generada por el sistema cuando este se encuentra en producción. Un ejemplo es el sponsor del proyecto.

Procesos:

1. Concepción: Espacio en el que la norma debe ser “todas las ideas son buenas pero hay que priorizarlas sin olvidar el retorno de la inversión”
2. Construcción: Vale la pena aclarar que este proceso involucra mucho más que el desarrollo del software y el respectivo pase a producción.
3. Operación: Indica que desde la salida en vivo de un producto, este debe mantenerse en observación constante.
4. Desactivación: Pues así como un sistema nace, también muere 😦

Y claro, actividades:

• Concepción / Colección: Actividad que va ganando formalidad mientras más información se tenga de la necesidad que se busca cubrir.
• Concepción / Priorización: Esta debe respetar un breve pero concreto análisis de impacto.
• Concepción / Kick off: Momento en el que todos los actores entienden la funcionalidad deseada y acuerdan iniciar su construcción y posterior entrega.
• Construcción / Diseño & Desarrollo: Actividad primordial de la construcción, lleva consigo sub actividades como estimación, delimitación de alcance y revisiones internas.
• Construcción / Verificación continua: Actividad de revisión que no necesariamente es interna. Debe involucrar al resto de actores para evitar ser vistos como juez y parte del producto que se está entregando.
• Construcción / Release: Representa a la entrega del producto, la cual no debe estar limitada en número pero tampoco debe afectar a la estabilidad del sistema. Una consecuencia importante es la transferencia al equipo de operaciones.
• Operación / Monitoreo Continuo: Actividad que debe medir el comportamiento de la aplicación. Aquí debemos aprovechar los indicadores generados gracias al diseño que hicimos o bueno, al uso de herramientas de application performance management. Estos indicadores deberían generar acciones de corrección o de evolución del sistema.
• Desactivación / Respaldo & Desinstalación: Aunque no lo crean, a veces se olvida la importancia de este punto y terminamos con sistemas zombie que nadie usa o de datos que perdimos luego de borrar un sistema.

¿Cuál es la clave de este modelo?

El factor diferenciador del modelo incluye por lo menos cinco aspectos:

• Retroalimentación: Las líneas punteadas del diagrama representan la naturaleza olvidada en los sistemas (y aquí hablo de algo que le molestaría mucho al maestro Ludwig). Todo sistemas debe retroalimentarse y sobre esto, generar una versión mejorada de sí mismo.
• Transparencia: Un ejemplo de esto, es que gracias a que la priorización incluye un análisis de impacto podremos entender si debemos o no entregar algo en un plazo cercano. O si el usuario encontrá utilidad en nuestro producto.
• Indicadores de salud: Así como debemos olvidar que la salud de un proyecto se mide por costo/tiempo/alcance, también debemos sacar de nuestras cabezas, que un sistema está bien si es rápido o si el usuario no se queja. No olvidemos que para lo segundo debemos estar dispuestos a brindar indicadores de uso de recursos (memoria, disco, red, procesador), picos de la aplicación, funciones más usadas, errores recurrentes o caídas de la aplicación.
• Herramientas: Así no estemos seguros de usar una herramienta, debemos empezar con una (pues no cuesta nada equivocarse)
• Automatización: Dicen que la rutina aburre y es cierto :), más vale automatizar que lamentarse por el tiempo perdido.

¿Qué recomiendo?

1. No confundamos este modelo con el proceso de desarrollo de software pues estamos hablando del ciclo de vida de una aplicación 🙂
2. No olvidemos que todos los miembros del equipo juegan un papel importante. Tampoco olvidemos que todos podemos aportar pero a su vez la priorización determinará el camino del producto a entregar.
3. La retroalimentación debe ser constante y si es visible para todos, mucho mejor.
4. Se deben evaluar acciones, decisiones y consecuencias, no a las personas.
5. Debemos utilizar prácticas ágiles:
   • Dicho esto, no recomiendo usar SCRUM a menos que nuestro equipo se conozca y tenga la madurez adecuada para respetar las ceremonias y roles correspondientes.
   • Si no cumplimos esa regla, pues tomemos sus elementos por separado y  por favor, no digamos que hacemos SCRUM (recuerda, es una metodología)
6. Usemos herramientas de colaboración como Trello o Jira & Confluence. El costo no es elevado y vale mucho más que una carpeta compartida localmente o en la nube.
7. Independiente a la herramienta de desarrollo, explotemos la gestión de versiones brindada por Github o Bitbucket. Ojo, tampoco abusemos 🙂
8. Orientemos nuestro trabajo a la automatización antes y después de la salida en vivo del producto.
   • Para integración continua he trabajado con TeamCity, TFS y Jenkins pero por si están por iniciar en este nuevo mundo, recomiento TeamCity
   • Posterior a la salida en vivo necesitamos ver lo que está pasando con nuestra aplicación y si no hemos implementado un framework de errores o mejor aún, uno de diagnósticos estamos complicados (quise decir fregados ustedes me entienden). Por mi parte he trabajado con Log4Net, Elmah y ahora con Log4J mientras aprendo a convivir con Splunk.
   • Adicional al diagnóstico que hayamos generado por nuestro lado, tenemos que darle paso a herramientas APM como New Relic (lo admito, soy un NR fan)

Y claro, nunca dejemos de lado a nuestro sentido común 🙂

Saludos,
JD

UPDATE: En la imagen dice “Respaldo & Desactivación”, debe decir “Respaldo & Desinstalación”