Die Hauptidee des Scrum-Frameworks besteht darin, den Entwicklungsprozess für eine schnellere Ausführung der Arbeiten in verschiedenen Phasen des Projektlebenszyklus zu organisieren. Aber treibt dieser Ansatz Entwickler immer zu den richtigen Verhaltensweisen? Viele Benutzer, die sich der Diskussion der obigen Frage angeschlossen habenhaben bei Stack Overflow ähnliche Erfahrungen gemacht, als Entwickler Abstriche machten, zu viel Wert auf hohe Punktzahlen legten, die ihren Tickets zugewiesen wurden, oder sogar vorgaben, vor Managern leistungsstarke Mitarbeiter zu sein. Wie können diese Gefahren vermieden werden? Die betreffende Frage wurde von arbeitsplatz.stackexchange.com zu softwareengineering.stackexchange.com verschoben . Dies legt nahe, dass Programmierer die Überlegungen zu Scrum und seiner Wirksamkeit als etwas ernstes ansehen, das über die Verwaltung des Softwareentwicklungszyklus hinausgeht. Sie spüren die Auswirkungen dieser Projektmanagementmethode auf das gesamte Arbeitsumfeld.
Ist Scrum die Ursache für schlechte Entwicklungspraktiken oder ist es nur eine Entschuldigung für dieses Problem?
Viele Kontroversen haben Spekulationen über die Auswirkungen von Scrum auf Teams und einzelne Entwickler und die Einschränkungen ausgelöst, die das Framework denjenigen auferlegt, die es verwenden. Während viele Scrum für Teamfehler verantwortlich machen, glauben andere, dass dies ein Attributionsfehler ist und dass die Wurzeln der Probleme in Entwicklungsteams viel tiefer gehen.
Scrum-Befürworter sehen schlechtes Management als die Wurzel des Problems. Hier ist, was Benutzer Llewellyn sagtFazit: „Das Management ignoriert Entwickler im Wesentlichen. Es gibt feste Fristen, die eingehalten werden müssen, um vorgegebene Ergebnisse zu erzielen. Die Arbeit wird nicht von einem Team geleistet, das sich darauf konzentriert, dasselbe Ziel zu erreichen, sondern von einer Gruppe von Menschen, in denen sich jeder nur um sich selbst kümmert. Vorausplanen und über den Tellerrand hinaus denken wird nicht empfohlen. Unter solchen Bedingungen erliegt der Programmierer infolgedessen den Umständen und findet Erlösung in der einfachen Ausführung der ihm zugewiesenen Aufgaben. Ich habe unter solchen Bedingungen gearbeitet. Aber beschuldigen Sie Scrum nicht dafür. "
Benutzer DJClayworth äußerte die Meinung vieler Kommentare und sagte, dass Programmierer, die glauben, unter Druck zu stehen, mit jeder Entwicklungsmanagementmethode schlecht abschneiden werden .
Die gegenteilige Meinung zu diesem Thema wurde am besten von Benutzer Martin Maat zum Ausdruck gebracht , der das Publikum auf die Tatsache aufmerksam machte, dass die Tatsache, dass so viele Menschen das Bedürfnis haben, sich zu diesem Thema zu äußern, für die Frustration spricht, die Scrum verursacht.
Was sind die häufigsten Probleme bei der Verwendung von Scrum?
In den Kommentaren sind einige häufige Scrum-Fallstricke aufgetaucht, die entweder aufgrund eines Missbrauchs des Frameworks oder aufgrund von Scrum-Problemen auftreten. Hier sind fast ein Dutzend Probleme dieser Art, die unsere Aufmerksamkeit erregt haben.
▍1. Tägliche Besprechungen sind für Manager
Die erste Kritik an Scrum bezieht sich auf die Tatsache, dass im Verlauf von täglichen Meetings (Stand-Ups) unerwünschte Tendenzen auftreten. Eines der Argumente für diese Idee ist, dass sich Stand-Ups auf den Stand der Ereignisse verschlechtern können, deren Teilnehmer nur das tun, was sie über ihre Produktivität sagen. Besonders wenn Manager bei solchen Veranstaltungen anwesend sind. Daher hat der Benutzer Matthew Gaiser (er hat bereits für uns geschrieben, aber wir sind zufällig auf seinen Kommentar gestoßen) Stand-up-Events genannt, die darauf abzielen, Manager über die aktuelle Situation zu informieren ( Update-Management)). Er glaubt, dass Entwicklerpräsentationen bei solchen Veranstaltungen Manager nur dazu ermutigen, zu beobachten, woran sie arbeiten, aber es bringt keinen Nutzen. Dies gilt umso mehr für verteilte Teams, wenn jedes Teammitglied in seinem eigenen Modus arbeitet.
▍2. Das Erledigen von Aufgaben spielt eine wichtige Rolle
Eine andere Idee, die in den Kommentaren auftauchte, ist, dass jede Entwicklungsmethode, die große Aufgaben in kleinere Aufgaben unterteilt und den Fortschritt dieser Aufgaben überwacht, absichtlich oder nicht zu neuen Ansätzen bei der Bewertung der Arbeit führt. Wenn Sie nur mit der Anwendung einiger Metriken beginnen, wirkt sich dies auf das Verhalten der Personen aus, deren Leistung anhand dieser Metriken bewertet wird.
Viele Kommentatoren sagen, dass dies bedeutet, dass Entwickler „Ecken abschneiden“ können, um das zu vervollständigen, was im aktuellen Sprint getan werden musste. Das Problem, auf das Benutzer Gaiser hingewiesen hatund anderen Benutzern ist, dass ein separates Ticket, an dem gearbeitet wird und das während des Sprints in die Kategorie "Bereit" übertragen wird, dies eine "Black Box" ist. Was auch immer sich in dieser "Black Box" befindet, es hat keinen Einfluss auf das Ergebnis der Bewertung der Arbeitsgeschwindigkeit. User Gaiser schreibt, dass die Implementierung von schlechter Qualität, die die QS-Abteilung durchlaufen hat, und die perfekt getestete und entworfene Implementierung sich nicht voneinander unterscheiden. Infolgedessen stellt sich heraus, dass die Berücksichtigung der Anzahl geschlossener Tickets ein unzuverlässiger Indikator für die Arbeitsproduktivität ist.
▍3. Extrem produktive Entwickler, die nicht als Team arbeiten
Ein anderer Thread diskutierte die Spannung zwischen großartigen Soloprogrammierern und großartigen Teams. Wenn jeder der Scrum-Methode folgt, können einige Entwickler äußerst produktiv sein, aber dann kann das "Team" vergessen werden. User Gaiser sagt, dass Selbstorganisation ohne die richtigen Anreize ein unerreichbares Ziel ist: „Teammitglieder werden Probleme nach eigenem Ermessen oder nach Anweisung lösen. Wenn es das Team nicht aufbaut, bleibt viel übrig und die Teammitglieder werden einfach in Unordnung vorankommen. "
Er fährt fort: "Darüber hinaus ist es schwieriger, den Code zu debuggen, wenn jeder Entwickler seine eigenen Methoden zur Lösung von Problemen auswählen kann."
▍4. Schwierige Aufgaben werden auf später verschoben
In gleicher Weise kritisiert Gaiser weiterhin die Illusion von Produktivität. Er sagt, dass bei der Anwendung von Scrum das Hauptaugenmerk darauf liegt, das Ticket in den Status "Bereit" zu bringen. Gleichzeitig tief über die Aufgabe nachzudenken scheint nicht besonders produktiv zu sein. Daher können Entwickler dazu neigen, einfache Aufgaben zu übernehmen und komplexere zu vermeiden. Auch hier die Worte des Benutzers Gaiser: "Scrum ermutigt Entwickler, einfache Aufgaben zu übernehmen, deren Lösung etwas Zeit in Anspruch nimmt, wodurch Entwickler eine konstant hohe Leistung zeigen können." Infolgedessen stellt sich heraus, dass die tägliche Auswahl von Aufgaben und die täglichen Arbeitsberichte die Auswahl der Aufgaben, die einen Tag in Anspruch nehmen, vorantreiben.
▍5. Produktmerkmale sind wichtiger als die Codequalität
Trotzdem glaubt Gaiser, dass die Verwendung des Scrum-Frameworks zu einem Rückgang der Produktqualität führt: „Wie gut ein Entwickler ist, hängt normalerweise von seiner Fähigkeit ab, zuverlässigen Code zu entwickeln. Scrum wertet diese Eigenschaft von Projekten ernsthaft ab, es sei denn, der Produktbesitzer versteht die Programmierung und überprüft den Code. " Er betont hier, dass die "Bereitschaft" eines Tickets häufig nicht nach Überprüfung der Qualität des Codes bestimmt wird, sondern erst, nachdem die entsprechende Funktion implementiert wurde.
▍6. Zeitmangel, um Arbeitsprobleme mit Kollegen zu besprechen
Wenn die Entwicklungsgeschwindigkeit der einzige Indikator für die Effektivität des Teams ist, bedeutet dies, dass die Teammitglieder keine Zeit mehr haben, einige Probleme miteinander zu diskutieren, die Meinung anderer einzuholen oder ihre Ideen zu testen über sie sprechen. Und genau das macht ein Team zu einem Team. Auch hier die Worte des Benutzers Gaiser: „Großartige Entwickler konsultieren häufig andere Entwickler und suchen nach Alternativen zu ihren Meinungen. Solche Klassen nehmen jedoch die Zeit in Anspruch, die zum Schließen von Tickets benötigt wird, und dies verlangsamt die Entwicklungsgeschwindigkeit. "
▍7. Kürzlich identifizierte Fehler müssen warten, bis sie an der Reihe sind
Ein weiteres schlechtes Scrum-Verhalten ist, dass "Fehler nach dem Sprint gefunden werden und als neue Aufgaben betrachtet werden". Dies kann Entwickler dazu bringen, Code von geringer Qualität freizugeben, da zusätzliche Aufgaben nicht im aktuellen Sprint enthalten sein können.
▍8. Ticketgesteuerte Architektur
Das Ticketsystem basiert nicht nur darauf, welche Aufgaben Entwickler für sich selbst auswählen. Benutzer Gaiser sagt auch, dass die Verwendung von Scrum versehentlich zu einer verwirrenden Architektur von Projekten führt, da Entwickler an Tickets in der Reihenfolge arbeiten, in der sie erscheinen, und unabhängig voneinander. Infolgedessen "wird Architektur schnell zum Spiegelbild von Tickets."
▍9. Eine Entwicklungsmanagement-Methodik, die absolut alles betrifft
Wenn Sie die Diskussion lesen, können Sie auf die Kommentare achten, deren Autoren feststellen, dass die Wurzel aller Probleme in der mangelnden strikten Einhaltung der Scrum-Regeln liegt. Die vielleicht stärkste Anti-Scrum-Behauptung von Gaiser ist jedoch, dass das Framework alles andere übernimmt. Dies kann ein starkes Team zerstören. "[Scrum] verzerrt und bricht alle anderen Mechanismen des Entwicklungsmanagements. Dieses Framework wird zu einem umfassenden Phänomen, bei dem nichts als Rituale einheitlich durchgeführt werden und die Durchführung dieser Rituale die Illusion von Erfolg erzeugt."
Wir haben eine ziemlich lange Liste von Problemen besprochen, die durch die Verwendung von Scrum verursacht werden können und möglicherweise erst durch die Verwendung dieses Frameworks deutlicher werden. In der Diskussion, die wir untersuchen, finden Sie jedoch ebenso viele Ideen, wie Entwickler in Frieden und Harmonie leben können, indem Sie die Scrum-Regeln befolgen .
Wie kann ich Scrum optimal nutzen?
Viele der Antworten auf Gaisers Kommentare, die viele positive Bewertungen erhielten, lauteten, dass es sich bei dem, worüber er sprach, nicht um Scrum handelte. Der Benutzer Stephen Byrne schrieb dazu Folgendes: „Ich denke, dies ist eine gute Antwort mit einigen wertvollen Erkenntnissen, aber ich muss vielen anderen Kommentatoren zustimmen, dass das, was hier beschrieben wird, definitiv kein Scrum ist und wird unter dem Deckmantel von Scrum angesehen. " Aber viele hassten Scrum entweder offen oder stimmten dem Gaiser-Benutzer zu, dass wenn etwas bei der Verwendung von Scrum schief geht, dies bedeutet, dass dieses Framework einfach nicht richtig verwendet wird.
Wie verwende ich Scrum richtig?
▍1. Tägliche Besprechungen sind nicht gleichbedeutend mit dem täglichen Abholen neuer Tickets
Viele Leute sagten, dass tägliche Meetings Entwickler dazu zwingen, jeden Tag Tickets zu schließen. Wie von DJClayworth festgestellt , können Sie jedoch nicht auf die Priorisierung von Aufgaben verzichten. Und wenn die Prioritäten nicht auf natürliche Weise festgelegt werden, sollte diese Aufgabe vom Scrum Master übernommen werden: „Wir müssen Aufgaben innerhalb der Sprints priorisieren, größeren Aufgaben muss eine höhere Priorität eingeräumt werden, sodass jemand am ersten Tag des Sprints schwierige Aufgaben übernehmen muss. Wenn bis zum zweiten Tag niemand eine große und komplexe Aufgabe übernommen hat, sollte der Scrum Master auf jeden Fall Folgendes sagen: „Ich sehe, dass niemand die Aufgabe übernommen hat, die Datenbank zu komprimieren. Und das ist eine große Aufgabe. Wenn wir den Sprint beenden wollen, müssen wir jetzt mit der Arbeit an dieser Aufgabe beginnen. "
▍2. ,
Alle im Sprint gelösten Aufgaben sollten in kleine Teile zerlegt werden. Das ist nicht zu leugnen. Das Scrum-Framework sagt jedoch nicht, dass Entwickler von Metriken besessen sein sollten, die Ergebnisse anzeigen. Scrum schlägt nicht vor, Entwickler gegeneinander auszuspielen. Der Gaiser-Benutzer schlägt vor , die Berücksichtigung der Punkte einzelner Programmierer vollständig aufzugeben. Er weist auch darauf hin, dass viele Manager möglicherweise die Regeln von Scrum neu lernen müssen: „Sagen Sie den Managern, dass der Moment, in dem sie Entwickler loben oder ihnen eine auf geschlossenen Tickets basierende Aktion geben, der Moment ist, in dem sie das Verhalten des Teams radikal ändern. ".
Benutzer DJClayworthstimmt zu, dass das bewusste Ignorieren der mit einzelnen Tickets verbundenen Metriken Teil der Aufgabe eines guten Scrum-Masters sein sollte: „Die Aufmerksamkeit sollte darauf gerichtet sein, sicherzustellen, dass das Team seine Ziele als Team erreicht. Ein Scrum Master sollte sich an diese Verhaltensweise halten und Diskussionen oder Kennzahlen vermeiden, die darauf beruhen, wie viele User Stories jedes Mitglied des Teams beworben hat. "
▍3. Sie müssen kleine Schritte in Richtung großer Ziele unternehmen, aber mit diesem Ansatz sollten Sie diese Ziele nicht vergessen.
Hier ist eine weitere Idee, um große Probleme in kleine Teile zu zerlegen: "Wenn Sie an einem kleinen Puzzleteil arbeiten, bedeutet dies nicht, dass Sie das gesamte Puzzle vergessen müssen."
Benutzer Llewellyn weist darauf hin, dass die Verwendung von Scrum keine Entschuldigung ist, um die Prinzipien der Qualitätssoftwareentwicklung vollständig zu ignorieren: „Sie müssen eine gute Vorstellung davon haben, wohin das Projekt geht. Dieses Wissen kann verwendet werden, um die Architektur des Projekts zu planen und auch innerhalb des aktuellen Sprints zu planen. "
Scrum befreit Programmierer nicht von der Notwendigkeit, ihre Arbeit zu erledigen, indem sie ihr gesamtes Wissen und ihre gesamte Erfahrung in sie investieren. Daher geht Llewellyns Anruf an die Programmierer, die zu den Lesern der Kommentare gehören: „Sie waren in der Besprechung, Sie können sich den Rückstand ansehen, Sie wissen, wie die Gesamtvision des Projekts in der Organisation aussieht. Sie möchten vermeiden, lange Zeit mit etwas aus der fernen Zukunft verbringen zu müssen. Es ist jedoch nichts Falsches daran, den Grundstein für ein erweiterbares, modulares System zu legen, das sowohl zur Lösung aktueller Probleme geeignet ist als auch es Ihnen ermöglicht, bereits geplante zusätzliche Möglichkeiten ohne Probleme für die Zukunft zu schaffen. "
▍4. Es muss entschieden werden, was "Fertig" bedeutet
Eines der Themen, die in der Diskussion angesprochen wurden, betraf die DoD-Kriterien (Definition of Done) und wie die Definition dieser Kriterien einzelnen Programmierern hilft, bestimmte Qualitätsstandards einzuhalten und die Erwartungen zu erfüllen. Die dringlichste Frage war hier, wer diese Kriterien wann entwickelte. Wenn es um das „ Wann “ geht, ging es normalerweise entweder darum, Kriterien so schnell wie möglich zu entwickeln oder wie sie während der Sprintplanung entwickelt werden sollten.
Die Antwort auf die Frage, wer DoD produziert, wurde vom Benutzer SpoonerNZ in Form einer Antwort auf eine andere Frage geschriebenauf der Software Engineering-Website. „Die Bereitschaftskriterien werden vom Team erstellt, für diesen Prozess ist jedoch möglicherweise die Anwesenheit eines Scrum Masters erforderlich. Dies ist notwendig, um Qualitätsgrenzen zu setzen, falls das Team keine klaren Entwicklungsstandards hat. Beispielsweise möchte ein Team möglicherweise nicht mit Codeüberprüfungen oder Komponententests herumspielen, was dazu führt, dass alle diese vom ScrumMaster zum DoD hinzugefügt werden, um eine qualitativ hochwertige Entwicklung sicherzustellen. In einer idealen Situation wird das Team, das die Stärken des Angebots verstanden hat, dies gerne akzeptieren, aber die reale Welt ist nicht immer ideal. "
Wer sollte arbeiten, indem er sich an das DoD hält? Ein natürliches (und herausforderndes) Ziel ist es sicherzustellen, dass die im DoD aufgeführten Bestimmungen in einem Team angewendet werden und von allen Mitgliedern dieses Teams unterstützt werden. Es gibt jedoch gute Gründe, den Einfluss von DoD auf mehrere Teams auszudehnen. Oder sogar die gesamte Organisation. Hier ist, was der Benutzer Alan Larimer darüber schreibt: „Das Fehlen einer allgemein anerkannten DoD-Definition für ein Produkt wirkt sich negativ auf die Qualität und Transparenz der Arbeit aus. Die Organisationsebene des DoD sollte minimal, technisch und manchmal organisationsspezifisch sein, was eine universelle Anwendung der Bereitschaftskriterien ermöglichen kann. Die Organisation kann Standards für die Codierung vorschlagen. Eine Organisation erfordert möglicherweise eine automatisierte Baugruppenerstellung, die die Ressourcen zum Erstellen und Verwalten von Baugruppen für jedes Produkt bereitstellt. Jeder Teil des DoD, ob er von einer Organisation oder von einem einzelnen Entwickler erstellt wird, muss den Bereitschaftskriterien etwas Wertvolles verleihen. "
▍5. Manager müssen die Rolle stiller Beobachter spielen
Während die Überschrift dieses Abschnitts bereits im offiziellen Scrum-Handbuch verankert ist, zeigt die Analyse der Diskussion, dass diese Regel in täglichen Besprechungen, an denen Manager teilnehmen, leider häufig verletzt wird. Aus diesem Grund müssen Programmierer erklären, warum Ticketaufträge länger dauern als geplant. Wenn nur Programmierer an der Besprechung teilnehmen, sind solche Erklärungen kaum erforderlich. Das Scrum-Handbuch sagt dazu Folgendes: „Daily Scrum ist ein internes Treffen des Entwicklungsteams. Wenn jemand anderes anwesend ist, stellt der Scrum Master sicher, dass er das Meeting nicht stört. "
▍6. Menschen sollten wichtiger sein als Prozesse
Lesen Sie die Anweisungen des Benutzers Frank Hopkins, um sich an ein klassisches Prinzip zu erinnern: "Menschen sind wichtiger als Prozesse." Hier fügte er Folgendes hinzu: "Ein gutes Team muss seine Prozesse definieren, streng definierte Prozesse tragen nicht zur Bildung eines guten Teams bei."
Ein anderer Benutzer, meriton , wies darauf hin, dass die Verwendung von Scrum von einzelnen Programmierern abhängt: „Scrum schreibt nicht vor, dass Entwickler unabhängig voneinander arbeiten. Scrum sieht vor, dass sich das Entwicklungsteam selbst organisiert, dh dass das Team Entscheidungen darüber trifft, wie seine Mitglieder interagieren. "
Benutzer nvoigt NotizenDie Teams in Scrum organisieren sich selbst, weil sie mit einer definierten Mission zum Projekt kommen: „Das Scrum-Framework basiert auf der Tatsache, dass Sie ein Team sind. Im Team spielt es keine Rolle, ob das Ticket gestern von einem bestimmten Programmierer geschlossen wurde. Jeder, der in einem Team arbeitet, versteht das Ziel (dh DoD) und bemüht sich, es zusammen mit dem Rest des Teams zu erreichen. "
▍7. Bauen Sie Scrum-Teams auf, aber erwarten Sie nicht, dass Scrum ein Team erstellt
Benutzer nvoigtwendete eine Sportmetapher an: „Stellen Sie sich vor, 11 Personen haben ein gedrucktes Fußballhandbuch erhalten. Man sagte ihnen, sie müssten jeden Tag gegen 10 Uhr 15 Minuten lang im Konferenzraum Nr. 5 üben. Glauben Sie, dass das Ergebnis eine gute Fußballmannschaft sein wird? Was wäre, wenn diese 11 Leute gute Profifußballer wären? Würde der Befehl sowieso nicht funktionieren? Ja, das würde es nicht. Es ist nur so, dass Fußballmannschaften nicht so geschaffen werden. Wie jeder Mannschaftssport braucht Scrum diejenigen, die diesen Rahmen nutzen, um ein Team zu sein. Wenn es sich nur um eine Gruppe von Personen handelt, von denen jede nur Punkte für sich selbst sammeln möchte, indem sie zeigt, wie viele Punkte in der User Story sie behandelt haben oder wie viele Ziele sie erreicht haben, verliert diese Gruppe immer gegen ein Team, dessen Mitglieder zusammen spielen und nicht nebeneinander. Freund,oder gegeneinander. "
Ergebnis
Der nvoigt- Benutzer ist bereit zuzugeben, dass Scrum "nicht für absolut alle Personen oder Teams geeignet ist". Und wie das Interesse der Community an dem hier diskutierten Thema gezeigt hat, kann die Anwendung einer Reihe von Regeln, die Scrum möglicherweise weiterentwickelt, zu einer Arbeitsumgebung führen, die weit von dem entfernt ist, was sie erstellen möchte.
Wir möchten dieses Material mit den Worten des Benutzers Seth R zusammenfassen... Er sagt, es sei nicht nötig, Wunder von agilen Ritualen zu erwarten. Zu viel wird von denen gewünscht, die mit ihrer Hilfe wie durch Zauberei versuchen, die Mängel des Entwicklungsteams zu korrigieren. So sieht er die Situation: „Es geht darum, das Feedback zu beschleunigen. Infolgedessen hat das Team die Möglichkeit, sich selbst zu überprüfen und Entscheidungen darüber zu treffen, wie die besten Ergebnisse erzielt werden sollen. Scrum hilft Ihnen nicht dabei, ein besseres Produkt zu entwickeln. Wenn Sie sich jedoch ernsthaft mit Selbsttests befassen, kann es Ihnen helfen, ein besseres Team aufzubauen. Dies führt wiederum zur Entwicklung eines besseren Produkts. "
Viele Menschen vergleichen diesen Rahmen mit Demokratie. Vielleicht ist Scrum neben allen anderen die schlechteste Form des Entwicklungsmanagements?
Oder vielleicht ist es, wie der offizielle Leitfaden sagt , ein Rahmen, der leicht zu verstehen, aber schwer perfekt zu beherrschen ist.
Wie würden Sie die Frage im Titel dieses Artikels beantworten?
