project management zertifizierung Scrum: zu viel oder nicht genug?




scrum master zertifizierung (7)

Meine Firma benutzt seit kurzem Scrum; Wir haben 2 Sprints gemacht. Wir lernen immer noch, aber wir haben schon einige Probleme in unserem Entwicklungsprozess aufgedeckt und behoben. Also im Allgemeinen denke ich, dass es gut für uns war.

Als ich viele der Internet-Gedanken über Scrum von Evangelisten, Zynikern und allen dazwischen gelesen habe, sind mir drei gängige und etwas widersprüchliche Themen aufgefallen:

  1. Die Scrum-Implementierung schlägt fehl, weil die Prozesse von Scrum nicht genau genug verfolgt werden.
  2. Die Scrum-Implementierung schlägt fehl, weil die Organisation Scrum nicht an ihre eigene Umgebung / Kultur / Praxis anpasst.
  3. Die Prozesse von Scrum sind nicht wichtig; nur die Werte im Agilen Manifest sind von Bedeutung.

Beispiele hierfür sind in den Antworten auf diese SO-Fragen zu finden:

Ich muss zugeben, dass wir noch nicht alle Richtlinien von Scrum befolgen: Wir haben am Ende der Sprints keine Veröffentlichung gemacht, unser Scrum Master möchte nicht, dass wir Aufgaben gegen Ende des Sprint Backlogs verschieben des Sprints, so dass er sehen kann, wie viel unsere Planung war (was bedeutet, dass die Burndown-Chart nie auf 0 geht), und dringende Probleme bei der Kundenbetreuung haben immer noch unglaubliche Macht, um die Planung aller zu stören, für einige Beispiele.

Meine Frage ist: Bei dem Versuch, diese und andere Probleme zu lösen, ist es besser zu versuchen, den offiziellen Scrum-Prozessen näher zu sein, näher an einigen unserer Pre-Scrum-Prozesse zu sein oder besser über die Prinzipien von Scrum zu meditieren Versuchen Sie es mit einem anderen Prozess?


Jedes Unternehmen ist anders, jedes Projekt ist anders und jeder Kunde ist anders.

Ich denke, es ist genauso leicht zu scheitern, wenn man dem Scrum (oder irgendeiner anderen Methode) in einer Umgebung, die nicht zur Methodik passt, zu eng folgt, weil es schief geht, weil man in einem Projekt, das zu ihm passt, zu locker sitzt.

Am Ende ist eine generische Antwort in einer QA-Site kein Ersatz für eine ernsthafte Analyse Ihres eigenen Projekts, Unternehmens, Teams und Kunden - es gibt keine Zauberformel und Sie müssen Ihre eigene Entscheidung treffen.


Es empfiehlt sich, Scrum nach dem Buch zu verwenden und die zugrunde liegenden Prinzipien und Werte des Agile-Manifests zu verstehen , bevor Sie es anpassen, damit der Prozess nicht denaturiert wird. Achten Sie darauf, am Ende jeder Iteration (Sprint) Retrospektiven durchzuführen, um Ihren Prozess zu " inspizieren und anzupassen " und Verschwendung zu vermeiden .

Für Ihren Scrum Master kann er verfolgen, was aus dem aktuellen Sprint entfernt wurde. Sprints sind auch basierend auf den vorherigen Sprints geplant, nicht auf dem, was vorher geplant war. Ich verstehe seinen Standpunkt nicht.


Scrum funktioniert . Nicht bei allen Teams in allen Situationen, aber es hat sich gezeigt, dass es funktioniert.

Ich würde vorschlagen zu versuchen, Lehrbuch Scrum so viel zu umarmen, wie es Ihre Geschäftsumgebung erlaubt, zu sehen, wie das funktioniert, und es dann zu tunen .

Warum möchte Ihr Scrum-Master keine Aufgaben aus dem Sprint-Backlog entfernen? Nimmt er nicht zu 100% die Prinzipien von Scrum an? (Ich würde das als beunruhigend in einem Scrum Master sehen)

Die meisten Probleme bei der Implementierung von Scrum sind eigentlich nur Probleme im Team oder Geschäft, die durch den Scrum-Prozess aufgedeckt werden, zB wenn Ihre Sprints durch unvorhergesehene Support-Probleme rausgeworfen werden, deutet dies darauf hin, dass Sie nicht genügend Ressourcen für den Support bereitstellen


Scrum ist nicht wirklich das Problem, das du zeigst. Die meisten Entwicklungsmethoden arbeiten, sogar Wasserfall, so viel wie wir es gerne, es funktioniert. Scrum lässt dich ein wenig mehr auf die wichtigen Dinge konzentrieren, aber es wird die Leute nicht davon abhalten, schlechte Entscheidungen zu treffen, weil sie dem Prozess nicht wirklich folgen.

Das System ist ziemlich einfach in seinem Kern.

Sehen Sie das Problem. Definiere was getan ist. Erstellen Sie eine Reihe von Aufgaben, mit denen Sie fertig werden. Schätzen Sie diese Aufgaben ab. Wählen Sie genug davon aus, damit Sie in kurzer Zeit etwas erledigen können. Beende die Aufgaben. Spülen und wiederholen.

OK, zugegeben, diese Schritte sind vereinfacht, und ich habe keinen Scrum-Master und keinen Kunden hineingeworfen. Aber der Punkt ist, dass der Rahmen nur eine grundlegende Zeitmanagementstrategie ist. Wenn die Leute in Ihrem System chaotisch sind und nicht gut darin sind, Dinge zu erledigen, dann wird Scrum ihnen wirklich nicht helfen.


Antwort: Sie müssen sowohl Scrum als auch XP gemeinsam anwenden, um die Vorteile von Scrum zu nutzen.

