Scrum Software Development

Software Entwicklung Scrum

Das Scrum ist ein Prozessmodell des Projekt- und Produktmanagements, insbesondere für die agile Softwareentwicklung. Mit Agile Software Development with Scrum hat Mike Beedle das erste Buch über Scrum veröffentlicht. Erfahrungsaustausch für alle, die sich für das Thema Lean / Agile Softwareentwicklung interessieren. Um in dieser flexiblen Umgebung schnell Lösungen anbieten zu können, haben viele Unternehmen agile Softwareentwicklungsprozesse wie Scrum eingeführt. Wendig und schlanke Softwareentwicklung in Ihrem Unternehmen.

mw-headline" id="Geschichte_und_und_Grundlegendes">Geschichte und Grundlegendes_span class="mw-editsection-bracket">[[Editieren | /span>Quelltext bearbeiten]>

Für das Van-Modell s. Autozam Scrum. Bei Scrum gibt es nur wenige Spielregeln. Diese sind im so genannten Agilen Atlas (für den Core, d.h. die Grundlagen) oder im (detaillierteren) Scrum Guide dargestellt. 4 ][5] Das Scrum-Framework muss durch Methoden zur Implementierung von Tätigkeiten, Artefakten und Funktionen präzisiert werden, um Scrum auch wirklich implementieren zu können.

Das Herzstück von Scrum wurde von den Implementierungstechniken abgetrennt, um zum einen die wesentlichen Handlungselemente und -mechanismen eindeutig zu bestimmen und zum anderen große Freiräume in der Gestaltung zu haben. Mit Scrum wird die Aufgabenstellung nicht vereinfacht, sondern in kleine und weniger komplizierte Komponenten, die inkrementiert. Funktionsfähige Software ist wichtig als eine umfangreiche Dokumentierung.

Um Scrum als Management Framework zu begreifen, haben mehrere Autorinnen und Autoren gefordert, weitere Funktionen aufzunehmen. 24 ] Da Scrum sich auf das Projektteam konzentriert und kein Management Framework ist, sind diese Aufgaben nicht im Scrum Framework enthalten. Bei grösseren Abteilungen und mehreren Gruppen gibt es besondere Rahmenbedingungen wie das Scaled Agile Framework.

25 oder Large Scale Scrum[26] Diese Rahmen legen zusätzliche Funktionen fest, die in großen agile Entwicklungsunternehmen vonnöten sind. Der Produktmanager berät sich regelmässig mit den Interessengruppen, um deren Anforderungen und Wünschen zu ergründen. Weitere Aufgabe eines Entwicklerteams ist es, den Umfang der Eintragungen im Produktrückstand (in der Produktrückstandsverfeinerung) abzuschätzen.

Zusätzlich zerlegt das Entwicklerteam in der Sprint-Planung die für einen Sprint selektierten Beiträge aus dem Produkt-Backlog in Aufgaben, deren Abarbeitung in der Regel weniger als einen Tag in Anspruch nimmt. Die Folge ist der Sprint Backlog. Stakeholders sind Aufgaben außerhalb von Scrum. Der Produkteigentümer hat die Pflicht, seine Kundschaft durch die Auslieferung des gewünschten Produktes zu inspirieren.

Daher sollten Produktbesitzer und Kunde für die gesamte Projektlaufzeit in engem Kontakt sein. 37] Vor Entwicklungsbeginn sollte der Produkteigentümer die Wünsche seiner Abnehmer so genau wie möglich verstehen. Bei Scrum sprechen wir über Events oder Aktionen anstelle von Besprechungen, um deutlich zu machen, dass es sich dabei um Arbeiten handeln muss.

Sämtliche Tätigkeiten von Scrum haben festgelegte Zeiträume ( "Timeboxen"), die nicht überschreitet werden sollten. Die im Produktrückstand erfassten Eigenschaften des Produkts präsentiert der Produktverantwortliche dem Entwicklerteam in der vorher festgelegten Rangfolge. Der Produktrückstand sollte im Sprint in der Produktrückstandsverfeinerung so aufbereitet worden sein, dass er bestellt, befüllt und die Eingaben für den folgenden Sprint abgeschätzt werden.

Im ersten Teil der Planungen erarbeitet das ganze Scrum-Team ein einheitliches Bild von der im Sprint zu leistenden Leistung. Darüber hinaus stimmt der Produkteigentümer mit dem Entwicklerteam die Entscheidungskriterien ab, die am Ende des Laufs darüber entscheidet, ob die neue Funktion bereit ist oder nicht; s. Done.

Dies wird vom Entwickler-Team geplant, wodurch der Produkteigentümer für Rückfragen erreichbar sein sollte. Das Resultat ist der Rückstand im Sprint: der Detailplan für den kommenden Lauf. Am Anfang eines jeden Arbeitstags treffen sich die Entwickler zu einem max. 15-minütigen täglichen Scrum, bei dem Scrum Master und Produktverantwortliche oft präsent, aber nicht involviert sind, wenn sie nicht selbst Backlog-Elemente aufbereiten.

Das Daily Scrum dient dem Austausch von Informationen. Das Daily Scrum löst keine Aufgaben - es geht darum, sich einen Eindruck über den Status der Arbeiten zu machen. Es ist bewiesen, dass jedes Team-Mitglied mit Unterstützung des Task Boards sagt, was er seit dem vergangenen täglichen Scrum geleistet hat, was er mit dem folgenden täglichen Scrum erzielen will und was ihm im Weg steht.

Mit dem Daily Scrum kann deutlich werden, dass die Durchführung einer Maßnahme mehr Zeit in Anspruch nimmt als erwünscht. Resultat des Sprint-Reviews ist das vom Produkteigentümer vermerkte Feed-back der Beteiligten. Diese Informationen sind notwendig für die weitere Auslegung des Produkt-Backlogs in der Nachbearbeitung. Der Produkteigentümer hat die Pflicht, die entstandenen Funktionen zu prüfen.

Die unfertigen User Storys werden in diesem Falle wieder in den Produktrückstand zurückgeführt und vom Produkteigentümer umpriorisiert. Die Verfeinerung des Produktstaus sollte nicht mehr als 10% der Zeit des Entwicklerteams in Anspruch nehmen. 10. Der Produktrückstand ist nicht komplett und hat keinen Anspruch auf Vollständigkeit.

60 ] Diese Abhängigkeit wird auch als Requirements Traceability genannt und als Abfallprodukt in dem Tool, das den Produktrückstand managt ( "Issue Tracker"), mitgeschrieben. Im Produktrückstau sollten die Forderungen nicht technischer, sondern funktionaler und anwenderorientierter Natur sein. Der Sprintrückstand ist der derzeitige Arbeitsplan für einen Spurt.

Der Sprintstau wird von den Teammitgliedern nach Abschluss einer (Teil-)Aufgabe fortlaufend aufbereitet. Das Herzstück von Scrum ist die Übersicht über den Produktfortschritt und den Sprint - innerhalb und außerhalb des Unternehmens. 63] Im Zentrum von Scrum steht keine spezielle Technologie für die transparente Darstellung des Vorgangs.

Der Begriff Done ( "Definition of Done") ist ein gängiges Konzept des Scrum-Teams, unter welchen Voraussetzungen eine Aufgabe als beendet beschrieben werden kann. Durch die zunehmende Erfahrungen des Scrum-Teams wächst die Bedeutung von Done. Folgende Verfahren werden oft in Zusammenhang mit Scrum eingesetzt. Sie sind nicht Teil des Kerns von Scrum, und es gibt mehrere Möglichkeiten zu allen anderen.

Wie, d.h. die technische Realisierung einer User-Geschichte, gehört in die Sprintplanung und wird nicht im Produkt-Backlog, sondern im Task-Board mit Unterstützung der Einzelaufgaben erfasst. Es zeigt zu jedem Zeitpunkt an, welche Produktrückstände für den Sprint selektiert wurden, welche Maßnahmen bearbeitet werden sollen und in welchem Bearbeitungsstatus sich diese Maßnahmen befinden.

