por: Jorge H. Abad L – jorge.abad@gmail.comtwitter@jorge_abad –blog: www.lecciones-aprendidas.info

Nexus – El Exoesqueleto para Escalar Scrum y la Deuda Técnica

Mis objetivos con esta sesión:

- Compartir sobre Nexus- Elevar nuestro nivel de conciencia sobre la deuda técnica

Esto no es del todo mío, se basa en crecer sobre el compartir

Presentación esta basada en las diapositivas de mi amigo Lucho Salazar @LuchoSalazarC

Blog: http://www.gazafatonarioit.com/

A planes más largos, mayores serán los supuestos y

mayores los riesgos. No permitas que la incertidumbre

te gobierne

@ourfounder

Historias de la vida real

¿Cuál de los siguientes procesos de software estás usando en

tu organización?

• Lean (Software Development)

• Kanban

• DevOps

• SAFe

• DAD

• LeSS

• eXtreme Programming

• Scrum

Historias de la vida real

¿Has estado involucrado en esfuerzos para escalar Scrum?

Levanta la mano si tu organización define ‘escalar’ como:

• Múltiples equipos trabajando en un producto

• Múltiples equipos trabajando en sus productos individuales

• Múltiples equipos trabajando en una suite de productos

integrados

• Un equipo trabajando en varios productos en paralelo

• Toda la organización TI adoptando Scrum

• Una transformación organizacional de 180º hacia Ágil

Historias de la vida real

¿Has estado involucrado en esfuerzos para escalar Scrum?

Levanta la mano si tu organización define ‘escalar’ como:

• Múltiples equipos trabajando en un producto

• Múltiples equipos trabajando en sus productos individuales

• Múltiples equipos trabajando en una suite de productos

integrados

• Un equipo trabajando en varios productos en paralelo

• Toda la organización TI adoptando Scrum

• Una transformación organizacional de 180º hacia Ágil

Scrum: diseñado para la complejidad

• Fomentar la creatividad

de las personas

• Controlar el riesgo

(Time-Boxing)

• Permitir el aprendizaje

validado

• Dirigido por metas

• Exitoso en el

descubrimiento

• Entrega de valor

• Un entorno delimitado

para la acción

DNA de Scrum

Autoorganización

• Los componentes de un sistema interactuando con un único propósito hacia una meta compartida, evitando cualquier poder externo

Empirismo

• Las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia

SIN EMBARGO…

¿Qué tal si empezamos haciendo Scrum antes de intentar escalarlo?

La Esencia de Scrum

1. Un equipo saca

trabajo de una

Lista de

Producto

2. Cada Sprint

entrega un

Incremento

distribuible del

producto

Incrementos

Equipo ScrumLista de

Producto

Definición de Scrum a Escala

• Cualquier implementación de Scrum

donde múltiples Equipos Scrum

construyen un producto o un

conjunto de características de un

producto en uno o más Sprints.

• Cualquier implementación de

Scrum donde múltiples Equipos

Scrum construyen múltiples

productos relacionados o

conjuntos de características de

productos en uno o más Sprints.

La Esencia de Scrum

1. Un producto

tiene una Lista

de Producto

manejado por un

Dueño de

Producto

2. Múltiples

Equipos crean

Incrementos

integrados

Lista de Producto

Equipos Scrum

Incrementos (Integrados)

¿Cuáles son tus mayores obstáculos al

escalar Scrum, implementar Scrum a

gran escala?

Los desafíos de escalar Scrum

La integración del trabajo (o la ausencia de ella)

Código pobremente mantenido produce

EL EFECTO MEDUSA

Un Equipo Scrum Haciendo el Trabajo

Lista de Producto

Algunos Equipos Scrum Haciendo el Trabajo

Lista de Producto

Lista de Producto

Muchos Equipos Scrum Haciendo el Trabajo

Tu habilidad de escalar depende de tu habilidad para:

– Manejar dependencias

– Integrar el trabajo en todos los niveles

– Crear Incrementos integrados

