Archive for the ‘Retrospectivas’ Category



Con una entrada de trabajo tremenda los sprints semanales se han ido terminando sin consecución de las metas esperadas. Cada semana con un poco más de atasco y menos objetivos cumplidos. Uno de los factores principales es que los criterios de aceptación no estaban claros y ello provoca trabajo en vano.  Por falta de análisis se toman decisiones equivocadas que tienen un alto coste y una estimación imposible (estimar sin saber con precisión lo que se necesita es "duro"). Se hace muy difícil calcular el valor que se aporta al negocio y la prioridad de la tarea. Se invierte un tiempo en planificación y retrospectiva del sprint para que no se termine la tarea.

Así que hemos pensado que hasta estabilizar la situación, dejamos los sprints semanales y hacemos un sprint por cada historia de usuario. Lo primero que se hará con la historia es sacar con la máxima precisión los criterios de aceptación. Escribiremos tests end-to-end al inicio de la historia (siempre que el codigo legado nos lo permita) que validarán su consecución. Así sabremos con exactitud lo que está terminado y sabremos que funciona. Además la figura del middle-man que traduce las charlas con el cliente en historias y criterios de aceptación se diluye un poco y todo el equipo se encarga de analizar y conseguir esos criterios: Más cohesión entre análisis-negocio y desarrollo.

El equipo de QA se convierte en un cuello de botella por deficiencia del proceso (o ausencia). Decidimos que los responsables de QA tendrán un pequeño meeting diario para ver cómo van las incidencias. Los jueves se hará especial esfuerzo en probar todo para confirmar que se puede desplegar en producción.

Además dedicaremos el último pomodoro del día a probar entre todos las tarjetas que están en estado "listo para UAT" para que lleguen más filtradas al equipo de QA.

Es prioritario reducir al mínimo la distancia entre el código que hay desplegado en producción y la rama principal del control de versiones. El ideal es poder desplegar en cualquier momento la rama principal, ya que usamos ramas para funcionalidades que están sin terminar. No obstante, a veces nos gustaria desplegar aunque haya funcionalidad a medias. Por eso vamos a intentar seguir puliendo la técnica de feature branches y además añadir en alguna ocasión feature toggles.

La información del kanban al final de la semana no va a parar a ningún documento histórico ni estadístico. Esto va a cambiar ya, para que tengamos el registro más fiable posible de costes en el corto, medio y largo plazo. Me encargo yo mismo. Esta información lógicamente no será pública 🙂

La mejora contínua sigue adelante y en estas semanas hemos avanzado con paso firme en lo siguiente:

  • Hay menos interrupciones. Antes de interrumpirnos entre nosotros nos preguntamos por skype o email y al terminar el pomodoro hablamos entre nosotros.
  • Estamos más concienciados con probar a mano las tarjetas antes de pasarlas al equipo de QA.
  • Cada día nos preocupa más la deuda técnica y pensamos más antes de programar.
  • Las reuniones diarias (daily meeting) van cada vez más fluidas, tardamos entre 10 y 15 minutos.
  • Las reuniones de retrospectiva son más directas y nos dan más información.
  • El número de tests automáticos sigue creciendo y su calidad también. Hemos alcanzado ya los 500 tests con javascript.
  • Hemos hecho varias mejoras de arquitectura sin que el cambio sea muy costoso ni traumático.
  • Hablamos más unos con otros y discutimos sobre código y arquitectura en el proyector antes de lanzarnos a programar lo primero que se nos ocurre.

El camino es largo, pero vamos mejorando hacia XP. Sólo hay que seguir vigilando para no retroceder y seguir practicando la honestidad, la valentía de hacer lo que es bueno para uno mismo (y eso será lo mejor para el equipo) y el sentido común. Ser consecuentes con lo que se hace y constantes con las prácticas.

 

RS: Aprovechar la experiencia

En el sprint de esta semana nos hemos dado cuenta de errores cometidos semanas atrás. Las acciones más importantes ahora para seguir mejorando, son:

  • Que cuando reimplementemos una funcionalidad (o una similar a otra que ya tuviesemos), contemos con las personas que desarrollaron la primera versión. Lo ideal es que las personas que estuvieron en el primer desarrollo estén haciendo pareja con quienes se enfrentan al problema por primera vez. Si no es posible, al menos deben sentarse a hablar de las dificultades que surgieron con la primera implementación y las soluciones que se encontraron.
    Lo primero será tratar de evaluar si se puede reutilizar parte del código existente. No siempre es fácil tomar esta decisión pero por lo menos hacer un estudio rápido de la situación. En caso que se pueda reutilizar, estudiar qué se debe refactorizar y a qué se le pueden añadir tests. En caso que haya que reescribirlo todo por completo, tener presentes las ideas que ayudaron más al buen funcionamiento de la primera implementación. Esto es: aprovechar la experiencia que ya tenemos.
  • Separar muy bien lo que es importante de lo que es urgente. Si todo es urgente, dejamos de saber lo que es importante. Nos ha pasado y nos ha perjudicado. Cuando digamos que algo es urgente, tendremos que saber que corremos peligro de dejar atrás lo imporante.
  • Tratar de evitar la entrada de imprevistos durante el sprint. Tiene que ver con lo anterior. Si surge una necesidad el jueves y no es bloqueante, debemos plantearnos esperar a abordarla el lunes, es decir, en el siguiente sprint. La idea es no romper la planificación semanal. Cuando la rompemos, nos distanciamos de los objetivos propuestos y entonces dejamos de ser predecibles. Ser predecibles es una de nuestras metas porque así sabremos cada vez mejor, cuánto podemos tardar en entregar funcionalidad con valor para el negocio.
  • Evitar hablar de "terminar tareas" y hablar más de poner en producción tareas que suman valor. No sirve querer terminar, sino querer desarrollar piezas que mejoran la experiencia del usuario. Cuando pensamos en terminar, es más fácil hacerlo mal (porque lo urgente quita de enmedio a lo importante). Rara es la semana que no se introducen nuevos requisitos en funcionalidad que estaba "terminada".

Esta semana estoy muy contento con la labor técnica del equipo:

  • Se ha respetado en todo momento que todos los tests pasen
  • Se han añadido tests para demostrar bugs
  • No recuerdo que se hayan escrito métodos nuevos de más de 10 líneas.
  • No se han introducido números mágicos ni código duplicado
  • Se ha prestado bastante atención a la code review y los commits han sido muy claros.

Es importante vigilar bien que sigamos por el buen camino, porque estamos en un punto en que retroceder lo andado no es muy dificil.

Buen comienzo de semana a todos 🙂

RS: planificación de sprint

Nuestros sprints son de una semana, empiezan el lunes y terminan el viernes. Planificamos en el daily standup meeting del lunes por la mañana. Pero el daily no queremos que pase de los 20 minutos (mejor seria no pasar de los 15). Asi que las últimas dos semanas, terminabamos el meeting sin haber cerrado la planificacion semanal, sin tener las tareas estimadas y por tanto, sin conocer cuál era el objetivo a cumplir. Eso hace que al terminar la semana no sepamos si lo hemos hecho mejor o peor. Dejamos de ser predecibles cuando pasa esto.

Por este motivo, la reunion del lunes podrá estirarse hasta un máximo de una hora con tal de que todos podamos estimar y comprometernos a entregar determinada funcionalidad el viernes, o por lo menos a intentarlo.

Aunque nuestra hora de meeting son las 9.30am, el lunes desplazaremos la hora lo que haga falta para que estemos todos. Esta semana faltaron personas que al no estar en el meeting de planificación no pudieron aportar su conocimiento. Eso llevó a que yo escogiera como prioritaria una tarea que en realidad no lo era, porque ya teniamos una funcionalidad parecida, hecha en código existente pero no lo sabíamos. Era una funcionalidad que conocía la persona no estaba. La tarea que se ha implementado hacía falta pero no era tan prioritaria en el sprint de la semana que ha terminado.

Por otro lado existe preocupación porque no estamos colocando las clases en los namespaces más adecuados, ni los ficheros en las carpetas adecuadas. El problema es que si no están en un lugar intuitivo podemos repetir funcionalidad. Para esto la code review juega un papel importante, por lo que hay que seguir haciendo incapié en ella. A parte de eso, la persona que detecte que se ha puesto un fichero en el sitio incorrecto o un namespace que no corresponde, debe actuar de manera concreta, bien modificando el código o bien avisando por email a los compañeros, diciendo exáctamente por qué no es correcto y cómo solucionarlo.

En el código legado sigue habiendo horrores que nos están haciendo daño pero la preocupación por la ubicación de clases y ficheros es un tema recurrente así que vamos a intentarla solventar, tomando acciones concretas y constructivas.

Esta semana hemos resuelto graves problemas de concurrencia que teníamos. El trabajo ha sido duro porque hemos invertido mucho tiempo y escrito pocas líneas de código y eso da mala sensación, pero el resultado es muy bueno. Hemos aprendido bastante y sabemos qué cuestiones debemos considerar desde ya, para que nuestro código esté preparado para la concurrencia. Escribiré un post sobre nuestros descubrimientos con Linq2Sql y concurrencia pronto.

En las últimas semanas hemos hecho muy poco pair programming porque buena parte del equipo pensaba que así avanzaríamos más teniendo la fecha de entrega muy cercana. La realidad es que no podemos cuantificar si ha salido adelante más trabajo o no, pero lo que sí hemos hecho es introducir deuda técnica y aumentar en desconocimiento de lo que los demás hacen, lo que lleva a la duplicidad del código. Falta comunicación. Sabemos que la próxima semana volvemos a nuestro ritmo habitual, intentando hacer las cosas lo mejor posible y sabiendo que cuando dos personas trabajan juntas y bien concentradas, nos acercamos más a ello.

 

RS: Trazabilidad

En la retrospectiva de esta semana hemos hablado sobre todo del proceso de desarrollo. Nuestro proceso se apoya en kanban, no hacemos scrum. Scrum es demasiado lento para la velocidad con que nos entran peticiones de cambio de funcionalidad. Nuestros sprints son de una semana y el objetivo es la entrega constante.

Lo que ha sucedido esta semana es que las tareas terminadas se han acumulado a las de sprints anteriores y hemos perdido la información de qué funcionalidades se estaban entregando. La solución que se nos ocurre es que la persona que recoge las incidencias y se encarga de notificar a los clientes de su resolución y de nuevas funcionalidades, esté presente en las reuniones 

diarias (daily stand up meeting). Además las tarjetas del kanban estarán tambien en nuestro trac, cuando coincidan con historias de usuario (hay tarjetas más pequeñas que una historia de usuario). Intentaremos que todo el mundo conozca el estado de una funcionalidad desde que se escribe la historia de usuario hasta que se notifica al usuario su puesta en producción. Para ello, todo el mundo es responsable de ayudar a definir bien las historias de usuario, si van a entrar en el WIP (work in progress) y nuestro dueño de producto no ha tenido tiempo de estudiarlas a fondo. Cada uno se reponsabiliza al coger una tarjeta para implementar, de que se finaliza, de que no se queda nada atrás y también de que se avisa de cuándo está subida a producción.

Esta semana toca hacer pruebas de carga de nuestros sistemas para estar seguros de la cantidad de conexiones que podemos aguantar con la puesta en marcha de nuestro nuevo producto. El objetivo de las pruebas de carga no es lanzar muchas peticiones contra el servidor y ver que aguanta, sino hacerle peticiones hasta que se caiga, y entonces tener la medida más precisa posible de hasta cuánto aguanta. Lo contrario sería un falso positivo.

Por otra parte, el haber elegido javascript como lenguaje principal para las nuevas aplicaciones, ha aumentado temporalmente el bus factor y los viernes estamos haciendo sesiones formativas sobre el lenguaje, aunque necesitamos que todo el equipo lea libros en su tiempo libre. En otras circunstancias no pediría al equipo que leyese en su tiempo libre temas profesionales pero siendo una empresa de poco tamaño que tiene metas tan fuertes, no queda más remedio.

 

RS: enfocados hacia la calidad

Este post de retrospectiva vale por las últimas semanas. Desde el último post de retrospectiva hasta ahora, estamos notando una evolución espectacular en el equipo, tanto en el compromiso que cada uno demuestra escribiendo código de calidad como en la responsabilidad de completar las releases semanales. En la pizarra que usamos en la última reunión de retrospectiva aparecieron más anotaciones positivas que anotaciones de mejora 🙂  Sin embargo en este post voy a resaltar lo que queremos lograr.

La cuestión es no parar aquí porque sigue quedando muchisimo camino por recorrer. Simplemente seguir trabajando duro con ayuda de esta sensación de progreso que va calando en el equipo.

Lo que queremos hacer:

  • Los commits aún más cortos y legibles (tengo pendiente un artículo sobre esto que saldrá en la proxima tirada de agilerecord.com). Evitar que los commits lleven diferencias en tabulaciones y espacios para que no se registren cambios que no son de verdad en código sino en configuración del editor de texto.
  • Un branch por feature: tenemos que quitarnos de encima el agobio de que el dia de la subida de versión el branch principal no acaba de estar fino para mezclarlo con estable. Al empezar una nueva funcionalidad iniciaremos un nuevo branch. Cuando se toca código cómun se mezclará con la rama principal y se compartirá para que los demás tengan el cambio disponible lo antes posible.
  • Acelerar la velocidad de nuestras máquinas. En compilar el proyecto (.sln) y lanzar los tests se iba un minuto en cada maquina. Insoportable e impracticable para hacer TDD. Hemos cambiado dos máquinas comprando todo el hardware nuevo, doblando la memoria RAM, y poniendo discos duros nuevos. También hemos optimizado la configuración de la compilación. Ahora se tardan 3 segundos en compilar y otros 3 en pasar los tests. Con eso recuperamos más que de sobra la inversión en hardware. Pero aún quedan varios compañeros con equipos lentos. Es muy importante resolverlo cuanto antes.
  • No hacer cambios en base de datos sin hablarlo primero con los demás y sin que sea totalmente inevitable. Nuestro objetivo es que la BD sea lo último que se toque, tratando de modelar primero el comportamiento en el código.
  • No olvidar pasar todos los tests despues de hacer "merge" y dar la voz de alarma cuando alguno se ha roto.
  • Mejorar el tiempo de respuesta de las incidencias.
  • Seguir formándonos, leyendo libros y practicando ejercicios. En la sesión formativa de los viernes y en casa.
  • Conocer más el código que hacen los demás y la funcionalidad para evitar duplicarla. Tener aún más cuidado en la code review de las mañanas.
  • Automatizar la generación de bases de datos de quita y pon, para pruebas de integración.
  • Cuando el código legado es abrumador, nos trazamos un mini "backlog" de los cambios que queremos conseguir hacerle y una estimacion de tiempos para irlo haciendo (ej: en 15 minutos, cambiar este método para que en lugar de recibir 7 parametros reciba un objeto).

Logros:

  • Aumento de lo concienciado que está el equipo para escribir código más legible y mantenible para los compañeros.
  • Despliegues automáticos. Yeah!!
  • Estamos priorizando mejor. Nadie ha tenido que hacer ni una hora extra porque hemos afrontado a tiempo todas dificultades y la comunicación va mejorando.
  • El número de incidencias va descenciendo.
  • Se están haciendo más commits y más pushes (nos acercamos a la media de 3 commits por hora).
  • Se hace pair programming cuando es productivo y se programa por individual cuando la pareja se da cuenta que no se está aprovechando bien.

RS: Pomodoros

reunion de retrospectiva

Esta retrospectiva vale por las dos últimas semanas. Lo que todo el mundo ha visto fácilmente y en consenso es que nos hace falta respetar más los pomodoros, de ahí el título de hoy.

Estamos contentos porque se van notando cambios muy positivos. Los repasamos juntos:

  • Refactor sólo donde duele: no tocamos código que funciona, si no tiene bugs (que sepamos) y no hay que ampliar su funcionalidad.
  • Refactorizamos siempre para alcanzar "the low hanging fruit": Extract method y Extract constant nos dan beneficio rápido sin apenas coste.
  • No nos metemos con tareas que no son de desarrollo funcional salvo que hayamos hecho un estudio claro y concreto de ventajas y desventajas: Mucho cuidado con las tareas de infraestructura u otras que no sean directamente entregar valor a corto plazo.
  • Code reviews: Sabemos que no pueden durar mas de 15 minutos al día asi que somos selectivos para combinar con pair programming con el objetivo de la propiedad colectiva del código. Están empezando a dar fruto. Ya sabemos que hay que mirar si el código que queremos hacer, lo ha hecho alguien ya. Reutilizar el esfuerzo de los demas.
  • Pair programming: nos damos cuenta cuándo hay que unirse en pareja y también cuándo hay que separarse. A veces nos equivocamos en los dos lados, por no hacerla y por hacerla.
  • El bus factor es malo, sabemos que lo tenemos que ir reduciendo poco a poco.
  • Un equipo XP entrega valor al negocio constantemente, sin parar.
  • El pomodoro nos lo tenemos que tomar todos más en serio. Demasiada interrupción, aunque no para todos, para los que tienen mayor bus factor.
  • El daily meeting se hace a su hora, esté quien esté. Ya casi siempre respetamos el tiempo y conseguimos contar lo importante.
  • Los meetings fuera del daily, son tóxicos. Mejor dejarlos para el viernes despues de la comida porque nos consumen mucho tiempo y es dificil valorar lo que aportan.
  • Nadie escribe código basura a conciencia. Ninguna prisa justifica escribir un código mal sabiendolo hacer bien. Si no se sabe hacer mejor, vale, de eso me voy encargando yo, poco a poco.
  • No tenemos tiempo para que todo el mundo aprenda todo lo que nos gustaria que supiera durante las horas de trabajo. Cada uno ha elegido ya un libro de la lista y la empresa ha comprado un Kindle además de libros en papel para continuar con la formación que ya tenemos en el día a día. Los viernes hay exposición aunque hoy nos hayamos comido el tiempo de Jaime con la restrospectiva. Sorry!

RS: demasiado cambio de contexto

La semana pasada hicimos la primera retrospectiva "formal" en equipo, guiada por Dani, con lo que había aprendido en el taller de Joserra Díaz en la CAS2011. Retrospectiva

El punto en el que más coincidimos es que teníamos demasiados cambios de contexto, es decir, demasiado cambio de tarea. Cuando se cambia de tarea se tardan al menos 15 minutos en ubicarse y empezar a resolverla.
Inicialmente habiamos pensado en dedicar las primeras dos horas del día a que todo el mundo resolviese incidencias y luego el resto del día todo el mundo desarrollando nuevos requisitos. Sin embargo despues de un mes parece que la idea no funciona bien y vamos a intentar que haya una pareja que se dedique toda la semana a las incidencias mientras el resto desarrolla. La pareja va rotando para que todas las semanas haya compañeros nuevos atendiendo las incidencias.

Por otra parte la automatización del proceso de despliegue aumenta su prioridad ya que el despliegue manual es muy propenso a errores.

Como me ven a mi desde la oficina

Como me ven a mi desde la oficina

Esta semana hemos empezado a hacer BDD con Javascript y Jasmine para desarrollar nuevas funcionalidades. Nos ha quedado un diseño con el que de momento estamos muy contentos.capas Estamos usando Backbone pero sólo para los DTOs y las colecciones de DTOs (models de Backbone). La cobertura de tests es casi del 100% y el diseño, muy desacoplado y reutilizable. Rotando las parejas durante la semana, hemos conseguido que casi la mitad del equipo ya esté familiarizado con este diseño y con la forma de hacer BDD. El trabajo en pareja está resultando muy muy productivo.

