En enero de 2018, el
mundo vio la luz del marco Nexus actualizado, una herramienta basada en Scrum diseñada para el trabajo en equipo en grandes proyectos. Los autores de la metodología corrigieron varias definiciones de términos y
cambiaron el procedimiento de licencia. Desde principios de año, la Guía Nexus está licenciada bajo una licencia Creative Commons. Y esto significa que cualquier empresa es libre de usar Nexus (como Scrum).
Hablemos de las características de la metodología y sus componentes principales.
/ foto de Sebastian Sikora CCQuién y por qué creó Nexus
En 1996, los desarrolladores Ken Schwaber y Jeffrey Sutherland presentaron la comunidad de desarrollo de software ágil
Scrum . Es un conjunto de iteraciones estrictamente limitadas en el tiempo (sprints), para las cuales los desarrolladores deben implementar nuevas funciones para el programa.
Como señala Jeff Sutherland, en su libro
Scrum. Un método revolucionario de gestión de proyectos "
, Scrum permite a los equipos de desarrollo lograr una" súper eficiencia "y aumentar la productividad laboral en un 300%.
Sin embargo, Scrum tiene un inconveniente: es muy adecuado para trabajar dentro de un equipo (y el número recomendado de sus miembros es de solo siete personas), pero no escala mucho más allá de sus fronteras, cuando es necesario coordinar el trabajo de un gran número de personas.
Para rectificar la situación y ayudar a ampliar la metodología, Ken Schwaber
presentó el marco Nexus en 2015. Nexus
ayuda a evitar los problemas frecuentes del desarrollo conjunto: dificultades al usar la misma base de código e inconsistencias al integrar los logros de los diferentes equipos.
Nexus utiliza enfoques iterativos e incrementales para escalar procesos de desarrollo de software. Cada equipo trabaja como parte de su sprint, y luego se combinan sus resultados. Esto hace que el desarrollo de productos sea más fácil de coordinar.
Componentes Nexus
El marco consiste en roles, eventos, artefactos, así como reglas, que son familiares para cualquier adherente de Scrum, que lo unen todo. En Nexus, estos componentes han cambiado ligeramente para que la metodología se pueda aplicar en proyectos a gran escala.
Roles Según la metodología Scrum, a todos los participantes en el proceso de desarrollo se les asignan roles específicos. Se pueden dividir en dos grandes grupos: "cerdos" y "pollos". El primero incluye a todos aquellos que están directamente involucrados en la creación de la aplicación: el Scrum Master, que lleva a cabo reuniones y supervisa el cumplimiento de los principios de scrum, el propietario del producto (Product Owner), que representa los intereses de los usuarios finales y, de hecho, el equipo de desarrollo (Equipo de desarrollo).
El segundo grupo, "pollos", incluye usuarios finales, vendedores, consultores, etc.
Nexus introdujo el papel del equipo de integración de Nexus (NIT) para ayudar a ampliar la metodología. Este es un equipo completo, que incluye al propietario del producto, Scrum Master y representantes de los equipos scrum. Su tarea es evaluar y prevenir posibles problemas de desarrollo del equipo. Es importante
tener en
cuenta que los miembros de NIT no están directamente involucrados en la programación, pero dan recomendaciones sobre la aplicación de los principios Scrum y Nexus a todos los demás participantes.
En general, la introducción de NIT ayudó a mejorar la coordinación entre los equipos debido a la distribución competente de las tareas. Sin embargo, los miembros de la comunidad de TI
dicen que el nuevo rol también contribuyó a la creación de una especie de "cuello de botella": cuando los miembros de NIT resuelven problemas organizativos, el equipo de desarrollo permanece inactivo esperando instrucciones.
Artefactos. En Scrum, los artefactos se entienden como un conjunto de requisitos para la funcionalidad del producto que ayudan a organizar las actividades de los desarrolladores. Estos requisitos se describen en dos revistas: la cartera de proyectos y la cartera de sprint.
El libro de deseos del proyecto enumera los requisitos generales de funcionalidad: las llamadas
historias de usuario , ordenadas en orden descendente de importancia. Ayudan a tener una idea de cómo debe verse el producto final.
Sprint Wish Journal: una lista de características de implementación seleccionadas por el propietario del producto. Según esta lista, los desarrolladores realizan un seguimiento de las tareas que deben completarse antes del final de un sprint.
En Nexus, los equipos usan el Backlog del producto en lugar del libro de deseos del proyecto. Para simplificar la interacción de un gran número de desarrolladores, esta revista se divide en partes. Cada parte está "asignada" a uno de los equipos. Por lo tanto, todos los desarrolladores entienden en qué tareas de todo el proyecto están involucrados. Al mismo tiempo, cada equipo aún mantiene su registro de deseos de sprint.
Eventos Todos los miembros del equipo asisten a reuniones, a veces denominadas el término general "eventos". Los "cerdos" los gastan a diario y los "pollos", al principio y al final del proyecto o sprint. Se necesitan reuniones para discutir el proceso de desarrollo, estimar planes, identificar cuellos de botella.
Para mejorar la comunicación entre diferentes equipos, los desarrolladores de Nexus han agregado cuatro nuevos tipos de eventos:
- Planificación de Sprint Nexus: en este momento, los equipos deciden quién es mejor para manejar un Sprint particular de la Lista de Producto. Después de eso, cada equipo planifica su propio sprint, comunicándose con otros equipos scrum para que sus tareas no se superpongan.
- Nexus Daily Scrum: se usa para discutir el estado actual de las cosas. Le permite planificar el día o resolver problemas de integración.
- Nexus Sprint Review: aquí los equipos comparten sus éxitos al final de cada sprint.
- Retrospectiva de Nexus: este tiempo se pasa evaluando experiencias pasadas y haciendo un plan para mejorar el proceso de desarrollo en el futuro.
En
la página oficial de la guía Nexus, puede encontrar un diagrama de la interacción y la secuencia de todos estos eventos.
Cuando usar Nexus
En proyectos a gran escala. El marco ayuda a organizar sin problemas el trabajo de varios equipos scrum en grandes proyectos. Por ejemplo, una empresa india que creó software de seguridad (los autores de Scrum no revelaron su nombre) usó Scrum durante un año para desarrollar sus productos. Al principio, la compañía tenía un equipo scrum, pero pronto su número aumentó a tres, y comenzaron los problemas con la
integración de soluciones individuales.
Luego, la compañía invitó a un experto de Scrum, y él propuso mover el flujo de trabajo de Scrum a un nivel de varios equipos, implementando Nexus. Ahora, según la metodología Nexus, seis equipos ya están trabajando, que lanzan constantemente nuevas versiones de software cada dos semanas.
En grandes empresas. Por ejemplo, el departamento de TI de Terminales Portuarios Peruanos (TPP), una empresa dedicada al envío en uno de los puertos de la capital del Perú, tardó nueve meses en lanzar una nueva versión de software especializado. Para remediar la situación, la compañía probó la metodología
Waterfall ,
RUP y los principios de
la gestión tradicional de proyectos . Sin embargo, todos ellos no dieron mejoras significativas, y en algunos casos incluso empeoraron.
Entonces la compañía decidió probar Nexus. La técnica permitió reducir el tiempo de liberación en tres veces y liberar el producto cada tres meses.
Nexus ayuda a establecer la interacción entre equipos, "dispersos" por todo el mundo. Daily Sprints admite un alto nivel de comunicación y participación de los empleados en el proyecto.
Tenga en cuenta que aunque Nexus ayuda a coordinar el trabajo de muchos equipos de desarrollo al trabajar en un proyecto grande y acelerar el lanzamiento de lanzamientos (como es el caso con TPP), aún
no puede resolver los problemas asociados con la estructura interna de la organización. Por ejemplo, el marco no tendrá un efecto notable si los equipos no tienen suficientes especialistas para resolver todos los problemas.
Por lo tanto, Nexus es adecuado para trabajar en grandes proyectos (de acuerdo con los creadores de la metodología, le permite administrar de manera efectiva nueve equipos scrum) y, con la aplicación adecuada, ayuda a acelerar el proceso de desarrollo de 3 a 4 veces. Sin embargo, el enfoque principal de esta metodología es resolver problemas de integración, ya que
no puede ayudar a resolver otros problemas de organización en la empresa.
PD: un par de materiales nuevos del primer blog corporativo de IaaS:
PD Varias publicaciones de nuestro canal de Telegram :