Diskussion:Scrum

message: Dieser Artikel enthielt viele zweifelhafte Stellen. Ich habe daher den Artikel heute grundsätzlich überarbeitet, um die Darstellung mit dem aktuellen Stand der Scrum-Technik (Scrum Guide/Agile Atlas) abzugleichen. Dabei habe ich die hier in der Diskussion aufgelisteten Punkte bearbeitet:
* #Bezug zum agilen Mainfest - ist korrekt, steht auch im Agile Atlas
* #Erfahrung dass die meisten modernen Entwicklungsprojekte zu komplex sind - Begründung formuliert, warum Scrum die Komplexität besonders wirtschaftlich adressiert
* #Daily Scrums - korrekt lt. Agile Atlas & Scrum Guide: ist für das Entwicklungsteam
* #Rollen - Diese Kritik war berechtigt, Scrum kennt nur drei Rollen. Daher habe ich die Rollen auf die drei Scrum Rollen reduziert. Die anderen Rollen habe ich zur Erklärung des Begriffs Stakeholder verwendet.
* #Artefakte - Diese Kritik war berechtigt. Jetzt stehen die korrekten Artefakte im Artikel.
* #Userstory fehlt - Abschnitt "Techniken" aufgenommen und User Story hierher verschoben, zusammen mit anderen Techniken die verstreut im Artikel standen
* #Sprint Textdoppelung - Textdoppelung beseitigt, Sprint neu formuliert.
* #Sekundärliteratur in den Verweisen und #Scrum Guide vs. Gloger - Bei der Überarbeitung habe den Agile Atlas und den Scrum Guide als Referenz genommen, da sie den "Stand von Scrum" definieren. Dieser Artikel reflektiert jetzt, was in der Scrum Community als "Scrum" definiert wird.
* #Letzter Absatz über das Entwicklerteam: Interdisziplinäre Urlaubsvertretung - habe ich so gelassen, inhaltlich stimmt das, kann man bestimmt besser formulieren, war aber jetzt nicht das #1 backlog item bei mir
* Ansonsten habe ich viele weitere Stellen korrigiert (z.B. Product Owner gehört zur Retrospektive dazu, Scrum ist kein Vorgehensmodell, Scrum ist nicht nur für die Softwaretechnik, ...etc.)
--Malte Foegen (Diskussion) 15:00, 29. Jun. 2014 (CEST)
thread_title: Grundsätzliche Überarbeitung

message: Im Artikel steht: "Scrum verkörpert die Werte des Agilen Manifests, das Menschen und deren Interaktionen vor Prozesse und Werkzeuge stellt." Wie soll das denn bitte funktionieren? Scrum definiert Prozesse und Werkzeuge. Das agile Manifest sagt in diesem Zusammenhang: Scrum ist wichtig, aber die Menschen und Interaktionen sind wichtiger. Meines Erachtens ein sehr wichtiger Punkt, der beim "blinden Anwenden" von Scrum in der Praxis gerne vergessen wird. Weiter unten im Artikel werden alle 4 Punkte des A.M. aufgeführt. Auch Punkt 2 hat nicht das geringste mit Scrum zu tun. Schließlich könnte man auch die Erstellung von Dokumentation mit Scrum durchführen. Wenn keine Einwände bestehen, würde ich also diese Abschnitte entfernen, zumal keine Quellenangaben vorhanden sind. --217.24.207.26 10:52, 27. Dez. 2011 (CET)
replies: text: Dass Scrum die Werte des Agile Manifests verkörpert, dafür lassen sich jede Menge Belege finden. Einen davon habe ich jetzt als Referenz beigebracht. Das gilt auch für Dokumentation - viele der agilen Techniken, die auch in Scrum empfohle werden reduziere die Dokumentation - vergleiche nur mal eine Storymap mit einem Pflichtenheft.  Und natürlich hast du recht - in der Praxis wird Scrum oft wie Cargo-Kult betrieben - da bleibe die Werte von Scrum meist auf der Strecke. --Sebastian.Dietrich  ✉ 20:49, 31. Okt. 2013 (CET)
thread_title:  Bezug zum agilen Mainfest 

message: Scrum definiert nicht(!) sechs, sondern lediglich drei Rollen:
- Product Owner
- Scrum Master
- Team
Die in diesem Artikel weiter aufgeführten Rollen (Customer, User, Manager) sind für die Softwareentwicklung natürlich relevant, haben mit Scrum direkt aber erst mal nichts zu tun.
Auch im offiziellen Scrum Guide (http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf) werden diese Rollen nicht behandelt. (nicht signierter Beitrag von Spezial:Beiträge/Dutze (Diskussion) 13:05, 16. Aug. 2012 (CEST)
thread_title:  Rollen 

message: Die Auflistung der Artefakte ist nicht korrekt. Laut Scrum Guide existieren folgende drei Artefakte:
- Product Backlog
- Sprint Backlog
- Inkrement
Im Artikel fehlt das Artefakt "Inkrement", dafür sind folgende aufgelisteten Artefakte keine Artefakte nach Scrum-Definition:
- Definition of Done
- Impediment Backlog
- Burn Down Charts
Siehe auch Scrum Guide (http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf). (nicht signierter Beitrag von Spezial:Beiträge/Dutze (Diskussion) 13:05, 16. Aug. 2012 (CEST)
thread_title:  Artefakte 

message: Im Text wird an nicht erwähnt was "User-Stories" sind. Wenn man mit Scrum vertraut ist, weiß man das zwar, aber für jemandem, der es nichts ist, wird es auch nicht aus dem Text ersichtlich, was genau eine Userstory ist. --2A00:1398:2:8022:221:9BFF:FE58:8417 16:05, 5. Nov. 2012 (CET)
replies: text: Zur User Story gibt es ein eigenes Lemma, auf das auch verlinkt wird. Der folgende Abschnitt steht in der Einleitung und sollte m.M.n. auch ausreichend sein: Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Anforderungslisten (vgl. Lastenheft/Pflichtenheft), die dann phasenweise umgesetzt werden, sondern durch das Ausformulieren von klaren Funktionalitäten aus der Anwendersicht, die dann in zwei bis vier Wochen langen, sich wiederholenden Intervallen, sogenannten Sprints iterativ und inkrementell umgesetzt werden. Diese Anforderungen aus Anwender-Sicht werden meist als User Stories bezeichnet um Lasten-/Pflichtenhefte zu ersetzen. Das ließe sich vielleicht noch knackiger und treffender formulieren, aber viel mehr Details brauchen da eigentlich nicht rein, denk ich. --Hamburger (Disk) 16:23, 5. Nov. 2012 (CET)
thread_title:  Userstory fehlt 

message: Mal ehrlich: Wer von Euch hat nicht schon eine Idee gehabt und innert ein paar Tage oder Wochen einen Prototypen gebaut, nur um danach 3/4 des Codes zu streichen und ein super Endresultat zustandebringen? Aber wie soll so was mit Scrum noch möglich sein, wenn mir alle in den Code quatschen?? Programmieren ist kein Jekami, es ist was zwischen Mensch und Maschine, und man benötigt viel Unabhängigkeit um gute Ideen in Code umzusetzen. Scrum kann man auch in der Kaffeepause tun, sofern man ausnahmsweise mal dazu kommt. Oder meint Ihr echt, Microsoft Office 1.0 oder Google oder Facebook wären durch Scrum zustandegekommen? Also...ECHT jetzt! PS: Scrum ist weder ein Framework noch Prozess, und auch keine Datenstruktur, sondern eine Methodik ;D...meiner Meinung nach eine quälend schlechte Methodik - um nicht zu sagen "Vergewaltigung". Einwand: Für Programmieranfänger oder schlechte Programmierer ist es aber sicherlich was Gutes! --178.197.234.15 23:44, 12. Nov. 2012 (CET)
replies: text: Bitte zuerst den Artikel lesen & dann erst Senf dazu geben. Scrum != Collective Code Ownership. Deine Ansichten bezüglich Softwareentwicklung sind übrigens ziemlich veraltet. Keine größere Software wird heute noch so entwickelt wie du es dir vorstellst ("Programmieren = was zwischen Mensch und Maschine mit viel Unabhängigkeit einzelner Programmierer"). --Sebastian.Dietrich  ✉ 08:45, 13. Nov. 2012 (CET)
thread_title:  Anti-Innovative Vorgehensweise 

message: Der Text bei Sprint beschäftigt sich einen großteil mit dem ScrumMaster und daher doppeln sich die Infos bzw sogar die ganzen Abschnitte und gehören nicht in den Sprint.
--Terraloader --93.214.239.157 10:54, 20. Mär. 2013 (CET)
replies: text: Das ist an mehreren Stellen so, z.B. ein ausführlicher Vorgriff auf das Planning 1 beim Team. Ich habe mal angefangen, die Dopplungen zu entfernen.--Philipp Sªsse (Diskussion) 06:50, 18. Jan. 2014 (CET)
thread_title:  Sprint Textdoppelung 

message: In den Einzelnachweisen findet sich oft Referenzen auf ein einzelnes Buch (Boris Gloger 2011: Scrum. Produkte zuverlässig und schnell entwickeln), leider sehr wenig Verweise auf die wichtigere Primärliteratur zu dem Thema (siehe "Scrum (Development)" auf englisch). Dadurch kommt es zu einer bestimmten, einseitigen Gewichtung der Themen. Der Artikel sollte deshalb grundsätzlich überarbeitet werden und sich im Detail auf andere Quellen beziehen. --Holger.Bohlmann (Diskussion) 00:04, 30. Apr. 2013 (CEST)
thread_title:  Sekundärliteratur in den Verweisen 

message: Gibt es zu "Burndown" eine übliche / mögliche / sinnvolle Übersetzung? --Peter2 (Diskussion) 19:50, 19. Aug. 2013 (CEST)
replies: text: abbrennen/niederbrennen --217.231.22.172 16:28, 4. Jan. 2016 (CET)
thread_title:  Übersetzung von "Burndown" 

message: Auf das Thema wird in dem Artikel gar nicht eingegangen. Eine entsprechende Erweiterung für Interessierte (wie mich) ist aber wichtig. --Morphelianus (13:49, 10. Sep. 2013 (CEST)
thread_title:  Zertifizierung 

message: Im Abschnitt über das Entwicklerteam gibt es so einen philosophierenden Absatz ohne Quellen, der für mich auch nicht überall schlüssig ist. Z. B. »Und fällt jemand aus privaten Gründen für einige Zeit aus, ist ein interdisziplinär aufgestelltes Entwicklungsteam besser in der Lage, die fehlende Expertise zu kompensieren.« ist doch Quatsch. Gerade eine Vertretung ist in einem Team mit engem Fokus viel einfacher. Je mehr verschiedene Aufgaben das Team erfüllen muss (Architektur, Implementierung, Infrastruktur, Testen, Dokumentieren), desto schwieriger wird es, für jede Aufgabe auch noch einen geeigneten Vertreter zu finden. Aber da der ganze Absatz nicht nur lausig ist, sondern auch für jedes Team unabhängig von Scrum gilt, würde ich ihn einfach komplett streichen. Okay?--Philipp Sªsse (Diskussion) (07:22, 18. Jan. 2014 (CET)
replies: text: Hallo, Philipp Sªsse, "aus privaten Gründen" ist auf jeden Fall überflüssig. Ansonsten finde ich das OK: Je interdisziplinärer ein Team ist, desto eher kann einer den anderen im Team ersetzen. Natürlich hast du Recht, dass es nicht leicht ist, diese Interdisziplinarität zu erreichen. Grüße, --Schotterebene (Diskussion) 09:47, 18. Jan. 2014 (CET)
thread_title:  Letzter Absatz über das Entwicklerteam: Interdisziplinäre Urlaubsvertretung (erl.) 

message: Die Prozess-Grafik im Abschnitt "Aktivitäten" finde ich keine besonders geglückte Darstellung.
Zwei Kritikpunkte: Was zeigt sie bei einer unvoreingenommenen (nicht schon scrum-vorgebildeten) Betrachtung:
1) Erst am Schluss - ganz rechts am Prozessende dargestellt - kommt ein dickes Packet Software heraus.
2) Nach ca. Zweidritteln der 30-Tage-Wiederholungsschleife (also nach ca. 20 Tagen) findet eine 24 h Wiederholungsschleife statt (ja, ich weiß, dass dies nicht gemeint ist; die Frage ist, was ist hier dargestellt; wenn ich im Bild wiederfinden muss, was ich eh schon weiß, brauche ich keine grafische Darstellung).
--Bri B. 17:23, 25. Sep. 2014 (CEST)
thread_title:  Prozess-Grafik 

message: Insgesamt ein interessanter, umfassender Artikel, der m. E. gut die Leitgedanken und wesentlichen Elemente erklärt. Allerdings fand ich ihn etwas weitschweifig. Deshalb bin ich im Begriff, ihn zu überarbeiten:
* Streichen von Paraphrasen und Selbstverständlichkeiten. Scrum setzt auf die Intelligenz und Organisationsfähigkeit der Beteiligten, dasselbe dürfen wir auch beim Leser voraussetzen. ;-)
* Zurückstutzen von Füllwörtern und Adjektiven.
* Der Artikel schwelgt im Jargon. Das führt zu Konflikten mit den Rechtschreibregeln; besonders wimmelt es von Leerzeichen in Komposita. Ich setze die englischen Begriffe kursiv und bei den deutschen Komposita Bindestriche.
* An einingen Stellen korrigiere ich die grammatische Bezüge, Genitive und andere Kleinigkeiten.
Gruß aus Freiberg am Neckar, --Mussklprozz (Diskussion) 11:20, 20. Dez. 2014 (CET)
replies: text: Hallo Mussklprozz, ja, deine Vorschläge sind gut. Grüße, --Schotterebene (Diskussion) 11:35, 20. Dez. 2014 (CET)
thread_title:  Artikel überarbeitet 

message: Schaut mal hier:
http://de.wikipedia.org/wiki/Gedr%C3%A4nge_%28Rugby%29
Dieses Scrum gibt's schon länger. Was ist zu tun? (nicht signierter Beitrag von 193.158.100.19 (Diskussion) 13:24, 29. Apr. 2015 (CEST)
replies: text: Nichts - da es den anderen Scrum in der deutschen Sprache nicht gibt. Aber dass der Name vom Scrum aus dem englischen Wort für Gedränge (Rugby) kommt, und nicht "englisch für Gedränge" ist - hab ich mal korrigiert. --Sebastian.Dietrich  ✉ 23:24, 29. Apr. 2015 (CEST)
thread_title:  Mehrdeutigkeit des Begriffs 

message: Die IP 94.222.224.237 hat die Einleitung grundlegend geändert. Ich habs wieder zurückgesetzt (). Grundsätzlich würde die Einleitung natürlich eine Verbesserung vertragen - aber vielleicht sollte man das vorher zur Diskussion stellen. Hier der Vorschlag der IP:
Scrum ist eine softwarebasierte Arbeitsumgebung für das Projekt- und Produktmanagement. Mit bestimmten Regeln für das Lean Development (Beleg: Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit, Addison-Wesley, Upper Saddle River, 2003.)(Beleg: Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 50–51.) bildet die Software einen Vorgehensrahmen bzw. -gerüst (Framework) ab und wird daher bewusst nicht als Vorgehensmodell bezeichnet. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert. (Beleg: Malte Foegen: Der Ultimative Scrum Guide. wibas, Darmstadt 2014, S. 112–113.). Obwohl Scrum ursprünglich mit dem Focus auf die Entwicklung von Softwaretechnik entwickelt wurde, kann es auch davon unabhängig verwendet werden und wird inzwischen in vielen anderen Bereichen eingesetzt.(Beleg: Scrum Alliance: The State of Scrum, S. 10 (abgerufen am 28. Juni 2014).)
Den Vorschlag der IP halte ich aus folgenden Gründen für ungeeignet/verbessrungswürdig:
* softwarebasierte Arbeitsumgebung ist eindeutig falsch. Scrum geht auch ohne Software
* die erste Ref (Lean Software Development) ohne Seitenangabe belegt nix
* in der Einleitung bereits auf den Begriff "Framework" vs. "Vorgehensmodell" einzugehen halte ich für verfrüht
* Empirisch, inkrementell und iterativ zu nennen ist mMn gut, dann sollten die einzelnen Punkte aber auch als solche erkennbar erklärt werden (z.B. mit Bulltepoints) - so wie vorgeschlagen halte ich es für zu eine lange Wurst...
--Sebastian.Dietrich  ✉ 17:48, 15. Jun. 2015 (CEST)
thread_title:  Änderung der Einleitung 

message: Im Artikel wird der Begriff "Story Points" zweimal benutzt, ohne erklärt worden zu sein. Könnte das mal jemand vom Fach übernehmen und einfügen? Grüße, --Joschi71 (Diskussion) 13:21, 13. Okt. 2015 (CEST)
thread_title:  Story points 

message: Es gibt sehr wenige Internetquellen, die SCRUM als Abkürzung von "Software Capability Rational Unified Model" nennen. Kennt jemand eine gute Quelle, damit diese Abkürzung den Weg in den Artikel finden kann?--188.96.190.21 22:27, 21. Nov. 2016 (CET)
replies: text: Das scheinen wohl einige Begriffe durcheinander gekommen zu sein. Es gibt den gut dokumentierten RUP (Rational Unified Process), das Capability Maturity Model und Scrum (aus der agilen Softwareentwicklung). Es macht keinen Sinn diese zu vermengen und dann unter einem dem ursprünglichen Begriff gleichen Abkürzung zu verwenden. --Oliver Emmler (Diskussion) 20:43, 23. Nov. 2016 (CET)
thread_title:  SCRUM = Software Capability Rational Unified Model 

message: „Als 30-jährige Geschäftsfrau möchte ich auf dem Weg zur Arbeit nur wenig in die Pedale treten müssen, damit ich nicht verschwitzt in der Firma ankomme.“ Das ist keine Anforderung an ein Produkt, sondern eine Unzufriedenheit mit sich selbst. Die korrekte Antwort darauf lautet: „Fahren Sie mehr Fahrrad, dann schwitzen Sie auch weniger.“ Wenn das Entwicklungsteam dann noch die Zeit, die es am Schreibtisch sitzend mit dem Entwurf von Elektrofahrrädern verplempert, dazu nutzen würde, selber Fahrrad zu fahren und Fahrradtouren anzubieten, hätten alle etwas sinnvolles getan. (nicht signierter Beitrag von 92.211.58.217 (Diskussion) 10:15, 3. Mär. 2017 (CET)
thread_title:  User Story: Das Beispiel mit dem Fahrrad 

message: Wer oder was definiert eigentlich was Scrum ist? Das kommt für mich auf der Seite nicht rüber. Bis heute war ich der Meinung dass der Scrum-Guide hierzu die Referenz ist. Der steht jedoch als nur als einer von vielen Nachweisen da. Freimatz (Diskussion) 13:27, 10. Mai 2017 (CEST)
thread_title:  Grundlage 

message: Einzelnachweis 10. und 26. sind identisch. Evtl. war die Absicht des Autors, die entsprechenden Seitenzahlen aus der Quelle zu ergänzen, was untergegangen ist.
Vorschlag: Konsolidieren und Nr. 26 entfernen.
--Dr.Xos (Diskussion) 12:40, 9. Sep. 2017 (CEST)
thread_title:  Einzelnachweise 

message: Im Text wird teilweise noch der Begriff User-Story verwendet. Das ist aus zwei Gründen problematisch. Zum einen wird der Begriff erst hinterher erklärt. Zum anderen wird bei der Erklärung darauf hingewiesen, dass User-Stories nur ein Weg zur Beschreibung von Anforderungen sind und selbst auch gar nicht zum Scrum Framework gehören. Im Text wird der Begriff aber äquivalent zu Anforderungen verwendet, was ja eben nicht so ist. Vielleicht kann das jemand mit mehr Wissen auf dem Gebiet korrigieren. Zusätzlich könnte es bei anderen Wörtern ähnliche Probleme geben, das weiß ich aber nicht mehr. --Claell (Diskussion) 15:11, 14. Sep. 2018 (CEST)
thread_title:  Verwendung von User-Story 

message: In dieser Woche hat eine IP drei Mal versucht, Werbung für eine Consulting-Firma einzuschleusen. Ich schlage vor, für die Seite vorübergehend eine Teilsperre (Nur angemeldete, nicht neue Benutzer) einzurichten. --Philipp Sªsse (Diskussion) 14:56, 27. Apr. 2022 (CEST)
replies: text: Das werden wir dann über die Benutzersperre lösen - Benutzer wurde darauf angesprochen: Benutzer Diskussion:91.8.246.112 --Sebastian.Dietrich   ✉  17:45, 27. Apr. 2022 (CEST)
thread_title:  Sperren? 

message: Ich habe das Gefühl, dass dieser Heise-Artikel relevant für dieses Lemma ist: Urteil-Einordnung: Echte Scrum-Entwickler wohl ohne Sozialversicherungspflicht. Zitat: "Das Urteil dürfte über den Einzelfall hinaus Bedeutung erlangen."
--212.8.145.44 21:54, 12. Aug. 2022 (CEST)
thread_title:  Selbständigkeit eines Scrum-Entwicklers durch Gericht bestätigt 

message: Bei Forbes: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/?sh=601004882071 Scrum basiert auf soziologischen Thesen, die in der realen Arbeitswirklichkeit nicht funktionieren. Scrum hat was von einer Sekte. --2003:C0:DF12:1700:4C05:884A:15D3:D8ED 17:18, 8. Jun. 2023 (CEST)
thread_title:  Kritik schon von 2019