Ich habe SCRUM in den letzten vier Jahren in drei verschiedenen Projekten verwendet. Einer der Vorteile von SCRUM scheint seine Flexibilität und Anpassungsfähigkeit zu sein, z. B. in Bezug auf sich ändernde Kundenanforderungen. Ein weiterer Vorteil besteht darin, dass das Management den Fortschritt eines Projekts leicht verfolgen kann.
Die Flexibilität von SCRUM kann von Vorteil sein z.B Bei der Implementierung einer Webanwendung, bei der sich die Anforderungen sehr schnell ändern und die Kunden wirklich verstehen, was sie wollen, nachdem sie einen Prototyp gesehen haben.
Andererseits gibt es andere Arten von Softwareprojekten (z. B. in der Luft- und Raumfahrt) Industrie), wo die Anforderungen ziemlich festgelegt sind: Sie erhalten ein Anforderungsspezifikationsdokument und müssen sechs Monate später mit funktionierender Software und vollständiger Dokumentation zurückkommen. Für diese Art von Projekten bezweifle ich, dass die von SCRUM gebotene Flexibilität (in dem Sinne) erforderlich ist dass Sie keine Prototypen erstellen und dem Kunden zeigen müssen, um Feedback zu den Anforderungen zu erhalten): Sie benötigen vielmehr einen sehr strukturierten und systematischen Ansatz, der sich wahrscheinlich für jedes Projekt immer wieder wiederholt und wenig Raum für Überraschungen bietet / p>
Wird SCRUM von seinen Befürwortern als universelle Softwareentwicklungsmethode angesehen oder wird es als besonders geeignet für bestimmte Kategorien von Projekten oder Anwendungsbereichen angesehen?
Für Ich habe mir kürzlich die Website eines Unternehmens angesehen, das Software für die Luft- und Raumfahrtindustrie herstellt, und festgestellt, dass sie das V-Modell verwenden. Würde ein SCRUM-Befürworter sagen, dass SCRUM für diese Art von Projekten weniger geeignet ist, oder eher vorschlagen, dass dieses Unternehmen versuchen sollte, auf SCRUM umzusteigen?
Hinweis dass ich nicht nach der Meinung der Leser dieses Forums frage, aber ich möchte wissen, wie die Meinung der SCRUM-Antragsteller lautet: Wird SCRUM als allgemein oder eher für bestimmte Klassen geeignet angesehen? nur von Projekten? In letzteren Fällen für welche Arten von Projekten?
Kommentare
- Siehe stackoverflow.com / Fragen / 596916 / Wann-solltest-du-nicht-scrum und eweek.com/c/a/IT-Management/…
- Dass “ ein Anforderungsspezifikationsdokument erhält und Sie sechs Monate später mit der funktionierenden Software “ ist ein Mythos. Selbst wenn Sie so etwas wie einen Compiler für eine formal definierte Sprache erstellen (bei der die funktionalen Anforderungen wirklich klar und fest zu sein scheinen), müssen Sie die zu implementierenden Dinge entscheiden und priorisieren. Es gibt nicht funktionale Anforderungen, die mit dem Benutzer besprochen werden müssen und Sie haben mehrere Freiheitsgrade, denn man muss entscheiden, wie man Dinge löst. Ein agiler Ansatz ist für solche Projekte sogar sinnvoll.
- “ Ein agiler Ansatz ist für solche Projekte sogar sinnvoll. „: Während Agile flexibler sein kann, sind andere Methoden ebenfalls flexibel. Möglicherweise sind andere Methoden flexibel genug und Agilität ist für bestimmte Projekte zu flexibel. Hier nur ein Brainstorming.
- “ Dass “ ein Anforderungsspezifikationsdokument erhält und Sie sechs Monate später zurückkommen müssen mit funktionierender Software “ ist etwas ein Mythos. „: Ich glaube nicht, dass ‚ dies tut . Während Sie die Beschriftung einer Schaltfläche auf einer Webseite schnell ändern können, weil die Kunden ihre Meinung nach dem Betrachten geändert haben, können Sie einen kritischen Teil einer Avionik-Software, die einen sich bewegenden Teil eines Flugzeugs steuert, nicht so einfach ändern. Möglicherweise sind späte Änderungen erforderlich, aber ich frage mich, ob eine agile Methode der richtige Weg ist, um sie zu verwalten, oder ob Sie eine komplexere Iteration einer anderen Methode (z. B. des V-Modells) benötigen.
Antwort
SCRUM ist eine Allzweckmethode, die für die meisten Projekte und Teamgrößen gut geeignet ist, für große Teams mit sehr großen Aufgaben jedoch weniger nützlich ist Projekte. Die bloße Anzahl von Personen, die an einigen Projekten beteiligt sind, macht eine agile Methodik äußerst schwierig bis nahezu unmöglich, da eine starrere Struktur erforderlich ist, um die Ordnung aufrechtzuerhalten. Die Luft- und Raumfahrtindustrie ist ein gutes Beispiel für eine Branche, die tendenziell große Projekte hat, bei denen agile Ansätze nicht immer machbar sind.
Kommentare
- Gibt es Gibt es Informationen darüber, wann ein Projekt als zu groß für SCRUM angesehen wird? Betrachten Sie beispielsweise ein 18-monatiges Projekt für ein Team von 15 Personen: Würde ein solches Team von SCRUM profitieren oder wäre auch ein anderes Modell wie das V-Modell geeignet? Der Grund, warum ich frage, ist, dass die Anforderungen und die Implementierung über 18 Monate genug Zeit haben, um zu reifen und sich zu stabilisieren, und dass die von SCRUM bereitgestellte Flexibilität möglicherweise nicht wirklich benötigt wird.Vielmehr ist hier ein eher mittel- bis langfristiger Ansatz geeignet. Gibt es Literatur dazu?
- Die @ Giorgio-Zeit des Projekts spielt keine Rolle, aber 15 Personen reichen aus, um mehrere Scrums zu erstellen Gruppen, aber es ist immer noch im überschaubaren Bereich für SCRUM. Wenn das Kommunikationsmanagement für Ihr Team zu einem Vollzeitjob wird, ist es an der Zeit, sich ein V-Modell anzuschauen.
- Ist das Ihr Ernst? Wir haben vorher ein V-Modell verwendet und auf SCRUM umgestellt. Tatsächlich haben wir das Gefühl, dass wir ‚ aus genau diesem Grund langsamer geworden sind: zu viel Buchhaltung.
- @Giorgio, das wäre für jeden Wechsel wahr, das sind Sie Ich werde mich zuerst langsamer fühlen, weil es neu ist, wie Pierre 303 sagte, dass Sie nach ein paar Sprints eine bessere Idee haben.
- @Giorgio – das ‚ ist wahr, Viele “ agile “ Methoden sind schwerer als die schweren Prozesse, die sie ‚ annehmen ersetzen! Dies bedeutet natürlich, dass sie ‚ falsch liegen – agil soll leicht und frei sein und für Außenstehende chaotisch erscheinen. Es bedeutet, dass Ihr Team sehr gut organisiert und diszipliniert sein muss, aber dass ‚ im Allgemeinen von Vorteil ist. Versuchen Sie stattdessen Crystal von Alistair Cockburn (einem der Gründer von Agile).
Antwort
Jede Art von Projekt ! Es funktioniert sowohl für große als auch für kleine Projekte.
Die Leute haben es für die Planung von Hochzeiten, Umzügen usw. verwendet. Also nicht einmal nur für Softwareprojekte.
Ich bin fest davon überzeugt Es gibt viele Geschäftsvorgänge, die von einem Scrum-ähnlichen Ansatz profitieren könnten.
Kommentare
- Wird Ihre eigene Meinung geteilt? von SCRUM-Antragstellern, dh von Autoren, die SCRUM kodifiziert und beworben haben?
- Ja – dies wurde kürzlich von Cheryl Hammond gesagt ( blog.bsktcase.com ), eine ALM-Beraterin mit Northwest Cadence bei einem Vortrag mit dem Titel “ Ein Scrum-Masters-Tag im Leben: Das neue visuelle Studio „. Sie können es hier ansehen: msevents.microsoft.com/CUI/…
Antwort
Bitte beachten Sie, dass Scrum keine Methodik, sondern ein Framework ist.
Scrum funktioniert am besten in einem c ross-funktionales Team von 5 bis 9 Entwicklern arbeitet an einem mittelgroß bis groß Projektgröße (von 4 Monaten bis zu mehreren Jahren). Wenn Ihr Projekt größer ist, können Sie mit Scrum of Scrums skalieren.
Ich werde hier nicht auf die funktionsübergreifende Sache eingehen, aber hier Das sagt der
offizielle Scrum Guide für die Teamgröße:
Optimale Entwicklung Die Teamgröße ist klein genug, um flink zu bleiben, und groß genug, um wichtige Arbeiten abzuschließen. Weniger als drei Mitglieder des Entwicklungsteams verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen. Kleinere Entwicklungsteams können während des Sprints auf Einschränkungen der Fähigkeiten stoßen, was dazu führt, dass das Entwicklungsteam kein potenziell freisetzbares Inkrement liefern kann. Mehr als neun Mitglieder zu haben, erfordert zu viel Koordination. Große Entwicklungsteams erzeugen zu viel Komplexität, als dass ein empirischer Prozess verwaltet werden könnte. Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint-Backlogs aus.
Ein Sprint dauert ungefähr einen Monat.
Sprints sind auf einen Kalendermonat begrenzt. Wenn der Horizont eines Sprints zu lang ist, kann sich die Definition dessen, was gebaut wird, ändern, die Komplexität kann steigen und das Risiko kann steigen. Sprints ermöglichen Vorhersehbarkeit, indem sie mindestens jeden Kalendermonat die Überprüfung und Anpassung des Fortschritts an ein Ziel sicherstellen. Sprints begrenzen das Risiko auch auf einen Kalendermonat Kosten.
Ich denke, es ist nicht sinnvoll, ein Framework zu verwenden, das auf einem iterativen Prozess mit kleineren Projekten basiert als 4 Monate. 4 Monate = 4 Sprints. Sie müssen auch berücksichtigen, dass Sie nach 3 Sprints eine genauere Geschwindigkeit erhalten.
Das heißt Ich persönlich verwende eine limitierte Version von Scrum für kleinere Projekte. Aber man kann es dann nicht wirklich Scrum nennen. In diesem speziellen Fall verwenden Sie einige Kernprinzipien von Scrum in Ihrer eigenen Implementierung des Frameworks.
Antwort
für den Anfang Stellen Sie sich SCRUM nur als eine Reihe von Richtlinien für die Implementierung agiler Praktiken vor. Betrachten Sie es niemals als ein „heiliges Buch“ über die Durchführung von Projekten. Für viele Projekte, bei denen ein stetiger Aufgabenfluss erforderlich ist, ist Kanbam beispielsweise besser geeignet.
Agile Projekte fallen in der Regel dort herunter, wo Sie Projekte ausführen, für die ein festes Enddatum oder feste Kosten erforderlich sind. Sie können diese Projekte zwar weiterhin mit agilen Methoden ausführen, müssen jedoch alles im Voraus planen Feststellen, ob es wahrscheinlich ist, dass Sie das Ziel wahrscheinlich treffen, ist nicht die übliche agile Methode. In der agilen Form arbeiten Sie so lange, bis Ihnen die zu erledigenden Aufgaben oder die Zeit dafür ausgeht. Für die meisten Projekte ist dies in Ordnung Da sich die Anforderungen während des Projekts ohnehin ändern.
Kommentare
- Die Art und Weise, wie wir in unserem Team agil vorgehen, besteht darin, dass der Kunde den Geschichten Priorität einräumt (von am meisten bis am wenigsten wichtig), wir schätzen User Stories mithilfe von Pokerkarten und planen so viele Storys, wie wir bis zum Stichtag implementieren können. Wenn sich herausstellt, dass wir schneller sind, planen wir mehr Geschichten, je nachdem, was als nächstes in der Prioritätenliste steht.
- Ich habe Ihre Antwort nach einigen Monaten erneut gelesen und sie ist tatsächlich sehr aufschlussreich. +1