“Cuando los documentos son en su mayoría para pasarse el testigo de unos a otros, son malos. Cuando capturan una conversación que es mejor no olvidar, son valiosos “.
Estándares, normas, procedimientos, registros, planes de viabilidad, plantillas, guías, manuales, pdfs y pdfs, excels y herramientas que automatizan la creación y expulsión de documentos.
Es difícil dejar de documentar si se tiene costumbre y existe la cultura organizativa de hacerlo. Y hay muchos miedos y razones para hacerlo, uno de ellos, en el área del desarrollo de software es… el miedo a, si no hay documentos, depender del desarrollador.
Antes de ir al vídeo….
El último curso este año es el de Peopleware, Equipos Ágiles y Management 3.0 (formación síncrona, directos en online y talleres prácticos) con Certificación oficial Management 3.0: «Certificate of Attendance del Fundamentals Online Workshop»: 09, 16, 23 y 30 de noviembre. Financiable por FUNDAE
Ah, RECUERDA que, 
si quieres AYUDARME a hacer más vídeos (y ayudar a la comunidad) y a difundir el conocimiento, puedes hacer algo tan fácil, rápido y gratuito como SUSCRIBETE AL CANAL DE YOUTUBE (que con más suscriptores YouTube nos desbloquea opciones que nos ayudan a difundir conocimiento).
Y ahora, vamos al vídeo…
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Es verdad. ay un gap entre lo que ven los desarrolladores y lo que ve el cliente que te pide un desarrollo de una aplicación o una modificación.
Para prescindir de la documentación el product owner tiene que tener las definiciones claras y hasta ahora, en todos los proyectos en los que he trabajad, con gente adulta y con jóvenes de corta edad, nunca sucedió.
Y lo peor de todo es que las reuniones para definir el backlog y el sprint backlog el product owner no es claro y preciso y los desarrolladores no consultan para eliminar sus dudas.
Por todo esto, en mi caso trato de armar una documentación tipo diagrama funcional que da el contexto a los requisitos de los usuarios y un breve diagrama sobre el requisito.
No hay que dejarse tentar por el lado oscuro. Sigo confiando en que los clientes y nuestros equipos madurarán para llevar proyectos agiles.
Saludos Javier.
Te sigo siempre.