He leído numerosas preguntas de Project Management SE sobre este tema, y también he buscado en Google. Soy consciente de que antes se han abordado diferentes encarnaciones de esta pregunta, pero no he encontrado algo que me proporcione una respuesta clara.
Soy el PM en un equipo de 20 personas, incluidos algunos recursos remotos. Desarrollamos o mantenemos unas 10 aplicaciones. Aproximadamente la mitad del equipo trabaja en la mayoría de las aplicaciones, que son estables y no tienen un propietario del producto ni una hoja de ruta real, excepto las correcciones de producción o las mejoras que el equipo presenta internamente. La otra mitad trabaja en una o dos aplicaciones que se ven muy afectadas y requieren modificaciones cuando la empresa lanza un nuevo producto cada pocos meses. Esas una o dos aplicaciones también tienen correcciones de producción y mejoras que el equipo presenta internamente. (Básicamente, tenemos la libertad de modificarlos como queramos, siempre que el negocio continúe siendo compatible). Soy nuevo en el equipo, así que aún no sé cuánto se pueden preparar esas aplicaciones para mitigar las modificaciones repentinas y urgentes.
El equipo ha estado tratando de adoptar scrum durante algunos meses antes de mi llegada, pero prácticamente sin dueños de productos, sin una visión cohesiva a largo plazo para las aplicaciones en su conjunto y poca interdependencia entre las soluciones, no sé si Scrum es el camino correcto a seguir. He leído sobre la combinación de kanban con scrum, pero parece que no puedo entenderlo. Scrumban suena bien, pero es mucho más nuevo y menos maduro que dudo en adoptarlo. ¿Cuál sería la mejor manera de administrar este equipo para que la carga esté nivelada en todos los recursos, trabajemos a un ritmo sostenible y tengamos un objetivo algo definido para guiar nuestros esfuerzos de desarrollo?
Basándome en experiencias pasadas, estaría de acuerdo con las otras publicaciones anteriores y recomendaría comenzar con un enfoque basado en el flujo, como un tablero kanban para las aplicaciones de soporte en curso, y tal vez mirar a Scrum para las que están en desarrollo más pesado en curso/características. También recomendaría comenzar con un tablero que coincida con su flujo real paso a paso y no con un flujo idealizado, incluso si parece muy raro, será una parte clave de la transparencia que obtiene de kanban. También creo que la transparencia le dará inmediatamente a usted y al equipo puntos de discusión sobre cómo organizarse mejor en subequipos, etc.
Sin embargo, no estoy de acuerdo con que necesite un Product Owner designado, particularmente para el soporte continuo, y especialmente si el equipo ya está mostrando la propiedad del producto. En los últimos años me he dado cuenta/apoyo la propiedad distribuida de productos como algo muy saludable; Al igual que un buen Scrum Master que intenta volverse obsoleto al mostrarle a un equipo cómo adoptar y prosperar completamente con kaizen, un buen PO (único) debe aspirar a volverse obsoleto a través de la radiación, una visión increíblemente fuerte y proporcionar herramientas de alineación continuas que todos pueden adoptar. y seguir adelante con.
Dicho esto, es mucho más difícil hacerlo en un producto de visión lo es todo en comparación con algo en mantenimiento, pero aún así debería ser un objetivo a largo plazo. :)
Scrum no es ágil. :) Es una forma de hacer ágil, no se adapta a todas las situaciones.
Según lo que ha descrito, un enfoque directo de Kanban funcionará mucho mejor para usted. Al admitir un servicio en vivo, cuando necesita hacer un cambio, a menudo es algo que debe cambiarse "ayer". Esperar al próximo sprint para agregarlo a la cartera de pedidos no va a ser suficiente.
¿Por qué Kanban? - Kanban no tiene iteraciones. El trabajo está controlado por el trabajo en curso o "WIP". - Kanban no tiene una reunión de planificación establecida. Se planifica como se necesita. - Kanban todavía tiene una acumulación ordenada por rango. - Se pueden agregar nuevos elementos a la cartera de pedidos en cualquier momento y se pueden agregar al final de la cola, lo que permite que los problemas urgentes tengan prioridad. - El trabajo es controlado por el WIP. Si tiene seis desarrolladores, entonces su columna "Haciendo" probablemente no debería tener un WIP de más de 3. Esto controla el tiempo de su ciclo y asegura que los problemas se solucionen rápidamente.
Algunas notas: - Todavía es importante practicar una buena creación de historias de usuario, incluso en artículos urgentes. Asegurarse de revisar las pruebas de aceptación en detalle puede marcar la diferencia entre corregir un error una vez o corregirlo tres veces. - Practicar buenas prácticas de XP como TDD te ayudará mucho. Acortará los tiempos de ciclo, reducirá el retrabajo y mejorará la calidad.
¿Cuál sería la mejor manera de administrar este equipo para que la carga esté nivelada en todos los recursos, trabajemos a un ritmo sostenible y tengamos un objetivo algo definido para guiar nuestros esfuerzos de desarrollo?
Si yo fuera usted, comenzaría con la siguiente propuesta de hombre de paja y la refinaría a partir de ahí:
Aproximadamente la mitad del equipo trabaja en la mayoría de las aplicaciones, que son estables y no tienen un propietario del producto ni una hoja de ruta real, excepto las correcciones de producción o las mejoras que el equipo presenta internamente.
Para el equipo que realiza el trabajo de mantenimiento, Kanban encaja mejor. Es posible que necesite los siguientes estados:
Y puede considerar 3 carriles de natación de la siguiente manera:
La otra mitad trabaja en una o dos aplicaciones que se ven muy afectadas y requieren modificaciones cuando la empresa lanza un nuevo producto cada pocos meses. Esas una o dos aplicaciones también tienen correcciones de producción y mejoras que el equipo presenta internamente.
Para el equipo que realiza principalmente trabajo de desarrollo, es probable que Scrum sea una mejor opción.
Puede designar a una persona como Scrum Master y a otra persona como Product Owner. Estos no necesitan ser roles de tiempo completo. Este Scrum Master también puede administrar el Tablero Kanban, ayudar a establecer límites WIP, hacer ajustes basados en el Diagrama de flujo acumulativo y también ayudar a resolver impedimentos para el otro equipo.
Si el tamaño de este equipo Scrum excede el límite de la Guía Scrum (consulte el extracto relevante a continuación), considere dividirlo en dos equipos.
Trate de mantener los equipos relativamente estables porque los equipos tardan en consolidarse y volverse productivos. Sin embargo, puede realizar ajustes ocasionales en función de la carga de trabajo proyectada.
Hay algunos aspectos en su situación que debe considerar antes de decidir cuál es el mejor proceso para su situación:
Dijo que no tiene propietarios de productos identificados y una visión a largo plazo para las aplicaciones. Debe crear una visión y un plan para la aplicación, ya sea que use un método ágil o en cascada para administrar el desarrollo; debe trabajar con las partes interesadas, especialmente el patrocinador, para identificar a los propietarios del producto y definir el plan. En scrum, al ser un proceso iterativo, debe definir en detalle al menos suficientes características para que el equipo trabaje en ellas durante el próximo sprint. También debe tener una serie de funciones vagamente definidas para futuros sprints.
Usted indicó que tiene un equipo de 20 personas. El tamaño óptimo de un equipo de desarrollo de Scrum es de 3 a 9 personas. Si elige usar scrum, debe considerar crear múltiples equipos de escoria que podrían trabajar en aplicaciones separadas o características separadas del trabajo pendiente.
El equipo de desarrollo de Scrum debe realizar pruebas de las funciones completas durante el sprint y corregir cualquier defecto antes de que se lancen las iteraciones de la aplicación al final del sprint. Sin embargo, para los defectos defectuosos después de que se lanza la iteración del sprint, debe trabajar con el propietario del producto para determinar si el defecto se puede agregar al sprint actual o futuro, o si el defecto es lo suficientemente crítico como para necesitar una resolución inmediata, que puede suele ser el caso. Para estos defectos urgentes, necesitaría un proceso diferente, fuera del estricto proceso Scrum, para manejar los defectos urgentes. Kanban puede ser una buena opción para correcciones de errores urgentes y para realizar una evaluación de los defectos detectados después del lanzamiento de la iteración. Puede dedicar algunos recursos para centrarse en estos defectos,
La diferencia entre Kanban y Scrum es que Kanban es un proceso de 'atracción' de flujo continuo, y Scrum es en realidad un híbrido entre un proceso de 'atracción' y uno de 'empuje'. Un proceso de 'atracción' completamente impulsado por la demanda y, por lo tanto, un proceso de 'atracción', como tal Kanban, es excelente para las solicitudes de servicio al cliente donde el tiempo de respuesta es primordial.
pedro