Serías capaz de… ¡por supuesto! o Scrum también da respuestas

SpideyVsWolverine Escribía un interesante post de Miguel Sierra, vecino de blog en Geeks.ms, sobre la implantación de CMMI que ha llevado a cabo su empresa. El post es interesante, y agradezco a Miguel que comparta su experiencias. Por mucho que para mi CMMI sea rara vez la elección metodológica adecuada, creo que es un marco metodológico que debemos conocer, aunque solo sea por la influencia que ha ejercido en el desarrollo de software en los últimos años. Además a mi ‘me va en el sueldo’, pues me toca apoyar técnicamente la implantación de TFS en organizaciones que han elegido CMMI como marco de trabajo.

Lo que motiva este post es el ‘reto’ que lanzaba Miguel preguntando si seríamos capaces de responder a una serie de preguntas relacionadas con el ciclo de vida de nuestros proyectos. Yo que llevo ya un tiempo viviendo en Bilbao, y se me ha pegado un poco la vena Vasca, no he podido remediar el recoger el guante y decir ‘que te apuestas a que sí”’. Es un poco como el chiste de meter cien vascos en un seiscientos… diciéndoles que no caben. Es un poco como las luchas fictícias entre superheroes tipo Lobezno contra Spiderman.

Aquí van las preguntas de Miguel y la respuesta que Scrum en particular y las metodologías ágiles en general darían, de la mano de TFS:

¿Serías capaz de …?

Identificar las tareas y pruebas funcionales relacionadas con un requisito concreto

Tras el Sprint Planning Meeting y antes de que cualquier trabajo de desarrollo se realice, el equipo de desarrollo desglosa las historias de usuario (requisitos) en tareas. Toda historia de usuario lleva explícitamente en su definición las condiciones de aceptación (versión ágil de las pruebas de aceptación). Luego la respuesta es si.

Identificar las partes de código fuente a las que afecta un cambio de requisito

Por supuesto. Todo cambio tendrá su historia de usuario asociada. En Scrum no se hace ningún desarrollo sin que pase por el backlog y por lo tanto sin que ese trabajo este definido. Apoyándonos en TFS podemos enlazar los cambios en el código con tareas o requisitos en el momento de hacer checkin… ¿a alguien se le ocurre algo más productivo, menos intrusivo para el desarrollador?. Además para que nadie se olvido lo podemos ‘imponer’ mediante políticas de código

Decir cuando se realizó una tarea en concreto y la cantidad de esfuerzo que supuso

Lo lleva el TFS. Sin salir del su entorno natural, el IDE de desarrollo (sea VS o Eclipse) el desarrollador puede actualizar el estado de sus tareas o bug en el mismo instante en el que comienza su trabajo o lo termina. Y sin cambio de contexto alguno. Evidentemente, aunque en Scrum no nos importa demasiado, es posible responder con facilidad el tiempo que te llevo implementar una determinada tarea, bug o requisito. Otra vez, gracias a TFS con burocracia cero para el desarrollador.

Realizar una estimación precisa de una tarea que ya realizaste en algún proyecto anterior

El Product Backlog se debe estimar, las tareas que forman parte de un Sprint se estiman. Scrum no dice nada sobre como debes estimar, pero la comparación con experiencias anteriores es la técnica que explicita o implícitamente todos usamos. Los equipos ágiles suelen preferir métodos más ligeros y más llevaderos de estimación, basados en mejorar el conocimiento, la responsabilidad compartida y el consenso.

Listar las tareas que tienes pendientes en un determinado módulo de tu proyecto

En Scrum el concepto de ‘hecho’ y ‘no hecho’ es clave para gestionar el avance del proyecto. Sabemos en todo momento que elementos del Product Backlog han sido completado y cuales no. Exactamente el mismo aplica a nivel de Sprint Backlog. No solo eso, además visualizamos este estado mediante los gráficos de burndown.

Decir el tiempo restante para terminar un módulo de tu proyecto

En Scrum evitamos construir por módulos. Un módulo por si mismo no suele se capaz de hacer algo de valor para le cliente. No se trata de completar módulos, sino de liberar en cada momento lo que más valor tiene para el cliente. Tratamos de construir el software en ‘tiras verticales’ que implementan toda la funcionalidad de una determinada historia de usuario. Logramos así un continuo flujo de valor. Mirando el Burdown Chart es muy simple decir cuanto queda para completar el proyecto. Evidentemente podemos filtrar este Burdown Chart para las historias de un area (módulo) concreto.