Gründe dafür:

Die Gründe dafür basieren auf Jahren, in denen ich XP und Scrum gemacht habe, und speziell auf das, was ich aus Jeff Sutherlands Vortrag gelernt habe (für den ACCU in London, Mai 2009).

  • Scrum ist eine Management-Technik - nicht unbedingt eine Software-Produktionsmethode. Manche Leute nutzen Scrum in anderen Bereichen, zB um Museumsausstellungen vorzubereiten und religiöse Institutionen zu leiten ... also hat es die Mechanismen, die man braucht, damit ein multidisziplinäres Team in kleinen Schritten Arbeit schafft.
  • Scrum umfasste ursprünglich alle extremen Programmierpraktiken . Jeff Sutherland sagte tatsächlich, dass er noch nie ein Scrum-Projekt gesehen habe, das die höheren Ordnungen der Produktivität, die für Scrum gemessen werden, erreicht, ohne die extremen Programmierpraktiken zu verwenden.
  • Scrum und XP kommen beide aus dem gleichen Hintergrund - Objektorientierte Programmierung, speziell mit Smalltalk. Die Programmierer gingen los und entwickelten XP, während die Führungskräfte Scrum kreierten. Sie brauchen beide Aspekte - Entwicklungspraktiken und Managementpraktiken.
  • Die XP-Praktiken wurden absichtlich von Scrum entfernt, um die Annahme zu erleichtern. - Die Umsetzung der XP-Praktiken ist schwierig und es ist schwierig, sie schnell zu übernehmen. Jeff sagte tatsächlich, dass Ken Schwaber die XP-Praktiken entfernt habe, um Leuten zu helfen, mit Scrum zu beginnen. Die Gefahr besteht jetzt darin, dass dieses minimale Gedränge alles geworden ist, was die Menschen sehen und erwarten.
  • Viele nicht-technische Projektmanager unterrichten jetzt Gedränge - aber sie haben nicht die Fähigkeit, XP zu unterrichten
  • Nicht alle Entwickler finden die XP-Praktiken leicht zu adoptieren - sie können schwer zu verkaufen sein und es dauert ein paar Monate und nicht die 2 Tage, die es braucht, um ein grundlegendes Gedränge herzustellen.

Fast alles, was ich über Scrum gelesen habe, sagt, dass einer der Schlüssel ist, den Prozess an deine eigene Situation anzupassen. Keine zwei Entwicklungsteams sind gleich, und verschiedene Dinge funktionieren für verschiedene Menschen.

Die wichtigsten Ideen hinter Scrum sind:

Haben Sie eine enge Rückkopplung von den Anforderungen zur Entwicklung und zurück zu den Stakeholdern.

Auf diese Weise kann das Entwicklungsteam kontinuierlich überprüfen, ob es tatsächlich etwas Gewünschtes schafft, und die Entwicklung kann leicht angepasst werden, wenn sich die Anforderungen und Erwartungen ändern. Stakeholder können Features zu jedem Zeitpunkt hinzufügen oder entfernen und sie können die Priorität der Features anpassen, wenn sich ihre Anforderungen ändern.

Bewahren Sie die Software am Ende eines beliebigen Sprints in einem Zustand auf, in dem sie freigegeben werden kann.

Das heißt nicht, dass Sie jeden Sprint veröffentlicht haben, aber Sie könnten das, wenn der Kunde entscheidet, dass er die neuesten Sachen haben möchte. Dies hilft auch einem Entwicklungsteam, die Situation der Integrationshölle zu vermeiden, die von Leuten kommt, die an einem Teil des Projekts monatelang isoliert arbeiten.

Sei völlig transparent mit dem, was in der Entwicklung vor sich geht, und jeder muss bereit sein, Kompromisse einzugehen.

Hier scheitern die meisten Projekte und Scrum kann wirklich erfolgreich sein, wenn sich alle in den Prozess einarbeiten. Es gibt so viele Entwicklungsprojekte, bei denen ein Release X-Funktionen am Y-Datum veröffentlicht haben muss und keine Flexibilität, dies zu ändern. Dies führt zu halb fertig gestellten Funktionen und fehlerhafter Software, da die Entwickler sich dazu entschließen, alle erforderlichen Funktionen auf ihrer Checkliste zu bekommen.

Die Realität ist, dass unerwartete Dinge in der Softwareentwicklung passieren. Mit offener Kommunikation und willigen Teilnehmern am Scrum-Prozess können Kunden und Entwickler den aktuellen Stand des Projekts kontinuierlich evaluieren und fundierte Entscheidungen zur Priorisierung der im Projekt verbleibenden Arbeiten treffen.


Scrum versucht nicht, die technischen Probleme in der Softwareentwicklung anzugehen . Es ist nur ein kleiner Managementprozess.

  • Die Stärke von Scrum ist, dass es nicht in die Quere kommt, indem es viele unnötige oder irrelevante technische Arbeiten vorschreibt.
  • Die Schwäche von Scrum besteht darin, dass es Ihnen nicht sagt, welche guten technischen Praktiken zu tun sind.

Extreme Programming befasst sich mit den technischen Problemen der Softwareentwicklung und passt sehr gut in Scrum. Der Grund, warum die Scrum-Leute nicht alle dazu zwangen, die technischen XP-Praktiken zu machen, ist, dass es etwa 6 Monate dauert, diese Tech-Praktiken zu implementieren, und nicht die 2 Tage, die nötig sind, um das grundlegendste Gedränge umzusetzen.

Ob Scrum "böse" ist oder nicht - es gibt sicherlich Nachteile. Wir diskutierten die schwierige Beziehung zwischen XP und Scrum ausführlich auf den XP Days, London, 2009: http://xpday-london.editme.com/WhereHasXpGone