continuamente

Pausa…

Despues volveremos sobre lo de la deuda tecnica

NexusScrum Profesional a Escala

“Un hombre que toma un gato por la cola

aprende algo que no puede aprender de otra

forma”.

- Mark Twain

Nexus

–noun

\ˈnek-səs\

: a relationship or connection between people or things

http://www.merriam-webster.com/dictionary/nexus

¿3-9 Equipos Construyendo un Producto? ¡Ayuda!

Incrementos (Integrados)

Equipos ScrumLista de

Producto

Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum

Identifica y trabaja alrededor de las dependencias:

Antes de que se haga el trabajo

Continuo

Persistente

En todas las dimensiones

Revela dependencias que permanecen desapercibidas:

Integración Frecuente

Pruebas de aceptación

Compilación y entrega continua

Reduce la deuda técnica

Diseñado para Manejar Dependencias

Proactivo Reificación*

*Reificación:

Hacer que algo se vuelva real o hacer

que algo abstracto se vuelva concreto

Nexus Aumenta Scrum

Construido sobre los principios, valores y fundamentos de Scrum

Crea rutas de comunicación

Extiende y profundiza los mecanismos de inspección y adaptación

Fomenta la transparencia continuada

Depende en la inteligencia hacia arriba

Evita soluciones fijas y definidas que agregan sobrecostos.

Nexus - Roles, Eventos y Artefactos

Roles Eventos Artefactos

Equipos de Desarrollo El Sprint Lista de Producto

El Equipo de Integración Nexus*

Planificación del Sprint Nexus*

Lista de Pendientes del Sprint Nexus*

Dueño de Producto Planificación del Sprint Lista de Pendientes del Sprint

Scrum Master Scrum Diario Nexus* Incremento Integrado

Scrum Diario

Revisión del Sprint*

Revisión del Sprint

Retrospectiva del Sprint Nexus**Específico de Nexus

El Equipo de Integración Nexus

Un Equipo Scrum

Trabaja con la Lista de Producto

Los Miembros están tiempo completo o medio tiempo

Su composición puede cambiar entre Sprints

Se enfoca en las dependencias y en la facilitación de la integración

Scrum Diario Nexus

• ¿El trabajo del día anterior fue integrado

exitosamente? Si no fue así, ¿por qué

no?

• ¿Cuáles nuevas dependencias han sido

identificadas?

• ¿Qué información necesita compartirse

entre los equipos del Nexus?

Prácticas de Scrum Profesional a Escala

Dependencias Reificación

Equipos de Características Automatización de artefactos ALM

Micro-servicios Desarrollo conducido por pruebas

Metadatos de la Lista de Producto Integración continua de todo el trabajo

Refinamiento continuo de la Lista de Producto Compilaciones frecuentes

Story mapping Pruebas Frecuentes

Mapeo de dependencias entre equipo de la Lista de Producto

Limited branching

Comunidades de práctica Descaling and Scrumble

La Arquitectura contiene experimentación Porciones de los elementos de la Lista de Producto componen los Pendientes del Sprint para ATDD

Desescalar

Escale con precaución

Adicione prácticas o herramientas

Reduzca el paso total, disminuyendo el número de equipos a un número más sostenible (o la velocidad)

Limpie e integre el software actual para que se pueda compilar sobre él en futuros Sprints

Vel

oci

dad

Equipos

Scrumble

Cuando la deuda técnica, el conocimiento del dominio y los resultados de las pruebas abrumen el progreso, haga ‘Scrumble’

Scrumble es un periodo de duración desconocida y de reclutamiento de personal cuando se trabaja para lograr que el progreso se reinicie

El reclutamiento debería minimizarse y el talento aplicado maximizado

Equipos

Vel

oci

dad

Nexus interconecta 3-9 Equipos Scrum que:

– Exhiban los principios y el DNA de Scrum

–Creen un Incremento de producto reificado

– Reduzcan sobrecostos, maximicen resultados

Volvamos al tema de la Deuda Técnica

Indaguemos

