Umstellung auf Scrum – 6 Monate danach

Werbung

In diesem Artikel geht es darum, dass wir vor 6 Monaten die Entwicklungsweise eines Projekts auf Scrum umgestellt haben. Hier möchte ich dazu meine Erfahrungen vor und nach dieser Zeit erzählen. Dieses erzähle ich aus der Sicht eines Senior PHP Developers.

Ich reiße auch kurz die Rollen und die Funktionsweise von Scrum an. Dies soll allerdings kein spezialisierter Artikel über Scrum werden. Dafür gibt es anderweitige Literatur, die ich am Schluss des Artikels aufführen werde.

Das Projekt

Bei dem Projekt handelt es sich um Traktorpool, einem Marktplatz für gebrauchte Landwirtschaftsmaschinen. Es ist ein Projekt des Landwirtschaftsverlags in Münster, welcher auch mein Arbeitgeber ist.

Zustand vor Scrum

Bereits vor der Umstellung auf Scrum haben wir mit Release Zyklen (in Scrum Sprints) und morgendlichen Stand Up’s (in Scrum Daily Scrum Meeting) gearbeitet. Ein Release Zyklus ging über vier Wochen, wobei sich diese in drei Wochen Programmierung und einer Woche Testphase unterteilten. Während der Testphase, die nicht von den Entwicklern durchgeführt wurde, hatten die Entwickler hauptsächlich die Aufgabe Nachbesserungen durchzuführen. Die meisten entstanden aus nicht definierten Anforderungen oder Verständnisproblemen. Nach den vier Wochen wurden die Änderungen in das Livesystem veröffentlicht (released).

Nach fast jedem Release gab es eine mehr oder weniger hohe Anzahl von Fehlern, die nachträglich behoben werden mussten. Oftmals waren dies sehr kleine Fehler, aber dennoch störend für die Benutzer des Portals.

Alle Features, und weniger wichtigen Bugfixes wurden im Bugtracker Mantis festgehalten. Vor jedem Release wurde dann aus diesem Pool eine Anzahl von Positionen für die dreiwöchige Programmierphase ausgewählt und nach Wichtigkeit eingeteilt. Die Auswahl traf die zuständige Fachabteilung ohne dabei mit dem Entwicklerteam zu sprechen. Somit haben wir quasi die Aufgaben vorgesetzt bekommen.

Wir versuchen Mal Scrum zu machen

So, oder zumindest so ähnlich hat es angefangen, als wir einen neuen Produktmanager bekommen haben, der technisch ganz anders an das Projekt heran ging. Dies ist aber auch seinem Hintergrund geschuldet. Er ist ebenfalls PHP Entwickler und kennt somit viel mehr die Sorgen und Nöte, die innerhalb eines Programmierteams entstehen.

Unser Programmierteam hatte also wirklich die Wahl, zumindest wurde es so besprochen. Ehrlich gesagt weiß ich nicht, ob wir noch zurück gekonnt hätten, wenn wir gewollt hätten. Gott sei Dank ist die Antwort auf diese Frage auch nicht wichtig, da wir auf keinen Fall wieder zurück wollen.

Das Scrum Team

Hier ist es wichtig zu verinnerlichen, dass es sich um ein Team handelt. Der Erfolg des Projekts ist über allem zu stellen. Es soll keine Eitelkeiten oder Neid unter den einzelnen Teammitgliedern geben. Ist ein Teammitglied in Schwierigkeiten, helfen die anderen im Team so gut sie können.

Die Rollen im Team – Der Product Owner

Eine der wichtigsten Rollen im Scrum Team ist die des Product Owners. Er entwickelt die Konzepte für die Projekte und ordnet diese nach der Priorität ein. Diese Konzepte werden in einem Product Backlog festgehalten. Dabei handelt es sich um eine priorisierte Liste mit Anforderungen und umfassen auch nicht nur ein Release. Aus dieser Liste entwickelt der Product Owner User Stories. User Stories sind aus der Sicht des jeweiligen Anforderungssteller in einer, nach Möglichkeit, nichttechnischen Schreibweise verfasst.

