on Wed May 06 2020
Este serie de publicaciones describe paso por paso los conceptos más importantes de Scrum, así como la forma en que pueden ser aplicados en una organización real.
Puedes acceder a toda la serie a través de estos enlaces:
Primera parte – El agilismo y el manifiesto ágil.
Segunda parte – Conceptos básicos: La guía de Scrum, Product Backlog, Items y User Stories
Cuarta parte – Cómo medir el progreso de desarrollo
Quinta parte – Conceptos básicos: El Scrum Master, el equipo de desarrollo, y Scaled Scrum
Sobre la guía de Scrum 2020: Esta serie de publicaciones se encuentra en construcción, y su contenido se basa íntegramente en la guía de Scrum de 2017. Finalizada la publicación de la serie, se trabajará en actualizar el contenido a la última versión de la guía de Scrum.
Antes de empezar a hablar sobre desarrollo ágil y sus fundamentos, permíteme aconsejarte: Si estás pensando en empezar a buscar información por primera vez sobre Scrum, mi recomendación es que te abstengas de ello. En el caso que quieras llegar a obtener una certificación, también es recomendable que de momento te abstengas en la realización de cualquier tipo de examen abierto de prueba, al menos hasta que:
El motivo principal es que, pese a que podemos leer sobre Scrum, y entender sus eventos, artefactos, y roles, no es nuestro objetivo simplemente implantar una serie de procesos e ir repitiéndolos hasta el infinito sin más, o cambiarle el título a una persona del equipo para seguir la nomenclatura de Scrum.
Nuestro objetivo va mucho más allá: Scrum es una forma de lograr unos objetivos, de seguir una filosofía que en la práctica optimizará la planificación, el desarrollo, y la entrega de nuestro producto, y mejorará enormemente la forma con la que nos relacionamos con nuestro cliente final.
De forma muy abreviada, podemos decir que Scrum es un medio para llegar a un fin, y este fin son los conceptos clave que podemos encontrar en el manifiesto ágil. Si no conocemos lo que queremos lograr a través de Scrum, tan sólo lograremos implementar cambios procedimentales o de nomenclaturas, que difícilmente darán su fruto, y harán plantearse a la dirección de nuestra organización si el cambio merece realmente la pena. No sólo hemos de «implementar» Scrum. Hemos de ser conscientes de que desarrollar de forma ágil implica un posible cambio de mentalidad, que nosotros y el resto de la organización hemos de estar dispuestos a asumir.
¿Y por qué no realizar exámenes abiertos de inmediato? Existen dos motivos principales:
En cualquier caso, y para dejar constancia de ello: Estas publicaciones se realizan conforme a mi experiencia reciente, y conforme al curso de PSM1 y PSPO1 de Management Plaza, que se imparte según la interpretación de Scrum.org.
Bien, hemos decidido que queremos ser ágiles. Tal vez llevamos trabajando un tiempo siguiendo metodologías ágiles, y por fin tenemos la oportunidad de organizar un equipo from scratch.
O simplemente queremos aprender y profundizar más en los conocimientos que ya tenemos, asegurarnos que realmente exprimimos al máximo los beneficios del desarrollo ágil.
En ambos supuestos existe un objetivo, una premisa, sin la que nuestra tarea va a resultar mucho más difícil, sino casi inalcanzable: Debemos asegurarnos que cada persona implicada directa o indirectamente en nuestro proyecto conoce los objetivos y beneficios del agilismo. No sólo al equipo de desarrollo hace referencia esta premisa, todos aquellos con quienes vamos a interactuar: Dirección, Marketing, Operaciones, Ventas, etcétera. Todos han de comprender el porqué del agilismo, entenderlo y apreciarlo.
No hace falta siquiera que empecemos a hablar aún de Scrum. Por supuesto que también es conveniente que sepan cómo funciona Scrum llegado el momento, y por ende cómo trabajamos. Pero la clave reside en que ellos, al igual que nosotros, conozcan qué queremos lograr y mejorar gracias a un desarrollo ágil, para que así entiendan y respeten los procesos que vamos a implementar a posteriori.
En caso contrario, fácilmente más pronto o más tarde se adoptarán decisiones que quedarán fuera del ámbito de decisión del Scrum Team (o incluso se producirán desde el propio Scrum Team, si no hemos sabido transmitir bien este conocimiento al resto de compañeros), que perjudicarán a la esencia del desarrollo ágil, e irán en detrimento de los beneficios que éste nos aporta.
Si algo queremos asegurar mediante este punto, es que Scrum genere el impacto positivo, y el retorno que se espera de él. No queremos que el resto de la organización perciba Scrum cómo «la forma en que se ha organizado el equipo de desarrollo», como algo ajeno a ellos de forma aislada.
Muchas organizaciones presumen en ser ágiles, pero en la práctica posteriormente todo se reduce a la forma en que trabajan los equipos de desarrollo de software, que son quienes en un momento dado pueden haber impulsado este tipo de cambios, mientras que el resto de la organización ignora o menosprecia (de forma inconsciente) los beneficios que nos aporta ser ágiles.
Dicho esto, la capacidad para que el resto de la organización aprecie y adopte algunos cambios, variará según la mentalidad de la propia empresa. No obstante, existe un trabajo previo de coaching a realizar muy importante, tanto con el propio equipo más cercano, como con todas las partes implicadas de la organización. Y es importante reiterar: Es bueno y necesario conocer y que el resto de personas conozcan como funciona Scrum (al fin y al cabo es lo que queremos implementar), pero carece de sentido si no explicamos con concisión qué queremos lograr, qué va aportarnos ser ágiles, y qué cambios hemos de estar dispuestos a realizar si queremos recibir en contraprestación esos beneficios.
En febrero de 2001, un grupo de personas redactó, subscribió y publicó el manifiesto ágil. Se trata de un documento que plantea que el Software debe desarrollarse siguiendo unas premisas generales. Veámoslas:
Lo anterior es el manifiesto ágil. Tiene un apartado de «doce principios del Software ágil» que también es recomendable leerlo en detalle, y viene a describir las conclusiones que podemos extraer del propio manifiesto.
¿Y qué significa cada uno de los puntos del manifiesto? Tal y cómo reza el texto:
1 – Individuos e interacciones sobre procesos y herramientas: No viene a decirnos que no necesitemos procesos, o no necesitemos herramientas (¡Es obvio que los necesitamos!). Sino que ante estos dos aspectos, las personas, su trabajo e interacciones deben ser más valoradas, y deben tener cierta capacidad de influencia sobre esos procesos y herramientas.
2 – Software funcionando sobre documentación extensiva: De nuevo: ¿Significa esto que no debamos realizar documentación? Ni de lejos, pero nuestro éxito se basa en desarrollar software. Software de calidad y que cumpla las necesidades del cliente. Implícitamente, al producir software de calidad implementaremos buenas prácticas; código cuyo flujo sea auto-descriptivo, que disponga de tests, comentado según necesidad, y cómo es obvio, con la documentación que sea necesaria. Pero al no haber documentado de forma excesiva, cuando estos requerimientos provenientes del cliente cambien, la documentación no actuará como un impedimento para seguir avanzando.
3- Colaboración con el cliente sobre negociación contractual: En este punto aplica un acercamiento similar: Las negociaciones contractuales van a existir, y van a ser una parte importante del proceso. Pero el desarrollo ágil pretende evitar que toda comunicación con el cliente se limite a lo especificado estrictamente en éstas. Debemos comunicarnos con el cliente, conocer sus cambiantes necesidades, adaptarnos a este cambio, y enseñarle nuestros progresos frecuentemente y obtener feedback de éste. En resumen: Nuestra relación con el cliente no debe limitarse a la entrega del producto según se especifique en el contrato, sino que el cliente debe formar parte en mayor o menor medida de nuestro flujo de desarrollo y entrega de producto.
4 – Respuesta ante el cambio sobre seguir un plan: Al hilo de lo comentado con anterioridad: Cuando desarrollamos de forma ágil, hemos de ser conscientes, y tener la mentalidad, y en definitiva asumir, que las necesidades que motivan nuestro desarrollo son cambiantes, o pueden ser más concisas conforme avanzamos. Debemos tener cierta valentía para asumir que van a producirse cambios de requisitos, y aceptarlos de buen grado. El manifiesto ágil da por hecho que durante el desarrollo de software no es válido idear un plan que pretenda preveer todas las casuísticas y requisitos de principio a fin de proyecto. Más bien, el approach que sugiere es el de realizar un plan menos extenso, que será desarrollado durante las semanas subsiguientes, para después poner el resultado en común con las partes implicadas (inclusive el cliente), y elaborar otro pequeño plan para las siguientes semanas. De esta forma, nos adaptaremos constantemente a los cambios, y nuestro producto responderá realmente a las necesidades finales del cliente.
Es muy recomendable leer los doce principios del manifiesto ágil. Este punto ofrece a modo de pequeños comentarios, determinadas formas de interpretar lo que puede extraerse de estos principios (interpretaciones de cosecha propia, ergo pueden ser cuestionables). Pero por supuesto no sustituye su lectura, que es necesaria y enriquecedora.
Aunque existe cierta tendencia a aplicar el desarrollo ágil a otros aspectos ajenos al desarrollo de Software, lo cierto es que el agilismo no sirve para todo.
Quizás la clave se encuentra en el constante cambio: Cuando desarrollamos un producto de software, las necesidades del cliente pueden cambiar constantemente. ¡E incluso el propio cliente puede cambiar de idea conforme le vayamos enseñando los resultados!
Con lo cual, lo ideal en estas situaciones es utilizar una metodología o framework ágil para el desarrollo: Realizaremos pequeños planes (a los que denominaremos iteraciones o Sprint, aunque este tipo de términos lo empezaremos a emplear en las sucesivas publicaciones) que consistirán en el desarrollo de una pieza de software terminada, una pequeña parte, una funcionalidad delimitada del proyecto que nos comprometeremos a diseñar, desarrollar, y testear en ese pequeño periodo de tiempo, para después mostrársela a personas implicadas y al cliente.
No obstante, y utilizando una analogía muy popular: ¿Qué pasa si queremos construir un cohete? Existen las mismas fases de desarrollo: Diseño, desarrollo, pruebas, etcétera. (Okey, lo he simplificado quizás demasiado, pero nos sirve para el ejemplo)
En este caso, sabemos que queremos construir un cohete, realizaremos un diseño que será aprobado, realizaremos la construcción y pruebas sobre este cohete, y al finalizar, éste será completamente operativo. Es un cohete al fin y al cabo, sabemos que debe ser capaz de realizar ciertas operaciones que no cambian constantemente, y podemos idear un «plan más extenso» en lugar de realizar pequeños plantes reiterados en el tiempo. Ergo no es necesario ni beneficioso aplicar desarrollo ágil para un proyecto en el que las necesidades no sean cambiantes.
Disclaimer: Disculpad por la enorme simplificación de este punto. Especialmente a las personas de aeronáutica que hipotétiamente puedan acabar leyendo esto.
Esta publicación ha pretendido analizar el manifiesto ágil: Los pilares del desarrollo ágil. Aprovecho para disculparme por adelantado por aquellos puntos que haya podido interpretar erróneamente, e insisto en que estoy abierto a comentarios, críticas y sugerencias.
Sobre este manifiesto se constituyen diversas metodologías y frameworks que amplían cada uno de estos puntos, y definen los procesos y formas de actuar para poder lograr estos objetivos.
En las próximas publicaciones empezaremos a tratar Scrum, no obstante, existen numerosas metodologías, a las que tal vez te interese echar un vistazo. Incluso algunas organizaciones implementan distintas formas de ser ágiles, y no por ello son menos ágiles que otras organizaciones que siguen Scrum con máxima fidelidad.