Con este post se abre una posible serie de posts de retrospectiva semanal sobre el trabajo de nuestro equipo. Las conclusiones que más suenan en mi cabeza pasan a estar escritas en el blog para que cuando las lea con el tiempo compruebe si hemos aprendido la lección o no.

La conclusión que me llevo de esta semana es que para que un equipo pequeño haga grandes cosas, todos deben ser capaces de enfrentar los problemas con la misma visión que el propietario de la empresa, además del punto de vista técnico.  Con la visión de querer hacer ganar al equipo y a la empresa, de crecer (sea lo que sea que se entienda por crecimiento). Con una visión de todo el bosque, que no se pierde entre los árboles. A veces los técnicos trabajamos desde la perspectiva equivocada, un punto de partida inadecuado.
A veces porque las personas se creen sin permiso a sugerir propuesta de un calado más profundo y a veces porque no se dan cuenta que no todo tiene que resolverse escribiendo líneas de código.

El ejemplo de la semana:

Nos ha tocado hacer frente a un problema de rendimiento en la aplicación. No sabíamos por qué pero algunos usuarios sufrían ralentización y teníamos que arreglarlo cuanto antes. En la mayoría de los casos que he visto en mi vida, el cuello de botella está en el acceso a datos (yo diría 90%) pero también hay problemas de ancho de banda que salen a relucir cuando hay mala conexión a Internet, así como posibles problemas de renderizado en máquinas antiguas (había alguna CPU al 100%). Algunas personas con más conocimiento de la aplicación sugirieron cambiar la forma en que se renderizan contenidos para reducir la cantidad de información que se envía por la red (quitar algunos controles ASP.NET) ya que no se daba con el problema en base de datos. Empezamos a mirar el código y después de 3 horas vi que el trabajo no sólo era tremendo sino muy propenso a errores. Podíamos tardar semanas en cambiar toda la aplicación y sin garantías de estabilidad. Pero lo peor de todo: sin estar seguros de la ganancia que conseguiríamos. ¿Cómo vamos  a invertir semanas sin tener ni la más remota idea del beneficio que podíamos conseguir? ¿sin saber realmente cuál era el cuello de botella? Más de uno se habría pegado tranquilamente los días haciendo ese trabajo sin más (no necesariamente de este equipo), total, como le pagan para programar...

Era mucho más rápido desplazarse hasta el cliente con una conexión 3G potente y un portátil de altas prestaciones para probar 2 cosas: Que ni el hardware ni el ancho de banda son problema. En caso que alguna de estas cosas fuese problema, es muchísimo mejor pagarle a nuestro cliente la conexión a internet y comprarle una máquina más potente para que pueda trabajar, en lugar de invertir semanas de trabajo de desarrollo.

Pero esta perspectiva sólo te viene a la cabeza si estas pensando en el dinero que va a suponer para la empresa tu decisión y tu capacidad resolutiva.

De aquí la importancia de cambiar de dimensión para ver los problemas de otro color. Según desde donde mires, te implicarás de una manera o de otra.

La otra gran lección que ha salido es que nunca nunca nunca se pueden hacer refactorings grandes en solitario, ni tan siquiera por 2 minutos, cuando no hay una gran batería de tests automáticos de respaldo. Llevaba años ya acostumbrado a tener mis tests y a hacer refactorings tranquilote y esta semana, me confié como si tuviera los tests e introduje varios bugs por refactorizar en solitario, a pesar de que fue por apenas unos minutos. Ya tenemos todos los puestos con doble teclado-ratón y doble pantalla y la ergonomía se ha mejorado así que no hay excusa para no sentarse en pareja a hacer refactoring. ¡Prohibido hacerlo en solitario!

  • Newer Entries →