Las tecnicas de manufactura que dieron paso a LSD y XP en la industria del software son aplicables en muchos ámbitos del diario proceder de las personas. Sobre todo como auxiliar en la generacion o mejoramiento de la calidad en los procesos de producción de servicios por su propia naturaleza intangible en el momento que se va construyendo.
Cuando las personas se acercan a uno para platicar al respecto de la aplicacion de estas técnicas a diferente campos de conocimiento nace la duda al respecto de si tambien seran aplicables para el mismo proceso de adquirir conocimientos dentro de los procesos productivos.
Ya que si queremos generar procesos con calidad para la asimilación de conocimientos algunas técnicas basadas en aprendizaje por experiencia, compartición, trabajo colaborativo, tecnicas visuales, etc serian efectivas. Pero como mezclamos todo eso con el proceso productivo que hemos hablado.
Lo que creo que se requiere es que podamos empatar los procesos ya conocidos en los que participa
XP y LSD (como el Scrum) con algunos mecanismos de aprendizaje, porque incluso cuando hablamos de ellos siempre remarcamos que esta basado su éxito en el aprendizaje y la experiencia que genera el saber más y hacer las cosas con los errores y éxitos que implica.
Pero el reclamo generalizado es que el aprendizaje no es formalizado dentro de un Scrum, y a veces este tipo de cosas genera incertidumbre en el equipo de trabajo o no facilmente visible al Produc Owner.
Si pensamos en un proceso típico de Scrum en donde dentro de las iteraciones, cuando hacemos la planeación y damos valores a nuestras historias de usuario, con su consecuente generación y cuantificación de las tareas que la llevarán a cabo de forma correcta de acuerdo con los criterios de aceptación que han sido escritos por el Product Owner.
Que les parece que dentro de la definición del Product Owner, el Scrum Master y el mismo equipo determine las necesidades de aprendizaje dentro del proceso, incluso como parte de las iteraciones -1 o 0 para contar con la infrestructura necesaria que incluye los conocimientos necesarios en el equipo.
Entonces la historia de usuario deberá tener la connotación de que "Que el equipo aprenda X o Y ".
Y dentro de los criterios de aceptacion el PO debera indicar como Él estara satisfecho al respecto que el equipo utilizó parte de los puntos disponibles para aprender ese X o Y de forma tan explicita. Se sugiere que sean en dos sentidos:
1.- Examen de evaluacion, si el conocimiento es de un sentido ampliamente teorico o introductorio. El reto es quién o como se genera dicho exámen.
2.- Un ejercicio/taller/prototipo si el conocimiento es de aplicacion inmediata o bien final de una cadena de conocimientos. Y que se vea su aplicación directa en los objetivos del proyecto que se está trabajando.
Obviamente estos criterios de aceptacion deberan estar definidos como si se tratase del cumplimiento de unos objetivos de un curso que los miembros del equipo tuviesen que tomar.
Durante el proceso de asignación de valor a la historia de usuario de aprendizaje, se deben utilizar solamente algunas cartas de valor en el pokar ya que su valoración es diferente a algo que se realizará con cierto grado de conocimiento. Las tareas que refieran a un concepto totalmente ignorado debería asignarse el valor superior (21); si se ha escuchado y no parece demasiado complejo el valor medio (13) y algo que se asemeja o se tiene referencia de su estructura para poder asimilarse el mínimo valor(5).
En el momento de generar las tareas, los miembros del equipo deberan definir como se llevará a cabo dicha asimilación de conocimientos, sobre todo si sera individual o grupal y sobre una secuencia de terminos para cada miembro o bien de forma colectiva. Y la última tarea, la aplicación del exámen o la preparación del ejercicio/taller/prototipo correspondiente.
La penúltima tarea debe ser necesariamente la que ayude a preparar las condiciones para que se cumpla lo anterior, considerando que podrá incluir desde generar o buscar el examen correcto, como verificar los términos o requisitos que se necesitara para preparar el ejercicio/taller/prototipo.
Cuando el conocimiento a adquirir lo permite, cada tarea debería cubrir un punto de un temario que ya haya sido probado que tenga la secuencia y contenido necesario para cada caso.
Al igual que otras Historias de Usuario ninguna debe sobrepasar una valoración en tiempo superior a la iteración, y sus tareas a un dia promedio efectivo, por lo que en caso necesario se divide de forma lo mas proporcinal posible por temas que se tengan contemplados.
Durante los Scrum diarios, lso miembros deberian proporcionar un pequeño resumen de avance de los temas, para poder evaluar su avance y solidificación de conocimientos. Aqui podriamos observar que lo mismo que sucede con las tareas o historias normales, pero la diferencia radica en que en este caso es necesario comentar del avance y su desarrollo, es decir, un mayor nivel de detalle del desarrollo de las tareas concluidas. En las historias "normales" solamente se declaran que se termino y se comenta en caso de alguna peculiaridad o problema que se haya presentado durante su desarrollo.
Y bueno, creo que con estas consideraciones estamos listos para formalizar e identificar de forma mas detallada los procesos de aprendizaje que requiera un proyecto de desarollo.
Espero comentarles que ajustes salieron en base a nuestras juntas de retrospectiva.
Hasta la próxima.