Sacar un listado de las incidencias de un proyecto y la desviación en esfuerzo, tiempo y coste

Una vez más la respuesta es el Burdown Chart que visualiza cualquier desviación en tiempo real. El Burdown Chart refleja las desviaciones en tiempo, pero todos sabemos que tiempo y coste son magnitudes convertibles en gestión de proyectos. Por ejemplo en este Burdown Chart se aprecia claramente una desviación de 60 puntos en un proyecto de 20 unidades de tiempo.

Sacar un listado de las peticiones de cambio de un cliente

El Product Backlog recoge continuamente todas las peticiones del cliente. Todo lo solicitado por el cliente es gestionado por el Producto Owner utilzando el Product Backlog que permanece vivo a lo largo del proyecto. TFS nos proporciona informes sobre la tasa de cambio que ocurre en el Product Backlog.

Certificar que los requisitos del proyecto han sido entendidos y comprometidos por el equipo de trabajo

Evidentemente. Durante el Sprint Planning Meeting, los desarrolladores entienden los requisitos, hacen preguntas y mejoran su conocimiento. La primera parte del Sprint Planning Meeting se dedica a esto. El Sprint Planning Meeting termina con el compromiso de los desarrolladores de hacer todo lo humanamente posible para lograr implementar los requisitos comprometidos para el Sprint durante el mismo.

Identificar, si una prueba falla, que requisitos se ven afectados

TFS permite asociar pruebas de aceptación y sus resultados con cualquier tipo de work item. Si haces esto, es simple responder esta pregunta. Yo he trabajado con equipos que hacen esto y equipos que no lo hacen. Si hay un tester en el equipo, es muy recomendable.

Entregar una versión del producto, mas o menos estable, al cliente, ahora mismo

Lógicamente. Esto es un problema clásico de SCM. En cierto modo no está ligado a la metodología, sino que es una práctica de ingeniería del software más que recomendable. En Scrum todo Sprint debe terminar con un ‘incremento de funcionalidad potencialmente entregable’. Las políticas de SCM de un proyecto que use Scrum deben adecuarse a este objetivo. Una vez más, aperece aquí, el objetivo de Scrum y de las metodologías ágiles en general de ‘crear un flujo continuo del valor para le cliente’.

Decir el porcentaje de construcción del producto o proyecto y certificar el coste actual, “on the fly”, del producto

Una vez más me remito al Product Backlog y a su primo visual, el Burndown Chart.

Decir los riesgos activos que hay en tu proyecto

Claro que gestionamos el riesgo, lo llamamos impedimentos y lo hacemos de una manera un poco diferente. No ponemos tanto énfasis pero todo proyecto Scrum tiene un backlog de impedimentos, que es ‘equivalente’ a la lista de riesgos. Otras metodologías ágiles, sobre todo MSF Agile, hace un gestión del riesgo mucho más explicita.

Enumerar las personas dedicadas al proyecto y el porcentaje de ocupación

Ufff… porcentaje de ocupación… es que alguien en alguna empresa no está ocupado al 100% :). Bromas a parte. En Scrum no nos importa tanto la ocupación del individuo como la del equipo. El concepto de equipo es vital. Pero lógicamente, en todo momento tratamos de ajustar la carga del equipo a su capacidad.

Decirme cuando queda liberado un recurso en concreto

Ummm… si por recursos te refieres a máquinas, servidores, fuentes de agua, y máquinas de café y refrescos… simplemente tratamos de tener los suficiente ;).

Decir las medidas correctivas que has tomado cuando has tenido desviaciones

Todo Sprint termina con una Sprint Retrospective. Se trata de saber que ha ido bien, que ha ido mal y plantear las acciones correctoras. Todas las conclusiones quedan reflejadas en TFS y las acciones correctores necesarias que impliquen un esfuerzo explicito se meten en Product Backlog para su gestión dentro de el marco de un Sprint.

Contar lo que se habló en la ante última reunión de seguimiento con el cliente

En Scrum las reuniones de seguimiento son obligatorias. Ocurren puntualmente con periodicidad predeterminada. En esta reuniones de seguimiento, Sprint Reviews en la jerga de Scrum, se muestra software que funciona mediante ‘demos’. Ocurre, sin excepción, al final de cada Sprint. El cliente puede ver el progreso, no imaginárselo en base a diagramas de Gantt o sesudos informes de seguimiento. Además puede y debe dar feedback sobre lo visto durante el Sprint Review.

Enumerar las tareas y esfuerzo que te va a suponer la puesta en producción

