Resumen: Este artículo toma un producto clave de una empresa líder en la industria de valores como ejemplo para discutir el resumen de la práctica de implementación ágil y a gran escala basada en las características de la industria mientras se desvía del marco existente.
Cuando se trata de escala y agilidad, la gente suele pensar inmediatamente en varios marcos principales del mercado. Es cierto que cuando el marco existente pueda integrarse mejor con el status quo de la empresa, la implementación basada en el marco ahorrará tiempo y esfuerzo.
Sin embargo, en la práctica, a menudo nos encontramos con situaciones en las que la situación de una empresa cambia constantemente, a menudo lejos de los supuestos del marco y, a veces, la aplicación del marco existente es costosa e incluso produce el efecto de reducir los pies y adaptarse al desempeño. Este artículo toma un producto clave de una empresa líder en la industria de valores como ejemplo para discutir el resumen práctico de la implementación ágil y a gran escala basada en las características de la industria mientras se desvía del marco existente.
01 Escala y agilidad en nuestros ojos
Cómo ganar fuerza en la investigación y el desarrollo de productos para capturar rápidamente oportunidades de mercado, transformarlas en beneficios comerciales y continuar haciéndolo es un problema que muchas organizaciones grandes deben resolver. Específicamente, en el desarrollo de productos complejos,
-¿Cómo unir múltiples equipos ágiles con un objetivo común?
-¿Cómo colaboran varios equipos ágiles?
-¿Cómo lanzar nuevas funciones de productos de forma rápida y continua?
-¿Cómo controlar la complejidad de la colaboración para reducir los costos de gestión y reducir los cuellos de botella del sistema?
-¿Cómo mantener la transparencia, hacer visible el proceso de desarrollo de productos, de modo que los riesgos y obstáculos se revelen y eliminen fácilmente?
-¿Cómo evolucionar para adaptarse a los cambios del entorno?
En nuestra opinión, la esencia de Scaled Agile es aplicar ideas y prácticas lean y ágiles para encontrar soluciones a estos problemas.
02Observación de la práctica ágil escalada a partir de cinco capacidades principales
Puede haber innumerables perspectivas de análisis para una escala ágil. Creemos que, desde la perspectiva de prácticas específicas, la agilidad a gran escala depende más de cinco capacidades centrales:
Alineación de objetivos, ritmo, sincronización, desacoplamiento de dependencia, mejora continua
Podemos derivar y desarrollar prácticas basadas en estas capacidades centrales, para que las organizaciones puedan trabajar juntas y responder rápidamente. Esta sección tomará un producto clave como ejemplo para presentar cómo ayudar al desarrollo de productos en la práctica basándose en estas cinco capacidades principales.
Figura 1 Cinco competencias básicas de escala ágil
La siguiente figura muestra el contexto del producto. En la elipse de dos capas de afuera hacia adentro, la capa externa representa la cartera a la que pertenece el producto y la capa interna representa la gama de productos de este texto. El producto contiene múltiples aplicaciones relativamente independientes, y cada aplicación tiene un Scrum Master (SM) y un Product Owner (PO) Las dos aplicaciones en la figura son para ilustración. Cada aplicación crea un equipo basado en el método Scrum, y cada aplicación incluye varios equipos Scrum fijos de tiempo completo.
Cabe señalar que las aplicaciones incluidas en este producto a menudo dependen al mismo tiempo de otros productos de la cartera, lo que forma una relación de interdependencia compleja y constituye una limitación clave en las actividades de desarrollo de productos.
Nota: El "Scrum Master" (SM) y el "Product Owner" (PO) que se mencionan a continuación son roles a nivel de aplicación y, por lo general, son responsables de varios equipos Scrum.
Figura 2 Alcance del producto y actividades principales
(Reunión de colaboración de productos: cada PO de aplicación lidera y colabora para definir prioridades
Planificación de la reunión de colaboración: SM domina cada aplicación, programa la siguiente iteración y revisa la iteración anterior
Punto de alineación de la interfaz, determine la interfaz entre los productos dependientes antes de que comience la iteración)
2.1 Alineación del objetivo
Probablemente hayas escuchado esta historia:
Tres albañiles están ocupados en el sitio de construcción. Un transeúnte preguntó, ¿qué estás haciendo? El primer cantero dijo: Estoy poniendo muros. El segundo dijo: Estoy ganando dinero para mantener a mi familia. El tercero dijo que estoy construyendo una catedral.
La gente a menudo admira el diseño del tercer albañil, pero el primer albañil puede estar demasiado "por cierto" subestimado. De hecho, deberíamos tener la catedral que estamos construyendo en nuestro corazón, ahí es donde radica nuestra misión. Sin embargo, ¿el muro que se va a construir ahora mismo debería ser el centro de atención?
Desde la perspectiva de la alineación de objetivos, debemos basarnos en objetivos comerciales a largo plazo, pero debemos ser capaces de:
- Divida las metas a largo plazo en pequeñas metas a corto plazo,
- Alinear los "pequeños objetivos" de las personas relevantes y el equipo,
- Haga que los equipos relevantes se alineen en el proceso de lograr pequeñas metas.
Las grandes metas a largo plazo nos dan dirección, las pequeñas metas a corto plazo nos permiten concentrarnos. La alineación de metas grandes y pequeñas nos permite trabajar duro juntos antes de poder seguir cumpliendo rápidamente.
La alineación de objetivos del producto está impulsada por las siguientes tres actividades clave.
Figura 3 Tres actividades clave impulsan la alineación de los objetivos del producto
Conferencia de colaboración de productos y sus actividades piloto
Con base en el valor comercial y considerando la interdependencia, cada OP del producto se crea conjuntamente para dividir la demanda y priorizar (adjudicación comercial si es necesario). La colaboración de productos generará una lista de requisitos programados para la próxima iteración.
La colaboración de productos será una combinación de actividades en línea y fuera de línea, y la mayor parte del trabajo sustantivo se realizará antes de la reunión. Antes de la reunión, las OP deben analizar sus necesidades en profundidad y comunicarse plenamente con las partes relacionadas; la reunión es más un punto de control para verificar y llenar las vacantes.
Tabla 1 Reunión de colaboración de productos
(Nota: cada iteración toma dos semanas; W: la primera semana de la iteración actual; W + 1: la segunda semana de la iteración actual; W-1: la semana antes del comienzo de la iteración ... otra analogía).
Planificación de la reunión de colaboración y sus principales actividades
Basado en el resultado de la reunión de colaboración del producto, la programación de colaboración SM de cada aplicación del producto. (Como se mencionó anteriormente, "SM" es una aplicación Scrum Master, y puede haber varios equipos Scrum detrás de ella).
La programación de la colaboración consiste esencialmente en extraer el trabajo de planificación a nivel de producto de las reuniones de planificación tradicionales de Scrum (el equipo de Scrum luego hará planes detallados en la reunión de planificación de iteraciones).
Al igual que en la reunión de colaboración de productos, la mayor parte del trabajo de programación sustantivo también ocurre en la comunicación fuera de línea antes de la reunión.
Tabla 2 Reunión de cooperación del proyecto
Punto de alineación de la interfaz
Según el resultado de la reunión de colaboración planificada, la arquitectura de cada producto define interfaces interdependientes; antes del inicio de la iteración (semana W-1), determine las interfaces de aplicación interdependientes. Esta actividad es un seguimiento de la reunión de planificación de la iteración y el preludio del trabajo conjunto de depuración en la iteración.
Tabla 3 Puntos de alineación de la interfaz
Se puede ver que el mecanismo de alineación de este producto combina una pequeña cantidad de actividades de rutina y una gran cantidad de comunicación fuera de línea: la colaboración del producto será similar a la colaboración planificada, las reuniones se utilizan como puntos de alineación, pero la mayor parte del trabajo sustantivo ocurre fuera de línea; los puntos de alineación de la interfaz son más Solo existe como puesto de control. Obviamente, esto es diferente de los marcos ágiles comunes. Por ejemplo, SAFe y LeSS enfatizan las actividades de planificación colectiva a gran escala en diversos grados.
Hay dos razones detrás de esta diferencia: primero, la cartera del producto es un grupo de múltiples productos relacionados y se entrelazan múltiples corrientes de valor; muchas aplicaciones de las que depende el producto sirven a otros productos de la cartera al mismo tiempo , Que es significativamente diferente de la única solución en escenarios típicos de SAFe o LeSS. En segundo lugar, los empleados de socios (subcontratación) que se utilizan ampliamente en el desarrollo de productos actualmente no están profundamente involucrados en las primeras actividades de demanda.
En este escenario complejo, la planificación colectiva a gran escala es difícil para garantizar la eficiencia. Por el contrario, el método de alineación adoptado por este producto se basa en un método de planificación descentralizado y progresivo, y está restringido por puntos de control centralizados, que tiene valor de referencia para situaciones similares.
2.2 Ritmo y sincronización
Si ha participado en una competencia de tira y afloja, probablemente sepa que la persona que está al lado de los gritos determina en gran medida el resultado del juego. Gritar es en realidad el control del ritmo. Usar un ritmo estable para crear ondas de choque en el juego es un truco para ganar.
La dependencia del ritmo del desarrollo de software a gran escala también es como un tira y afloja. Todos los productos relacionados cooperan entre sí sobre la base de un ritmo iterativo fijo, y las actividades importantes son predecibles y manejables, para formar una sinergia entre los equipos y evitar el caos y el desorden.
La sincronización ocurre en el ritmo, incluidas las actividades formales e informales, basadas en el intercambio de información para promover la cooperación, y bajo la premisa de alineación de objetivos, las personas tienen la oportunidad de sopesar las compensaciones como un todo.
Las aplicaciones de la cartera de productos descritos en este artículo comparten el mismo ritmo iterativo en dos semanas. Para productos altamente conectados, un ritmo tan unificado favorece la alineación del objetivo.
En el momento de escribir este artículo, el ritmo de iteración y las actividades principales se muestran en la figura siguiente.
- La "creación conjunta de prioridad entre productos" se adelanta 2 ciclos a la iteración del desarrollo. Su principal actividad es el "Product Collaboration Meeting" mencionado anteriormente, que sirve como disparador para la investigación y el desarrollo.
- La "combinación de requisitos y la programación de iteraciones cruzadas" proporciona información directa para las iteraciones de desarrollo, incluidas las actividades de comunicación de requisitos, las actividades de sincronización de interfaces y el análisis y diseño de requisitos. Estas actividades están un ciclo por delante de la iteración de desarrollo.
- La "iteración del desarrollo" es la principal etapa de generación de valor. En la iteración de desarrollo, hay puntos de control de depuración conjunta, que indican la hora de inicio de control de la depuración conjunta entre sistemas; y los puntos de control de prueba indican la hora de inicio de control de la presentación de pruebas del sistema, que son ligeramente diferentes para diferentes equipos.
Figura 4 Ritmo iterativo y actividades de sincronización en él.
El mismo ritmo proporciona un latido confiable para la alineación de objetivos de múltiples productos y la colaboración de I + D, y es la base para una entrega estable.
Limitado por la situación actual del personal, el diseño del ritmo actual todavía es un poco complicado: el socio completa una parte considerable del desarrollo y las pruebas del producto, y la alta movilidad de los empleados del socio dificulta la formación de acumulación, lo que conduce a más necesidades de control y respuestas correspondientes. Enlace de proceso: aquí tenemos que seguir explorando el mecanismo de simplificación.
2.3 Desacoplamiento de dependencia
En escenarios a gran escala, la dependencia entre equipos suele ser un asesino de la eficiencia. El "desacoplamiento de dependencias" consiste en aplicar varios métodos para reducir y controlar las dependencias para que el trabajo del equipo sea lo más independiente posible. Algunas personas incluso creen que la esencia de la escala ágil es "desescalar", lo que significa reducir la complejidad de la colaboración organizacional a través del desacoplamiento entre organizaciones de I + D. El desacoplamiento organizacional completo puede no ser factible u óptimo. El mejor punto de entrada-salida del desacoplamiento debe abordarse gradualmente a través de la exploración. Los intentos típicos utilizados por este producto incluyen el desacoplamiento a largo plazo de las capacidades comerciales básicas y los mecanismos de pasajeros a corto plazo.
Creación de capacidad empresarial básica
Las capacidades comerciales básicas están incorporadas como servicios públicos compartidos por múltiples aplicaciones. La extracción de capacidades empresariales básicas es un intento de reducir la complejidad del sistema, y la clave aquí es tratar de evitar que los servicios públicos se vuelvan dependientes del desarrollo empresarial.
El deber ineludible del departamento de TI es responder a las necesidades comerciales de forma rápida y con alta calidad. Sin embargo, debido a los recursos limitados, las capacidades de respuesta a corto y largo plazo son una contradicción. A corto plazo, debemos responder a las solicitudes comerciales lo más rápido posible con toda nuestra mano de obra; a largo plazo, debemos reservar mano de obra para el desarrollo de la capacidad empresarial básica, porque el soporte de la capacidad empresarial básica madura puede hacer que el desarrollo de la función de la aplicación sea más eficaz. (Nota: esta práctica requiere precaución. Si la capacidad empresarial básica no puede lograr una gran independencia, es probable que produzca efectos contraproducentes).
En el desarrollo de este producto, adoptamos la idea de la construcción gradual de capacidades comerciales básicas.
Como se muestra en la siguiente figura: Como visión, las capacidades comerciales básicas esperadas y el desarrollo de productos de aplicaciones deben desacoplarse, y el desarrollo de capacidades comerciales básicas debe tener una visión de futuro y una madurez adecuadas, centrarse en los servicios públicos y apoyar el desarrollo de aplicaciones.
Sin embargo, las capacidades comerciales básicas actuales también incluyen la parte del "servicio específico de la aplicación", cuyo contenido todavía está estrechamente relacionado con aplicaciones específicas.
Para garantizar la velocidad de respuesta empresarial, la parte del "servicio específico de la aplicación" debe seguir de cerca el ritmo del desarrollo de la aplicación; al mismo tiempo, los desarrolladores relevantes deben mantener una estrecha cooperación con las capacidades comerciales básicas (especialmente los arquitectos) y están sujetos a la infraestructura y las reglas de las capacidades comerciales. Restricciones para prepararse para la plataforma de funciones relacionadas.
A largo plazo, con la mejora de las capacidades comerciales básicas, las funciones de software de la parte de "servicios específicos de la aplicación" deben diferenciarse en las direcciones superior e inferior, parte de los servicios generales de las capacidades comerciales básicas, y parte de ellas se integrará en el desarrollo de los requisitos comerciales.
Figura 5 Equilibrio de las funciones de la aplicación y desarrollo de la capacidad empresarial básica
Mecanismo de pasajeros
Los equipos ágiles deben basarse en una organización de valor. Al mismo tiempo, los equipos ágiles también deberían permanecer estables. Sin embargo, estos dos principios a veces entran en conflicto. ¿Qué hacer cuando hay un conflicto? Aquí nos basamos en el concepto de pasajeros en LeSS (en referencia a que los pasajeros en LeSS, en lugar de pedir prestados, están más inclinados a empoderar al equipo objetivo, y el propósito principal de los pasajeros aquí es la entrega a pedido).
Si hay un trabajo de desarrollo de aplicaciones más específico para la capacidad empresarial básica en una determinada iteración, el ingeniero de I + D del equipo de capacidad empresarial básica puede unirse temporalmente a la aplicación como "pasajero" y trabajar de acuerdo con la prioridad de la aplicación. Los efectos de este enfoque son:
Uno, reducir el grado de acoplamiento entre equipos, reduciendo así la complejidad de la coordinación (la comunicación entre equipos se transforma en comunicación dentro del equipo).
En segundo lugar, equilibre el desarrollo de capacidades comerciales básicas con el desarrollo de requisitos de aplicación. Entre los dos, el sistema de pasajeros de subida y bajada proporciona flexibilidad.
3. Promover la estrecha cooperación entre las capacidades comerciales básicas y las aplicaciones comerciales, y mantener la sensibilidad empresarial del desarrollo de las capacidades comerciales básicas.
Por supuesto, el mecanismo del pasajero es solo un intento posible, lejos de una bala de plata. En esta situación en la que se intercalan múltiples corrientes de valor, necesitamos encontrar un equilibrio entre "eliminar la dependencia" y "gestionar la dependencia".
2.4 Mejora continua
Evolución del estilo de trabajo
Con base en la comprensión de conceptos ágiles y ajustados y la retroalimentación de la práctica, las prácticas de desarrollo de productos se ajustan y adaptan constantemente.
En diferentes ámbitos, las principales actividades portadoras del mecanismo de mejora continua incluyen:
(1) Reunión de revisión de iteraciones del equipo Scrum
Esta es una actividad básica de inspección y ajuste derivada del marco clásico de Scrum.
(2) Reunión regular de SoS en la aplicación
El ejemplo de SoS en la aplicación tiene dos funciones: una es la sincronización del trabajo diario y la otra es la revisión oportuna y la mejora de problemas en el proceso de desarrollo. Las mejoras resultantes de esta revisión oportuna se registrarán en la Wiki y los resultados se comprobarán en la próxima reunión. Cada retrospectiva enfatiza el descubrimiento de problemas de abajo hacia arriba, y el liderazgo se compromete a ayudar al equipo a resolver problemas.
(3) Reunión de colaboración iterativa de gama de productos
Esta actividad se ha introducido en la sección "Alineación de objetivos" anterior, por lo que no la repetiré aquí.
Beneficios de las prácticas ágiles a gran escala
(1) En el escenario a gran escala, es particularmente necesario evitar que cada equipo luche por separado. El diseño del mecanismo de alineación de este producto se basa en la co-creación prioritaria de múltiples aplicaciones. Cada aplicación colabora para producir una lista de funciones a completar en cada iteración y objetivos comerciales a apoyar, de modo que cada aplicación tenga el mismo objetivo reconocido, que se convierte en la colaboración entre aplicaciones Fundacion solida.
(2) El ritmo unificado de múltiples aplicaciones proporciona un marco de proceso confiable para cada evento en el desarrollo de productos. El mismo ritmo facilita las actividades de sincronización descentralizadas, y los puntos de control de rutina (centralizados) y las herramientas de apoyo (Wiki, Jira) se utilizan para mejorar la transparencia y garantizar la calidad de las actividades descentralizadas. Esto simplifica la comunicación y la colaboración al tiempo que expone y elimina de manera efectiva los obstáculos en la ejecución iterativa.
(3) El ciclo iterativo dual de demanda y realización (complementado por procesos, roles y responsabilidades claros) hace que las actividades de combinación de la demanda sean rigurosas y ordenadas, y que la planificación del producto y la realización de la demanda se superpongan y avancen regularmente.
03 Principales desafíos actuales y exploración en curso
En la situación de múltiples corrientes de valor, la dirección de evolución de la escala
Como se mencionó anteriormente, la cartera de este producto se enfrenta a un escenario complejo donde coexisten múltiples productos y dependen unos de otros, y se entrelazan múltiples flujos de valor. En esta circunstancia, el marco existente a gran escala no puede proporcionar una solución sistemática y uno debe explorar su propio camino. Nuestra exploración continua se basa en la consideración de los siguientes puntos clave:
Primero, alineación de objetivos multiproducto. Dentro del alcance de la cartera de inversiones, la red formada por múltiples productos se considera como una red de flujo de valor en su conjunto, que tiene objetivos comerciales compartidos. Una dirección en la que estamos trabajando es: basarnos en la co-creación prioritaria de múltiples aplicaciones, y respaldar la estrategia organizacional a largo plazo con una hoja de ruta (alineación de objetivos a largo plazo), para que múltiples aplicaciones puedan concentrar sus fuerzas, colaborar en la misma versión y respaldar juntas Necesidades comerciales en todos los productos (alineación de objetivos a corto plazo).
En segundo lugar, colaboración descentralizada. Cuanto más grande y compleja sea la red de flujo de valor, más costosas serán las actividades y decisiones colectivas a gran escala, y más necesitamos depender de la colaboración descentralizada. Esto se complementa con el empoderamiento de los empleados.Contamos con empleados sobresalientes para completar sus respectivos resultados con un alto grado de autonomía y alta calidad, y confiamos más en su estrecha colaboración y apoyo mutuo con los socios.
En tercer lugar, transparencia . En el escenario descentralizado, necesitamos un diseño de medición efectivo para formar una visión general del proceso y la medición, a fin de poder exponer la necesidad de prestar atención a los problemas de desarrollo y los problemas sistémicos. De esta manera, tenemos la oportunidad de eliminar obstáculos al proceso de desarrollo de requisitos y evitar el caos mientras nos descentralizamos.
Soporte "Big Need": un desafío específico
La "gran demanda" que afecta a múltiples productos en la cartera aún no se ha incorporado por completo al mecanismo de alineación y al ritmo de iteración: en la actualidad, la gran demanda a menudo se basa en una programación independiente y una aceptación única en un punto de tiempo de entrega fijo, operando fuera del ritmo iterativo.
En este sentido, estamos tratando de desmontar la gran demanda en la forma de "MVP + incremento", y en base a esto, fortalecer el mecanismo de alineación dentro de la cartera, llevar el desarrollo de la gran demanda al mismo ritmo iterativo y proporcionar el conjunto a través del Kanban visual en consecuencia. ver.
Figura 6 Diagrama esquemático del método de división MVP para gran demanda
Al final
La exploración ágil y a gran escala de este caso ha entrado en la zona de aguas profundas. Si bien estamos comprometidos a explorar las soluciones a estos problemas profundamente arraigados, esperamos que estas exploraciones en el desarrollo de este producto puedan ser de valor de referencia para usted, y también podemos discutir la práctica del desarrollo ágil a gran escala con nosotros.
Bienvenido al foro de discusión.
Haga clic para seguir y conocer la nueva tecnología de Huawei Cloud por primera vez ~