¡Oh no, otra herramienta de Scrum!

Cuando volvimos a la versión 4 de Teamwork después de revisar algunas lecturas sobre métodos ágiles, y en particular reconsiderando la perspectiva de Scrum, se volvió progresivamente más claro que mapear las ideas de Scrum a esta o aquella funcionalidad de un software es inevitablemente una simplificación y quizás incluso una traición a la filosofía ágil: ya que estas metodologías se refieren a la forma en que abordas los problemas, y tienen grandes variaciones en el detalle cuando se trata de cada caso particular; ver

Gestión de proyectos ágiles con Scrum de Ken Schwaber, Microsoft Press

que está lleno de ejemplos.

Desde esta perspectiva, el punto principal no es y no debería ser el software de gestión que estás utilizando. Volveremos a esto en las consideraciones finales.

Asumimos aquí familiaridad con los conceptos de las metodologías ágiles y Scrum. También los ejemplos están ajustados al desarrollo de software, pero la línea, si es válida, es válida en general.

Ejemplos de mapeo

Si uno decide usar un software de gestión para administrar procedimientos ágiles, debe tener cuidado de no tomar decisiones simplistas.

Considera, por ejemplo, el backlog: recopilar un backlog es el paso más básico; ¿cómo recopilas el backlog? Puede ser, por ejemplo, un documento de Google compartido; por lo tanto, desde el punto de vista del software de gestión de proyectos, tu backlog es un documento no estructurado que el software no administra. Puede ser un conjunto de entidades separadas, digamos, problemas (issues)? Puede estar hecho de tareas con descripciones detalladas y estimaciones de trabajo; y así sucesivamente.

En muchos ejemplos de enseñanza de Scrum vemos tarjetas pegadas en tableros, y algunos softwares simplemente usan esa idea para la interfaz de usuario. La gente parece simplemente no darse cuenta de que un proyecto de desarrollo puede tener fácilmente unas 800 “tarjetas”. ¿Cómo demonios voy a pegarlas en un tablero??? No puede funcionar. Necesitas algo más flexible y potente que un tablero concreto o digital.

Reuniones diarias (stand-up): ¿por qué el registro del backlog es el tema de la gestión por software y las reuniones no lo son? Esta es una perspectiva típica y equivocada de los hackers, porque algunas personas enfocan su gestión más en su agenda que en su lista de tareas pendientes, si es que tienen una. Y tendrás proyectos con ambos tipos de personas (y muchas más).

¿Por qué el registro de la actividad en las tareas asignadas tiene que hacerse reduciendo las horas en los elementos seleccionados del backlog? ¿No sería más práctico si, por ejemplo, uno pudiera registrar la actividad en los commits de Subversion? ¿O en tu feed de Twitter? Aquí también, necesitas una herramienta de final abierto, que recopile datos de muchas fuentes de diferentes maneras.

Un ejemplo: veamos una estructura de proyecto y asignación de muestra: supongamos que tienes un cliente, un desarrollador líder y un conjunto de desarrolladores, D1, D2, D3; quieres recopilar el backlog, y básicamente tu objetivo principal es permitir que los desarrolladores trabajen en condiciones tranquilas y con un conjunto estable de requisitos durante un mes. Bueno, modelar eso en Teamwork no es gran cosa, puedes apoyar este procedimiento de varias maneras; por ejemplo, puedes tener un proyecto raíz ROOT, en el que todos están asignados como “lector”, y el desarrollador líder como gerente de proyecto; tienes un hijo BACKLOG, donde el cliente está asignado como “trabajador”, para que pueda contribuir insertando el backlog; el backlog se inserta como problemas (issues) en esta tarea BACKLOG.
Luego creas una nueva tarea hija de ROOT’ llamada FIRST SPRINT, mueves el subconjunto de problemas que constituyen su esfuerzo a ella, y asignas a D1, D2 y D3 como “trabajadores”, para que puedan editar y cerrar los problemas, pero nadie externamente cambiará el conjunto de problemas. Eso es todo.
En esta estructura, Teamwork te da muchas, muchas, muchas herramientas para continuar, trabajar cómodamente, conectar este proyecto con otros estructurados de manera diferente; puede ser incluso un hijo de un proyecto con una estructura completamente diferente. Puedes estructurar la tarea BACKLOG misma como un árbol; puedes tener varios sprints en paralelo; puedes tener después del sprint un flujo de trabajo de aprobación, y de nuevo aquí Teamwork te apoya con tareas como procesos. Se podrían hacer más ejemplos.

Consideraciones finales

Una consideración muy importante es que las metodologías particulares, digamos Scrum, ayudan a resolver algunas clases de problemas, pero nunca cubrirán la totalidad de la actividad laboral de una empresa, ni siquiera la totalidad de los proyectos de una empresa. De hecho, los textos originales de Scrum están escritos con plena conciencia de esta limitación.
Así que sería extremadamente no ágil tener un software específico para seguir los proyectos “ágiles”, y otro para los “otros”. E incluso los proyectos “ágiles” tendrán tantas variaciones, que encajarán en las metáforas ágiles en diferentes niveles, y difícilmente encajarán en un único “modelo de software Scrum”.

Así que al final nos dimos cuenta de que el mapeo entre la metodología y el software (o papel) requiere gran flexibilidad; la agilidad está en la metodología, no en el software. Si quieres usar un software, debe ser lo suficientemente flexible para permitirte mapear proyectos, tareas y problemas a personas y clientes, de infinitas maneras diferentes, pero de modo que todos los datos de los diferentes proyectos y metodologías terminen en el mismo lugar.
Así que no, Teamwork no es otra herramienta de Scrum, es una herramienta de gestión que puede ayudar también a aquellos que decidieron usar Scrum para algunos proyectos, si no prefieren usar tarjetas de papel 😀