Los equipos ágiles tratamos de hacer de la puesta en producción una hábito. La idea es minimizar el esfuerzo de puesta en producción hasta limites tales que sea inapreciable. Para ello nos apoyamos en técnicas como la integración continua o frecuente y el testeo automatizado. Dicho esto, cualquier tarea que se realice, sea del tipo que sea, se debe meter en el marco de un Sprint.

Como podéis ver Scrum responde las mismas cuestiones que CMMI de una manera diferente, pero las responde. No podía se de otra manera, pues muchas de las cuestiones planteadas por Miguel, son cuestiones universales en la gestión de proyectos de software.

Esto me lleva a pensar… es posible usar Scrum + TFS, para cubrir CMMI Nivel 2… la respuesta es que sí. Precisamente de esto habló mi compañero Jose Luis Soria hace poco en un evento sobre CMMI, a ver si se anima y publica las ppts en Slideshare.

¡Un saludo!

Exprimiendo Scrum: ¿Cuál es tu definición de equipo?

Equipo ALa problemática de la gestión de proyectos en las organizaciones que desarrollan software se deriva, simplificando el asunto, de dos situaciones: gestionar proyectos muy grandes o gestionar muchos proyectos pequeños. Todos estaremos de acuerdo en que cualquiera de estas dos situaciones es más compleja que la situación, más equilibrada, en la que tenemos un número limitado de proyectos con unas dimensiones limitadas.

De estas tres posibilidades, sin duda la más compleja es muchos proyectos pequeños. Los grandes problemas siempre se pueden dividir en problemas de tamaño medio y reducir así la complejidad, llevarlos a la categoría de ‘un numero pequeños de proyectos medianos’.

El por qué la situación más compleja se da cuando tenemos muchos pequeños proyectos es simple: tendemos a tener más cambios de contexto. Los cambios de contexto se dan al ‘pasar’ de un proyecto a otro y son tiempos perdidos. Si a un número grande de proyectos pequeños, unimos que no hay concepto de equipo, los cambios de contexto son continuos y la caída de productividad acusada. Cuando un proyecto está en manos de una persona y no de un equipo, esta persona inevitablemente es un cuello de botella. No voy ha hablar hoy de los cambios de contexto, en otra ocasión volveré sobre el tema, que ya he tratado, someramente, en alguna otra ocasión.

Cuando tratamos de implantar Scrum en una organización este problema de la gestión de proyectos también nos afecta de manera decisiva. Como hemos comentado se trata de un problema de cambios del contexto y el antídoto de Scrum para los cambios de contexto es el concepto de equipo autoorganizado y autogestionado. La idea clave es que un equipo autoorganizado y autogestionado puede elegir en que momentos introducir los cambios de contexto, y por simple sentido común elegirá los momentos idóneos. Siguiendo con esta argumentación se hace patente que es precisamente en entornos que presentan muchos pequeños proyectos en los que más dificultoso es implantar Scrum y en los que más atención se debe prestar a un tema clave: definir que es un equipo en tu organización.

En empresas con ‘muchos pequeños proyectos’, como la gran mayoría de las pequeñas y medianas consultoras, la gran dificultad pasa por encontrar que es un equipo para esa organización, en primer lugar, y en segundo lugar definir cuantos product backlogs se van manejar.

Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenemos que pasar de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Esa es la gran dificultad.

El principal problema que tenemos en la situación actual es el tiempo que se os va en cambios de contexto, insisto. Probablemente estemos en la típica situación de prioridades difusas, de atender a los fuegos, al cliente que más grita… el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo, por ahí empiezo yo toda implantación de Scrum en este tipo de situaciones, definir los equipos.

Esa definición de equipos se puede hacer atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)… Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.

Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:

1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.

Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Aunque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.

Hay una manera muy simple de saber si hemos hecho esto bien: elegimos un desarrollador al azar y le preguntamos:

¿Tu a qué equipo perteneces?
¿Dónde está vuestro product backlog?
¿Quién son vuestro Producto Owner y Scrum Master?
¿Cuáles son los objetivos de tu equipo para este sprint?

Si recibimos respuestas ambiguas, es que no tenemos un modelo de equipos. Sin un modelo claro de equipos no es posible una correcta implantación de Scrum.

El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo en lugar de algunos proyectos grandes que respondan al modelo simple de Scrum.

Este post, se inspira en una interesante conversación mantenida sobre este tema en la lista de Agile Spain, quizás queráis leer los pensamientos allí expuestos.

¡Espero vuestros comentarios!