Proyectos de Software de 1 persona (P1P)

Estoy convencido de que no existe ninguna cosa bien hecha que haya sido realizada por una sola persona. Incluso obras de arte como la capilla sixtina o la piedad requirieron asistentes y soporte de muchas otras personas además del autor a quien se le atribuye (sin desmeritarlo). Sin embargo, existen también multiples circunstancias donde se desarrollan productos de software (y en otras áreas) que son diseñados, construidos, implementados y soportados por una sola persona. Estos productos pueden ser de tipo hobby o proyectos universitarios, proyectos de voluntariado e incluso productos comercialmente viables, al menos en sus inicios.

En esta publicación abordaremos diversas consideraciones importantes para el desarrollo, implementación y soporte de productos de software por una sola persona tomando como base la metodología SCRUM.

El mito de los P1P’s (proyectos de 1 persona)

Tengo la experiencia de haber desarrollado e implementado diversos productos de software por mis propios medios; es decir sin un equipo de software dedicado al diseño, desarrollo y soporte del producto. Acá menciono tres ejemplos mas o menos triviales:

1. Vamos a Misa punto ORG: Es una herramienta web que le permite a parroquias de la Iglesia Católica en Costa Rica, programar misas y que sus feligreses puedan asistir a estas mediante reserva con el fin de asegurar un aforo adecuado, principlamente como respuesta a la pandemia de COVID 19 (https://vamosamisa.org).
   
2. Pokerphase: Sistema de votaciones anónimas de bajo sesgo para proyectos SCRUM (https://pokerphase.c9eb.space)
   
3. El Juego de las Tablas: Un sencillo juego para niños que les permite repasar y memorizar las tablas de multiplicar. (Juego de las Tablas de Multiplicar)
   
4. Next-biz-date: Una biblioteca de NPM que permite calcular el siguiente día hábil basándose en un cronograma de días feriados, una fecha de inicio y una cantidad de días a contar. (https://www.npmjs.com/package/next-biz-date)

Aun cuando en efecto yo realicé estos proyectos por mi propia cuenta, o «con un equipo de 1 persona» por decirlo de forma coloquial, la realidad es que ninguno de estos productos habria sido realidad sin el soporte de muchas personas, desde mi esposa y mis hijos que me dan retroalimentación, hasta las tareas de hogar que dejé de realizar y que otras personas hicieron por mí.

En otras palabras no existe el logro personal sin el esfuerzo continuado y muchas veces anónimo de incontables participantes.

Dicho esto, esta publicación se enfoca en estos proyectos donde uno es el que realiza y coordina las tareas directamente relacionadas con el proyecto (diseño, arquitectura, construcción, pruebas, implementación, mantenimiento, mejoras, etc)

Una categorización básica

Podemos modelar el problema de los «proyectos de 1 persona» (p1p) dividiéndolos en dos categorías basándonos en sus necesidades de mantenimiento en el tiempo:

1. Productos de entrega-y-olvido
   
2. Productos de ciclo de vida prolongado

Los productos de entrega-y-olvido son aquellos que desarrollamos y demostramos en un punto en el tiempo y luego simplemente los lanzamos al olvido, es decir no requieren mayor mantenimiento ni mejoras con el tiempo. Ejemplos de esta categoría son los proyectos para cumplir con cursos universitarios, así como algunos proyectos de código abierto de bajo perfil. En mi lista puedo mencionar el juego de las tablas, y next-biz-date.

Los productos de ciclo de vida prolongado son aquellos que se desarrollan y se implementan y que requieren mantenimiento en el tiempo. En mi lista el mejor ejemplo es vamosamisa.org que requiere mantenimiento constante, y adaptación a las nuevas necesidades de sus clientes conforme evoluciona la pandemia.

Algunos productos pueden traslaparse entre estas dos categorías. Tal es el caso de pokerphase, el cual podría no dársele mayor mantenimiento en el futuro, pero servir a miles de clientes al rededor del mundo.

En resumen, los elementos a considerar para el desarrollo e implementación existosas de un producto de software tipo P1P varían dependiendo del ciclo de vida y las necesidades de mantenimiento del producto.

SCRUM adaptado

Las metodologías de tipo ágil como SCRUM son el pan de cada día en el desarrollo moderno de productos de software. Estas metodologías favorecen la sana interacción de los equipos de desarrollo mediante la definición clara de roles, actividades (ceremonias) mediante modelos iterativos que permiten al equipo crecer en integración, calidad y compromiso.

Existe un consenso tácito en la industria de desarrollo sobre los límites de escalabilidad respecto al tamaño de los equipos SCRUM. Se estima que un equipo saludable oscial entre 4 a 6 desarrolladores más otros roles como Scrum Master, Product Owner, stakeholders, etc.

Roles

En un proyecto P1P, todos estos roles son asumidos por la 1 persona que conforma el «equipo de desarrollo»:

1. Propietario de Producto: La persona que define y mantiene el backlog
2. Stakeholder: La persona con mayor interés en el sano progreso del proyecto. Usualmente un inversionista.
3. Scrum Master: Quien provee orientación al equipo sobre la metodología SCRUM
4. Desarrollador: Quien construye/codifica el producto.
5. Control de Calidad: La persona encargada de probar de forma objetiva el funcionamiento integral del producto luego de cada cambio.
6. Líder Técnico: La persona que más conoce de las tecnologías usadas en el producto. Provee al equipo de una guía sobre las tecnologías y métodos técnicos utilizados.
7. Arquitecto: Quien define el uso de tecnologías, componentes e interacciones entre esos componentes.
8. Líder de Equipo: Líder que conoce del negocio, del producto y de la industria de desarrollo y provee coaching en las diversas facetas del proyeccto.

Ceremonias:

La metodología SCRUM está basada en una serie de actividades recurrentes o ceremonias. Todas estas ceremonias pueden adaptarse al entorno de P1P toda vez que la persona dedique el tiempo recurrentemente para realizar estas actividades de forma conscienzuda y dedicada, siendo una sola persona, sería más bien dedicar el tiempo de forma reflexiva:

Diseño y Planeamiento de Producto:

Consiste en dedicar un tiempo razonable a entender las necesidades del cliente, a definir y diseñar el producto y planear el desarrollo en términos de un «backlog» o lista de historias de usuario (user stories) y grupos de funciones (epics) que se deben desarrollar para completar el producto. Este tiempo que puede ser también iterativo, se debe incluir aspectos de diseño de arquitectura de alto nivel. Para este efecto puede ser útil la metodología BDAT para definición de arquitectura.

Poda del Backlog

Esta actividad consiste en tomar cada historia de usuario y agregar detalles, aclarar dudas de forma que se pueda considerar como «lista» respecto a una definición adecuada de «listo» (definition of ready)

En general cada historia de usuario debe tener:

1. Descripción en términos de «Como <rol> quiero que <requermiento> con el fin de que <valor>«
2. Criterios de aceptación, es decir una lista de cosas que debe cumplirse para considerar la historia de usuario como realizada.
3. Todas las preguntas o dudas deben haberse resuelto.

Planeamiento de Iteración

En esta actividad se toma un conjunto de historias realizable para la siguiente iteración (usualemente 2 semanas) y se estima el esfuerzo necesario para cada una. En el caso de P1P’s se puede pensar en iteraciones diarias o semanales. Cada historia es evaluada en términos de incertidumbre, dependencias y cantidad de esfuerzo y se estima el peso en puntos (1,2,3,5,8,13). Una vez que una historia de usuario tiene una estimación en puntos, se puede considerar «lista» para ser ejecutada en una iteración.

Se eligen las historias de usuario estimadas que quepan en la siguiente iteración y se realiza un compromiso (personal en el caso de los P1P) de realizar todas las historias elegidas duante la siguiente iteración.

Ejecución de Iteración / Actualización Diaria

En un equipo normal SCRUM, se realizan reuniones diarias de actualización en las que los miembros del equipo comunican entre sí los avances que han tenido, las dificultades que han enfrentado, los planes para el siguiente día y las situaciones de bloqueo que pudieran estar enfrentando.

En el caso de un proyecto P1P, esta ceremonia refiere a sacar diariamente un tiempo no mayor a 15 minutos para reflexionar en esos mismos 3 aspectos. (1) avances realizados, (2) planes siguientes, (3) problemas o bloqueos.

Demostración de Iteración

En un equipo SCRUM normal, al final de la iteración se realiza una demostración a los stakeholders y al resto del equipo de cada nueva funcionalidad o del valor agregado por cada historia de usuario ejecutada.

Para los P1P’s de nuevo podemos pensar en un repaso personal reflexivo sobre cómo funciona cada cosa desarrollada o qué valor se ha agregado al proyecto. Esta puede también ser una buena ocasión para grabar videos instructivos de funcionamiento o resúmenes escritos.

Retrospectiva

En SCRUM la ceremonia retrospectiva le permite al equipo discutir areas de mejora y cosas que se están haciendo bien. Suelen organizarse en temas bajo las categorías de (1) Happy, (2) Nah y (3) Sad. Se hace una lista de tres columnas y se agregan temas para discutir (reflexionar) en cada columna; al final de la conversación se buscan acciones en términos de (1) cosas para dejar de hacer, (2) cosas para continuar haciendo y (3) cosas para empezar a hacer, y se asignan encargados para cada acción; se le dará seguimiento en la próxima sesión retrospectiva.

En un escenario P1P es igualmente clarificante reflexionar en esos mismos términos y definir acciones a tomar.

Entrega de Valor Incremental

Consiste en realizar entregas (implementaciones) de forma regular tras cada iteración a los ambientes con visibilidad al usuario (ambiente de pruebas de aceptación) y opcionalmente a los ambientes de producción real.

Herramientas

Seguidamente listamos algunas herramientas útiles en el modelo SCRUM que pueden ser aplicables a los P1P:

1. SWAG: En Inglés «scientific wild-ass guess» se traduce como «suposición scientífica salvaje» es una estimación de esfuerzo inicial para cada historia de usuario, que contiene un número en puntos (1,2,3,5,8,13) sin haberse detenido a considerar los detalles.
   
2. Burn-down Chart: gráfico que representa la cantidad de esfuerzo pendiente en una iteración respecto al ideal de esfuerzo pendiente para cada día de la iteración.
   
3. Velocidad y Estimación por Puntos: Cada historia de usuario es estimada durante la ceremonia de planeamiento en términos de puntos subjetivos (1,2,3,5,8,13) donde 1 representa el mínimo esfuerzo y 13 el máximo. Usualmente se toma la puntuación 13 como una historia que tomaría toda una iteración o mas en ser realizada. Al final de cada iteración se suman las historias de usuario que hayan sido completadas en su totalidad y se determina esta suma como «la velocidad» del equipo (del individuo en el caso de P1P’s). Se dice que el equipo es capaz de hacer «n» puntos por iteración. Así, combinando con los SWAG se puede estimar cuantas iteraciones tomará un proyecto o una etapa importante del proyecto en ser realizada.
   
4. Bitácora de Desarrollo: Consiste en mantener un listado de acciones realizadas en el tiempo de forma que el desarrollador pueda luego re-visitar esa bitácora y aprender de ella.
   
5. Chart de velocidad (compromiso vs logro): Opcionalmente durante las actividades retrospectivas se puede evaluar históricamente la cantidad de puntos que se asumió como compromiso de cada iteración y la cantidad de puntos realmente completada a fin de tener una medida mas o menos estable de la velocidad real del proyecto P1P.
   
6. Hoja de Ruta: En ocasiones es también útil definir una serie de hitos para ser alcanzados en el tiempo; y dar seguimiento de forma retrospectiva al progreso real de dicha hoja de ruta.
   
7. BDAT: Es indispensable describir el proyecto en terminos de negocio (B), Datos (D), Componentes de Aplicación (A) y Tecnologías aplicadas (T). Esta descripción faculta al desarrollador para pensar de forma detallada y expedita sobre los diversos aspectos del proyecto y del producto.
   
8. KANBAN de Soporte: Una vez implementado el producto, cuando requiere soporte vale la pena tener un mecanismo de seguimiento de incidentes o solicitudes de servicio para el mantenimiento adecuado del producto.

Ciclo de Vida

El ciclo de vida de un proyecto se define desde que se inicia el proyecto en etapa de exploración, pasando por la arquitectura, diseño y construcción, luego la implementación y soporte del producto, para terminar en el proceso de fin de vida del producto.

Definir y evaluar constantemente en qué punto de su ciclo de vida se encuentra el procucto es de vital importancia.

Para esto podemos listar una serie de fases comunes:

1. Ideación Inicial
2. Exploración y Conceptualización
3. Diseño y Arquitectura Inicial
4. Construcción Iterativa
5. Implementación y Puesta en Marcha
6. Mantenimiento y Mejora Continua
7. Desmantelación y Fin de Vida

Mas allá de P1P

Los proyectos P1P suelen ser un inicio para muchos productos exitosos. Es importante tener presente que se trata de un inicio; y que cuando un producto es exitoso, es imprescindible poder escalar el modelo de trabajo para incorporar un equipo de desarrollo formal que lo lleve a nuevos horizontes y haga realidad su máximo potencial.

A la vez los desarrolladores de P1P’s debemos tener en cuenta que nuestras capacidades individuales son siempre muy limitadas comparadas con nuestras capacidades en un equipo de trabajo saludable. Un riesgo que es de vital importancia mitigar es el de convertise en un «pizote solo», es decir un desarrollador incapaz de trabajar en equipo y de alcanzar metas superiores.

 3,279 total views,  3 views today