RS: Sprint por historia de usuario

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.

 

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • Juan Quijano

    Buenas Carlos,

    Al cambiar el tamaño de los sprint, ¿por historia de usuario?, te has cargado las métricas que llevabas en el proyecto. Es decir, da la sensación que has hecho un borrón y cuenta nueva, y así no sabes ni la velocidad, ni puedes saber en qué estado se encuentra el proyecto ni puedes sacar conclusiones.

    No sé, no conozco el proyecto mas que con tus palabras, pero creo que el camino elegido va a producir más dolores de cabeza.

    Otra razón que me lleva a pensar esto es que planificar un sprint por historia de usuario tiene dos consecuencias malas. Uno, cada sprint va a tener un tamaño diferente, rompiendo el principio de desarrollo iterativo y regular. Algunas historias requieren más esfuerzo, otras menos. Y pasas de una métrica de carga plana a la puntiaguda que deberíamos dejar atrás.

    Dos, es prácticamente seguro que si has tocado el tamaño de los sprint, mañana empecéis a cambiar el tamaño de las historias de usuario.

    Más cosas que pienso que deberías revisar es la sensación que QA no es parte integrante del flujo. Yo, al igual que un tal Luís Fraile, pienso que su tarea empieza incluso antes que el equipo, construyendo el plan de pruebas partiendo de los criterios de aceptación. Y aportando al desarrollo el despejar múltiples dudas funcionales que siempre emergen e los mismos (los criterios). Y un plus de análisis inmediato.

    Siguiendo con el análisis de tus palabras, creo erróneo trabajar en sprint de una semana ya que provocan una carga y tensión al equipo que no es buena. Literalmente, no hay tiempo de equivocarse. Y si además le unes que utilizáis Pomodoros (técnica de gestión de tiempo personal que no estoy seguro si tiene sentido en trabajo en grupo) me parece que estáis (para mi gusto) metiendo demasiada presión.

    Valga la analogía, no solamente llevas el motor en la línea roja de revoluciones, si no que le has puesto un turbo. Y los pistones terminan por resentirse.

    Más cosas, es ir contra uno de los valores básicos del Agilísimo lo que comentas de darle más valor a la comunicación por Skype o email, que cara a cara. Es justo lo contrario. Las interrupciones, el hablar, el reírte, el comentar, el pensar en otra cosa fuera del rígido control del pomodoro, enriquecen el nivel de comunicación. Y por eso se le da un gran valor en cualquier desarrollo Agile.

    Carlos, sabes que todo lo que te digo es desde el enorme respeto que te tengo y sabiendo que eres de las pocas personas que atesoran las críticas, siempre que sean constructivas.

    Creo que os estaís metiendo mucha “caña” y estáis entrando en un estado pre caótico. Me da la sensación que estáis tratando el desarrollo como una carrera de velocidad, cuando debiera ser una carrera de fondo.

    Mi consejo, desde la ignorancia de solo responder a tus palabras: quita los pomopdoros, las comunicaciones (menos las formales) cara a cara y hablando. Y Sprint de dos semanas con cambio de alcance hasta que no tengáis claro la métrica de velocidad. U olvidarte de los sprint, mantienes las liturgias que creas convenientes y trabajáis en un Kanban corrido.

    Es que suena a agotamiento… 🙂

    Espero que alguna de mis divagaciones te sea útil.

  • http://carlosble.com Carlos Ble

    Hola Juan!
    Muchas gracias por el feedback es muy apreciado.

    Cuando digo sprint, me refiero solo a que la tarjeta cruce nuestro kanban de punta a punta. No hacemos scrum. Asi que la idea que tenemos de sprint es diferente en este caso.

    Con respecto a skype, es solo para decirle al compañero… “cuando puedes vente por aqui que necesito tu ayuda” y hablarlo despues cara a cara, en persona. Es para evitar que te interrumpan cuando estas concentrado.

    Los pomodoros nos estan ayudando mucho porque nos permiten concentrarnos y luego nos permiten descansos.

    El equipo de QA efectivamente debe estar desde el inicio pero no tenemos recursos para ello todavia. Tenemos un equipo de 10 haciendo el trabajo de 50. Es lo que pasa en startups que trabajan para el sector privado jugandose un coste-oportunidad muy alto.

    Efectivamente vamos a 4000 revoluciones pero no queda otra solucion ahora mismo. En negocio no se puede parar y el software lo tenemos que hacer cada vez mejor. Asi que nos saltaremos todas las reglas agile que haga falta para conseguirlo, aunque en verdad, si lo vieras de cerca, verias que no son tantas las que rompemos.

    El propio Kent Beck es quien recomienda los sprints de una semana. Yo los llevo haciendo tiempo y me encantan 🙂

    Gracias!!!

  • http://www.estudiolibelula.com Eladio López

    Gracias Carlos por seguir contando tu experiencia.
    Y especialmente de agradecer y útil, que cuentes los problemas que tenéis y como decidís solucionarlos. No me parece muy habitual este tipo de artículos, siempre que se
    lee sobre XP, TDD, Scrum, solo se lee lo maravilloso y lo bien que funciona todo.
    Los que seguimos siendo algo cowboys a la fuerza, aunque intentando cada día salir un poco más del hoyo,
    nos cuesta creer tanto cuento de hadas, y un artículo como este pone realismo al asunto.
    Por supuesto que creo que es el camino, pero sé que el proceso es complicado, no es un camino de rosas, de felicidad y gamificación :). Es duro y con problemas, porque programar no es fácil y hacerlo bien es complicado… por eso nos pagan, no?

    Dicho esto algo de mi experiencia… es verdad que lo de los pomodoros y el decir que no te gusta que te interrumpan queda mal.
    Yo lo dije en mi anterior trabajo y creo que quede muy mal, y en una entrevista hará 5 meses también
    lo dije y se me mal interpretó, así que con este tema, que a mí me parece obvio y de sentido común, hay que tener especial cuidado al expresarlo. Vamos yo doy por sentado que todo el mundo sabe que el hecho de que te interrumpan cada 5min es muy malo para tu rendimiento… que es de buena educación el aproximarte a alguien primero por email o por chat, que si están disponibles te van a contestar en el momento, pero si están en un momento de concentración te pedirán un ratillo para terminar su tarea de forma adecuada… pues, no. Parece que eres un borde si actúas así.

    Lo de los sprints es otro tema delicado y no lo entiendo muy bien. Yo considero que la longitud del sprint debe
    de ser la que mejor se adapte a tu proyecto y a tu equipo. Yo cuando usé scrum hacíamos sprints de 2 semanas y
    de un mes, según lo que hacíamos y el tiempo del que disponíamos y creo que en ese aspecto acertábamos.
    Esto también lo dije en la misma entrevista y también me dio la impresión de quedar fatal :). Eso sí, un sprint
    de 1 semana me parece solo aptos para CR7-Messis de la programación… yo soy un Tamudo.

    Se menciona también lo de las estadísticas y conocer tu velocidad, otro tema con el que he tenido controversia…
    sí creo que son importantes pero en un segundo plano, vamos que si tienes unas métricas espectaculares,
    pero tu proyecto no vale para nada y el usuario piensa que es una castaña, pues enhorabuena por tus números pero no vale.

    El tema de las ramas, es otro tema que me da miedo. Tengo que reconcer que tengo pánico al merge (sobre todo si lo he hecho yo). Es posible, que se deba al hecho de que nunca he trabajado en un entorno con más del 60% de cobertura de test automáticos y verdaderamente ágil.

    Un abrazo!

  • Miguel

    Hola Carlos,

    sería muy interesante que continues comentando tus experiencias con feature-per-branch y feature toggling, como afectan a la integración continua y su conseguís reducir el tiempo de salida a producción al minimo. Veo resultados muy dispares en diferentes empresas y siempre se agradece ver mas casos.

    En mi proyecto actual (sobre 10-12 developers) después de mucho debatir optamos por Feature Toggling ya que requeria menos cambios en la metodologia de planificación y en el pipeline de integración continua. Y porque hacer un merge únicamente al final de una tarea, por mucho que se intente reducir su alcance, me acojonaba.
    Estamos bastante contentos. Solemos desplegar a producción mínimo una vez al dia (antes llegábamos a necesitar 3/4 días hasta cuadrar una versión sin funcionalidad a medias) y no hemos encontrado ningún problema, pero sigo indagando a ver como le ha ido a otros equipos.

    Un saludo

  • http://www.carlosble.com Carlos Ble

    Muchas gracias por el feedback Miguel. Tan pronto como tenga algo que contar a este respecto publicare un post. De momento no hemos empezado el feature toggling aunque sera inminente.