Etiqueta: projectStory

Estabilizando la velocidad

Durante las dos primeras iteraciones decidimos no puntuar las stories con un valor explícito de estimación. Simplemente a la hora de determinar el compromiso de la iteración utilizamos la tantas veces usada técnica de «estimación a ojo de buen cubero». Pero ya en la tercera iteración el cliente nos pidió que puntuáramos las todas las stories del backlog para poder hacer una proyección. Así que eso hicimos, repasamos todo el backlog haciendo una estimación de mano (una variante del famoso planning pocker).

Adicionalmente al comienzo de cada iteración, repasamos los valores asignados a cada story  y de considerarlo necesario los volvimos a estimar.

La semana pasada completamos la sexta iteración y por primera vez entregamos exactamente lo que habíamos comprometido. Hasta entonces siempre habíamos tenido un pequeño delta positivo o negativo.

Comprometido vs. Entregado

Como se puede apreciar en el gráfico precedente la cantidad de puntos entregados por el equipo ha ido en aumento desde la iteración 4. Parte de ese incremento se debe a que las iteraciones 4 y 5 tuvieron días feriados en los que no trabajamos y que hicieron que dichas iteraciones fueran más cortas en términos de días trabajados.

En este momento estamos trabajando en la iteración 7 y el tamaño del compromiso tomado es bastante mayor a las iteraciones anteriores (75 puntos). Esto se debe a que se sumo una nueva persona al equipo.

Al finalizar la iteración 8 saldremos a producción. Yo hubiera preferido salir antes, pero resulta que estamos reemplazando un producto existente y ha sido muy difícil hacer un recorte de funcionalidad que nos permita salir antes sin impactar negativamente en el negocio.

Continuará…

Mejorando el flujo de trabajo a partir del burndown chart

Ayer completamos la tercera iteración del proyecto y la cosa empieza a fluir de lo lindo. Si bien veníamos cumpliendo con los compromisos asumidos el flujo de trabajo en las dos iteraciones anteriores había sido medio accidentado/abrupto como evidencia el burndown chart de la iteración 2.

Burndown chart iteración 2

En la retrospectiva de la iteración 2 tomamos conciencia de este flujo accidentado y decimos tomar medidas para mejorarlo. Principalmente intentamos tener ítems de backlog más pequeños, limitar el WIP y deployar de forma más frecuente. El resultado se puede apreciar en el siguiente gráfico.

Burndown chart iteración 3

 

A pesar de la mejora yo sigo teniendo un pequeña molestia pues no me gusta el cierre abrupto de la iteración. Este cierre es consecuencia de que terminamos a último momento el testing de la última porción de trabajo.

Ya que he compartido los gráficos quiero aprovechar también para compartir un breve análisis comparativo de los mismos:

  • Si bien ambas iteraciones tuvieron la misma duración calendario, la cantidad de días laborales en cada una, fue diferente (los días no laborales está representados por las franjas verticales de color gris más oscuro).
  • Debido al ítem anterior, el tamaño del compromiso asumido por el equipo también fue distinto: en la iteración 2 el compromiso fue de más de 50 puntos, mientras que en la iteración 3 fue de unos 40 puntos.

Nuevo desarrollo: ProyectoH

Luego de casi 2 meses trabajando con el equipo de DevOps en cuestiones de infraestructura y soporte a los equipos de desarrollo, pasé a integrar un nuevo equipo de desarrollo. En este nuevo equipo somos 4 personas de perfil técnico (siendo yo una de ellas) y una persona de negocio.
Dos de los técnicos se especializan en cuestiones de UI lo cual implica que se encargan de relevar/diseñar junto con la persona de negocio la UI/UX de la aplicación.
El otro técnico está enfocado en cuestiones de backend y básicamente se encarga de la programación server-side y de realizar algunas de las pruebas de concepto de arquitectura.
Por mi parte tengo un rol medio «híbrido» que incluye tareas varias como ser:

  • Facilitar el cumplimiento del proceso y la prácticas técnicas
  • Asistir a la persona de negocio en el armado/refinamiento del backlog de producto
  • Y obviamente codear

Continuará…

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 componentes

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á…