El pasado viernes 8 de Julio, tomé el webinar "El enfoque agil para la gestión de proyectos de software", dictado por Thomas Wallet en el marco del "Centro de formación, investigación y desarrollo de soluciones de e-learning" de la UTN FRBA. Si, son muchos formalismos para citar la fuente, pero son absolutamente intencionales, ya que mi primer objetivo en este post, es recomendarles a los interesados en comprender el funcionamiento de las metodologías ágiles, tomar este otro seminario dictado por la misma gente: "Metodologías ágiles para el desarrollo de software".
Pero como en este blog, suelo volcar algo de información, me gustaría compartir con ustedes, las notas que tomé durante el seminario.
El 45% de las funcionalidades brindadas por una aplicación no se utiliza (jamás). Esto ocurre principalmente porque el usuario describe la problemática dándole la misma importancia a todos los ítems, como si fuera la única oportunidad de ser relevado, y como si una aplicación desarrollada no se pudiera modificar. Entonces, "pide más por las dudas". Somos en gran medida responsables de esta problemática, ya que los enfoques tradicionales del desarrollo de software, ven al cambio como un "enemigo", un taboo, o mínimo, la excepción.
El enfoque Agile, en cambio, propone que "el cambio es la norma", y pareciera ser esta, la piedra angular de las metodologías ágiles. De hecho, es esto lo que impulsa la investigación de estas metodologías, la cual de cierta forma encuentra su "baseline" en la escritura del manifiesto.
Sobre sus puntos:
- Individuos e interacciones sobre procesos y herramientas: No descarta los procesos y herramientas. Simplemente, le da mayor valor al equipo y la forma en que este interactúa. Es importante destacar que se tiende a equipos con la posibilidad de autogestión (lo cual amerita un replanteo de los roles tradicionales y sus funciones).
- Software funcionando sobre documentación extensiva: Nuevamente, no se descarta la documentación, pero se hace incapié a la necesidad del software funcionando. Esto parece obvio, pero no refiere solamente al final del proceso de desarrollo, sino en los distintos momentos de generar entregables, y como minimizar los detalles para poder tener una versión "deployable" lo antes posible. Una nota personal, que no fue charlada durante el webinar: La documentación tradicional tiene algunos bemoles importantes. El más obvio y popular: SE DESACTUALIZA casi instantáneamente. Cuando realizamos, por ejemplo, diagramas de clases, o descripciones de arquitectura, estamos tomando la fotografía de algo "vivo", es decir, algo que evoluciona. Teóricamente, esa foto está desactualizada instantáneamente. Prácticamente, está desactualizada en un tiempo tan corto, que el esfuerzo de generar cierta documentación, carece de justificación. Según las buenas prácticas de desarrollo, el mismo código debe ser la mejor documentación, si se escribe como corresponde. Sin irnos a tal extremo, creo que es algo a considerar. Se debe encontrar el balance entre la documentación estática y la requerida por este enfoque.
- Colaboración con el cliente sobre negociación contractual: La cantidad de energía puesta en la negociación del contrato, podría invertirse en el desarrollo en si mismo, dando posibilidad a software con mejores features. Pero esto no es todo. Se supone que estamos apostando al cambio. Un contrato muy estricto, no permitiría al cliente redefinir los requerimientos durante el ciclo de desarrollo. Se debe fomentar un contexto de confianza para lograrlo. Una nota personal: Siempre recomendé a los project managers que hicieran sentir al cliente parte del desarrollo. En primer lugar, porque lo es, pero más estratégicamente: Es más dificil criticar o desestimar algo que uno mismo construye. Debemos despojarnos del enamoramiento de nuestras ideas para poder recibir críticas de buena manera. Pero también podemos intentar que las ideas provengan se construyan de forma conjunta para que la crítica sea siempre constructiva. De todos modos, esto no es algo simple, y me motivó a preguntar acerca de cómo comunicar o "vender" esto a un cliente. La respuesta del instructor fue catedrática: El ejemplo es el de un restaurante. El cliente pide un plato. El mesero toma el pedido, el chef y cocineros lo preparan, y se le lleva el plato al cliente. En ese momento el cliente puede decir: "Esto no es lo que pedí. No está cocido al vapor, tiene demasiada pimienta, y el punto de cocción no es de mi gusto". Como restaurante tenemos dos opciones. Hacer caso omiso y perder al cliente, o, realizar otro plato con las nuevas especificaciones. Si, estas nuevas especificaciones llegaron una vez que el producto estaba finalizado. Demasiado tarde. Mayor costo para el restaurante y una gran pérdida de tiempo para el cliente. Agile en cambio plantea abrir la cocina al cliente. Que este recorra junto al chef el proceso y pueda realizar las sugerencias a tiempo. Finalmente, obtiene su plato, como el lo quería, y realizado por un profesional. Resulta obvio, y me gustaría encontrar un restaurante así (al menos es mi opinión como profesional de IT y como aficionado a la cocina). Mis aplausos por esta respuesta.
- Respuesta ante el cambio sobre seguir un plan: Por último, no habla de que NO HAYA PLANIFICACIÓN. Habla de ponderar más la capacidad de reacción. Con lo expuesto anteriormente, creo que más que un valor, esto es una consecuencia de la buena aplicación de estas metodologías.
Me resultó muy clara la comparación realizada. El enfoque predictivo, como indica su nombre, intenta preveer lo que va a ocurrir. Es el enfoque adoptado por PMP y es análogo a Preparen, Apunten, Fuego
- Preparen: Entender el negocio, manejar los riesgos, formar el equipo, comprender el alcance, etc.
- Apunen: Fijar objetivos.
- Fuego: Ejecutar los planes.
Agile sería más bien un Preparen, Fuego y Apunten. Y si, lo primero que viene a nuestras mentes es "no es peligroso disparar antes de apuntar?" Bueno, si salimos de la analogía es peligroso (no recomiendo disparar incluso teniendo claro el objetivo). Pero manteniéndonos en la anañogía, también es peligroso. Supongamos que realizamos todo el proyecto y luego nos planteamos los objetivos. Las posibilidades de éxito resultan bajísimas. Bien, no se trata de un solo fuego, sino períodos cortos e iterativos en donde, se comienza a ejecutar con una idea, y se corrige la puntería en base a la experiencia. De esta forma (y más apuntado a Scrum), las primeras iteraciones estarían más "equivocadas" que las últimas. Pero siempre es un mejor escenario que realizar todo el proceso sin tener ningún tipo de feedback.
Aquí se realizó un corte, una tanda de preguntas y respuestas, y se continuó con una descripción de una de las metodologías (Agile no es una metodología sino un conjunto de ellas). Fue el turno de SCRUM, y creo que será mejor dejarla para otro POST.
Vuelvo a recomendar que tomen el seminario completo. Se realizó una grabación del webinar, y ni bien tenga la URL para poder verla, estaré actualizando este POST.
Finalmente, agradecer a Thomas Wallet y al "Centro de formación, investigación y desarrollo de soluciones de e-learning" de la UTN FRBA, por haber dado este webinar de forma gratuita y online. De facil acceso, y una calidad que vale la pena.