Was jetzt vielleicht kompliziert geklungen hat, ist aber gar nicht so schwer.

Beispiel:

Ich gehe davon aus, dass wir einen Onlineshop haben, der Bücher anbietet. Jetzt brauchen wir für den Shop eine Funktion mit der dem potenziellen Käufern auf der Detailseite zu einem bestimmten Buch noch weitere Bücher präsentiert werden, die auch interessant sein könnten.

Diese User Story könnte man jetzt auch der Sicht des Käufers oder aus der Sicht des Marketings schreiben.

Aus Sicht des Käufers:

Damit ich einen besseren Überblick hat welche Bücher für mich noch interessant sein könnten, möchte ich als Käufer, ähnliche Bücher übersichtlich angezeigt bekommen.

Aus Sicht des Marketings:

Damit wir unseren Absatz von Büchern steigern, möchte ich als Marketingverantwortlicher, dass dem Käufer ähnliche Bücher angezeigt werden.

Wie man sieht, sind das zwei sehr ähnliche User Stories, von der aber Beide profitieren können.

Zu einer User Story können auch noch eine Reihe von Akzeptanzkriterien definiert werden, die erfüllt werden müssen, damit die User Story erfolgreich abgearbeitet wurde.

Beispiel von Akzeptanzkriterien:

  • Auf jeder Buchdetailseite gibt es 5 alternative und zum Thema passende Angebote
  • Die Angebote werden mit Vorschaubild in der Größe 80×80, dem Titel und einem Link zur Detailseite angezeigt
  • Klickt der Benutzer auf einen dieser Links, so gelangt er zur Detailseite des Angebots
  • Auf der Detailseite des angeklickten Angebots gibt es einen Zurück Button auf die Detailseite des ursprünglichen Angebot

Die Akzeptanzkriterien beschreiben so genau wie möglich die Anforderungen ohne dabei den Entwickler zu sehr einzuengen. Wichtig ist, dass alle Merkmale beachtet werden und das bei Unklarheiten diese bereits im Sprint Planning Meeting 1 (später dazu mehr) besprochen werden. Sollten Probleme bei der Umsetzung während der Programmierung auftreten, so muss der Product Owner darüber informiert und eine Lösung gesucht werden.

Die Persönlichkeit des Product Owners

Der Product Owner sollte eine motivierende und nicht kolerische Person sein. Ich bin der Meinung, dass die optimale Besetzung des Product Owner Postens sehr entscheidend für den Erfolg des Projekts ist. Bei unerwartet auftredenden Fehlern ist keinem geholfen, wenn der Product Owner in die Entwicklungsabteilung rennt und dort seinem Ärger freien Lauf lässt. Das zieht nur die Entwickler runter und mit Sicherheit steigt dadurch nicht die Motivation.

In unserem Team haben wir das Glück einen motivierten und meiner einer Vision versehenen Product Owner zu haben, der Aufgaben klar definieren kann und das dazu nötige Wissen hat.

Die Rollen im Team – Der Scrum Master

Was sich im ersten Moment anhört wie der oberste Chef im Team, trifft nicht zu. Der Scrum Master ist der ruhende Pol im Scrum Team und auch für das Gelingen zuständig.

Da wir zu Beginn unseres Scrum Versuchs über keinerlei fortgeschrittene Erfahrung bezüglich Scrum verfügten, führte unser Product Owner Scrum ein bzw. leitete den Scrum Master ein. Das Glück unseres Teams war es, dass wir eine Person mit Scrum Erfahrung hatten, nämlich den Product Owner und eine weitere Person, die Bock darauf hatte den Scrum Master zu machen. Weiter half uns auch die Einstellung aller Beteiligten, die einfach Lust darauf hatten Scrum auszuprobieren. Mit allen Konsequenzen daraus.

Der Scrum Master sollte kein Vorgesetzter sein, weil man sonst wieder in die Versuchung kommt, dass Scrum Team lenken zu wollen. Diest ist aber nicht die Aufgabe eines Scrum Masters. Er muss Störungen beseitigen können, die innerhalb eines Sprints auftreten können. Nach Möglichkeit sollten diese Störungen auch für die Zukunft vermieden werden. Als Beispiel sei hier z.B. den Abzug eines Programmierers in ein anderes Projekt genannt oder der immer besetzte Konferenzraum, wenn Meetings stattfinden sollen.

Dies wird bei uns gut gelöst und bisher sind dabei kaum Probleme aufgetreten und wenn, dann sind sie schnell beseitigt worden.

Die Rollen im Team – Die Entwickler

Ich schreibe hier bewusst „Die Entwickler“ und nicht „Das Entwicklungsteam“. Dies würde bereits den Scrum Master und den Product Owner aus dem Team ausgrenzen. Zwar geschieht dies nur auf dem Papier, aber trotzdem sollte man dies im Ansatz schon vermeiden.

Die Größe des Teams sollte so groß sein, dass Abhängigkeiten von außen vermieden werden. Das bedeutet, dass zum Beispiel auch jemand für die Konfiguration der Server oder zumindest dafür verantwortlich sein, dies in Auftrag zu geben. Ich möchte hier keine Empfehlung für die Größe abgeben, da ich der Meinung bin, dass man theoretisch Scrum auch alleine machen kann. Alleine? Ja, zumindest in den Grundzügen kann man danach arbeiten. Bei den bereits erwähnten und später noch konkretisierten Meetings, wird das zwar recht einsam, aber hauptsächlich geht es um die Verinnerlichung der Methode. In einem größeren Team, also wenn man nicht Alleinunterhalter ist, sollte man allerdings Scrum so komplett wie möglich durchziehen und nicht versuchen zu viele Abkürzungen zu nehmen.

Wir als Entwickler organisieren die Umsetzung des Sprints alleine. Also wir haben keine, der uns sagt wie wir was zu tun haben. Dafür haben wir uns in Sprint Planning 1 dazu verpflichtet alle angenommenen User Stories in dem Sprint auch abzuarbeiten und fertig zu kriegen. Ja, als Entwickler hat man in Scrum die Freiheit die Anzahl der Stories zu bestimmen, allerdings nicht in welcher Priorisierung. Dies ist die Aufgabe des Product Owners. Wenn wir Entwickler dann vor einem Sprint der Meinung sind, wir haben bereits genug User Stories im Sprint, dann ist das so und kann von uns auch begründet werden.

Neben der Programmierung haben wir als Entwickler auch die Aufgabe im Schätzmeeting die anstehenden Aufgaben (User Stories) zu schätzen. Dabei geht es nicht um eine Stunden, Tage, Wochen oder Monate Einteilung, sondern hier wird nach Aufwand geschätzt.

Wir erledigen mit dem sogenannten Planning Poker. Wir benutzen dabei Karten, die den Aufwand einer User Story darstellen und zwar in der Wertigkeit 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, sowie ein ? und eine Kaffeetasse. Wie ich erst jetzt beim recherchieren für diesen Artikel festgestellt habe, ist dies eine kommerzielle Abwandlung der eigentlichen Fibonacci Folge, die ja korrekterweise 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 lauten würde.

Die Fibonacci oder abgewandelte Form wird benutzt, da je schwieriger eine Aufgabe ist, desto ungewisser ist die Schätzung. Unser Product Owner versucht daher schon vorher die User Stories so klein wie möglich zu halten, also maximal schätzen wir in der Regel bis 20.

Jeder Entwickler besitzt ein komplettes Kartenset und darf pro User Story eine Karte, erst verdeckt, auf den Tisch legen. Haben alle Entwickler ihre Karte auf den Tisch gelegt, werden alle gleichzeitig umgedreht. Sind die Werte einen Wert auseinander, also es liegen nur Karten der Wertung 8 und 13 auf dem Tisch, erhält die User Story die höhere Wertung, also die 13. Sind die Unterschiede größer, also liegen Karten der Wertigkeit 5, 8 und 13 auf dem Tisch, wird diskutiert. Dabei entstehen bereits fruchtbare Diskussionen. Nicht jeder Entwickler kennt die Anwendung bis auf die letzte Codezeile. Aber vielleicht hat ein Entwickler vor kurzem in dem Bereich gearbeitet, der jetzt dafür zuständig ist, die User Story abzuarbeiten. Somit hat er einen Wissenvorsprung und evtl. kennt er auch die Tücken, die dort entstehen können. Nach dieser Diskussion werden die Karten wieder aufgenommen und neu ausgelegt. So nähert man sich an einen gewissen Wert an.

Wir haben bisher nicht mehr als zwei Versuche gebraucht um uns auf einen Wert zu einigen, bzw. es kommt auch vor, dass wir in der zweiten Runde einen Wert auseinander liegen, zum Beispiel 8 und 13. Dann wird wie bereits erwählt die höhere Wertigkeit genommen.

Werbung

Unser Schätzmeeting geht in der Regel eine Stunde und dies führen wir einmal in der Woche durch.

Die Rollen im Team – Das Management

Im Prinzip kommt dem Management die Aufgabe zu, alles zu tun, damit das Scrum Team in Ruhe arbeiten kann. Dazu gehören auch die Notwendigen Materialien zur Verfügung zu stellen, wie z. B. ein Scrum Board. Natürlich muss keiner vom Management selbst in ein Geschäft fahren und Material kaufen, hierbei geht es eher um die Freigabe des benötigten Geldes.

Weitere Rollen

Es gibt noch die Rollen Customer und User. In unserem Projekt spielen sie zumindest für das Scrum keine Rolle. In einer Internetagentur wird man aber zumindest die Rolle des Customers vorfinden.

Der Customer (Kunde) ist der Auftraggeber eines Projekts. Er arbeitet eng mit dem Product Owner zusammen, der dann die Aufgaben (User Stories) definiert.

Der User ist der Benutzer des entstehenden Produkts oder Features. Dies könnte zum Beispiel auch eine andere Abteilung sein. Hier wäre es wichtig, dass der User im Sprint Planning 1 und im Review dabei ist. So kann er sich davon überzeugen, dass alle im Sprint Plannning 1 festgelegten Sprint Ziele auch erreicht wurden.

Das Scrum Board

Zur Organisation der User Stories in einem Sprint haben wir zusätzlich zu unserem bereits vorhandenen Whitboard noch zwei zusätzliche angebracht.

Dort sind die User Stories, Bugs und Operations in Tabellenform aufgehängt und zwar mit Zetteln und Karteikarten mit Magneten befestigt. Das ist kein Rückschritt aus dem papierlosen Büro, sondern dient einfach der Übersicht und spielt auch eine elementare Rolle im Daily Scrum Meeting.

In der ersten Reihe unserer Tabelle befinden sich die „Bugs of the day“. Das ist eine von uns geschaffene Möglichkeiten neben User Stories auch Bugs in die Boardorganisation zu integrieren.

Die zweite Zeile ist für Operations. Dabei handelt es sich um Dinge, die nicht über eine User Story abgebildet werden können. Eigentlich sollte es dies gar nicht geben, aber es lässt sich bisher noch nicht zu 100% vermeiden, aber wir sind auf einem guten Weg. Als Beispiel sei hier einfach nur ein Mitglied des Scrum Teams genannt, welches auch Aufträge von außerhalb bekommt. Also gehören diese Aufgaben eigentlich nicht zum Sprint, aber damit dieses Mitglied auch sinnvoll am Scrum Meeting teilnehmen kann, werden diese Aufgaben auch auf unserem Board festgehalten.

In den weiteren Zeilen sind die User Stories, die im Sprint Planning 1 für den Sprint bestimmt und angenommen wurden. Jede Story ist in einer eigenen Zeile der Tabelle.

Die Spalten der Tabelle bestehen aus der Spalte mit den User Stories, bzw. bei uns ist für die erste Spalte der Bugs und Operations einfach eine Karte mit „Bugs“ und „Operations“ aufgehängt. Dabei werden die User Stories nach Priorität geordnet. Und Story sollte nur begonnen werden, wenn die vorherige fertig ist. Dies ist leider nicht immer der Fall, speziell wernn externe Abhängigkeiten bestehen.

Die zweite Spalte ist die Todo Spalte. Hier sind die Karteikarten aufgehängt, die eine User Story in einzelne, noch nicht begonnene, Teilaufgaben aufteilen. Dies geschieht im Sprint Planning II.

Die dritte Spalte heißt Inprogress. Das sind Karten, die aus der Todo Spalte gezogen wurden, also bereits begonnene Teilaufgaben.

Die vierte Spalte nennt sich Done. Erledigte Teilaufgaben, die nicht mehr in Inprogress sind, werden hierher gezogen.

Wir haben noch eine fünfte Spalte, die mit Live beschriftet ist. Hier werden alle fertigen Karteikarten hingezogen. Im Scrum gibt es diese Spalte eigentlich gar nicht. Aber wir brauchten eine Spalte mit der wir bereits live gestellte wichtige Bugfixes visuell markieren konnten.

Auf diversen Scrum Boards gibt es auch noch die Spalte „to verify“. Diese Spalte ist nach „Inprogess“ und vor „Done“ einzuordnen und ist quasi die Testphase der User Story. Diese Spalte haben wir auf unserem Board weggelassen und benutzen eine andersfarbige Karteikarte mit „Testing“. Wenn diese Karte für eine Story in der „Done“ Spalte ist, wissen wir, dass diese User Story getestet und live gestellt werden kann.

Eine weitere Ausnahme, die wir uns gegönnt haben, sind die sogenannten Daylies. Dabei handelt es sich um Aufgaben, die keine Bugs sind, aber auch nicht im Sprint Planning als User Story angenommen wurden. Dies könnte zum Beispiel eine wichtige Änderung für einen sehr wichtigen Kunden sein. Daher rechnen wir dies bereits in dem Sprint Planning ein. Allerdings sollte dies wirklich eine Ausnahme und nicht die Regel sein. Früher oder später kommt man sonst in Teufels Küche und gewährdet den Erfolg von Scrum.

Die Meetings

Daily Scrum

Das Dalily Scrum Meeting findet jeden Tag zur gleichen Uhrzeit statt und das so früh wie möglich. Wir haben uns auf 09:30 Uhr geeinigt, da wir Gleitzeit bis 09:00 Uhr haben und um 09:30 Uhr wirklich jeder da sein sollte.

Jeder Entwickler beantwortet die Fragen:

  1. Was habe ich gestern gemacht?
  2. Gab es Hindernisse, die mich aufgehalten haben?
  3. Was mache ich heute?

Die Hindernisse werden schriftlich festgehalten und spielen in der Retrospektive noch eine Rolle.

Extrem wichtig ist das Bewusstsein wofür das Daily Scrum da ist. Das ist keine Kontrolle was ich gemacht habe und sollte auch nicht in einem Wettbewerb ausarten, bei dem die abgearbeiteten Karten der einzelnen Entwickler gezählt werden.

Es geht darum, dass jeder den aktuellen Stand der Entwicklung, also des Sprints kennt. Keiner der beteiligten Personen bildet sich ein Urteil darüber, was jemand am Tag zuvor geschafft oder nicht geschafft hat. Auch hier wieder der Hinweis darauf, dass es sich um ein Team handelt und man gewinnt als Team, aber man verliert auch als Team. Bevor ich jetzt drei Euro ins Phrasenschwein schmeissen muss, mache ich lieber weiter.

Die Antwort auf die Frage „Was habe ich gestern gemacht?“ und „Was mache ich heute?“ wird durch das verschieben der Karteikarten unterstützt. Also am Vortag erledigte Aufgaben aus „Inprogress“ werden nach „Done“ verschoben und die heute anzugehenden Aufgaben werden von „Todo“ nach „Inprogress“ gezogen. Damit man auch etwas zum verschieben hat, sollten die Teilaufgaben so klein sein, dass sie innerhalb von maximal einen Tag erledigt werden können.

Die Erfahrung hat gezeigt, dass dies nicht immer möglich ist, aber mit der Zeit lernt man die User Stories so aufzuteilen, das  es passt.

Sprint Planning 1

In diesem Meeting stellt unser Product Owner die User Stories vor, die im kommenden Sprint erledigt werden sollen. Er geht dabei nach einer Priorität vor und wir als Entwickler entscheiden dann, wieviel von diesen Stories in den Sprint passen und beachten dabei auch Urlaubs- und Feiertage. Je weniger Zeit zur Verfügung steht, desto weniger kann in einem Sprint erledigt werden, dies sollte klar sein.

Wichtig ist noch zu erwähnen, dass alle Entwickler sich dieser Auswahl an User Stories verpflichten (committen). Dies würde auch Überstunden bedeuten um einen Sprint erfolgreich zuende zu bringen. Dies sollte allerdings nur eine absolute Ausnahme sein. Beim nächsten Planning würden dann entsprechend weniger Stories angenommen werden.

Sprint Planning 2

Optimalerweise direkt im Anschluß an das Sprint Planning 1 sollte der zweite Teil erfolgen. Hier ist der Product Owner in der Regel nicht mehr anwesend. Wir Entwickler teilen jetzt die angenommenen User Stories in einzelne Teilaufgaben und machen für jede eine einzelne Karteikarte.

Anschließend hängen wir die ausgedruckten User Stories und die Teilaufgaben an das Scrum Board.

Sowohl für das kürzere Sprint Planning 1, als auch das Sprint Planning 2 sollte ausreichend Zeit vorhanden sein. Daher wird bei uns der komplette Tag für die beiden Meetings geblockt. Sollte danach noch Zeit sein, fangen wir direkt mit dem Sprint an.

Schätzmeeting

Das Schätzmeeting habe ich ja bereits schon bei der Rolle der Entwickler erwähnt. Hier werden noch nicht geschätze User Stories nach ihrer Wertigkeit im Planning Poker Verfahren geschätzt. Teilweise sind dies auch Stories, die nachgeschätzt werden, weil sie beim ersten Mal noch nicht geschätzt werden konnten. Oder die Stories umgeschrieben wurden. Hier wird dann überprüft, ob sich die Wertigkeit geändert hat.

Review

Während des Review, welches nach dem Sprint, aber vor dem Release stattfindet, wird allen beteiligten Personen, auch denen ausserhalb des Scrum Teams, die Änderungen aus dem Sprint vorgestellt. Dies ist insbesondere für den Support wichtig, damit sie nicht von Änderungen überrascht werden. Es gibt nichts schlimmeres, als wenn ein Kunde bei dem Support anruft und dieser nicht weiß wovon der Kunde spricht.

Retrospektive

Die Retrospektive findet nach dem Sprint statt. Hier werden die Hindernisse, die im Daily Scrum festgehalten wurden besprochen und schon nach ersten Lösungen gesucht. Der Scrum Master kümmert sich darum, dass diese Hindernisse aus der Welt geschafft werden.

Der Sprint

Ein Sprint, also die Länge der Programmierphase sollte zwischen zwei und vier Wochen betragen. Wir haben unseren alten vier Wochen Zyklus beibehalten.

Testing

Das Testen hat sich bei uns grundlegend geändert. Jetzt wird eine fertige Story von den Entwicklern in Zusammenarbeit mit dem Product Owner getestet. Und zwar nicht gegen Ende des Sprints, sondern fortlaufend. Hier werden dann auch noch kleinere Änderungen besprochen, allerdings wird nicht die gesamte Story infrage gestellt.

Fazit

Die Umstellung auf Scrum hat uns viel gebracht. Die Motivation ist viel höher als vorher, die Bugs, die durch einen Sprint entstehen sind fast auf null reduziert worden. Der Glaube an das Produkt ist von allen Seiten besser geworden. Sowohl von den Entwicklern, aber auch vom Management.

Wir waren allerdings auch in der glücklichen Lage, dass alle beteiligten Personen sich darauf eingelassen haben ohne Vorbehalte.

Die Arbeit der Entwickler ist strukturierter als vorher. Gerade die Aufteilung der User Stories in einzelne Tasks war eine erhebliche Verbesserung. Dies hat dazu geführt, dass mehrere Entwickler an einer Story in unterschiedlichen Tasks arbeiten und jeder sich Gedanken dazu macht, wie man optimal die komplette Story zum Abschluß bringen kann. Somit hat sich auch die Code Qualität innerhalb von diesen sechs Monaten erheblich gesteigert.

Scrum ist keine Vorschrift. Scrum ist ein Rahmenwerk und jedes Team muss seinen Weg finden ohne dabei zu weit vom Rahmen abzuweichen. Eine zu große Abweichung birgt immer die Gefahr die Errungenschaften zu verlieren.

Ich hoffe mit dem Artikel ein kleines bisschen die Angst vor Scrum genommen, bzw. euch auf den Geschmack gebracht zu haben. Scrum kann Spaß machen, wenn alle sich einbringen.

Sollte es Fragen, Anregungen oder Kritik zu dem Thema geben, so beantworte ich gerne alle Fragen auch per E-Mail.

Links zum Thema:

Scrum Erklärung
Bilder von Scrum Boards

Hat dir der Beitrag gefallen? Dann würde ich mich sehr freuen, wenn du ihn weiterempfehlen würdest.Share on FacebookShare on Google+Tweet about this on Twitter

5 Gedanken zu „Umstellung auf Scrum – 6 Monate danach

  1. Hi!

    Super Artikel – der einem wirklich mal aus Sicht eines Praktikers ganz konkret beschreibt, wie’s laufen kann.
    Eine Frage dazu: Du schreibst, dass Ihr mit Mantis arbeitet (über dieses Schlagwort in Kombination mit Scrum hab ich den Artikel hier erst gefunden 😉 Inwiefern habt ihr hier ’ne Verbindung? Sind die User Stories jeweils Einträge in Mantis? Legt Ihr für jede Teilaufgabe auch einen Bug an? Tragt Ihr die Aufwände in Mantis ein bzw. allgemein übernehmt Ihr Daten aus dem Scrum in Mantis? Gibt’s das Scrum-Board womöglich auch als Abbildung in Mantis?
    Bzw.: Würdet Ihr das gerne machen, aber es scheitert halt an nicht vorhandener Unterstützung durch Mantis bzw. entsprechende Plugins?

    Wir arbeiten bei uns intensiv mit Mantis und haben das an zig stellen schon sehr weit aufgebohrt und an unsere Bedürfnisse angepasst, so dass es auf eiin Plugin mehr oder weniger auch nicht mehr ankommt 😉

    Wäre super, wenn Du evtl. kurz per EMail und/oder Kommentar hier im Blog was dazu schreiben könntest – auch wenn der Beitrag hier schon „etws älter ist“ 🙂

    Danke

    Stefan

  2. Tja und wir sind von Scrum auf klasissche Entwicklung umgestiegen.
    Es stoerte sehr, dass die sogennanten Product Owner nie vorrausplanten, sondern immer nur alberne kleine Features mal schnell einbauen lassen wollten. NUn muessen sie halt mal vorher kontzeptionell ueberlegen und Requirements anlegen.
    Nach einigen Monaten muss ich sagen,d ass klassische ENtwicklung viel besser ist. Alle sind motivierter. DIe SOftware ist viel viel besser geworden, da wir auch mal mehr als 2 WOchen fuer Infrastruktur brauchen koennen.

  3. Bei uns war es genau anders herum. Aber ich kann verstehen was du meinst. Es ist von allen Beteiligten Disziplin erforderlich und nicht nur von den Entwicklern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.