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!

11 comentarios sobre “Serías capaz de… ¡por supuesto! o Scrum también da respuestas”

  1. Rodrigo, que buen post: 100% práctico y veo que la fama que tienen por el pais Vasco es cierta jejeje

    Saludos

    Aunque la frase «Por mucho que para CMMI sea rara vez la elección metodológica adecuada, creo …» si la escuchan los militares, te comen crudo !!!

  2. Ya sabía yo que no iba a tener muchos amigos en esta batalla…
    Estoy de acuerdo en todo o casi todo, aunque sigo defendiendo el modelo como una alternativa a tener en cuenta.

    Si llego a saber que se iba a tomar esto como un reto (con testosterona incluida ;P ) me hubiese esmerado más en escribir preguntas mas detalladas.

    En la única parte que no estoy de acuerdo es que para nosotros es muy importante el porcentaje de ocupación de una persona, ya que no es habitual que participe solo en un proyecto y responder a la pregunta de cuando termina su tarea en un proyecto, es fundamental.

    Aunque soy de padre Cántabro y de madre Gaditana…, estuve un año viviendo en Bilbao, algo se me pegaría, no¿?

    Apa!

  3. Hola!

    Miguel, Sin llegar a discutir si una puede ser mejor que otra, aunque tengo clara mi opción, creo que es de alabar el esfuerzo que estáis haciendo por implantar una metodología, ya que lo peor considero que no es hacer nada.

    Ya habéis dado el primer paso, que es darse cuenta de que las cosas se puede mejorar y hacer algo por conseguirlo.

    Ahora os falta el siguiente paso, daros cuenta de que las metodologías ágiles os puede ayudar aún más 🙂

  4. @Bruno: talibanes hay en todas las facetas… no hay miedo, con razones y con discusión sana es como avanza el mundo.

    @Miguel: Insisto en lo que ya digo en el post, creo que es encomiable el que compartas tu experiencia. No me lo tome como un reto, sino como una oportunidad de explicar como hacemos en Scrum cosas que se hacen en CMMI. Sobre el tema del equipo, hacer equipo es algo vital en Scrum y algo vital en gestión de proyectos en general es evitar los cambios de contexto. El otro día escribía sobre esto precisamente (http://geeks.ms/blogs/rcorral/archive/2009/06/25/Exprimiendo-Scrum_3A00_-_BF00_Cu_E100_l-es-tu-definici_F300_n-de-equipo_3F00_.aspx). El trabajar en equipo es vital para evitar los cambios de contexto que son una remora para la productividad.

    @Ibon: Comparto lo que dices, no hay nada peor que la indolencia o la gente que cree que ya gestiona sus proyectos… y en realizada no hace nada…

    ¡Un saludo y gracias por los comentarios!

  5. Hola!
    Comenta Miguel: «En la única parte que no estoy de acuerdo es que para nosotros es muy importante el porcentaje de ocupación de una persona, ya que no es habitual que participe solo en un proyecto y responder a la pregunta de cuando termina su tarea en un proyecto, es fundamental.»
    Uhmm ¿Esto suena un poco a «pool de programadores», no?
    http://geeks.ms/blogs/rcorral/archive/2007/09/12/el-pool-de-programadores.aspx
    😀
    Un abrazo!

  6. «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 ;).»

    Jejeje, muy bueno. Bromas aparte, buena reflexión sobre Scrum.

  7. ((Error!! el comentario anterior iba para el blog de Javier Barbuglia. En él le agradecía el enlace a tu blog, pero me he liado. Mil perdones… ))

  8. Rodrigo,
    Considero que parte de las cosas que aparecen resueltas en tu listado de «capacidades», viene más dadas por TFS en sí, que por el seguimiento de una metodología ágil.
    Pienso que el hecho de que TFS cubra estas utilidades, viene dado porque TFS puede utilizarse para implementarse una metodología que siga los requisitos CMMI.
    Saludos

  9. Hola Carmen:
    No estoy de acuerdo con tu comentario. TFS nos ayuda muchísimo y nos facilita la recolección de datos históricos, evidencias y métricas enormemente. Pero cualquier equipo que haga Scrum puede responder estas preguntas, use o no TFS como herramienta de gestión de proyectos.

    Eso sí, no tengo duda que a un equipo que use TFS le será mucho más facil dar estas repuestas.

    ¡Un saludo y gracias por el comentario!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *