Wie groß ist zu groß für XP/SCRUM?

Question

In den frühesten Phasen der Planung der Entwicklung eines neuen Systems, welches Entwicklungsmodell zu folgen scheint vorrangig. Ich habe immer an der Überzeugung festgehalten, dass ein klassischer Wasserfall (oder hybrider Wasserfall/iteratives Prototyping) der beste Ansatz für mittlere bis große Projekte ist. Es scheint, dass, sobald ein Projekt eine bestimmte Größe erreicht, die Agile/XP/Scrum-Paradigmen komplexe Anforderungen, ein großes Team, die Komplexität zwischen mehreren Subsystemen, den Bedarf an Dokumentation, personelle Veränderungen usw. nicht berücksichtigen können. etc.

Was ist die Grenze solcher agilen Methoden in Bezug auf Systemgröße, Teamgröße, LOC, etc?

Answer 1

Ich glaube nicht, dass es eine Grenze gibt, nachdem all die Ideen von Scrum aus der Automobilproduktion kamen und das ist ziemlich groß in Bezug auf Menschen. Die Sache mit großen Projekten ist, dass Sie mit einem kleinen Team beginnen und es im Laufe der Zeit wachsen müssen. Halten Sie separate Teams, die über Scrum of Scrum interagieren und es wird skaliert, wenn die Leute bereit sind zusammenzuarbeiten, wird es funktionieren. Es ist wie immer in unserem Geschäft: teile und herrsche. Brechen Sie das große, schwere Problem in kleinere, überschaubare Brocken.

Answer 2

Innerhalb eines Teams sind die Kommunikationskanäle proportional zu (N * N-1)/2 als Obergrenze und könnten daher als O (N^2) betrachtet werden. Der dezentrale Charakter agiler Teams bedeutet, dass es keinen zentralen Bezugspunkt gibt und die Kommunikation näher an die Obergrenze herankommt, als wenn es einen solchen Bezugspunkt gäbe.

Wo Sie eine schriftliche Spezifikation und eine formellere Struktur haben (siehe Painless Functional Specification für eine Diskussion von Spezifikationsdokumenten), ist die Kommunikation näher an einem Hub-and-Spoke-Modell, das näher an O (N) -Kanäle (für N Mitarbeiter des Projekts). Der Großteil der Faustregeln, die ich gesehen habe, legt den Schwerpunkt für Agile-Teams auf 6 oder weniger und die Obergrenze auf etwa 10, obwohl die Laufleistung variieren kann.

In den PFS Artikeln Joel (ja, dass Joel) diskutiert die Rolle eines Programme Manager, dessen Rolle ist es, die Spezifikation zu entwickeln und zu besitzen. Die Serie "Painless Functional Specifications" geht hier ausführlich auf und ist auch für nichttechnisches Management zugänglich. Ich habe einige Leute auf diesen Artikel hingewiesen.

Answer 3

Bild Scrum/XP als eine Reihe von Mini-Wasserfälle. Zunächst möchten Sie im Voraus versuchen, einen guten, gut definierten Rückstand zu erhalten. Nicht unbedingt das ganze System, würde ich argumentieren, dass es Zeit ist, Sprints zu beginnen, sobald Sie ein oder zwei Sprints im Wert von Product Backlog Items haben. Gleichzeitig mit dem Sprint sollten Sie zusätzliche PBIs erstellen (und diese entsprechend neu priorisieren).

Die Idee ist, dass Sie den Geschäftswert erhalten können, bevor das System vollständig definiert ist.

Answer 4

Scrum kann mit "Scrum of Scrums" skaliert werden.

Von der Scrum Alliance kommt diesen advice auf Scrum von Scrums Treffen der Durchführung:

Das Gedränge von Scrums Treffen ist eine wichtige Technik Scrum zu großen Projektteams bei der Skalierung. Diese Treffen ermöglichen es Gruppen von Teams, ihre Arbeit zu diskutieren, wobei sie sich insbesondere auf Überlappungs- und Integrationsbereiche konzentrieren.

