Vi la posibilidad que traten de implementar scrum en el trabajo. Esto sería recomendable pero un poco estúpido.

Yo tuve Scrum funcionando en el área hasta que los cambios del corporativo (24 nov) dejaron fuera esa manera de trabajar. Curiosamente varias comunidades en línea y dos razones sociales que manejo usan la misma fecha pero este no es un evento relacionado.

Lo extraño del caso es que , como dije, Tanto SAEM como XFB y AGB ya estaban usando Scrum con su lista de labores del día, pendiente del día y demás. Todo en basde al procedimiento, sabiendo que era SCRUM pero sin decirlo. Funciona.

Hace unos años empezó este problema en varias consultorías que he visto. Personas que tienen idea de vocabulario, escupen metodologías y no implementan ninguna. En este caso, no solo están regresando al repositorio, sino que supongo se darán cuenta de que ya estaba implementado 5s y CMMI 2, además de los 12 pasos de Joel on Software (entre otras).

No me gusta decir se los dije, pero como se los dije, probablemente usen otra metodología y no Scrum.

Un resumen de Scrum tomado de :
===================================================
http://www.ingenierosoftware.com/equipos/scrum.php

estión de proyectos con SCRUM

Por Joaquin Gracia
4 de Septiembre de 2006

¿Qué es SCRUM? SCRUM es una forma de gestionar proyectos de software. No es una metodología de análisis, ni de diseño, como podría ser RUP, es una metodología de gestión del trabajo.

Una de las características más importantes es que es muy fácil de explicar y de entender, lo que ayuda mucho a su implantación.

Por otra parte SCRUM puede ser aplicado a distintos modelos de calidad (como podría ser CMMI) puesto que estos te dicen qué tienes que hacer, es decir, te dicen que tienes que gestionar el proyecto, pero no te dicen cómo. Ahí es donde entra SCRUM como modelo de gestión del proyecto.

Pero vamos a la materia, los siguientes son los elementos básicos de SCRUM.

Una lista con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. Esta lista se llama «Product Backlog». No hace falta que esta lista contenga todas las funcionalidades inicialmente.

De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama «Sprint Backlog». Estas tareas serán realizadas en el siguiente mes.

Además de estos elementos tenemos unas cuantas reglas básicas y sencillas que tenemos que cumplir.

Una vez que se pasan las tareas más prioritarias del «Product Backlog» al «Sprint Backlog», estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas.

Al final del mes, este periodo se le llama «Sprint», se tiene que tener un ejecutable con las funcionalidades del «Sprint Backlog».

Todo el mundo puede añadir funcionalidades al «Product Backlog», pero sólo una persona puede ordenarlo. A esta persona se le denomina «Product Owner». Es el responsable del producto final.

Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo: ingenieros y gestor (llamado «Scrum Master») en la que cada miembro del equipo expone sólo los siguientes temas:
¿Qué es lo que se hizo el día anterior?
¿Qué es lo que se va a hacer hoy?
¿Qué impedimentos tengo para realizar mi trabajo?
Sólo se tratan estos temas para que la reunión sea rápida y no malgastemos el tiempo de los demás. Si se tiene que tratar otro tema se hace otra reunión sólo con las personas implicadas. ¿Recordáis la serie de TV «Canción triste de Hill Street» en la que el sargento tenía una reunión matutina con sus agentes y que terminaba con un «Tengan cuidado ahí fuera»? pues viene a ser algo parecido.

Al final del mes, es decir, al final del Sprint, se presenta el producto y se toma del «Product Backlog» ordenado las funcionalidades para cubrir en el siguiente mes.
Básicamente esto es todo. Como podéis observar las reglas son sencillas y claras.

La duración del Sprint se puede modificar. Hay gente que prefiere Sprints más largos al comienzo, mes y medio o dos meses, ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos, una semana o dos, cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.

Para gestionar el proyecto sólo necesitamos dos listas, el «Product Backlog» y el «Sprint Backlog». Podemos usar Excel para manejarlas.