Unter der ersten Rubrik Requirements finden Sie die vom Entwicklerteam für diesen Sprint ausgewählten Produktrückstände - in der vom Produktverantwortlichen festgelegten Rangfolge. Die Produktbesitzerin führt die zu schätzende Anwendergeschichte ein. Im Gespräch mit dem Produkteigentümer erläutert das Projektteam seine Fragestellungen zur Geschichte.

Der Hindernisstau ist eine Methode, mit der der Scrum Master alle Arbeitshindernisse aufnimmt. Die Entwicklungsmannschaft bringt den Sprint Burndown im Daily Scrum auf den neuesten Stand. Der Scrum Guide [5] schreibt zwar die wesentlichen Bestandteile von Scrum vor, aber viele Firmen weichen offenbar deutlich davon ab. So wenig wie andere Verfahren und Prozessmodelle kann Scrum eine Garantie für den Erfolg sein.

Beim Einsatz von Scrum muss man darauf vorbereitet sein, dass die Originalbewertungen dauerhaft über- oder unterschritten werden. Bei Scrum werden vom ersten Tag an die Abweichung vom Sollzustand angezeigt. Wie Scrum zu einer schnellen, guten, kostengünstigen oder hochwertigen Produktentwicklung beiträgt, ist davon abhängig, wie das Scrum Team die erworbenen Kenntnisse einsetzt.

Ein " Idiotenteam " kann laut Swaber auch zu Scrum gehören. 75 ] Das Projektteam sorgt am Ende eines jeden Laufs für zuverlässige Produktzuwächse, führt alle Besprechungen durch und teilt die Aufgaben an Scrum aus. Aber wenn das Ergebnis vom Projektteam nicht genutzt wird, um anders zu funktionieren und Änderungen durchzuführen, wird das Projekt nicht besser oder früher fertiggestellt.

Bei Scrum müssen alle Mitarbeiter in der Lage sein, eine Vielzahl von Aufgabenstellungen in einem Sprint zu erledigen. Wer sich ausschließlich als Prüfer, Entwickler oder Architekten versteht, fügt sich laut Scrum nicht perfekt in ein Entwicklerteam ein.

Scrum - kurz gesagt: Rolf Dräther, Holger Koschek und Carsten Sahling. Ausgabe. 1. wibas, Darmstadt 2014, ISBN 978-3-9815837-5-5. Boris Gloger: Scrum Produkte sicher und rasch weiterentwickeln. Der Hanser Verlagshaus, 2011, ISBN 978-3-446-42524-8 Boris Gloger: Scrum: Der paradigmatische Wandel im Projekt- und Warenmanagement. Hengstler: Konzeption der Service- und Vertragsbeziehungen für Scrum-Projekte.

2012, S. 113-116 Holger Koschek: Stories of Scrum: Of Sprints, Retrospectives and Agile Values. 2009, ISBN 978-3-89864-640-6. Sven Röpstorff, Robert Wiechmann: Scrum in der Praxis: Erlebnisse, Problembereiche und Erfolgfaktoren. 2012, ISBN 978-3-89864-792-2. Ken Schwaber: Scrum Development Process, Advanced Development Methods. Ken Schwaber: Agiles Projekt-Management mit Scrum.

Microsofts Presse Deutschland, 2007, ISBN 978-3-86645-631-0 (Englisch: Agiles Projektmanagement mit Scrum. Scrum in der Firma. Mit der ISBN 978-3-86645-643-3 (englisch: The Enterprise and Scrum.). Kenner von Sutherland: Software in 30 Tagen. Dorthin. Verlagsnummer 2013, ISBN 978-3-86490-074-7 (Deutsch: Software in 30 Tagen.). Mary Poppendieck, Tom Poppendieck: Schlanke Softwareentwicklung: Zum agilen Toolkit.

The Ultimate Scrum Guide 2.0. Die Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, S. 50-51. The Agiles Atlas - Core Scrum - Improuv verweist auf ein 12-seitiges PDF ( 120 KB); übersetzt vom Jänner 2013; Zugriff am 25. 12. 2016. - ? Die Scrum Guide. scrum. org, July 2016, S. 6 (von 19), Zugriff am 25. 12. 1. 2016 (PDF).

The Ultimate Scrum Guide. mwibas, Darmstadt 2014, S. 112-113. ? Boris Gloger: Scrum. Der Hanser Verlagshaus, München 2011, S. 12. Ken Schwaber, Jeff Sutherland: Der Scrum Leitfaden. S. 6. Dean Leffingwell: Agiles Software-Anforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen (Agile Softwareentwicklung).

Addison-Wesley, Boston 2010. ? Larman Bas Vodde: Schlanke und agile Entwicklungsskalierung : Entwicklung großer, standortübergreifender und Offshore-Produkte mit großem Scrum. Addison-Wesley, Boston 2010. Das neue Produktentwicklungsspiel. 1998. Jeff Sutherland. Zurückgeholt am 22. Okt. 2011 ? Boris Gloger: Scrum.

Der Hanser Verlagshaus, München 2011, S. 19. ? aus Wie ist Scrum entstanden? Zurückgeholt September 2011. Ken Schwaber: Scrum im Unternehemen. Universität Oxford, 2008, S. 215-216. ? Boris Gloger: Scrum. Der Hanser Verlagshaus, München 2011, S. 27-30. Scrum Alliance: Agiler Atlas. U2012. 12. 13, S. 4-6. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide.

S. 4?6. ? Boris Gloger, Scrum - Zuverlässige und schnelle Produktentwicklung, Hanser, 4th edition, 2013. in Englisch. Dean Leffingwell: Agiles Software-Anforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen (Agile Softwareentwicklung). Addison-Wesley, Boston 2010. ? Larman, Bas Vodde: Schlanke und flexible Skalierungsmethoden für die Entwicklung : Entwicklung großer, standortübergreifender und Offshore-Produkte mit großem Scrum.

Addison-Wesley, Boston 2010. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide. Zurückgeholt von der Scrum Alliance am 23. Mai 2014, S. 5. Scrum Alliance: Agiler Atlas. S. 4. ? Boris Gloger: Scrum. Der Hanser Verlag, Munich 2011, p. 78-87. - ? Römer Pichler: Scrum - Agiles Projektmanagement erfolgreich einsetzen. d. Punktverlag, Heidelberg 2009, p. 10-13. ? Roman Pichler: Scrum - Agiles Projektmanagement erfolgreich einsetzen. d. punkt Verlag, Heidelberg 2009, p. 15. ? Scrum Alliance: Agile Atlas.

S: Scrum - Agiles Projekt-Management mit Erfolg nutzen. d. Punktverlag, Heidelberg 2009, S. 20-23: S: Scrum - S: Scrum - mit Erfolg. xxxx: Scrum: Scrum: Scrum: Pichler: Scrum: Scrum: Managen: Pichler: Malte Foegen: The Ultimate Scrum Guide 2.0. Die Ultimate Scrum Guide 2.0. wibas, 2014, S. 62-65. ? Boris Gloger: Scrum. Der Hanser Verlagshaus, München 2011, S. 88-101. ? Boris Gloger: Scrum. Der Hanser Verlagshaus, München 2011, S. 101-103. Scrum Alliance: Agiler Atlas.

S. 10. ? Boris Gloger: Scrum. Ken Schwaber, Jeff Sutherland: The Scrum Guide. Scrum Alliance: Agiler Atlas. S. 3. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide. Ken Schwaber, Jeff Sutherland: The Scrum Guide. Ken Schwaber, Jeff Sutherland: The Scrum Guide.

Die Scrum Alliance: Agiler Atlas. Eine Änderung für Scrum. Zugriff am 18. Jänner 2013. , ? Scrum. Erfolgreiches agiles Projekt-Management umsetzen. dpunkt. Verlagshaus, Heidelberg 2009, S. 104-107. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide. Seite 11. Scrum Alliance: Agiler Atlas.

S. 10-11. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide. Seite 11-12. Scrum Alliance: Agiler Atlas. The Ultimate Scrum Guide 2.0. Die Scrum Anleitung, Darmstadt 2014, S. 140-141. ? Ken Schwaber, Jeff Sutherland: The Scrum Guide. Seite 13. Scrum Alliance: Agiler Atlas.

The Ultimate Scrum Guide 2.0, Darmstadt 2014, S. 92-93 und 96-97. Ken Schwaber, Jeff Sutherland: Der Scrum Leitfaden. S. 12?13. ? Scrum Allianz: Wendiger Atlas. V 2012.12. 13, S. 6. ? Patrik Rempel, Patrik Mäder: Schätzung des Risikos der Umsetzung von Anforderungen in agilen Softwareentwicklungsprojekten mit Traceability-Metriken.

In : Ingénierie : Software Quality Foundation (= Computer-Kursnotizen). Scrum Alliance: Agiler Atlas. Scrum Alliance: Agiler Atlas. Scrum Alliance: Agiler Atlas. s: v 2012.12. 13, s. 9-10: e. V. Scrum - Agiles Projekt-Management mit Erfolg nutzen. d. Punktausgabe, Heidelberg 2009, s. 46-47. e: e: e: e. V. S: e.V. S. 9-10. de: e. V. 11: e. V. Malte Fügen: e.V:

Ultimativer Scrum Guide 2.0. in Darmstadt 2014, p. 104-105. Seite 11 von 14. November 2010 Rom ans Pichler: Scrum - Using Scrum - Agiles project management successfully. d. Punktverlag, Heidelberg 2009, p. 46-47. ? Boris Gloger: Scrum. Der Hanser Verlagshaus, München 2011, S. 167-169. Mike Cohn: Agiles Schätzen und Planen. Die Prentice Hall, 2005, ISBN 0-13-147941-5. abc Scrum Effort Estimations - Planning Poker, The International Scrum Institute, wurde am Dienstag, den 22. Januar 2015 aufgerufen. ? Esther Derby, Diana Larsen: Agile Retrospectives: Making Good Teams Great.

The Ultimate Scrum Guide 2.0. Die ultimativen Scrum-Guides, Darmstadt 2014, S. 148-151. elib. uni-stuttgart. de: Das sind die Unterschiede in der Verwendung von Nahkampf? Ken Schwaber: Scrum et al. (Minute 14) Retrieved December 2011. Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: Der wendige Festpreis: Wegweiser für wirklich gelungene IT-Projektverträge.

Der Carl Hanser Verlagshaus, 2012, ISBN 978-3-446-43226-0. SCRUM Anwendergruppe Deutschland: Schulung & Zertifizierungen. Im: scrum-usergroup.de. Zurückgeholt Dezember 2016. PRINCE2 Agiles Training. Abholung am 13. Juni 2016. ? borsgloger consulting: borsgloger consulting Schulungen. borsgloger consulting: borsgloger consulting, abrufen am 24. August 2018. borsgloger consulting: borsgloger consulting Produktverantwortliche Schulungen.

borsgloger consulting, aufgerufen am 24. Mai 2018. - ? borsgloger consulting: borsgloger consulting Kombitrainings. borsgloger consulting, aufgerufen am 24. Mai 2018. EXIN: EXIN Agiles Scrum. EXIN, aufgerufen am 16. Mai 2017. ? TÜV SÜD: Scrum - Agile Projektleitung. Zurückgeholt per 31. Mai 2016. pmi. org Zurückgeholt am 21. Mai 2015. abc Zertifizierungen in Scrum, Webseite der Scrum Alliance, zurückgeholt am 22. Oktober 2014. Scrum. org, Assessments & Zertifizierungen, zurückgeholt am 17. Mai 2014.

Mehr zum Thema