Das Buch Agile und Iterative Entwicklung auch discuss dieser Ausgabe.

Answer 5

Agile Skalen fein. Es ist keine Raketenwissenschaft. Tatsächlich handelt es sich um Modularität.Software-Entwicklung ist ein CAS (Complex Adaptive System) und, wie fast jedes CAS, hat es Module, um die Komplexität besser zu beherrschen. Scrum of Scrums ist einer der möglichen modularen Ansätze für die Skalierung von Entwicklungsprozessen. Funktionelle Abteilungen (Entwickler, Qualitätssicherung usw.) sind ein weiterer modularer Ansatz. Der schlimmste Fall ist, wenn Sie in einem großen Projekt überhaupt keine Module haben.

Je nach Projekttyp kann das Team entscheiden, welche Module für das Projekt verwendet werden. Allgemeines Muster besteht darin, mehrere Teams zu bilden, die an einigen Modulen mit niedriger Kohäsion arbeiten. Jedes Team sollte ziemlich autonom sein, aber die Interaktion mit anderen Teams sollte gut sein.

Die Analogie von CAS ist ein menschlicher Körper zum Beispiel. Wir haben Organe wie Herz und Leber. Sie sind getrennte Module (Zellenteams), die über Nervensystem/Blut/etc interagieren.

Answer 6

Schauen Sie sich this blog post von Bernie Thompson.

Es umreißt eine Menge der Probleme und Kompromisse, die er beim Skalieren von Scrum/XP bei Microsoft erfahren hat, und hat einige sehr durchdachte und interessante Lösungen.

Es gibt andere Beiträge im selben Blog, die sich auch mit diesen Problemstellungen beschäftigen, die Sie betreffen - IMO, es ist eine Goldgrube von Ideen zu "Agil für Erwachsene".

Answer 7

Die Skalierung von Scrum oder einem agilen Ansatz hängt von Ihrer Umgebung ab.

Wenn Sie mehrere Projekte mit mehreren Teams haben, können Sie bei der Skalierung einfach Best Practices zwischen Teams austauschen. Sobald Sie anfangen, die Integration zwischen Systemen/Projekten zu erfordern, seien Sie vorsichtig. Eine engere Integration zwischen Teams ist zu diesem Zeitpunkt vorzuziehen.

Wenn Sie ein großes Projekt haben (ich hatte ein Team von 45 an einem Punkt), gibt es verschiedene Ansätze zur Skalierung. Wir entschieden uns dafür, ein Team mit mehreren Standups zu halten - Entwickler Standup getrennt von BA/QA Standup. Der Iterationsmanager nahm an beiden teil, und mindestens einer von beiden Seiten besuchte den anderen. Wir hatten eine Kartenwand, aber es enthielt Pre-Iteration Zeug (Geschichten im Prozess der Analyse, Produktion Bugs zu verfolgen) und Post-Iteration Zeug (Release/Deployment Arbeit).

Ich war auch ein Teil eines sehr großen Projekts mit vielen Scrum-Teams (~ 20 Teams - einige verteilt - mit jeweils 10-20 Mitgliedern). Jeder hatte separate Standups, und es gab ein Gedränge und sogar ein Gedränge von Scrum-of-Scrums. Ich denke, wir haben einen Fehler gemacht, indem wir die Teams nach Funktionsbereichen und nicht nach Arbeitsabläufen segmentiert haben. Unsere Segmentierung hat Silos von Code-Besitzern mit schwierigen Integrationsmanagementproblemen zwischen Teams geschaffen.

In der Summe geht es nicht nur um Größe für die Skalierung ... es geht auch um den Inhalt des Projekts. Fühlen Sie sich frei, mehr Details über Ihre Umgebung zu teilen, um spezifischere Ansätze zu erfahren, wie Sie die Skalierung in Ihrer Umgebung angehen können.