El dificil trabajo de llevar un mundo estocástico a uno binario

Como sabrán vivimos en un mundo imperfecto, donde el cambio es el rey  y señor. En ese mundo el profesional informático debe especificar requerimientos, hacer estimaciones y vivir.

Esto provoca muchos problemas, los cuales son los más caros sino se los detecta a tiempo. Como sabrán un defecto en los requerimientos provoca el mayor coste de retrabajo, no solo porque desarrollamos algo que no se usa sino porque tenemos que removerlo y luego volverlo a desarrollar. O podemos modificarlo, lo que conlleva que insertemos muchísimos bugs y la funcionalidad quede con vicios.

Por lo tanto lo que se hace normalmente es hacerle muestras a el usuario de lo que estamos trabajando, lo importante de esto es que el usuario debe tener el conocimiento y estar preparado para entender que es solo una carcasa que falta terminar.

Utilizando scrum por ejemplo deberíamos tener un compromiso mayor de los usuarios, es más un usuario debe ser parte del equipo pero esto no sucede con normalidad, el problema es que un proyecto que utiliza scrum pocas veces es vendido como un proyecto scrum, por lo tanto se trata de adaptar scrum a una fecha de entrega y a no tener un usuario como parte del equipo lo que conlleva a un desastre.

Scrum pide muy pocas cosas y deberíamos respetarlas o no hacer scrum. Y si no tenemos la suerte de trabajar con scrum, debemos tratar de lograr un compromiso con el usuario, hacer entregas tempranas, validar los requerimientos, revisión por pares etc.

Kanban vs Scrum

• Jim: “¡Por fin hemos conseguido implantar Scrum del todo!”
• Fred:“ ¿Y qué tal os va?”
• Jim: “Bueno, mucho mejor que lo que teníamos antes...”
• Fred:“...¿pero?”
• Jim: “... pero claro, está el equipo de operación y mantenimiento.”
• Fred:“sí, ¿Y?”
• Jim: “Bueno, nos encanta todo lo de organizar por prioridades en una Pila de Producto, los equipos auto-organizados, el Scrum diario, las retrospectivas, etc....”
• Fred: “¿Y cuál es el problema?”
• Jim: “Seguimos fracasando en nuestros Sprints”
• Fred: “¿Por qué?”
• Jim: “Porque nos resulta muy difícil comprometernos a una planificación de 2 semanas. Las iteraciones no tienen mucho sentido para nosotros, simplemente nos ponemos con lo más urgente que tenemos cada día.¿Quizás deberíamos hacer iteraciones de una semana?
• Fred: “¿Os podríais comprometer al trabajo de una semana? ¿Se os permitiría concentraros en eso y trabajar en paz durante una semana?”
• Jim: “En realidad no, tenemos asuntos que van surgiendo en el día a día. Quizás si hiciéramos sprints de un día...”
• Fred: “¿Vuestras tareas tardan menos de un día en solucionarse?”
• Jim: “No, a veces tardan varios días”
• Fred: “Así que los sprints de 1 día tampoco funcionarían. ¿Habéis considerado eliminar por completo los sprints?”
• Jim: “Bueno, la verdad es que eso nos gustaría. Pero ¿no va eso en contra de Scrum?”
• Fred: “Scrum es solo una herramienta. Tú eliges cuándo y cómo usarla. ¡No seas su esclavo!”
• Jim:“¿Qué deberíamos hacer entonces?”
• Fred:“¿Has oído hablar de Kanban?”
• Jim:“¿Qué es eso? ¿En qué se diferencia de Scrum?”
• Fred:“¡Toma, lee este libro!”
• Jim: “Pero a mi me gusta el resto de Scrum, ¿tengo que cambiar ahora?”
• Fred:“¡No! Puedes combinar ambas técnicas”
• Jim:“¿Qué? ¿Cómo?”
• Fred:“Sólo sigue leyendo..”

Así comienza el libro quiero recomendarles, muy bueno explica Kanban confrontándolo con Scrum de forma totalmente didáctica. Y al final una aplicación practica.

Dejo el link:

http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf