Recientemente asistimos a un curso de CSM donde Robin Dymond nos mostró un video que merece la pena ver. ¿Será este el primer Scrum Master de la historia? juzgar vosotros mismos.

|

Leyendo lo que Roberto nos dice en su post "Preparados para ser ágiles" me ha venido a la cabeza algún que otro problemilla que hemos sufrido en proyectos cuando algún director, al finalizar un sprint, pregunta: y bien, ¿cómo va el avance del proyecto? ¿qué tal ha ido esta iteración? quiero un pequeño informe para ir tomando decisiones. Mi respuesta inicial fue: lo mejor que puedes hacer es acercarte al panel de tareas, echarle un vistazo al burndown chart y al release burndown chart, con esto podrás contestar todas tus preguntas.

Esta respuesta te puede servir por primera vez pero al final te siguen pidiendo, iteración tras iteración, alguna forma menos pesada (para ellos) de tener datos, al final yo pensaba: "ya estamos volviendo a la burrocracia innecesaria. Esto no es nada ágil, si la información está ¿por qué tenemos que reproducirla en otro formato?"

Finalmente, después de leer un buen libro (Agile estimating and planning) tome prestada una pequeña idea de Mike Cohn presentando al final de cada sprint un resumen.

Os muestro un ejemplo donde he eliminado algunos datos "confidenciales" con algún borrón que otro ;-)


La primera sección comienza con una explicación del contexto del sprint: indicamos fecha de inicio, fin, número de días laborables y el personal que ha participado.

Si os fijáis en la última tabla se ponen días planificados vs. días trabajados, mostrará si una persona estuvo al 100% asignada, si estuvo enferma, etc. esto ayudará a dar explicaciones de qué ocurrió en la iteración.





La siguiente sección mostrarán gráficos muy útiles: burn down chart y un gráfico de barras de la velocidad de las últimas iteraciones, junto con la media.


Finalmente, siempre siempre me gusta poner una valoración del sprint donde indicaremos que historias de usuario fueron incluidas y los puntos que realmente han ganado.


Si os digo la verdad este tipo de informes, que a mi me llevaban 40 minutos, ayudó a la dirección de la empresa a ver un estado del proyecto y a mi mismo para tener datos históricos del equipo que en el futuro nos ayudaría a mejorar. Y vosotros, ¿usáis algo parecido? sería muy interesante si alguien comparte su experiencia.

|

Las metodologías ágiles se postulan como una respuesta adecuada a las necesidades actuales (rápidez, adaptación al cambio, flexibilidad) en el desarrollo de software. Leyendo y revisando sobre estas metodologías, especialmente SCRUM, me ronda por la cabeza una idea que comparto en este artículo: ¿estamos preparados para ser ágiles?.

Si explicamos las bases y el funcionamiento de SCRUM a cualquier persona (recomiendo realizar el "experimento" con alguien no relacionado con la informática) su primera reacción será la de preguntarnos por qué buscamos nombres complicados ("Product Owner", "Sprint", "Backlog") a algo que parece de sentido común. El método propuesto, las figuras y roles que participan, la filosofía de trabajo y la relación entre todas las partes (clientes, equipos de trabajo, partes interesadas "stakeholders") son simples de entender. Si me apuras, diría que también son simples de aplicar. La primera vez que leí sobre SCRUM tuve la tentación de pensar que, de alguna manera, ya había aplicado algunos de sus principios a los proyectos en los que había participado.

Tenemos en nuestras manos una metodología como SCRUM que no necesita de grandes tecnicismos, que facilita la colaboración y comunicación entre clientes, ingenieros, comerciales, directivos, entonces, ¿por qué volvemos a las metodologías tradicionales, a lo ya conocido, cuando las cosas se ponen difíciles?, ¿estamos realmente preparados para aplicar las metodologías ágiles, independientemente de la situación del proyecto?. Mi opinión es que el planteamiento de las metodologías ágiles lo asumimos sin ningún esfuerzo por bueno. La estructura de una gran mayoría de las empresas cuentan con una organización (departamentos, áreas, responsables de departamento, comités de evaluación,etc) y asignación del personal en múltiples proyectos que impide la implantación de SCRUM o de cualquier otra metodología ágil. En otras ocasiones la dificultad viene de las personas que participan en el proyecto, asumir responsabilidades, disciplina, compromiso en realizar lo que he dicho públicamente que voy a hacer, parece que no es tan fácil.

Me interesa saber si, ¿realmente estamos preparados para ser ágiles?.

|

Cuando comencé a utilizar por primera vez Scrum me planteé utilizar alguna herramienta donde se pudieran ir creando historias de usuario, tareas, etc. ya que colocar un panel de control dentro de la oficina se planteaba complejo. Algunas herramientas disponibles requerian sencillamente de un servidor web, un poco de tiempo y que cada uno fuera actualizando sus tareas actualizando la herramienta.

Hay algunas gratuitas con un número limitado de usuarios como Tiny pm (http://www.tinypm.com/) que automáticamente iban actualizando el burndown chart y liberaban al Scrum Master del trabajo más "burocrático".

Finalmente decidí probar lo que parecía algo mucho más artesanal y logré que nos dejaran usar una pared en la sala donde realizabamos el daily scrum meeting , pusimos algunas cartulinas, los tipicos carteles de "para hacer, en progreso y hecho" y toda la información se actualizaba a diario, creo que si hubieramos usado alguna herramienta al final me hubiera tocado a mi ir actualizando todo a la vez que el equipo hablaba y lo mejor de todo es que todo el mundo, independientemente de si pertenecía al proyecto o no, veía el grado de avance.

Después del exito de las cartulinas, los post-it, las historias de usuario en tarjetas de cartón me decanto por seguir usando las manualidades en lugar de una herramienta, por lo menos para proyectos donde no haya equipos distribuidos, ¿y vosotros?.

Aquí os muestro algunos ejemplos de nuestro panel, decidimos usar inglés para que las etiquetas no fueran gigantescas ;-) a ver que os parece

taskboard antes de comenzar el sprint 1

etiquetas con nombres y burndown chart

|