🔴 Taller de Desintoxicación DOCUMENTAL (en desarrollo software) (Vídeo Agile Fast&Furious)

“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 “.

Mike Cohn y Tom Poppendieck

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…

 

Ver este vídeo en YouTube.

1 comentario en “🔴 Taller de Desintoxicación DOCUMENTAL (en desarrollo software) (Vídeo Agile Fast&Furious)”

  1. 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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba