Diskussion:Scrum

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Scrum“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

Unterschied Review <-> Retrospektive

Gibt es da wirklich einen Unterschied? Bzw. wo liegt der?

• --194.45.12.12 14:23, 6. Mai 2008 (CEST) : Das Review Meeting dient dazu, den Stakeholdern den aktuellen Stand zu beschreiben, es hat also das Produkt zum Gegenstand. Die Retrospektive dagegen hat den Scrum Prozess als Gegenstand und dient dazu, dem Team eine Möglichkeit zu geben, den Prozess anzupassen. Beides auf Basis von Ken Schwabers Buch "Agile Management with Scrum".

Beschreibung des Product Owners

Ich bin mit der Beschreibung des Product-Owners nicht einverstanden, in meinen Augen ist er der Besitzer des Product Backlogs und übernimmt damit die Verantwortung für das Produkt. Was er mit der „Kapitalrendite“ zu tun haben soll ist mir schleierhaft.

Ist das auch auf Großprojekte anwendbar?

Wenn ein Großprojekt in Kleine Teams von maximal 15 Leuten zerlegbar ist funktioniert das. Entsprechender Abschnitt fehlt aber noch im Artikel --FabianLange 20:57, 13. Nov 2005 (CET) Ein Grossprojekt sollte als scrum of scrums abbildbar sein.

Woher stammt die Bezeichnung 'Scrum'?

http://www.mountaingoatsoftware.com/pres/scrumpres.pdf erwähnt DeGrace and Stahl, Wicked Problems, Righeous Solutions, 1990

Mehr Angaben unter http://www.controlchaos.com/download/Controlled-Chaos%20Software%20Development.pdf Seite 11

Im Eintrag fr:Scrum wird darauf hingewiesen, dass die Bezeichnung aus dem Wortschatz der Rugby-Spieler stammt.

http://www.ifi.unizh.ch/req/courses/seminar_ws03/12_Boegli_Anforderungen_Ausarbeitung.pdf enthält noch weitere Angaben. HJH 22:45, 10. Apr 2006 (CEST)

Magic Numbers

Dieser Artikel enthält Magic Numbers, bspw. "15 Minuten". Das finde ich nicht richtig. Auch für die Scrum-Ablaufgrafik würde ich auf jeden Fall erwähnen, dass das nur exemplarische Werte sind. (nicht signierter Beitrag von 88.215.124.106 (Diskussion | Beiträge) 19:15, 17. Sep. 2009 (CEST))

Scrum Master

Die Beschreibung des Scrummasters hinkt in dem Punkt, dass er weder zum Management noch zum Team gehört. Es wird sogar auf der Beschreibung des ScrumMasters auf der Offiziellen Website der Scrumalliance darauf hingewiesen, dass dies eine praktikable Möglichkeit ist. (nicht signierter Beitrag von 212.64.228.99 (Diskussion | Beiträge) 14:35, 10. Dez. 2009 (CET))

Grundlegende Überarbeitung erforderlich

Einiges an diesem Artikel entspricht nicht den Tatsachen, bzw. den zugrunde liegenden Forschungsergebnissen und Definitionen. Nonaka und Takeuchi beschreiben kein Scrum - als Vorgehensmodell - sondern vergleichen die von ihnen beobachteten Veränderungen in einigen Unternehmen mit dem Teamspiel von Rugby. Auch die weiter unten beschrieben A, B, C Typen haben als solche nichts mit Scrum zu tun, sondern mit der Entwicklung überlappender Prozessphasen. Ich werde in den nächsten Wochen sukzessive versuchen, die entsprechenden Darstellungen zu korrigieren und den Artikel auf ein solides Fundament zu stellen.

Andreas Schliep (nicht signierter Beitrag von 88.71.196.162 (Diskussion) 23:00, 14. Mai 2010 (CEST))

Backlog

Bei den ganze Fachbegriffen hier fehlt mir vor allem mal eine Definition was eigentlich genau ein Backlog ist. Leider gibt das dafür ja auch keinen allgemeinen Wikipedia-Artikel. --Hcy 09:42, 17. Sep. 2010 (CEST)

Ein Backlog ist prinzipiell mal eine Liste. In Scrum gibt es mehrere Backlogs: Product-Backlog, Sprint-Backlog, Impediment-Backlog, ... - also Listen mit Dingen, die noch offen sind. Keine Task- oder ToDo-Listen (weil dort nicht unbedingt Tasks/ToDos draufstehen), keine vollständigen/unumstößlichen Listen (weil sie agil wachsen/schrumpfen/nicht völlig umgesetzt werden können). Ist eigentlich mit nichts aus dem klassischen Projektmanagement vergleichbar... --Sebastian.Dietrich ✉ 20:24, 19. Okt. 2010 (CEST)

Tendenziöser Artikel

Der gesamte Artikel ist tendenziös und reflektiert in keiner Weise, welche strukturellen Schwächen Scrum aufweist. Auch würde ich gern wissen, worin die "Hinzunahme streng wissenschaftlicher Vorgehensweisen" besteht. (nicht signierter Beitrag von 195.37.205.30 (Diskussion) 10:04, 19. Okt. 2010 (CEST))

Das mit den streng wissenschaftlichen Vorgehensweisen hab ich mal ausgebaut - kommt wenns dafür einen Beleg gibt gerne wieder rein. Ansonsten kann ich keine Tendenz erkennen - mMn ist der WP:NPOV gut gewahrt. Etwaige Strukturelle Schwächen von Scrum bitte mit Beleg in den Abschnitt "Kritische Betrachtung". --Sebastian.Dietrich ✉ 20:16, 19. Okt. 2010 (CEST)

Die Scrum-Lüge

Aus persönlicher Praxis kann ich nur berichten wie bei uns Scrum angewendet wird (bzw. was von Scrum noch übrig ist): Es gibt keine Product Owner mehr; auch vorher war der Einfluss der Product Owner zu gering. Review und Retrospektive waren einmal. Den Scrum-Mastern ist das ganze in den Kopf gestiegen und sie agieren großteils nicht im Sinne des Scrum-Teams und auch nicht im Sinne von Scrum sondern nehmen Möchtegern-Chef-Positionen ein (ohne Legitimation und ohne Kompetenz). Scrum-Planning findet praktisch nicht statt. Die Motivation aller Team-Mitglieder ist am Boden. Ein Product-Backlog existiert zwar, es gibt jedoch viele die darüber stehen. Aber das ganze wird noch immer als "Scrum" und als Erfolg verkauft. -- 178.191.76.235 00:52, 5. Nov. 2010 (CET)

Das was Du ansprichst ist die alte Frage "Wieviel X brauche ich, um mich X nennen zu dürfen" - konkret auf agile Prozesse angewandt: bin ich agil, wenn ich 1%, 5%, 99% eines agilen Prozesses umgesetzt habe. Die meisten Projekte, die ich kenne, die sich "Scum" nennen liegen irgendwo zwischen 20% und 60% - Dein Projekt scheint sich eher bei 20% oder weniger zu bewegen. mMn kann man das aber nicht dem Prozess per se anlasten. --Sebastian.Dietrich ✉ 10:24, 5. Nov. 2010 (CET)

Nur weil es beim Unternehmen X nicht so funktioniert wie vom Erfinder angedacht, bedeutet das nicht, dass es nicht funktioniert. Wir alle – die bereits Praxiserfahrung haben – wissen, dass es im realen Leben oft nicht so ablaufen kann wie in einem Modell. Es wird immer irgendwelche Manager, Kunden oder andere Großmäuler geben die sich zwar gerne mit irgendwelchen netten Schlagwörtern schmücken und im Hintergrund läuft alles anders. Für diesen Artikel ist dies jedoch unerheblich, da hier lediglich das Prozessmodell erläutert wird und nicht wie es im Unternehmen X oder Y in der Realität abläuft. LG, ひき肉器 ^公議 20:05, 6. Nov. 2010 (CET)