Genera gráficos burndown de forma sencilla
Si utilizas scrum como metodología de trabajo o si has oído hablar de ella, seguramente habrás oído hablar también del gráfico burndown. Con él, de forma sencilla puede verse de un vistazo información sobre cómo va el trabajo realizado durante el sprint entre otras cosas.
Estos gráficos son muy sencillos de realizar, pero si no quieres complicarte nada la vida, tienes Yet another online burndown generator o, lo que es lo mismo, un generador de burndown online.
El funcionamiento es muy sencillo: indicamos los puntos (u horas o la unidad de trabajo con la que estés midiendo tu velocidad), los días y un título. Con estos tres datos, la aplicación te genera un PDF del tamaño de un A4 horizontal listo para imprimir con tu gráfico.
http://www.burndowngenerator.com
Como apunte a este post "fusilado" del autor. Nosotros utilizamos esta herramienta para generar burndown en el trabajo, es rápido y sencillo. Imprimimos y al panel 
Es cierto que puedes tener tu hoja de excel... pero si me lo da una web me parece más sencillo y cómodo, los ficheros en el equipo local o se "traspapelan" o quien lo tiene que utilizar igual no lo tiene Es una web sencilla con un objetivo claro, generar burndown!
Referencia: tatai.es
Scrum: Velocidad vs Calidad
Un título tal vez algo sensacionalista y poco acertado, pero hace unos días me entró la duda de como afrontar este dilema.
En primer lugar, el concepto de terminado que tiene el equipo tiene que estar claro para cumplir el concepto de calidad, por ejemplo:
- Código documentado
- Documentación técnica
- Refactorización de la tarea (si es necesario).
La velocidad de un equipo puede ser constante si el criterio de terminado está definido y se aplica en todas las historias, pero... ¿cuándo tenemos que dejar de refactorizar y/o optimizar?
No se trata de que en cada tarea de historia optimicemos al máximo el código ya que puede que en la demostración se pidan cambios, pero si intentar tener un criterio para no extenderse. Esto puede ser un problema si eres demasiado perfeccionista o estás desarrollando pensando en el futuro. Es bueno preveer el futuro, pero si nos centramos en la funcionalidad inmediata es más sencillo el ir cumpliendo objetivos.
Si en el desarrollo nos centramos en cumplir funcionalidad podemos ir avanzando en el proyecto a una velocidad mayor, pero si en el criterio de "Refactorización" o de "Homogeneización" de código del equipo no se cumple estaríamos generando deuda técnica para futuras iteraciones.
Creo que lo más difícil pensando en la parte técnica, es el llegar a decir "Hasta aquí..." en cuanto a dejar el código como nos gustaría que estuviese. Los técnicos solemos pecar a menudo en intentar a veces hacer naves espaciales para poder cruzar de acera... (Yo el primero) todos nos gusta tener la sensación de "Esto ha quedado dpm!" por eso el ponerse el tope de no ir más allá de donde realmente tenemos que ir, ya que todo es mejorable hasta el infinito y más allá...
Obviamente, cuando nos planteamos una iteración centrándonos en mejorar nuestro criterio de calidad la velocidad es más lenta (he descubierto el mundo xD) pero tal vez no en todos los proyectos se pueda tener la calidad que pueda ofrecer el equipo.
Nuestro amigo Ángel Medinilla siempre afirma que la calidad no es negociable, ¿pero hasta que punto?
A la hora de vender un proyecto la empresa podría ofertar productos/proyectos en diferentes calidades? si... penalizando la calidad, pero también podemos comprar diferentes calidades de un coche por ejemplo las gamas de un mismo modelo. El abanico que podría estar ofertando la empresa podría ser diferente, pero también entraría en conflicto con la posible deuda técnica que podría generar el penalizar la calidad de un servicio no siendo rentable entonces para la empresa.
Calidad, calidad de que funciona siempre! pero el resto de la calidad que no se ve podría ser la que podría variar?
Ser ágil, no significa ser rápido.