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

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)

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