Mi nueva Scrum vida – reglas vrs. guias

Como algunos ya saben estoy tratando de independizarme y fortalecer un proyecto personal de desarrollo y soporte, que espero que termine en algo más grande. Y ya que aun no estoy dedicado al 100% al ambito laboral la verdad prefiero que sea en algo mio y no codeando como desquiciado (si necesitan algo pregunten jajaja) por mala paga.

Como en todo hay que ser organizado pues he estado documentandome un poco acerca de Scrum y otras metodologias de administración de proyectos. Sin embargo para lo que hago en este momento es perfecta la forma como Scrum ayuda (equipo pequeño, desarrollo rapido, feedback instantaneo) y aunque al inicio chocaba con mis principios J2EE y desarrollo bien planificado. Descubri que la JVM tambien se lleva bien con Scrum :).

Pero bueno uno de mis primeros choques con la transición RUP->Scrum ha sido el marco de trabajo. Para los que han trabajado en RUP o alguna metodologia tradicional lo primero que se nota en RUP (o al menos que yo note) es que en Scrum el marco de trabajo no se ve definido por un par de libros o documentación estricta.

Este es uno de los aspectos que me han gustado de Scrum. El enfoque de otras metodologias es establecer una serie de reglas para el desarrollo de un proyecto. Lo cual a muchos principiantes como yo o en proyectos de mediano tamaño nos encasilla y limita en lugar de simplemente establecer orden. En Scrum al contrario los principios Scrum si es que asi se les puede llamar tienden a ser lineas guia y «pactos funcionales» para los desarrolladores.

El dinamismo en Scrum viene dado porque la naturaleza de las reglas nos dice que estas nacen para establecer un comportamiento y  sin embargo las guias permiten que los involucrados escojan un comportamiento apropiado.

Asi pues si su proyecto es mediano y necesitan tenerlo para ayer, cosas tan simples pero a la ves logicas como:

1. Las contribuciones de cada miembro del equipo son importantes
2. Todos los miembros tienen el mismo derecho a opinar
3. Enfocarse en terminar con el problema y no con el que lo provoco
4. Respetar las diferencias y las virtudes de cada miembro del equipo

Parecieran sacadas de un libro de autoayuda y superación personal. Sin embargo cuando todos los miembros del equipo las respetan y todos participan pueden ser la diferencia entre entregar un proyecto a tiempo o simplemente pedir prorrogas que molestan a un cliente que cree que cualquiera puede programar y el desarrollo de software solo involucra saber escribir ciclos y sentencias condicionales.