Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Workflow

SCRUM: Die Geschichte eines agilen Teams

by
Read Time:28 minsLanguages:

German (Deutsch) translation by Katharina Grigorovich-Nevolina (you can also view the original English article)

Scrum ist eine der am häufigsten verwendeten agilen Techniken. Es geht nicht um Codierung; Stattdessen konzentriert es sich auf Organisation und Projektmanagement. Wenn Sie ein paar Momente Zeit haben, lassen Sie mich Ihnen etwas über das Team erzählen, mit dem ich zusammenarbeite, und wie wir Scrum-Techniken angewendet haben.


Eine kleine Geschichte

Scrums Wurzeln reichen tatsächlich über die Agile-Ära hinaus.

Scrums Wurzeln reichen tatsächlich über die Agile-Ära hinaus. Die erste Erwähnung dieser Technik findet sich 1986 bei Hirotaka Takeuchi und Ikujiro Nonaka für die kommerzielle Produktentwicklung. Das erste offizielle Papier zur Definition von Scrum, geschrieben von Jeff Sutherland und Ken Schwaber, wurde 1995 vorgestellt.

Die Popularität von Scrum wuchs kurz nach der Veröffentlichung des Agile Manifesto im Jahr 2001 sowie des von Ken Schwaber und Mike Beedle gemeinsam verfassten Buches Agile Software Development with Scrum.


Ein paar Fakten

Scrum definiert eine Reihe von Empfehlungen, denen die Teams folgen sollten. Es definiert auch mehrere Akteure - oder Rollen, wenn Sie diese Terminologie bevorzugen - zusammen mit einem iterativen Produktionsprozess und einer periodischen Planung. Es gibt verschiedene Tools, die den Scrum-Prozess unterstützen. Ich werde in diesem Artikel auf einige verweisen, aber die mächtigsten Werkzeuge sind die weiße Tafel und Haftnotizen.

Es gibt keine Liste mit "Scrum Best Practices" und wird es auch nie geben, da der Team- und Projektkontext alle anderen Überlegungen übertrifft. - Mike Cohn

Die Rollen

Alles beginnt mit dem Schwein und dem Huhn. Das Huhn fragt das Schwein, ob es daran interessiert ist, gemeinsam ein Restaurant zu eröffnen. Das Huhn sagt, sie könnten es "Schinken und Eier" nennen. Das Schwein antwortet: "Nein, danke. Ich wäre verpflichtet, aber Sie wären nur involviert!"

Das ist Scrum! Es gibt eine konkrete Reihe von Rollen an, die in zwei Gruppen unterteilt sind:

  • Engagiert - diejenigen, die direkt für die Produktion und Lieferung des Endprodukts verantwortlich sind. Zu diesen Rollen gehören das gesamte Team, seine Mitglieder, der Scrum Master und der Product Owner.
  • Beteiligt - vertritt die anderen Personen, die an dem Projekt interessiert sind, aber nicht aktiv oder direkt an den Produktions- und Lieferprozessen teilnehmen. Diese Rollen sind in der Regel Stakeholder und Manager.

So haben wir angefangen

Alles hängt von Engagement und gutem Willen ab. Wenn Sie möchten, dass Ihr Team effizient, produktiv und pünktlich ist, benötigen Sie jemanden, der sich mit agilen Techniken befasst. Scrum mag für Sie ideal sein oder auch nicht, aber es ist sicherlich einer der besten Startpunkte. Finden Sie heraus, dass jemand in Ihrem Team, der bereit ist, den anderen zu helfen, oder Sie selbst die Verantwortung für die Einführung von Scrum übernehmen können.

Sie fragen sich vielleicht, warum es Sie interessieren sollte, wie ein anderes Team wie ich Scrum macht. Sie sollten sich darum kümmern, denn wir alle lernen, wie man Scrum besser macht, indem wir Geschichten darüber hören, wie es von anderen gemacht wurde - insbesondere von denen, die es gut machen. - Mike Cohn

Das talentierte Team, mit dem ich zusammenarbeite, wusste bereits viel über Agile. Wir haben von der Wasserfallentwicklung zu einem agileren Prozess gewechselt und ziemlich häufig veröffentlicht. Wir haben es erfolgreich geschafft, alle drei bis sechs Monate zu veröffentlichen, wobei nach jeder Veröffentlichung eine anständig geringe Anzahl von Fehlern aufgetreten ist.

Trotzdem waren wir weit von dem entfernt, was wir heute erreichen können. Wir haben den Prozess oder die Regeln verpasst, die uns zwingen würden, unsere Sicht auf das Produkt und den Prozess zu ändern. Dies war der Moment, in dem unser Teammanager uns Scrum vorstellte, ein Begriff, von dem wir damals noch nie gehört hatten.

Diese Person übernahm die Rolle des Scrum Masters.

Der Scrum Master

Der Scrum Master ist leicht eine der wichtigsten Rollen. Diese Person ist dafür verantwortlich, eine Brücke zwischen dem Produkt-Inhaber (unten definiert) und dem Team (auch später definiert) zu schaffen. Diese Person verfügt normalerweise über ein starkes technisches Wissen und nimmt aktiv am Entwicklungsprozess teil. Er oder sie kommuniziert auch mit dem Produkt-Inhaber über die Benutzergeschichten und die Organisation des Rückstands.

Der Scrum Master koordiniert die Entwicklungsprozesse, verwaltet sie jedoch nicht im Mikrobereich (das Team ist selbst organisiert). Zu Beginn des Prozesses kann der Scrum Master jedoch einen Teil des Teams mikroverwalten, um die Teaminteraktion und die Selbstorganisationstechniken zu verbessern.

Scrum Masters haben mehr Verantwortlichkeiten, und ich werde sie behandeln, wenn wir diesen Prozess diskutieren.


Einführung des Begriffs "Sprint"

Persönlich haben wir kein Problem mit Veröffentlichungen von drei bis sechs Monaten, aber ich konnte mir ursprünglich keinen so häufigen Veröffentlichungsplan vorstellen. Ich fand es zu schnell und hatte nicht die notwendige Zeit, um unsere Produkte zu integrieren und zu debuggen. Aber dann führte uns unser Scrum Master in den Begriff Sprint ein.

Sprint: eine grundlegende Entwicklungseinheit in Scrum. Es kann zwischen einer Woche und einem Monat dauern, und das Produkt befindet sich nach jedem Sprint in einem stabilen Zustand.

Das klingt empörend! Jede Woche stabil > Unmöglich! Aber in Wirklichkeit ist es durchaus möglich. Erstens haben wir unsere Produktionszyklen von drei Monaten auf eineinhalb Monate und schließlich auf einen einzigen Monat reduziert. All dies wurde erreicht, ohne unseren Stil zu ändern. Sie müssen jedoch einige Regeln für einen Sprint von weniger als 30 Tagen einführen. Hier gibt es keine magischen Regeln. Die Regeln müssen Ihrem Projekt zugute kommen.

Wenn ich mich richtig erinnere, war die erste wesentliche Änderung in unserem Entwicklungsprozess die Einführung der Sprintplanung.

Sprintplanung

Dies ist eines der verschiedenen Meetings, die Scrum empfiehlt. Vor jedem neuen Sprint planen das Team, der Product Owner und der Scrum Master den nächsten Sprint. Dieses Treffen kann einen ganzen Tag dauern, aber kürzere Sprints brauchen wahrscheinlich nur ein paar Stunden oder so.

Unser Prozess besteht hauptsächlich darin, das Produkt-Backlog zu überprüfen und eine Teilmenge von User Stories zu bestimmen, die im nächsten Sprint enthalten sein werden. Diese Entscheidungen werden durch direkte Verhandlungen zwischen dem Team, vertreten durch den Scrum Master, und dem Product Owner getroffen.

Der Product Owner

Das Festlegen der Richtung eines Produkts durch Erraten, welches kleine Merkmal den größten Wert bietet, kann die schwierigste Aufgabe sein.

Diese Person ist für die Definition der Benutzergeschichte und die Pflege des Produktrückstands verantwortlich. Er oder sie ist auch eine Brücke zwischen dem Team und dem höheren Management. Der Product Owner wertet die Anfragen von Stakeholdern, höherem Management, Benutzern und anderen Rückmeldungen (wie Fehlerberichte, Benutzerumfragen usw.) aus.

Er oder sie priorisiert diesen Rückstand und bietet den Stakeholdern in kürzester Zeit den größtmöglichen Nutzen. Der Product Owner erreicht dies, indem er die wertvollsten User Stories plant, die rechtzeitig fertiggestellt werden können. Das klingt vielleicht raffiniert - das ist es! In der Tat kann es die schwierigste Aufgabe des gesamten Prozesses sein, die Richtung eines Produkts festzulegen, indem erraten wird, welches kleine Merkmal den größten Wert bietet. Andererseits ist es manchmal ziemlich einfach. Möglicherweise fragen tausend Benutzer nach einer bestimmten Funktion. In diesen Fällen liegt die richtige Wahl auf der Hand.

Wenn diese Benutzer einen großen Teil Ihrer Benutzerbasis repräsentieren, erhöht die Bereitstellung dieser spezifischen Funktion die Loyalität.

Aber auch dies ist eine schwierige Wahl. Was wäre, wenn Sie Ihre Benutzerbasis durch die Implementierung einer anderen Funktion um 100% erhöhen könnten? Sie können also entweder die Loyalität Ihrer aktuellen Benutzer erhöhen oder die Benutzerbasis erhöhen. Was ist die richtige Wahl? Es hängt alles von der aktuellen Richtung des Geschäfts ab, und der Product Owner muss entscheiden, wohin das Produkt gebracht werden soll.

In der Firma, für die ich arbeite, werden diese Entscheidungen an das Team weitergegeben. Dies ist keine Anforderung des Scrum-Prozesses, aber besonders nützlich bei neuen Teams. Der Austausch von Informationen trägt wesentlich dazu bei, dass jeder versteht, warum einige Entscheidungen getroffen werden und warum scheinbar offensichtliche Funktionen verzögert oder gelöscht werden können.


Die Plantafel

Ich erinnere mich an den Morgen, als es passierte: Ich kam im Büro an und fand unseren Scrum Master, der eine provisorische Planungstafel mit A4-Papier und transparentem Klebeband vorbereitete. Ich hatte keine Ahnung, was er tat. Wie jeden Morgen bereitete ich eine Kanne Kaffee zu und wartete darauf, sie zu sehen.

Als Sie fertig waren, wurde eine weiße Tafel an die Wand gehängt. Es hatte mehrere Säulen und verwandelte sich in eine rechteckige Form. Mehrere farbige Haftnotizen pfefferten die "Tafel". Das war vor zwei Jahren.

Das Board beherbergt jetzt den Lean-Entwicklungsprozess, den wir heute verwenden. Denken Sie daran, bei Agile dreht sich alles um Veränderung und Anpassung an Veränderungen. Befolgen Sie niemals blind die Regeln.

Also, was ist auf dieser Tafel?

Spalten für den Entwicklungsprozess

Es gibt vier Hauptspalten:

  • Rückstand bei der Freigabe - Hier befinden sich alle Storys der aktuellen Version. Ja, das Produkt ist nach jedem Sprint zur Veröffentlichung bereit, aber das bedeutet nicht unbedingt, dass wir es tatsächlich veröffentlichen. Wir haben normalerweise fünftägige Sprints.
  • Sprint-Rückstand - Wenn wir planen, verhandeln wir, was der Product Owner im Sprint abschließen möchte. Wie entscheiden wir, was wir vervollständigen können und was nicht? Durch Schätzen der Schwierigkeit jeder Geschichte (siehe unten - Schätzen von Geschichten). Das Endergebnis ist eine Reihe von Storys, die vom Release-Backlog in das Sprint-Backlog verschoben wurden. Das Team konzentriert sich darauf, diese Geschichten in der kommenden Woche fertigzustellen.
  • Arbeiten an - Dieser ist einfach. Wenn Teammitglieder eine Geschichte aufnehmen, fügen sie sie dieser Spalte hinzu, um allen zu zeigen, woran sie arbeiten. Dies dient der Mitarbeiterkontrolle, sondern der Kommunikation mit Teammitgliedern. Jeder sollte immer wissen, woran seine Teamkollegen arbeiten. Im obigen Bild enthalten die kleinen Lesezeichen auf den Haftnotizen die Namen meiner Teammitglieder.
  • Fertig - Vervollständige alle Dinge! Ja, hier gehen fertige Geschichten hin. Es ist jedoch wichtig zu definieren, "was getan wird". Am Ende eines idealen Sprints sollten alle Storys und Fehler aus dem Sprint-Backlog in dieser Spalte enthalten sein.

Tipp: Viele Teams teilen die Spalte "Arbeiten an" gerne in mehrere andere auf, um verschiedene Arbeitsphasen besser zu definieren. Wir haben unsere in Design, Entwicklung und Test aufgeteilt. Fühlen Sie sich frei, Ihre eigenen Schritte entsprechend Ihrem Prozess zu erfinden.

Die Definition von Fertig

Was wird gemacht? Wann können Sie sicher sagen, dass eine Geschichte vollständig ist? Woher wißen Sie das?

"Fertig" muss klar und präzise definiert sein, damit jeder weiß, wann eine Geschichte vollständig ist. Die Definition von "erledigt" kann von Team zu Team und sogar von Projekt zu Projekt unterschiedlich sein. Es gibt keine genaue Regel. Ich empfehle, dass Sie dieses Problem bei einer Teambesprechung ansprechen und entscheiden, was eine vollständige Geschichte bestimmt. Hier sind einige Ideen, die Sie berücksichtigen sollten:

  • Erstellen Sie ein minimalistisches Design.
  • Erstellen Sie ein GUI-Modell.
  • Verwenden Sie TDD oder stellen Sie sicher, dass Unit-Tests durchgeführt werden.
  • Schreiben Sie den Code.
  • Lassen Sie ein anderes Teammitglied Ihre Geschichte manuell testen.
  • Das gesamte System kann mit dem neuen Code erstellt und kompiliert werden.
  • Funktions- oder Abnahmetests bestehen erwartungsgemäß, nachdem der neue Code in das System integriert wurde.

Es gibt mehrere Ideen, die in die Definition von erledigt einbezogen werden können. Nehmen Sie das, was Sie für Ihr Team für notwendig halten, und nutzen Sie es. Vergessen Sie auch nicht, diese Definition im Laufe der Zeit anzupassen. Wenn Sie feststellen, dass Ihre Definition veraltet ist, können Sie einige Elemente entfernen oder notwendige, aber häufig vergessene Ideen hinzufügen.

Im obigen Bild beschreiben die grünen Haftnotizen, was wir für jeden Teil des Prozesses als erledigt angesehen haben.


Die Tafel bevölkern

Das war die Frage, die wir uns gestellt haben. Bis zu diesem Zeitpunkt haben wir keine Haftnotizen für die Planung verwendet. Wir haben Software verwendet, um User Stories und Bugs zu verfolgen, aber ansonsten haben wir nichts verwendet. Nach dem Mittagessen überreichte uns unser Scrum Master einen Berg farbiger Haftnotizen. Nachdem er ein Dutzend Notizen vorbereitet hatte, erklärte er sie uns.

Die Benutzergeschichten 

Eine Benutzergeschichte ist eine kurze Definition eines Features oder einer Funktion mit einem Satz.

Dies sind die Hauptfunktionen, die wir implementieren möchten. Eine User Story ist eine kurze Definition eines Features oder einer Funktion mit einem Satz. Es wird als User Story bezeichnet, da es aus der Perspektive eines Benutzers präsentiert wird. Der Begriff Benutzer ist natürlich die Person, die unsere Anwendung verwendet. Diese Person kann einer oder mehreren verschiedenen Kategorien zugeordnet sein: einem Systemadministrator, einem eingeschränkten Benutzer, einem Manager usw.

Ein Beispiel für eine solche Geschichte könnte ungefähr so klingen: "Als Benutzer möchte ich einen Ordner für meine Teamkollegen freigeben."

Zu diesem Zeitpunkt war noch kein Product Owner definiert, daher hat unser Scrum Master diese Geschichten erfunden. Dies ist zu Beginn akzeptabel, aber ich empfehle dringend, diese beiden Rollen zu trennen. Wie kann der Scrum Master ansonsten den Sprint-Rückstand mit dem Product Owner aushandeln?

Sie denken sich vielleicht: "Warum verhandeln? Ist es nicht besser, wenn eine einzelne Person entscheidet, was und wann zu tun ist?" Nicht ganz. Die beiden Rollen würden durch die Ansichten einer einzelnen Person über das System oder Projekt beeinflusst. Auf der anderen Seite haben zwei Personen eine bessere Chance, dem Team einen objektiveren Weg zu bieten, um sicherzustellen, dass das Endziel (bessere wertvolle Software) erreicht wird.

Der Product Owner sollte Benutzergeschichten definieren. Das Team sollte über ihre Ausführung verhandeln und der Scrum Master vertritt sie.

Usere Geschichte definieren alles Neue, was getan werden muss. Sie werden durch gelbe Haftnotizen auf unserer Tafel dargestellt.

Fehler, Fehler, Fehler 

Das Verfolgen Ihrer Fehler ist unglaublich wichtig.

Wir listen auch Fehler an der Tafel auf. Sehen Sie diese roten Haftnotizen? Dies sind die Fehler, die wir für die nächste Version beheben müssen.

Verschiedene Teams behandeln Fehler auf unterschiedliche Weise. Unser Team mischt die Fehler mit den Geschichten, aber wir beginnen einen Sprint immer mit der Behebung der Fehler.

Ich kenne andere Teams, die drei Sprints lang Fehler häufen und jeden vierten Sprint damit verbringen, sie zu reparieren. Andere teilen Sprints für Fehler/Geschichten in 25/75 auf. Außerdem arbeiten andere Teams möglicherweise morgens an Geschichten und nach dem Mittagessen an Fehlern. es kommt einfach auf das Unternehmen an.

Es liegt an Ihnen, die beste Lösung für Ihr Team zu finden und natürlich Ihre Fehler im Auge zu behalten. Schreiben Sie sie auf Haftnotizen, damit Sie die Probleme Ihres Systems und die Korrekturen für diese Probleme verfolgen können. Das Verfolgen Ihrer Fehler ist unglaublich wichtig.

Aufgaben oder Untergeschichten

Aufgaben werden aus Entwicklersicht als einfache Sätze geschrieben.

Im Idealfall sollte jede Geschichte kurz genug sein, um relativ einfach abgeschlossen zu werden, aber das Aufteilen von Geschichten in andere Geschichten kann sich als schwierig erweisen. Einige Projekte bieten diese Möglichkeit einfach nicht an. Trotzdem finden Sie große Geschichten, an denen mehrere Teammitglieder arbeiten können. Es ist wichtig, große Arbeitsstücke in kleinere, einfacher zu verwaltende Teile aufzuteilen.

Ein Ansatz teilt große Geschichten in Aufgaben auf. Aufgaben werden aus Entwicklersicht als einfache Sätze geschrieben. Beispielsweise kann die vorherige Geschichte zur Ordnerfreigabe in verschiedene Aufgaben unterteilt sein, z. B.: "Benutzeroberfläche für die Freigabe erstellen", "Mechanismus für die öffentliche Freigabe implementieren", "Zugriffssteuerungsfunktionen implementieren", "Kontrollkästchen für die Zugriffssteuerung zur Benutzeroberfläche hinzufügen" und demnächst. Der Punkt ist, dass Sie jedes Mal mehr über die Geschichte nachdenken müssen, wenn Sie sie in kleinere Aufgaben aufteilen. Ihr Team hat viel mehr Kontrolle über eine Geschichte, wenn Sie jedes Stück analysieren.

Wir verwenden hellblaue Haftnotizen für Aufgaben auf unserem Board. Schauen Sie in die letzte Spalte (die Spalte "Fertig") und Sie finden unsere Aufgaben unter den Benutzergeschichten-Stickies. Diese besondere Geschichte wurde in ungefähr vier Aufgaben unterteilt.

Technische Aufgaben

Bestimmte Aktivitäten müssen abgeschlossen sein, um eine Aufgabe, eine Geschichte oder den Sprint als Ganzes zu beenden. Diese Aufgaben beziehen sich normalerweise auf die Infrastruktur. Möglicherweise müssen Sie jedoch Änderungen am System vornehmen. Dieser Prozess kann Teil einer Geschichte sein oder nicht. Beispielsweise muss möglicherweise eine Drittanbieteranwendung installiert werden, um die Freigabefunktion Ihrer Anwendung zu implementieren. Ist das Teil unserer Benutzergeschichte? Möglicherweise, aber vielleicht auch nicht.

Wir haben festgelegt, dass diese Aufgaben von der eigentlichen Geschichte getrennt werden sollten. Dies hat uns geholfen, diese zusätzlichen Aufgaben besser zu verfolgen. Auf unserer Tafel finden Sie diese Aufgaben auf grünen Haftnotizen. Es gibt einen im Sprint-Rückstand und ungefähr drei im Test.

Der technische Rückstand 

Für ein junges Team mit wenig Erfahrung mit Agile und Scrum ist es hilfreich, diese Aufgaben mit einem Mini-Rückstand hervorzuheben.

Dieser Rückstand dient infrastrukturellen Aufgaben wie der Aktualisierung des automatisierten Testsystems, der Konfiguration eines neuen Servers und anderen Dingen, die unsere tägliche Entwicklungsarbeit erleichtern. Dies sind Dinge, die irgendwann erledigt werden müssen, aber nicht direkt mit der Entwicklung zusammenhängen.

Sie müssen diese Elemente nicht in einem separaten Rückstand ablegen. Tatsächlich kenne ich Teams, die sie nicht trennen. Unser Team hat vor einigen Monaten unseren technischen Rückstand abgebaut. Wir haben entschieden, dass Infrastrukturaufgaben genauso wichtig sind wie andere Aufgaben. Für ein junges Team mit wenig Erfahrung in Agile und Scrum ist es jedoch hilfreich, diese Aufgaben mit einem Mini-Rückstand hervorzuheben. Ich empfehle Ihnen daher, es auszuprobieren. Möglicherweise funktioniert es für Sie, und wenn nicht, legen Sie einfach Infrastrukturaufgaben auf Ihre Plantafel, möglicherweise in einer anderen Farbe.


Die große Herausforderung: Schätzung

Während eines Planungsmeetings entscheiden wir, welche Benutzergeschichten und Fehler aus dem Produkt-Rückstand (oder in unserem Fall dem Release-Rückstand) in den nächsten Sprint aufgenommen werden sollen. Das mag einfach klingen, ist aber in Wirklichkeit ziemlich kompliziert.

Der Product Owner legt eine Reihe von Geschichten vor, an denen er arbeiten kann. Diese Liste enthält normalerweise mehr Arbeit als im Sprint erledigt werden kann. Der Scrum Master muss zusammen mit dem Team den Product Owner davon überzeugen, was während eines Sprints getan werden kann. Mit der Zeit wird dieser Prozess einfacher, da der Product Owner die ungefähre Geschwindigkeit des Teams erfährt. Andererseits kann das Team mit jedem Sprint produktiver werden, sodass mehr Geschichten fertiggestellt werden können. Der Trick ist, ein Team zu haben, das die Erwartungen wirklich übertreffen will!

Jetzt möchte der Produktbesitzer mehr Geschichten fertigstellen, als wir im Sprint tun können. Wir müssen den Arbeitsaufwand schätzen, den wir in Bezug auf die vom Produktbesitzer eingereichten Geschichten leisten können, und wir können dies auf verschiedene Arten tun.

Geschichte Punkte 

Geschichte Punkte sind eine der häufigsten Methoden zum Schätzen von Geschichte, Fehlern oder Aufgaben. Sie sind nicht unbedingt der beste Ansatz, aber dennoch ein guter Anfang.

Was ist ein Geschichte Punkt? Zu Beginn des Prozesses sucht das Team nach der einfachsten Geschichte, die es an der Tafel finden kann. Es spielt keine Rolle, wie schwierig es ist oder wie lange es dauert, bis es fertig ist. Wenn sie diese Geschichte finden, setzen sie sie als Referenzgeschichte für einen Punkt. In einigen Projekten kann eine solche Geschichte so einfach sein wie das Reparieren von UI-Elementen in zehn Minuten. Die einfachste Geschichte für komplexere Systeme kann zwei Stunden dauern, bis drei Personen fertig sind. Nachdem Sie eine Basislinie haben, bewerten Sie die anderen Geschichten und Fehler und weisen Sie ihnen Punkte zu.

Dies kann schwieriger sein, als es scheint, und es gibt verschiedene Punkttechniken, mit denen sich Geschichten besser einschätzen lassen. Hier sind zwei davon:

  • Verwenden Sie Fobinacci-Zahlen - 1,2,3,5,8 (und vielleicht 13, aber eine 13-fache Geschichte riecht für mich zu groß).
  • Verwenden Sie Potenzen von 2 - 1,2,4,8 (und vielleicht 16, aber diese Zahl sollte vermieden werden).

Sie können frei wählen, womit Sie sich am wohlsten fühlen. Sei agil! Vielleicht möchten Sie zwei Punktschritte verwenden, weil Ihre Aufgaben am besten auf diese Weise geschätzt werden. Bravo an Sie! 

Semaphoren

Zahlen sind großartig und viele technische Leute lieben sie. Möglicherweise stellen Sie jedoch fest, dass Programmierer irgendwann beginnen, Story-Punkte mit der Zeit zu verknüpfen. Sie werden denken: "Ich brauche zwei Tage, um das zu tun. Geben wir fünf Punkte." Das ist falsch. Schätzungen werden immer schlimmer, wenn dies geschieht. Geschichte Punkte sollten sich niemals auf die Zeit beziehen.

Die Verwendung von Semaphorfarben kann helfen, dieses Problem zu beheben. Anstatt Geschichten Geschichten zuzuweisen, kann das Team diese Geschichten mit Farben verknüpfen. Unser Team hat diese Änderung vor einigen Monaten vorgenommen und sie hat uns sehr geholfen, unsere Sichtweise zu ändern.

Natürlich hat jede Farbe eine andere Bedeutung.

  • Grün bedeutet eine einfache Aufgabe, die im nächsten Sprint erledigt werden kann.
  • Gelb bezieht sich auf eine schwierigere Aufgabe - eine, die mehr Aufwand von mehreren Teammitgliedern erfordert. Es hat auch eine hohe Chance auf Abschluss im nächsten Sprint.
  • Rote Etiketten werden Geschichten zugewiesen, die extrem schwierig sind und möglicherweise nicht in einem einzigen Sprint beendet werden. Es sollte wenig bis gar keine solchen Geschichten geben, aber wenn Sie Sprints von einer Woche annehmen, sind fünf Tage eine kurze Zeit.

T-Shirt Größen

Zahlen können für Sie hässlich sein, Farben zu künstlerisch. Es ist Zeit für T-Shirt Größen! Diese Technik schlägt vor, den Vergleich der Komplexität der Geschichte mit dem Zeitpunkt der Fertigstellung aufzugeben. Einfach ausgedrückt, verwenden Sie anstelle von Zahlen Größen wie S, M, L, XL, XXL für Ihre Geschichten.

Ich persönlich habe mich nie von dieser Art von Einschätzung angezogen gefühlt, aber einige glauben, dass dies der beste Weg ist. Probieren Sie es aus, wenn Sie sich mit der Idee wohl fühlen.


Der Product Owner, die Stakeholder und die Manager müssen wissen, was sie vom Ende eines Sprints erwarten können. Sie müssen entscheiden, ob die Geschichten, an denen gearbeitet wurde, veröffentlicht werden sollen, und sie müssen wissen, wann die Funktionen fertig sind. Es ist keine gute Lösung, alle neuen Funktionen am Ende des Entwicklungszyklus eines Produkts freizugeben. Die häufigere Veröffentlichung der wertvollsten Funktionen ist ein wesentlich besserer Weg. Um dies zu erreichen, müssen sie wissen, was kurzfristig verfügbar sein wird, und ihre Informationen sollten vom Team stammen. Daher sollte das Team die Arbeit, die es im Sprint leisten kann, so gut wie möglich einschätzen.


Entwicklungsgeschwindigkeit messen

Sie möchten also sehen, wie gut Sie im aktuellen Sprint abschneiden? Eine häufig verwendete Methode ist das Burndown-Diagramm:

In dieser Tabelle haben wir einen fünftägigen Sprint und wir gingen davon aus, dass wir zehn Punkte im Sprint erreichen könnten. Jeder Wertpunkt repräsentiert die verbleibenden Story-Punkte am Ende eines jeden Tages. Die grüne Linie zeigt den idealen Weg: zwei Punkte pro Tag. Die rote Linie zeigt unsere tatsächliche Leistung oder die tatsächliche Entwicklungsgeschwindigkeit.

Es ist nicht auf dem Bild der Plantafel zu sehen, aber mein Team hatte früher ein A4-Blatt Papier über der Plantafel mit der Burndown-Tabelle für jeden Sprint. Am Ende eines jeden Tages war eines der Teammitglieder für die Berechnung der für diesen Tag erzielten Punkte verantwortlich. Es ist ganz einfach: Wenn Programmierer die Geschichte während der Arbeit von Spalte zu Spalte verschieben, ist es einfach, die verbleibenden unvollendeten Geschichten zu finden.

Es gibt keine halbfertigen Geschichten. Wenn eine Geschichte fertig ist, ist sie fertig. Wenn es nicht vollständig ist, wird es nicht in der Burndown-Tabelle gezählt.

Natürlich werden Sie - GROSSE ZEIT - beim Schätzen versagen! Dies gilt insbesondere am Anfang. Es gibt leider keine Möglichkeit, dies zu vermeiden. Es gibt keine Möglichkeit zu wissen, wie viele Punkte Sie liefern können. Ihr erstes Diagramm könnte sehr gut aussehen:

Unser erstes Diagramm sah dem sicherlich ähnlich. Ich denke, wir haben nicht einmal die Hälfte unseres Engagements abgeschlossen. Warum? Nun, weil die Schätzung schwierig ist. Egal, was Sie tun oder wie gut Sie sind, wenn Sie jemand fragt, wie kompliziert etwas ist, das Sie noch nie zuvor getan haben, fällt es Ihnen schwer, eine genaue Schätzung abzugeben. Keine Panik! Versuch dein Bestes. Mit der Zeit werden diese Dinge einfacher. Möglicherweise können Sie irgendwann für kurze Sprints mit einer Genauigkeit von 70% schätzen. Wenn die Sprints länger sind, ist Ihre Genauigkeit wahrscheinlich geringer, da mehr Geschichten zu schätzen sind und mehr Variablen schief gehen können.

In diesem Fall passen Sie an. Für den nächsten Sprint nehmen Sie vier Punkte. So was:

Das ist wieder schlecht. Sie waren zu konservativ und haben früh Schluss gemacht. Es ist eine natürliche Reaktion des Teams, sich anzupassen, basierend auf dem Scheitern der vorherigen Schätzung. Trotzdem ist dies wieder ein Misserfolg, aber auf der anderen Straßenseite.

Das Problem? Was machen Sie, nachdem Sie fertig sind, was Sie geplant haben? Eine andere Geschichte? Wie bringen Sie das auf die Karte? Sie können die ursprüngliche Linie nicht neu zeichnen.

Bei der Arbeit mit Burndown-Diagrammen wird empfohlen, immer einen Durchschnitt der letzten 3-5 Diagramme zu erstellen, um die Punkte für den bevorstehenden Sprint anzugeben. Natürlich stehen Ihnen zu Beginn solche Informationen nicht zur Verfügung, sodass Sie nicht so genau sind wie in der Zukunft. Das ist okay.

Nach einiger Zeit ähneln Ihre Diagramme immer mehr dem ersten Beispiel. Sie werden die meiste Zeit alle Geschichten beenden und eine anhaltende Geschwindigkeit haben.

Geschwindigkeit?

Dieser Begriff bezieht sich auf Ihre Entwicklungsgeschwindigkeit. Es bezieht sich darauf, wie viel Sie in einem Sprint tun können. Eines der wichtigsten Konzepte in Agile ist eine konstante Geschwindigkeit. Lassen Sie das Team in einem konstanten Tempo liefern. Beim herkömmlichen Projektmanagement nimmt die Geschwindigkeit mit zunehmendem Alter des Projekts ab. Komplexität und Steifheit verringern die Entwicklungsgeschwindigkeit.

Agile Methoden und Techniken zielen darauf ab, ein konstantes Tempo aufrechtzuerhalten. Liefern Sie jetzt schnell und später schneller. Wie machen Sie das? Scrum ist eines der Elemente des Puzzles. Andere wichtige Teile sind die Techniken, mit denen Programmierer ihren Code und ihren Entwicklungsprozess verbessern können. Zum Beispiel XP (eXtreme Programming), Pair Programming, TDD (Test Driven Development) usw. All dies zusammen kann ein Team wirklich großartig machen.

Wir messen diese Geschwindigkeit, aber was machen wir eigentlich damit?

Tipp: Das Messen der Geschwindigkeit dient dazu, bessere Vorhersagen zu treffen. nicht für die Beurteilung eines Teams oder seiner Mitglieder.

Verwenden Sie die Geschwindigkeit, um zu wissen, was Ihr Team tun kann. Verwenden Sie die Geschwindigkeit, um zu wissen, was Sie erwartet. Verwenden Sie Geschwindigkeit, damit Ihr Team mehr will und besser wird. Verwenden Sie niemals Geschwindigkeit, um Ihr Team zu beurteilen oder die Produktivität Ihrer Programmierer zu bewerten.


Immer zurückblicken und verbessern

