Pensar en las metodologías de desarrollo suele hacerme pensar en la biología, los ecosistemas y la evolución. Cada metodología tiene un nicho en el cual domina por características particulares, siendo estos nichos de extensión variable en el tiempo, al igual que ocurre con los nichos ecológicos, los cuales pueden variar por eventos tales como la aparición de nuevas especies o cambios en el clima.
Centrándonos en el mundo del desarrollo del software pero sin abandonar la metáfora, se han producido recientemente dos eventos, más o menos coincidentes en el tiempo, los cuales han contribuido a cambiar por completo el ecosistema de las metodologías de desarrollo:
1. Internet.
Hablamos de un entorno en el cual miles de millones de usuarios consumen software diariamente, con cada vez mayores expectativas de calidad y con menos paciencia para esperar a consumir dicho software. El crecimiento y penetración de Internet puede considerarse un evento de extinción masiva -semejante a la caída de un meteorito- en muchos ámbitos: extinción de costumbres, puestos de trabajo, tecnologías y, entre otros muchos, metodologías de desarrollo.
No creo que la extinción sea un proceso instantáneo, supongo que el meteorito que -popularmente al menos- acabó con los dinosaurios no fue sino un desencadenante de procesos los cuales, sumados entre sí, causaron la extinción de dichos animales.
Con ‘el meteorito Internet’ ocurrirá igual. Por ejemplo: la tecnología en la que están basadas los libros convencionales sigue adelante, pero indudablemente ha acusado el golpe de los libros digitales y dicho impacto será mayor a medida que pase el tiempo. Ahorrar espacio en casa -adiós a las grandes estanterías-, comprar libros con un clic leyéndolos al instante siguiente y tener acceso a toda tu biblioteca allá donde te encuentres son mejoras evolutivas demasiado significativas como para que el libro de papel pueda confiar en un amplio nicho en el futuro.
2. Aparición de las metodologías ágiles.
Pensemos en las metodologías ágiles como una mutación (aunque no fortuita) que permite a las empresas de software que la incorporan a su ‘ADN’, entregar productos rápidamente pero de forma incremental, adaptándose a cambios en los requerimientos de dichos productos. ¿Existe algún ecosistema en el que las características de la ‘mutación ágil’ puedan ser vistas como un factor que contribuya al éxito? ¿Qué tal un mercado en el que millones de usuario consuman software diariamente, con grandes expectativas de calidad y escasa paciencia para consumir dicho software? Este escenario no debería ser nuevo para nosotros.
No creo en las generalizaciones y por mi parte pienso que siguen existiendo nichos ‘ecológicos’ en los cuales las ‘especies’ de desarrollo waterfall proliferen. No veo el scrum como metodología muy apta para el desarrollo de software embarcado en un drone militar, por ejemplo, aunque también estoy seguro de que mientras escribo estas líneas habrá cientos de equipos de desarrollo en todo el mundo trabajando duro para hacer que sus metodologías no ágiles incorporen todos los ‘genes ágiles’ que sean capaces de adaptar.
Fractalia, como empresa -entre otras actividades- constructora de software, ha adquirido y sigue adquiriendo ‘genes ágiles’ que le permitan luchar por el liderazgo en sus campos de actividad.
Incorporar la agilidad de la metodología scrum a nuestro ‘ADN’ no ha resultado ser un proceso inmediato. Por el contrario se trata de un camino duro e iterativo que implica cambiar aspectos de fácil modificación -como por ejemplo herramientas de desarrollo- y aspectos cuya alteración supone un trabajo muy arduo, como por ejemplo la mentalidad de las personas que forman parte de la organización.
Cuando empiezas a formarte en el scrum al principio puede ser difícil el paso de la teoría a la práctica pues cualquier metodología de trabajo se debe particularizar para adaptarse la compañía que la aplica. Desde Fractalia tenemos la necesidad de entregar valor muy rápido y podemos hacerlo de forma incremental, cuadra con el scrum. Nuestros requisitos son cambiantes, perfecto. Pero si seguimos enumerando nos encontramos con una importante características: no tenemos un equipo de desarrollo completo para cada producto, tenemos un equipo de desarrollo para ‘n’ diversos proyectos/productos. Los ingenieros que escriben el código no se centran en un producto -o en un subconjunto de ellos- sino que por el contrario saben que en la siguiente release tendrán, muy posiblemente, que trabajar en un software totalmente diferente, tal vez desconocido para ellos pero que a la vez les brinda la oportunidad de aprender, estar al día de diversas tecnologías aunque este hecho conlleve a la par de una mayor complicación para gestionarlo adecuadamente.
¿Hacemos sprints paralelos por producto? Inviable. ¿Se imaginan un daily scrum en el que participa el 20% de una persona y el 80% de otra? Más absurdo todavía, ¿se imaginan que tras ese daily scrum hay otro en el que participan las mismas personas pero con proporciones invertidas. En mi caso particular, no puedo jurar por mi ética de Product Owner que cuando el 20% de una persona me diga que no tiene tiempo para completar una historia de usuario, seré capaz de resistirme a la tentación de pedirle ayuda al 80% restante perjudicando así el sprint paralelo.
¿Cómo asignamos los recursos a los sprints? ¿Dónde tenemos una visión unificada de las prioridades de la compañía? Son preguntas a las cuales el scrum puro no responde de forma satisfactoria en nuestro caso.
¿Cómo hemos implantado el scrum en Fractalia? Si es un equipo el que toca todos los productos, hagamos un único backlog. Ordenemos todas las prioridades en una única pila sabiendo así si, para los clientes y para la compañía, es más importante mejorar la gestión de televisores Smart TV a nuestra plataforma de Digital Signage, incorporar algún nuevo tipo de player a la plataforma o bien añadir un nuevo tipo de tickets de navegación en nuestro producto de control de acceso a Internet.
Somos un equipo ajustado, con un Product Owner para todos los productos, y Desarrollo ya tiene la costumbre y la habilidad de cambiar de contexto rápidamente, por lo que el enfoque termina de encajar. No habrá conflictos por la cantidad de recursos asignados a cada producto dado que en cada momento habrá una visión unificada respecto a qué es lo más importante de entre las tareas pendientes.
El enfoque, examinado y reevaluado severamente sprint a sprint, nos ha permitido incorporar al backlog incluso tareas de innovación, de forma que éstas cuenten con un acceso controlado y priorizado al presupuesto de Desarrollo, sistematizando así este tipo de esfuerzo innovador.
Este es el sabor particular que Fractalia le da a su scrum, la mutación concreta que hemos incorporado. Desde luego no la más académica, pero sí la más adaptada -por ahora- a nuestras necesidades.
Leave a Comment