Cuando leí esta pregunta ( Tratar con departamentos externos, entrega continua/menor alcance de funciones ), me hizo pensar en nuestra situación en el trabajo. Sin embargo, la principal diferencia es que la resistencia a la entrega continua proviene principalmente de nuestros clientes.
Contexto
Trabajo en una pequeña empresa b2b2c que atiende a grandes plataformas de bienes raíces en línea. Mi función (similar a la de un experto en scrum) es ayudar a nuestro equipo de desarrollo (multifuncional) a volverse más ágil simplificando/optimizando los flujos de trabajo, facilitando la colaboración y el aprendizaje, y fomentando la creación de valor incremental. Estamos usando un marco kanban suelto, pero creo que este problema se aplicaría incluso si estuviéramos usando Scrum o XP (de ahí las etiquetas). Nadie en el equipo tiene experiencia con Agile/Lean, pero he visto un progreso constante en ese sentido durante el último año.
Asunto
Por extraño que parezca, el problema principal al que me enfrento es que intento sugerir más cortes verticales para crear valor más rápido (por ejemplo, lanzar una característica en menos de una semana en lugar de esperar tres o cuatro semanas para lanzar cinco) y acortar el ciclo de retroalimentación. , es que los clientes preferirían que publiquemos actualizaciones con menos frecuencia. Según tengo entendido, se debe a que nuestros productos están integrados en su sitio web, por lo que utilizan los mismos procesos (lentos y pesados) que utilizan para su propio sitio web y productos, tanto para control de calidad como para fines de marketing.
Me parece que todavía tendría sentido enviar pequeños incrementos internamente y luego agruparlos en un lanzamiento para nuestros clientes, pero dada la falta de experiencia del equipo con las prácticas Agile, preferirían hacer lo siguiente:
El punto del equipo es que, dado que no podemos enviar antes de que se complete el lanzamiento completo, es más eficiente hacer todo el procesamiento a la vez. Dado que no están acostumbrados a las prácticas ágiles, esto también es más consistente con la forma en que siempre han trabajado.
Desde mi perspectiva, esto agrega mucha presión a la persona al final del proceso (es decir, la integración de front-end) y elimina la flexibilidad en el sentido de que si nos estamos quedando sin tiempo, no podemos simplemente descartar funciones.
Pregunta
¿Cuáles son los buenos enfoques para tratar con este tipo de clientes? Incluso si el cliente no quisiera cambiar, ¿debería empujar al equipo a enviar incrementos más pequeños internamente?
Me concentraría en cambiar los procesos de los clientes para integrar sus lanzamientos más fácilmente. Pero hay muchos detalles a considerar.
Si no , no me preocuparía por sus procesos. Consiguen la liberación cuando quieren. Si se saltan los lanzamientos y toman cada 5 lanzamientos, depende de ellos. Debes asegurarte de que puedan saltar.
Si es así , ya que desarrolla el producto de sus clientes, intente comprender completamente por qué sus clientes no están dispuestos/no pueden lanzarlo más rápido. Vea cuáles podrían ser los beneficios para ellos si cambiaran. Vea cómo tendrían que cambiar para obtener estos beneficios. Consúltelos para optimizar sus procesos de liberación.
Pero de todos modos, las versiones incrementales pequeñas deben preferirse internamente. No sé la relación exacta que tiene con sus clientes, pero si no es realista cambiar algo con sus clientes, intente encapsular su proceso de liberación del resto. Usted se mantiene efectivo, flexible y transparente, y sus clientes se registran cuando están listos. Siempre obtienen una pieza de software terminada. Los beneficios del desarrollo incremental son conocidos.
Es posible que desee considerar el uso de conmutadores de funciones .
Esto le permitirá hacer lanzamientos de producción frecuentes, pero le dará a sus clientes la opción de hacer que las funciones estén disponibles solo cuando estén satisfechos con su funcionalidad.
A largo plazo, podría valer la pena trabajar con sus clientes para mejorar sus procesos de entrega. La entrega continua funciona mejor cuando es de extremo a extremo.
nvoigt
Balala
Balala
Bart van Ingen Schenau
alan larimer
Balala
Balala
Balala