Nach den ersten Sprints versammelte unser Scrum Master das gesamte Team. Er begann uns nach den guten und schlechten Dingen der letzten Woche zu fragen. Das mag am Anfang unangenehm sein, ist aber immer noch unglaublich wichtig. Wenn Sie beschreiben, was in der letzten Woche schief gelaufen ist, schaffen Sie Bewusstsein. Und natürlich ist es auch hilfreich hervorzuheben, was gut gelaufen ist!

Diese Treffen werden normalerweise als Rückblicke bezeichnet. Sie bieten die Möglichkeit hervorzuheben, was gut war und was schief gelaufen ist. Hier einige Beispiele aus meinen eigenen Rückblicken.

Schlechte Dinge

  • Die Teammitglieder kämpften zu viel
  • Teammitglied X oder Y war bei der Paarprogrammierung nicht kooperativ
  • Wir haben zu viel Zeit mit kleinen Dingen wie X oder Y verloren
  • Wir haben das Programm nicht die ganze Zeit gepaart
  • Wir haben keine Unit-Tests für Modul M geschrieben

Versuchen Sie bei der Diskussion von Problemen, Ihre persönlichen Gefühle beiseite zu legen. Sprechen Sie darüber, was Sie stört. Dies ist die einzige Möglichkeit für das Team, das Problem zu beheben. Das Wichtigste ist, sofort eine Lösung für jedes Problem vorzuschlagen. Lassen Sie die Liste nicht einfach schreiben und vergessen. Bleiben Sie ein paar Minuten und lassen Sie das gesamte Team darüber nachdenken, was getan werden kann, um sie nächste Woche zu vermeiden.

Gute Dinge

  • Wir waren pünktlich fertig
  • Wir konnten reden ohne zu kämpfen
  • Einige von uns wurden empfänglicher für Vorschläge und Ideen
  • Wir haben den gesamten Code mit TDD geschrieben

Heben Sie wieder so viele gute Dinge wie möglich hervor - besonders zu Beginn oder mit Junior-Programmierern. Zum Beispiel kann es für ein Juniorenteam eine große Leistung sein, den gesamten Code mit TDD schreiben zu lassen. Lassen Sie sie sich wirklich gut fühlen, lassen Sie sie es immer mehr tun. Gleiches gilt für eine A-Nationalmannschaft. Sie haben einfach andere Dinge hervorzuheben (TDD erfolgt durch Reflex).


Ich möchte sehen, was Sie diesen Sprint gemacht haben

Die Demo dient dazu, den Stakeholdern (und dem Product Owner) den Fortschritt des Projekts zu zeigen.

Diese Überschrift stammt aus den Worten meines Scrum Masters. Zu diesem Zeitpunkt war er auch der Produktbesitzer. Vor dem Ende eines Sprints bat er uns, ihm das zu präsentieren, was wir erreicht hatten. Wir haben eine Demo oder ein Arbeitsbeispiel in einer kontrollierten Umgebung vorbereitet.

Scrum schlägt diese Demos am Ende jedes Sprints vor. Diese sollten vor dem oben diskutierten retrospektiven Treffen erfolgen. Das Team sollte eine spezielle Umgebung vorbereiten und sicherstellen, dass das Produkt die in diesem Sprint durchgeführten Funktionen präsentieren kann. Die Demo dient dazu, den Stakeholdern (und dem Product Owner) den Fortschritt des Projekts zu zeigen.

Sie fragen sich vielleicht, warum ich eine kontrollierte Umgebung erwähnt habe, wenn unser Produkt am Ende jedes Sprints produktionsbereit sein sollte. Ja, das Produkt sollte so nah wie möglich an der Produktion sein, aber das bedeutet nicht, dass die Funktion selbst bereit ist. Oft gibt es Features, die zu groß sind, um in einen einzelnen Sprint zu passen. Das Produkt bleibt stabil, aber die Funktion ist noch nicht vollständig verfügbar. Wenn Stakeholder die Demo sehen, möchten sie die Funktion und ihre Funktionen überprüfen. In vielen Fällen müssen zunächst spezielle Umgebungen vorbereitet werden, um einige Funktionen für unfertige Features zu präsentieren.

Basierend auf diesen Demos kann der Product Owner außerdem feststellen, dass eine größere Funktion gut genug ist und eine neue Version des Produkts veröffentlicht und an die Benutzer gesendet werden sollte. Selbst wenn eine Funktion nicht vollständig ist, hilft eine Version dem Projekt in den meisten Fällen dabei, wertvolles Benutzer-Feedback zu erhalten und die Fertigstellung der Funktion so zu konzentrieren, dass möglichst viele Benutzer zufrieden sind.

Das klingt ganz einfach. Sie sind ein agiles Team, halten Ihre Tests immer auf grün und Ihr Produkt befindet sich in einem stabilen Zustand. Wie schwierig kann es sein, eine schnelle Demo vorzubereiten? Es ist schwieriger als Sie vielleicht denken!

Wenn ich mich richtig erinnere, brauchte unser Team mehr als fünf Versuche, bevor wir die Demo richtig vorbereiten konnten. Zum Glück waren die Stakeholder in diesen ersten fehlgeschlagenen Demos nicht enthalten!


Dennoch brauchen wir mehr Anleitung

In diesen Besprechungen muss jedes Teammitglied drei Fragen beantworten.

Es war der Moment, in dem unser Scrum Master vorschlug, jeden Tag ein Treffen abzuhalten. Ja! Jeden Tag, jeden Morgen, genau zu einer Stunde!

Ich finde das sehr gut für neue Teams - für Leute, die noch nicht miteinander oder mit dem Projekt vertraut sind. Diese täglichen Besprechungen, die als Daily Scrum bezeichnet werden, werden täglich zu einer bestimmten Zeit im Team abgehalten. Dies sollte aufbewahrt werden, bevor Arbeiten für den jeweiligen Tag ausgeführt werden. In meinem Team haben wir die Zeit jeden Morgen auf 10 Uhr eingestellt, was schwierig war. Trotzdem war es die richtige Entscheidung.

