Ya varias veces, comunicándome con colegas en conferencias y conferencias, recibí esta pregunta:
Parece que es hora de arreglar en alguna parte la respuesta y consultar en ocasiones :)
Entonces, ¿es necesaria la gestión ágil del conocimiento, donde la información se transfiere de persona a persona? De hecho, este es el caso cuando la respuesta está contenida en la pregunta misma. La información se transmite de persona a persona, es decir, hay un intercambio de conocimiento . La tradición oral es una de las herramientas de gestión del conocimiento. Muy poco confiable, pero sin duda el más popular. La tarea de la persona a cargo de la gestión del conocimiento es crear un entorno que sea conveniente para compartir el conocimiento. Por supuesto, en equipos ágiles, el entorno será diferente de las estructuras organizativas clásicas. Pero básicamente la respuesta, por supuesto, es "sí, es necesario". Comprendamos con más detalle.
Comencemos con el manifiesto Ágil mismo. Sus autores dicen directamente que
"Es decir, sin negar la importancia de lo que está a la derecha, todavía valoramos más lo que está a la izquierda"
¡El Manifiesto Ágil no nos dice que "no documentemos nada"! Él dice que el cliente paga dinero por un producto que funciona. Si lo recibió, en ausencia de documentación hermosa puede cerrar los ojos, pero no al revés. El manifiesto ayuda a priorizar, pero no pone prohibiciones. E incluso si no tiene tiempo para grandes muelles, en el proceso de trabajo se crea una gran cantidad de artefactos de gestión del conocimiento, que luego puede operar al tomar nuevas decisiones: tickets, registros de cambios, etc.
"Las personas y la interacción son más importantes que los procesos y las herramientas".
En un estudio realizado entre trabajadores de TI, está claro que las
personas en la industria de TI colocan el intercambio de conocimientos (es decir, la
interacción ) en el segundo lugar entre los desafíos existentes en el desarrollo de software.
En general, los resultados de este estudio confirman la primera tesis del manifiesto. Me parece que las piernas de la pregunta están creciendo por el hecho de que la gestión del conocimiento por parte de muchos en el desarrollo se entiende como documentación, y no la interacción entre las personas en la transferencia de experiencia.
Sí, por cierto, en una de las publicaciones anteriores ya dije que el conocimiento no es documentación, sino la experiencia adquirida en la implementación de un proyecto específico por parte de un empleado específico . Incluso si no ha creado la documentación del producto, definitivamente adquirió algo de experiencia durante el proyecto. Además, las herramientas ágiles contribuyen indirectamente al hecho de que esta experiencia se revuelve constantemente.
Por ejemplo, retrospectivas . ¿Qué es esto si no es un proceso de intercambio de conocimientos? El equipo se reúne, comparte los problemas existentes (en el campo de KM, esto se llama "lecciones aprendidas" ) y desarrolla un plan de cambio para resolver estos problemas. Es decir, las personas rebuscaron en su experiencia mutua, lo discutieron, desarrollaron una estrategia para superar los inconvenientes en el futuro cercano y registraron en algún lugar este mismo plan de cambios (artefacto de gestión del conocimiento). Por lo general, los resultados de tales reuniones se almacenan en algún lugar. No estoy seguro de que haya comandos efectivos que, después de completar la iteración, eliminen datos sobre todos los retro anteriores.
O emparejar la programación . Incluso Wikipedia nos cuenta sobre esta herramienta lo siguiente:
Ventajas:
***
Mentoring
Todos, incluso un programador novato, saben algo que otros no saben. La programación en pareja es una forma indolora de difundir este conocimiento.
***
Entrenamiento
Los programadores intercambian constantemente conocimientos.
Dos programadores experimentados se inflan mutuamente, utilizando su propia experiencia. El señor bombea el juna, actuando como mentor. La tutoría en equipo es generalmente una de las encarnaciones más populares de la gestión del conocimiento en el desarrollo de software. El mismo Yandex incluso comenzó a enseñar este arte exteriormente.
O tome la situación cuando use kanban. Suponga que los probadores prueban 10 funciones por mes y los desarrolladores logran implementar 20. Esto lleva a la acumulación de trabajo en QA y, por lo tanto, pone en riesgo la calidad de su trabajo. En este caso, puede, por ejemplo, redistribuir recursos y conectar a los desarrolladores para la creación de pruebas automáticas. Como resultado de la iteración, el equipo recibió una experiencia de planificación negativa y, en base a ello, puede elaborar un nuevo plan de tal manera que se garantice el máximo rendimiento de la tubería con los mismos recursos. Es decir, en el proceso de desarrollo, se obtuvo conocimiento (= experiencia), después de analizar qué, el equipo llegó a la optimización del proceso.
Bueno, hay una pregunta muy superficial: ¿no utilizará el equipo la experiencia adquirida mientras trabaja en el proyecto cuando trabaje en otros proyectos? Es decir, experimentalmente para el proyecto actual, descubrieron que pueden implementar con pruebas un promedio de 15 funciones por mes. ¿No volverán a estar en el nuevo proyecto inicialmente establecido en 20?
El conocimiento es todo lo que sucedió alrededor del proyecto. El proceso de desarrollo no tiene lugar en el vacío. Coordinación, enlaces útiles, interacción con otros equipos, incorporación de principiantes, etc. Cualquier equipo pasa por esto. Con un conjunto de experiencia, aparecen varios artefactos, como listas de verificación de adaptación para principiantes o una base de datos de enlaces útiles. Esto es conocimiento fijo o el resultado de comprender la experiencia adquirida.
Todos participamos en procesos de intercambio de conocimientos todos los días (bueno, realmente, ¡nos comunicamos constantemente entre nosotros!), Y trabajar en la metodología Agile no nos excluye de este proceso. Además, ya incluye herramientas de gestión del conocimiento muy eficaces. Solo queda organizar el trabajo del equipo para que estas herramientas den el máximo escape.
En una publicación di solo algunos ejemplos. Analicemos en los comentarios qué otras herramientas ágiles también son herramientas de gestión del conocimiento. Bueno, o discuta por qué estoy equivocado :)