Cuando el mínimo producto viable es demasiado grande

El proyecto en el que estamos trabajando es una plataforma que nuestro cliente ofrece como servicio a sus propios clientes bajo un modelo tipo “suscripción”.

Más específicamente estamos construyendo una nueva versión de esta plataforma, pues el cliente ya tiene versión que ha construido durante varios años. Más aún el cliente ya está recuperando su inversión. Las razones que lo llevan al contratar a un nuevo proveedor para hacer una nueva versión de su plataforma no vienen al caso en este artículo, pero es interesante destacar que la nueva versión no incluye nuevas funcionalidades (al menos en un principio) aunque se espera que resulte mucho más estable y escalable. Pero esta cuestiones técnicas no son precisamente lo que más me inquieta.

El tema que más me inquieta tiene que ver con la planificación. Construir un nuevo producto con toda la funcionalidad existente en el producto actual podría llevarnos más de un año. Demasiado tiempo, demasiado riesgo.

En estos días precisamente estamos trabajando con la gente de negocio para intentar identificar un estrategia que nos permita liberar al menos una parte del producto y de esa forma comenzar a tener un retorno de la inversión y mitigar los riesgos.

Continuara…

 

El equipo de DevOps

El equipo de DevOps

Como mencioné anteriormente ya estamos en producción y dado que el cliente no tiene un area de sistemas está acordado que nosotros mismos nos encarguemos de la operación. Para esto armamos el equipo “DevOps”, y para ser sincero debo admitir que inicialmente el nombre no me cerró, yo lo habría llamado directamente “operaciones”. Pero creo que la intención al llamarle “DevOps” fue ya desde el nombre intentar transmitir el mindset con el que se quiere trabajar. En fin, en punto del nombre no es tan relevante. Creo que lo interesante es la forma en que estamos intentando trabajar. En este momento somos 3 personas:

  • Una persona con skills de operaciones/sysadmin y automatización (en particular usando Chef)
  • Una persona proveniente del equipo de UI (js/html/css)
  • Una persona proveniente del equipo de desarrollo server-side (C#). Este soy yo, que adicionalmente estoy oficiando de “facilitador” del equipo

Para la coordinación/organización del equipo estamos usando las siguientes herramientas:

  • Una lista de correo
  • Un canal de Slack
  • Un tablero Kanban (en Jira)

Respecto de la dinámica de trabajo, trabajamos en un flujo continuo, limitando el work-in-progress e intentando planificar semanalmente. En este sentido cada lunes reportamos los items completados la semana anterior e identificamos los items más prioritarios para trabajar en la semana actual. Luego con el correr los días se van sumando a nuestro backlog nuevos items que debemos atender en forma inmediata. En todos los casos estos items “urgentes y no planeados” los registramos en el Jira para que quede constancia de nuestro trabajo.

Respeto del tipo de tareas que realizamos, en este momento tenemos 3 hilos de trabajo principales:

  • Automatizar el provisionamiento de toda nuestra infraestructura
  • Armar la arquitectura de build y el pipeline de deployment
  • Atender pedidos puntuales de los equipos de desarrollo (por ejemplo asistir a un equipo en la configuración de alguna herramienta cuya configuración aún no está automatizada)

Un punto que puede resultar curioso es que este equipo de operaciones no se encarga completamente de la operación, al menos no por ahora. En este momento tenemos una solo aplicación en producción pero es el equipo que la desarrolló quien la monitorea y atiende eventuales alertas.

Por el momento me gusta la forma en que esto está fluyendo, pero recién empezamos, ya veremos como evoluciona.

 

projifm: Estadísticas del primer release

Finalmente la semana pasada salimos a producción. El evento en cierto modo fue muy tranquilo ya que nuestra aplicación estaba instalada y funcionando en el ambiente productivo desde hacía varias semanas.
Comparto aquí algunas estadísticas:
Estadísticas de proceso
  • 7 iteraciones (2 semanas cada una) con un equipo de 5 ingenieros
  • 6 semanas de trabajo “on-demand” de un ingeniero monitoreando y realizando ajustes menores
  • 313 items de Jira resueltos
Estadísticas de código
(esto números son específicos del nuestra aplicación, pero el equipo también trabajó sobre componentes compartidos con otras aplicaciones que no está considerados aquí)
  • 138 test automatizados
  • 83.5% de cobertura
  • 67 clases (sin contar las clases de tests)
  • 7329 líneas totales de código
  • 4211 líneas de  código productivo (57%)
  • 3118 líneas de código de tests (43%)

Deuda técnica
Al momento de este primer release registramos los siguientes items de deuda técnica:

  • Código duplicado en los tests
  • Dependencias externas desactualizadas
  • Falta de monitoreo más granular de ciertos components

De regreso a C++

Hace un par de semanas comencé a trabajar en proyecto con C++. Hacía ya bastante tiempo que estaba con ganas de hacer un proyecto de índole industrial/comercial con C++ por ello cuando me surgió la oportunidad de este proyecto, ni lo dudé a pesar de estar con una agenda casi completa.

El proyecto consiste básicamente en ayudar a un equipo a implementar prácticas técnicas para mejorar la calidad del producto. Dicho producto fue creado hace ya varios años y no cuenta con ningún tipo de pruebas (ni automatizadas ni manuales). El proceso de prueba es totalmente ad-hoc, lo cual implica que dependiendo quien realice la prueba, el resultado puede ser distinto.

Inicialmente pusimos en funcionamiento un servidor de integración continua (Jenkins). Luego revisamos el proceso del desarrollo-testing y propusimos algunos cambios y este momento nos encontramos trabajando en implementar “developer testing”: usando Google Test como framework de testing estamos escribiendo pruebas unitarias y de componentes sobre las partes más sensibles del producto.

Continuará…

 

projifm: fin de primera iteración

El lunes pasado completamos la primera iteración con un muy buen desempeño. A pesar de haber sufrido retraso por parte de un proveedor externo de una API logramos entregar toda la funcionalidad comprometida, solo nos quedó pendiente una tarea relacionada a una aplicación legacy con la que debemos integrarnos.

Me sentí muy cómodo con la estructura del equipo: 3 devs (yo entre ellos) + 1 tester + 1 facilitador + PO (+ 1 persona en tareas de infraestructura con dedicación parcial).  La forma en que trabajamos es bastante aproximada a lo propuesto por XP. Entre las prácticas que utilizamos están: daily stand ups, reunión de planificación, reunión de review, retrospectivas, #noEstimates, product backlog, spikes, pruebas automatizadas, deploy automatizado, mob-programming, collective ownership, control de configuración, TDD (poco pero en ascenso), versionamiento de base de datos, etc.

Entre los temas a mejorar surgidos en la retrospectiva estuvieron:

  • Mejorar el flujo de release: nos pasó que varios de los items del backlog se estiraron durante varios días y luego los cerramos “todos juntos” hacía el final de la iteración. Esto generó que el burn-down chart tenga una meseta importante.
  • Mejorar la interacción con nuestro “DevOp” pues tuvimos algunas fricciones consecuencia de la falta de claridad en algunos acuerdo de trabajo (lo pongo entre comillas pues considero que DevOps es más un mindset que un rol)

Aplicaciones legacy, monolitos y micro-servicios

Una plataforma desarrollada durante varios años sin prestar mayor atención a a algunas buenas prácticas de desarrollo (integración continua, test-automatizados, trazabilidad de artefactos, control de la configuración, separación de ambientes, etc). Desarrollada por una software factory externa a la organización.

En un momento la organización decide cambiar de software factory y es ahí donde entramos somos.

Nos encontramos con una plataforma legacy, con arquitectura monolítica, issues de performance, corriendo sobre máquinas físicas (nada de cloud, ni virtualización), sobre la que el cliente espera que agreguemos nuevas funcionalidades. La visión es ir hacia una arquitectura de micro-servicios corriendo en la nube. Este desafío nos plantea una seria de interrogantes:

  • Cómo organizar el equipo para poder dar soporte a la plataforma actual y al mismo tiempo desarrollar nuevas funcionalidades
  • Cómo mitigar los riesgos de introducir modificaciones sobre una plataforma legacy
  • Cómo vivir en una infraestructura mixta cloud  y on-premise
  • Cómo mantener la motivación al trabajar sobre código legacy/frágil escrito por terceros
  • Cómo introducir la nueva arquitectura basada en nuevas tecnologías de una forma no disruptiva para el negocio y los usuarios

Esta es la situación que estoy afrontando en mi proyecto actual y es también la temática de una charla/presentación que en la que empecé a trabajar esta mañana.

 

team.split() & Project.new()

Hace tres meses me sume a un proyecto que recién estaba empezando. En aquel momento el equipo estaba aún en formación y éramos unas 9 personas. Hace dos semanas llegamos a ser 15 personas en el equipo. Obviamente ya no era factible alimentarnos con dos pizzas.

Por ello fue que la semana pasada partimos el equipo y ahora estoy trabajando en un equipo de 5 personas: 3 devs, 1 tester y 1 facilitador. Estamos trabajando en rehacer desde cero un componente existente en la plataforma. Esperamos poder liberarlo en aproximadamente 5 o 6 semanas.

Ayer empezamos la primer iteración. La planning estaba agendada para las 11 de la mañana, pero como todos estabámos en la oficina desde las 9, decidimos comenzar a trabajar en algunas tareas de setup todos juntos: creación del repositorio Git y de la estructura de la solución base y configuración del Jenkins para que haga integración continua (#ci). Luego hicimos la planning donde acordamos con nuestro PO los items a trabajar durante la iteración. Por el momento y dadas las particularidades de nuestro proyecto, no estamos estimando los items de nuestro backlog (#NoEstimates). Simplemente intentamos particionar los items de forma tal que sean pequeños y que requieran no más de 2 días de trabajo cada uno. De esta forma medimos cantidad de items completados por iteración.

A continuación de la planning debatimos algunas cuestiones de diseño de alto nivel. Ya por la tarde, con todo el equipo trabajando sobre una compu + proyector (#mob-programming like) comenzamos a escribir las pruebas de aceptación que nos guiarán en el desarrollo de las funcionalidades comprometidas (#tdd). Esto nos permitió detectar en forma temprana algunas dudas sobre el comportamiento esperado de la aplicación.

Estoy muy entusiasmado con este proyecto, ya que implica el trabajo con un equipo nuevo, teniendo la confianza del cliente para hacer las cosas de la forma que nosotros consideramos más apropiada.

Continuará…