Vorteile von Scrum für die Entwickler selbst? [geschlossen]

Scrum ist eine Projektmanagementmethode. Wie würden Sie sie an die Entwickler in einem Team verkaufen, das mit der aktuellen Situation einigermaßen zufrieden ist?

Es scheint mir einfach zu sein, unserem Produktmanager zu erklären, wie Scrum es ihm ermöglicht, regelmäßige Releases zu erhalten, Anforderungen zu ändern und das Team dazu zu bringen, sich zuerst auf die Storys mit der höchsten Priorität zu konzentrieren. Ich fand es einfach zu erklären, was TDD oder Continuous Integration im täglichen Leben eines Entwicklers bewirken.

Aber wie können Entwickler davon überzeugt werden, Scrum anzunehmen? Wie würde Scrum ihr Leben leichter machen?

Scrum bietet viel mehr Transparenz über das, was gerade passiert . Schlechtes Management, kurzfristige Änderungen, Druck und alles, was ein Entwickler normalerweise zu erwarten hat.

Es bringt jedoch auch eine Menge Sichtbarkeit für Zauderer, bösartige Entwickler, verrückte Individualisten, mit anderen Worten, böse Entwickler.

Scrum ist ein zweischneidiges Schwert

Scrum bietet Ihnen die Möglichkeit, diese Probleme zu lösen. Deshalb ist es so mächtig.

Indem Sie das große Ziel ("Lass die Software fertig werden") in kleinere Teile - Storys - aufteilen und entscheiden, was beim aktuellen Sprint zu tun ist, verbessern Sie die Produktivität und reduzieren den Stress. Wenn Sie speziell wissen , was Sie tun sollen jetzt , gibt es wenig Stress zu, und Sie können sie auf das kleine Stück zu tun , anstatt das Gefühl von den großen Ganzen überwältigt.

Stack Ranks / Backlog verhindert, dass Meilensteine ​​zu Todesmärschen werden

Als Entwickler sehe ich das zerstörerischste Muster in der Softwareentwicklung, wenn ein externer Controller (z. B. Projektmanagement, Geschäftsführung) sehr aufgeregt darüber ist, dass das Lieblingsfeature es nicht schafft. Kalenderdatum 'und befiehlt einen Todesmarsch.

Scrum unterstützt Entwickler dabei, diese Spannung auf zwei Arten proaktiv zu bewältigen, da es in einer Backlog-Liste als wichtig eingestuft wird. Erstens können Sie "Lieblingsfunktion" im Backlog als hoch einstufen, so dass er / sie höchstwahrscheinlich glücklich ist. Zweitens gibt es eine sehr anschauliche und konkrete Antwort auf die Frage: "Da wir 'blinkende Widgets' auf Rang 1 verschoben haben, werden wir in diesem Sprint wahrscheinlich keine 'springenden Hasen' mehr sehen, da er jetzt Rang 7 ist." Fühlen Sie sich wohl mit diesem Kompromiss? "

Ich habe auch festgestellt, dass bei kurzen Sprints 'externe Controller' sich weniger darüber aufregen, die Arbeit zu verschieben. Wenn "Blinkende Widgets" nicht in "Meilenstein 1" und "Meilenstein 2" erst in 9 Monaten endet, ist der Sponsor von "Blinkenden Widgets" sehr verärgert. Aber wenn 'Blinkende Widgets' den Stapelrang 7 anstelle von 1 hat, weil es wirklich 6 wichtigere Dinge gibt, die zuerst erledigt werden müssen, bedeutet dies, dass wir es wahrscheinlich im Sprint + 1 oder im schlimmsten Fall im Sprint + 2 schaffen, was bedeutet Es wird in 12 oder 18 Wochen angezeigt (bei 6-wöchigen Sprints). Meiner Erfahrung nach ist das Warten von 3 Monaten für den Ungeduldigen "akzeptabel" - im "Wasserfall" -Modell mit Meilensteinen von mehr als 3 Monaten.

Wenn wir das Ende des Sprints erreichen und es länger als erwartet gedauert hat, ist es sehr schön, die Rückstandspunkte 5-6-7 auf den nächsten Sprint zu verschieben und sicherzustellen, dass wir 1-2-3 abgeschlossen haben -4 mit hoher Qualität und ohne 70 Std. Wochen. Immerhin werden wir sicher beim nächsten Sprint 5-6-7 sein. Angesichts der kürzeren Fristen, die mit der Verschiebung verbunden sind, fühlen sich 'externe Controller' im Allgemeinen damit wohler und bestehen nicht darauf, dass wir den Meilenstein zwei Wochen überschreiten und das Abendessen jede Nacht bestellen, 'um es einfach durchzuziehen'.

Die Leute in einem Scrum-Team müssen viele Dinge selbst entscheiden: Was wird im nächsten Sprint gemacht, wie teilen wir diese Geschichte in Aufgaben auf, wer arbeitet an was usw. Dies befähigt sie und ist fast das genaue Gegenteil von Mikro -Verwaltung.

Die Tatsache, dass sich die Anforderungen ändern, wird von Anfang an berücksichtigt. Entwickler müssen keine detaillierten Spezifikationen mit präzisen Schätzungen erstellen und dann wochenlang ein Feature entwickeln, um zu erkennen, dass der Kunde seine Meinung ändert, sobald er das Ergebnis sieht ...

Für mich ist es aus Entwicklersicht das größte Verkaufsargument, Aufgaben aus dem Backlog selbst zuzuweisen. Die Intimität mit dem Kunden / Produktbesitzer hilft auch, das größere Schema der Dinge zu verstehen.

Einige Sachen:

• Darauf aufbauend, dass sich Xavier seine Anforderungen von Anfang an geändert hat - entsteht eine weniger politische Atmosphäre, wenn jeder von Anfang an akzeptiert, dass einige Dinge nicht den Erwartungen des Kunden entsprechen. Schnelle Lieferung und Überprüfung bedeuten, dass die Kosten für Fehlkommunikationen gering sind. Anstatt das Schuldspiel zu spielen, können die Entwickler die Dinge einfach so ändern, dass sie so funktionieren, wie es der Kunde erwartet.

• Story Punkte! Welcher Entwickler mag es nicht, Punkte für seine Arbeit zu bekommen !!?! Im Ernst, es ist besser als Abzeichen in SC2 oder Stack Overflow zu bekommen.

Es gibt einige Dinge, die ich als Entwickler an Scrum mag.

Die Entwickler erhalten in der Regel mehr Informationen im Voraus. Der Produktbesitzer muss alle Arbeiten, die während des nächsten Sprints ausgeführt werden sollen, so detailliert erklären, dass gute Schätzungen möglich sind.

Eine Just-in-Time-Schätzung bedeutet, dass diese Schätzungen ziemlich genau sind. Jeder hat normalerweise eine ziemlich gute Vorstellung davon, was in einem Sprint beendet wird. Dies gibt Programmierern und Projektmanagern die Möglichkeit, sich gegen unzumutbare Anforderungen zu wehren.

Es ist schön, alle drei bis vier Wochen einen Schritt zurückzutreten und Luft zu holen und wenigstens eine Abwechslung zu haben.

Selbstorganisierende Teams scheinen die Arbeit etwas abwechslungsreicher zu gestalten.

Zumindest theoretisch gibt es während des Sprints weniger Unterbrechungen und "Notfälle".

Die tägliche Sitzung zwingt die Programmierer, jeden Tag mehrere Wörter zu sagen.

Es ist einfacher zu sehen, welche Fortschritte erzielt werden, wenn die Storys am Ende jedes Sprints explizit beendet und überprüft werden.

Die Burn-Down-Charts sind ein sehr effektives und leichtes Mittel, um den Fortschritt zu verfolgen.

Vorteil für Entwickler ist frühzeitiges Feedback (vom Kunden, Tester, Product Owner usw.).

Auch als Entwickler bin ich immer daran interessiert, Dinge Schritt für Schritt ohne Ablenkung zu machen. Scrum bietet dies.

PS: Scrum ist keine Methode, sondern ein Framework.