Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.
En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.
Después de haber realizado siete iteraciones, o sprints, y haber completado tres versiones de un proyecto, ya en producción, y otros tres proyectos más casi en producción, puedo dar mis conclusiones acerca de esta metodología de planificación del desarrollo de software:
- Scrum permite el desarrollo ágil, esto es, sobre todo, basándonos en un diseño global, y aplicando un poco la metodología de los prototipos evolutivos, conseguir una versión simple, lo más rápidamente posible y que asiente las bases de lo que será la aplicación futura.
- Las iteraciones cortas, de dos a tres semanas, permiten una supervisión de lo que se va haciendo cada poco tiempo, pudiendo cambiar el rumbo entre sprint y sprint, para adecuarse a los cambios de requisitos funcionales o cambios de prioridad que puedan surgir a lo largo del desarrollo del programa.
- El gráfico de burn-down es una muy útil herramienta que permite tener una visión dinámica de la velocidad con la que se va produciendo el desarrollo y prepararse, de forma anticipada, a posibles variaciones en las fechas de entrega, ya sea resumiendo o eliminando funcionalidad. En caso positivo, si la marcha del proyecto va más rápido, permite agregar otras tareas no planificadas o prioritarias que se pensaban hacer en futuros sprints.
- Las tarjetas y el tablero de juego que plantea esta metodología, le da una visión lúdica al trabajo y hace que se convierta en un juego. Las tareas se suceden y, todos saben lo que hace cada cual. Incluso los directivos inmediatamente superiores, en lugar de interrumpir el trabajo, con solo mirar el tablero, ya saben cómo va el proyecto.
- El hecho de partir tareas, hace que se puedan paralelizar mejor, con lo que aumenta la potencia del trabajo en equipo, pudiendo hacer varias personas tareas sin solaparse. En esto, el trabajo con metodologías de tipo Xtreme Programming, programando por parejas, tareas concretas de corto espacio de tiempo y basándonos en el desarrollo orientado a pruebas hace que sea más óptimo.
A todo esto, sumamos el orgullo de poder presentar los proyectos en la fecha pactada, junto con la sensación de que el trabajo se ha realizado en el tiempo adecuado, sin quemar a nuestro personal, y tenemos una combinación muy óptima.
¿Qué es lo siguiente? En principio me planteo seguir profundizando en las técnicas de Xtreme Programming para integrarlas en el desarrollo de las tareas individuales que propone Scrum, ya que así son completamente compatibles y muy potentes. Así mismo, adentrarme más aún en los frameworks de pruebas unitarias tanto para PHP, como Ruby, Erlang y C. Espero así, conseguir incluso hasta mejores resultados, ya no hablando de tiempos, sino de calidad de producto.
Loading ...
Me parece que el único “problema”, es el tiempo que se propone al desarrollo. En mi percepción en cuanto a trabajar con estas metodologías, es que se tiene que dar una estimación de tiempo una vez terminado el diseño del proyecto, ya que hasta entonces no puedes ver el nivel de dificultad que tienen los módulos a desarrollar, provocando así un desface de tiempo en partes que quizá pensabas que no serian mucho problema.
También nos encontramos con variantes que no se pueden controlar como son ausencias de enfermedad, vacaciones, distracciones, etc. Que provocan retrasos en el desarrollo.
Es bueno dar una o dos o semanas como “colchón”, dependiendo del tipo de proyecto, así también te da espacio para pruebas y optimización de algunos módulos o simplemente para no quedar “apretados” con la entrega del proyecto.
En cuanto a la metodología del gráfico y del Scrum, me parecen excelentes herramientas de planificación de desarrollo de software.
Saludos.
[ Responder ]
Respecto al diseño, siempre se debe de realizar un diseño a alto nivel sobre qué es lo que se quiere conseguir, e incluso adentrarse un poco en detalles de desarrollo, como las librerías, marcos de trabajo (frameworks), lenguajes y demás elementos a tener en cuenta.
En proyectos “novedosos”, en los que se usan tecnologías no cotidianas para el equipo de desarrollo y se plantean “desafíos”, que podrían resolverse en poco o mucho tiempo, no se puede establecer una norma fija, pero si se puede preveer un tiempo específico para:
Problemática a resolver
Opciones a estudiar
Decisión de las opciones por las que decantarse
Desarrollo de las mejores opciones
Elección de la opción que evolucione mejor
Esto sí se ve en el diseño a gran escala, el número de posibles puntos “conflictivos” que se pueden llegar a encontrar, y el tiempo que se puede destinar a intentar resolver cada uno de ellos. En caso de que se complique, siempre se puede tomar una opción tangente y proponer una posible mejora para una futura iteración.
En lo que respecta al “colchón” estoy totalmente de acuerdo. Yo siempre agrego un mínimo del 10% a lo que se estima en un principio y no tengo en cuenta ni fines de semana, ni festivos, ni vacaciones de personal, por supuesto. Ahora que, en lo que respecta a faltas sin aviso, distracciones o ausencias por enfermedad… supongo que esto es como las “catástrofes naturales” que ningún seguro (o casi ninguno) cubre. A este respecto, en el que se incluyen cambios de prioridades, requisitos o ausencia de recursos humanos, no se puede hacer nada.
[ Responder ]
Estoy de acuerdo contigo.
Guillermo
[ Responder ]