Das tägliche Gedränge ist eine kurze und einfache Besprechung (nicht länger als fünfzehn Minuten). Ziel ist es, den Teammitgliedern zu helfen, zu erkennen, wer was tut, und festzustellen, wo die Probleme und Engpässe im Entwicklungsprojekt liegen.

Tipp: Da wir sicherstellen möchten, dass diese Besprechungen kurz bleiben, stehen wir auf. Menschen werden normalerweise nach 15 Minuten Stehen müde, was perfekt ist! Wenn Sie Mitarbeiter finden, die nach Sitz- und Ruheplätzen suchen, hat Ihre Besprechung wahrscheinlich zu lange gedauert.

In diesen Besprechungen muss jedes Teammitglied drei Fragen beantworten:

  • Was haben Sie gestern gemacht? - Eine kurze Antwort wird erwartet - maximal 2-3 Sätze.
  • Was haben Sie heute vor? - Dieselbe Art von kurzer Antwort, Dinge wie "Ich werde heute an dieser Geschichte arbeiten."
  • Gibt es Probleme mit Ihrem Prozess? Wenn ja, was? Können sie schnell gelöst werden? Dies sollte eine Antwort sein, die die Probleme und Lösungen hervorhebt, falls bekannt. Während dieses Treffens sollten keine detaillierten Diskussionen geführt werden. Der Scrum Master sollte das Problem zur Kenntnis nehmen und gemeinsam mit dem Team daran arbeiten, es zu lösen, nachdem das Meeting unterbrochen wurde.

Die Lösung der Probleme und Hindernisse für Entwickler sollte für das Team eine hohe Priorität haben, damit sie ihre Entwicklung so schnell wie möglich fortsetzen können. Oft ist die Person, die das Problem hatte, in der Lage, es rechtzeitig zu lösen. In anderen Fällen benötigt er oder sie die Hilfe eines Teamkollegen. Und ein anderes Mal kann das Problem so schwerwiegend sein, dass das Team die Entwicklung stoppen und sich ausschließlich auf die Lösung der einen Sache konzentrieren muss, die sie daran hindert, ihre Arbeit fortzusetzen.

Ich erinnere mich, dass mein Team bei verschiedenen Gelegenheiten auf diese riesigen Straßensperren gestoßen ist. Es gab Aufgaben und Geschichten, die auf den ersten Blick ganz offensichtlich waren, aber nachdem ein Paar oder ein einzelner Programmierer die Chance hatte, sich in das Problem zu vertiefen, wurde das Offensichtliche verwirrend und falsch. Wir haben mehrmals festgestellt, dass eine Bibliothek eines Drittanbieters uns nicht die benötigte Funktionalität bieten konnte, und haben schließlich alle unsere Bemühungen darauf konzentriert, eine andere, leistungsfähigere Bibliothek zu finden - oder sogar selbst eine Lösung zu implementieren.

Der größte Teil unseres Projekts ist in PHP geschrieben. An einem bestimmten Punkt mussten wir unser Projekt mit VMWare verbinden. Wir haben die offiziellen Bibliotheken für die VMWare-API überprüft und herausgefunden, dass es Java- und Perl-Versionen gibt. Es gibt auch eine inoffizielle Ruby-Option. Wir waren uns sicher, dass wir eine davon verwenden und einfach ein paar exec()-Aufrufe von PHP aus machen könnten, um die Ausgabe als String zu erfassen. Wie wir dachten, sollte das Parsen von dort aus ein Kinderspiel sein.

Es stellte sich heraus, dass dies so gut wie unmöglich war. Keine der API-Bibliotheken funktionierte ganz so, wie wir es erwartet hatten. Einige waren aufgegeben oder unvollständig, und sie hatten fast unmöglich zu parsende Ausgaben. Letztendlich waren wir gezwungen, etwas zu tun, was noch nie jemand zuvor getan hatte: eine VMWare-API-Bibliothek in PHP zu implementieren. Leider gab es keinen anderen einigermaßen akzeptablen Weg, dies zu tun.

Dieses Problem war massiv; es hat die ursprünglichen Pläne um Wochen zurückgeworfen! Natürlich wurde unser Product Owner sofort benachrichtigt, und gemeinsam mit ihm planten wir einen neuen Zeitplan und entwickelten neue Stories, die die Erstellung dieser API-Bibliothek beinhalteten.

Meistens werden Ihre Probleme viel kleiner sein. Die Leute bleiben vielleicht bei einer etwas anspruchsvolleren Logik hängen, aber oft haben sie am nächsten Morgen schon Ideen und Lösungen. Ein anderes Mal sind sie einfach auf dem falschen Weg, und ein Teamkollege muss ihnen helfen, wieder auf den richtigen Weg zu kommen. Dies sind Ihre typischen Probleme.


Schlussfolgerung

Hier sind wir beim Abschluss. Zumindest hat mein Team auf diese Weise mit Scrum angefangen. Einige Regeln waren sehr nützlich, andere weniger. Außerdem waren einige Regeln nur für eine kurze Zeit nützlich, während andere von unserem Team immer noch religiös respektiert werden.

Ich kann Ihnen nur empfehlen, sich auf den agilen Prozess einzulassen, Scrum auszuprobieren und Ihre eigenen Schlüsse zu ziehen. Ich bin mir sicher, dass Sie Teile finden werden, die Sie für Ihr Team übernehmen können. Seien Sie agil, passen Sie es an Ihren Arbeitsstil, an Ihre Projekte und Ihre Persönlichkeiten an und scheuen Sie sich nicht, eigene Regeln hinzuzufügen.

Schließlich bedeutet Agilität Anpassung und nicht das blinde Befolgen eines vorgegebenen Regelwerks!

Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.