La deuda técnica son las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware.

Wikipedia

La deuda técnica son las consecuencias de:• un desarrollo apresurado• un desarrollo inconsciente de software • o un despliegue descuidado de hardware

Que se terminará pagando ya sea con:• baja velocidad de desarrollo• inversión de tiempo removiéndola o• bajo rendimiento del sistema

@jorge_abad

¿Quienes han estado enun Proyecto que fuecancelado debido a que era más práctico iniciarde cero que continuartrabajando en el?

¿Y CÓMO LUCE?

Nuestro servidor agotado por :• La carga• Necesita continuos reinicios• Carecemos de

• buen hardware• Software liviano adecuado

para el hardware• Software bien construido(por lo general las últimas dos)

Ejemplos

¿Algún ejemplo más?

Presiones de Negocio

Poco entendimiento del proceso

Software no modular, clases muy acopladas

Falta de una buena suite de pruebas

Falta de documentación

Falta de colaboración entre equipos

Falta de acompañamiento a desarrolladores jóvenes

Desarrollo paralelo (en dos o más branches)

Postergar la refactorización

Inexistencia de estándares o no alineación con ellos

Poco conocimiento por parte del desarrollador de buenas prácticas

Poca apropiación del código

Pobre liderazgo técnico

Subutilización del software base

Sobreutilización del software base

Presiones por cambios de último minuto

Entre otros

Causas

Síntomas

Despliegue lentos

Constantes reinicios del servidor por consumo de memoria

Código inmantenible

Código inestable o con el síndrome de castillo de naipes

Toco aquí y daño allá

No sé donde tocar

Tengo miedo a tocar

Costo alto de cambios

Costo alto de corrección de código

Disminución de la velocidad de los sprints

Entre otros

Efectos

Deuda técnica a ser pagada

Process DebtMethodology Debt

Prácticas Técnicas compartidas por todo el equipo• Revisiones de código• Pruebas de Aceptación• Pruebas Unitarias• Propiedad Colectiva de Código• Clean Code• Test Driven Development• Integración Continua• Entrega Continua (Continuous Delivery)• Diseño Simple• Programación por pares• Mob Programming• Estándares de codificación• Refáctoring• Monitoreo de la deuda técnica

Como resolverla

Como resolverla

Cerrando

Qué nos ha enseñado la experiencia

Qué nos ha enseñado la experiencia

Colaboración

Entrega de Valor

(Temprana, continua y con excelencia

técnica)

Adaptaciónal Cambio

MejoraContinua

– Alistair Cockburn

Maximice el “Corazón de Ágil”

Qué nos ha enseñado la experiencia

Qué nos ha enseñado la experiencia

Qué nos ha enseñado la experiencia

Donde No hay • Ni compromisos• Ni planes• Ni métricas• Ni Arquitectura• Ni ingenieria

AGILE NO es desarrollo hippie

PREGUNTAS

Sobre el material utilizado

Esta presentación se basa en el trabajo de Guther Verheyen (@Ulizee) y otras personas de Scrum.org

Adicional en

– Lucho Salazar @LuchoSalazarC

– Javier Garzas @jgarzas

– Ángel Nuñez @snahider

Además de las referencias explícitas, esta presentación puede contener material o ideas de otras personas u organizaciones que omití sin intención.

Nota: Trate de dar crédito a todos, pero si consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad, por favor, no dudes en hacérmelo saber, contactándome a: Jorge.abad@gmail.com

Aviso de Copyright

Eres libre de:– Compartir- copiar, distribuir y transmitir este trabajo

– Modificar- adaptar el trabajo

Bajo las siguientes condiciones

– Atribución: debes atribuir el trabajo en la manera especificada por el autor o

licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del

trabajo).

Nada de lo dispuesto en esta licencia menoscaba o

restringe los derechos morales del autor.

Para más información ver http://creativecommons.org/licenses/by/3.0/

Información de contacto

Jorge Hernán Abad Londoño

– Jorge.abad@gmail.com