Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Escalar. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Escalar. Mostrar todas las entradas

miércoles, enero 17, 2018

Revisión a la Guía de Nexus 2018


Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.
Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.
Estos son los cambios más significativos:
1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.
2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.
3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.
4.    Claridad alrededor del rol del Equipo de Integración Nexus:
a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.
b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.
c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.
5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.
a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.
b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.
c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.
6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.
a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.
b.    Se eliminó de la Tabla de Contenido.
7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.
a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.
b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.
8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.
9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.
a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.
10. El Incremento Integrado representa el estado actual del trabajo integrado.
11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.
12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.
13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.
14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.
Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.
La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.
Para conocer más de Nexus, pueden leer mi artículo:
En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.

jueves, junio 08, 2017

Escalar Para Qué

La pregunta no es o no debería ser ¿cómo escalar Ágil? Más bien es un asunto de ¿por qué escalar Ágil? Pero antes de entrar en materia, quiero recordarles algo que he mencionado en varios escenarios: antes de escalar Ágil como solución, pensemos en ‘desescalar’ el problema.
El asunto con el escalamiento es que se nos está convirtiendo en una cuestión de cuál método usar y no en lo que verdaderamente importa a las Organizaciones: ¿por qué escalar? Debemos ir a la causa raíz, el problema detrás del problema, es quizás una de las pocas vías razonables que tenemos para encontrar una razón de peso para escalar Ágil y tal vez un buen camino a seguir.
Los marcos de trabajo o los métodos de escalamiento proporcionan herramientas que ayudan en el proceso, pero me parece que apenas si nos permiten lograr que los equipos realicen correctamente el trabajo y que lo hagan de manera integrada. Pero hacer correctamente el trabajo correcto es otra cosa.
Cuando empezamos la transformación a o la adopción de Ágil, lo hacemos provistos con el Manifiesto Ágil y quizás Scrum o Kanban, acompañados de algunas otras prácticas y el pensamiento Lean. Tenemos la férrea esperanza de que el área de TI no necesite nada más allá de algunas otras herramientas Ágiles que hoy ya podemos brindar como “paquetes” (BDD, Refactoring, User Story Map, entre otras).
Luego nos damos cuenta que, contrario a lo que sucedía con el enfoque tradicional, el Ágil es un pensamiento que debe tener un lugar en cada uno de los asientos de la empresa y en cada lugar que habitan sus miembros. Entonces, cuando queremos salir fuera de la oficina de TI, hacia el resto de la Organización, nos olvidamos del Manifiesto y nos aprovisionamos con todo tipo de artilugios ‘agilísticos’ como si se tratara de la cruzada definitiva, la última cruzada de los agilistas o algo similar.
Pensamos más en el número de equipos y de personas a escalar que en el Valor y en el número de productos o servicios que debemos desarrollar.
No todas las corporaciones necesitan escalar Ágil. Algunas solo necesitan Ágil para entregar software con Valor de manera temprana y frecuente. No se trata de que tan Ágil soy comparado con mis vecinos, más bien de lo que se trata es de si voy correctamente en el camino Ágil correcto y de lo que debo hacer para mantenerme allí.
En definitiva, lo que tenemos que responder, mientras seguimos encontrando formas mejores de hacer las cosas, tanto por nuestra cuenta como ayudando a otros, es si nuestra Organización o la que estamos acompañando en su camino Ágil ve el tiempo de respuesta como un diferenciador crítico para sus consumidores finales o ante sus competidores.
Pero aun más importante es si queremos escalar la forma cómo pensamos acerca de las personas y sus interacciones o solo la forma de desarrollo de nuevos productos y servicios. ¿Queremos escalar el nivel de motivación y felicidad de nuestros compañeros de trabajo y colegas o solo su productividad y eficiencia? Y si se trata de ambas cosas, ¿lo estamos haciendo? Más aun, ¿lo estamos haciendo de una manera correcta?
Otros porqués incluyen:
  • ¿Qué tan innovador queremos que sea el portafolio de la Organización?
  • ¿Qué tanta incertidumbre hay en nuestros esfuerzos de desarrollo y, por extensión, en nuestro futuro?
  • ¿Queremos innovar o simplemente realizar el mejor mantenimiento posible a lo que hacemos y proporcionamos?
  • La estocástica también juega un papel importante. ¿Qué tan aleatoria es la demanda de nuestra Organización?
Finalmente, ¿estamos planeando o ejecutando ya una metempsicosis organizacional, en el sentido de transformación, a la que podamos sumar la adopción de Ágil a gran escala? ¿O simplemente queremos vender o implantar una marca más por asuntos de moda que por aspectos fundamentados en la ingeniería y en las prácticas de la industria?
¿No será que estamos cayendo una vez más en el uso de un gran número de métodos o marcos de trabajo y sus variantes, con diferencias poco entendidas e incrementados artificialmente y que además carecen de evaluación y validación experimental creíble? Eso ya nos sucedió, de allá venimos, de metodologías y prácticas inmaduras que obstaculizaban gravemente la ingeniería de software, en particular, y el desarrollo y entrega de productos y servicios con Valor, en general.
Otro asunto, riesgoso y de mayor impacto para la Organización, es tratar de escalar sin haber terminado de construir los cimientos o cuando todavía hay disfunciones Ágiles en el nivel más básico. En ese caso, lo único que lograremos escalar serán precisamente los problemas, no las soluciones. Pero este será tema de otro artículo.
Escalemos la entrega de Valor, no solo el método o marco de trabajo que queremos usar.