¿Qué tan grande es demasiado grande para XP/SCRUM?

Question

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.?

Answer 1

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.

Answer 2

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.

Donde tiene una especificación escrita y una estructura más formal (vea Painless Functional Specification para una discusión sobre documentos de especificaciones) la comunicación está más cerca de un modelo hub-and-spoke, que tiene más O (N) canales (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 el PFS artículos Joel (sí, que Joel) analiza el papel de un Programme Manager, 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.

Answer 3

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.

Answer 4

Scrum se puede escalar utilizando "Scrum of Scrums".

de la Alianza Scrum viene esta advice en la realización de las reuniones de Scrum Scrums:

El scrum de reunión scrum es una técnica importante en la ampliación de Scrum a grandes equipos de proyecto. 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 discuss este problema.

Answer 5

Escalas ágiles bien. No es una ciencia espacial. De hecho, se trata de modularidad.El desarrollo de software es CAS (Complex Adaptive System) y, como casi cualquier CAS, tiene módulos para regular 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 funcionen 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.

Answer 6

Eche un vistazo a this blog post por Bernie Thompson.

Describe muchos de los problemas y las desventajas que se encontró al ampliar Scrum/XP en Microsoft, y tiene algunas soluciones muy interesantes.

Hay otras publicaciones en el mismo blog que también tratan sobre estos problemas de escala que le preocupan: IMO es una mina de oro con ideas sobre "agilidad para adultos".

Answer 7

El scrum de escalamiento o cualquier enfoque ágil depende de su entorno.

Si tiene múltiples proyectos con varios 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 (yo tenía 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.