architecture - ¿Qué tan grande es demasiado grande para XP/SCRUM?
process agile (7)
En las primeras etapas de planificación del desarrollo de un nuevo sistema, el modelo de desarrollo a seguir parece primordial. Siempre he mantenido la creencia de que una cascada clásica (o cascada híbrida / prototipos iterativos) es el mejor enfoque para proyectos de medianos a grandes. Parece que una vez que un proyecto llega a tener un determinado tamaño, los paradigmas Agile / XP / Scrum no pueden dar cuenta de los requisitos complejos, un equipo grande, las complejidades entre múltiples subsistemas, la necesidad de documentación, cambios de personal, etc. etc.
¿Cuál es el límite de tales metodologías ágiles en términos de tamaño del sistema, tamaño del equipo, LOC, etc.?
Dentro de un equipo, los canales de comunicación son proporcionales a (N * N-1) / 2 como un límite superior, por lo que podrían verse libremente como O (N ^ 2). La naturaleza descentralizada de los equipos ágiles significa que no existe un punto central de referencia y que la comunicación crecerá más cerca del límite superior que si existiera dicho punto de referencia.
Cuando tenga una especificación escrita y una estructura más formal (consulte la Especificación funcional sin dolor para una discusión de los documentos de especificaciones), la comunicación está más cerca de un modelo de cubo y radio, que tiene canales O (N) más cercanos (para N personal en el proyecto). La mayoría de los comentarios sobre reglas generales que he visto ubican a los equipos ágiles en 6 o menos y el límite superior en alrededor de 10, aunque su kilometraje puede variar.
En los artículos de PFS, Joel (sí, ese Joel) discute el papel de un Administrador de Programas , cuya función es desarrollar y poseer la especificación. La serie de especificaciones funcionales sin dolor entra en esto con bastante detalle y también es bastante accesible para la administración no técnica. He referido a algunas personas a este artículo.
No creo que haya un límite, después de que todas las ideas de scrum surgieron de la fabricación de automóviles y eso es bastante grande en términos de personas. Lo importante de los grandes proyectos es que debes comenzar con un equipo pequeño y crecer con el tiempo. Mantenga equipos separados que interactúen a través de Scrum of Scrums y se escalará; si la gente está dispuesta a colaborar, funcionará. Es como siempre en nuestro negocio: dividir y conquistar. Divide el gran problema en trozos manejables más pequeños.
Picture Scrum / XP como una serie de mini-Cascadas. Inicialmente, desea hacer un esfuerzo inicial para obtener una buena cartera de trabajo bien definida. No necesariamente todo el sistema, yo diría que una vez que obtenga uno o dos sprints por valor de artículos atrasados de productos, es hora de comenzar a correr. Al mismo tiempo que el sprint, debería crear PBI adicionales (y volver a priorizarlos adecuadamente).
La idea es que pueda obtener el valor comercial entregado antes de que el sistema esté COMPLETAMENTE definido.
Scrum se puede escalar usando "Scrum of Scrums".
De la alianza Scrum surge este consejo sobre la realización de reuniones de Scrum of Scrums:
La reunión de scrum of scrums es una técnica importante para escalar Scrum a grandes equipos de proyectos. Estas reuniones permiten que los grupos de equipos discutan su trabajo, centrándose especialmente en las áreas de superposición e integración.
El libro Agile and Iterative Development también analiza este tema.
Echa un vistazo a esta publicación de blog de Bernie Thompson.
Describe muchos de los problemas y las compensaciones con las que se topó al escalar Scrum / XP en Microsoft, y tiene algunas soluciones muy interesantes.
Hay otras publicaciones en el mismo blog que también se ocupan de estos temas de escala que le preocupan: IMO es una mina de oro de ideas sobre "ágil para adultos".
Escalas ágiles bien. No es una ciencia de cohetes. De hecho, se trata de modularidad . El desarrollo de software es CAS (Complex Adaptive System) y, como casi cualquier CAS, tiene módulos para controlar mejor la complejidad . Scrum of Scrums es uno de los posibles enfoques modulares para escalar el proceso de desarrollo. Las divisiones funcionales (Desarrolladores, QA, etc.) es otro enfoque modular. El peor caso es cuando no tienes módulos en absoluto en un proyecto grande.
Dependiendo de la naturaleza del proyecto, el equipo puede decidir qué módulos funcionarán para el proyecto. El patrón general es formar varios equipos que trabajen en algunos módulos de baja cohesión . Cada equipo debe ser bastante autónomo, pero la interacción con otros equipos debe ser buena.
La analogía de CAS es un cuerpo humano, por ejemplo. Tenemos órganos como corazón e hígado. Son módulos separados (equipos de células :) que interactúan a través del sistema nervioso / sangre / etc.
El scrum de escalamiento o cualquier enfoque ágil depende de su entorno.
Si tiene múltiples proyectos con múltiples equipos, escalar es simplemente compartir las mejores prácticas entre los equipos. Tan pronto como empiece a requerir integración entre sistemas / proyectos, tenga cuidado. Una mayor integración entre los equipos es preferible en ese punto.
Si tiene un proyecto grande (tuve un equipo de 45 en un punto), existen diferentes enfoques para escalar. Elegimos mantener un equipo con varias versiones en standups: desarrolladores independientes separados de BA / QA standup. El gerente de iteración asistió a ambos y al menos uno de cada lado asistió al otro. Tuvimos un muro de cartas, pero incluía elementos previos a la iteración (historias en proceso de análisis, errores de producción para perseguir) y cosas posteriores a la iteración (trabajo de lanzamiento / implementación).
También he sido parte de un proyecto muy grande con muchos equipos de scrum (~ 20 equipos, algunos distribuidos, que van de 10 a 20 miembros cada uno). Cada uno tenía peleas por separado, y había un scrum de scrums e incluso un scrum de scrum de scrums. Creo que cometimos un error al segmentar los equipos por área funcional en lugar de flujos de trabajo. Nuestra segmentación creó silos de propiedad del código con problemas de administración de integración onerosos entre equipos.
En resumen, no se trata solo del tamaño para escalar ... también se trata del contenido del proyecto. Siéntase libre de compartir más detalles sobre su entorno para escuchar enfoques más específicos para abordar la escala en su entorno.