Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
106 | SCRUM UND <strong>XP</strong> IM HARTEN PROJEKTALLTAG<br />
Produkt A<br />
Product Owner<br />
<strong>Scrum</strong>Team<br />
Produkt B<br />
Product Owner<br />
<strong>Scrum</strong>Team<br />
Produkt A + B<br />
Product Owner<br />
<strong>Scrum</strong>Team<br />
Berater<br />
Nun nehmen wir an, sie haben ein einzelnes <strong>Scrum</strong>-Team mit 12<br />
Mitgliedern <strong>und</strong> der Code ist zu schlecht, um zwei Teams getrennt<br />
voneinander daran arbeiten zu lassen. Um irgendwann das Team sinnvoll<br />
aufteilen zu können, stecken Sie lieber etwas Mühe in die Verbesserung<br />
des Codes, als an neuen Features zu arbeiten. Diese Investition zahlt sich<br />
sicherlich bald aus.<br />
Parallel laufende Sprints - Ja oder Nein?<br />
Angenommen, drei <strong>Scrum</strong>- Teams arbeiten am selben Produkt. Sollten<br />
ihre Sprints parallel ablaufen, also gemeinsam starten <strong>und</strong> enden? Oder<br />
sollten sie sich überlappen?<br />
Am Anfang haben wir mit zeitlich überlappenden Sprints gearbeitet.<br />
Uns hat gefallen, dass es so <strong>im</strong>mer jeweils einen Sprint gibt, der bald zu<br />
Ende geht <strong>und</strong> einen der bald startet. Außerdem wäre das Arbeitspensum<br />
des Product Owners gleichmäßig verteilt, es gäbe regelmäßig<br />
irgendwelche Releases, Vorführungen... Ach wie w<strong>und</strong>erbar!<br />
Das klang gut. Zu jedem Zeitpunkt würde es einen laufenden Sprint<br />
geben, der kurz vor dem Abschluss steht <strong>und</strong> einen neuen, der bald<br />
beginnen würde. Die Arbeitslast des Product Owners würde sich<br />
gleichmäßig über die Zeit verteilen. Das System würde kontinuierlich<br />
Releases ausspucken. Vorführungen in jeder Woche. Hallelujah.
Change language