Bug vs. Feature

Nein, ein Bug ist kein Feature!

Während des Sprint 5 Planning Meetings hat sich erneut herausgestellt, dass das Verständnis über die Frage was ein Bug ist und was ein Feature, zwischen Team und Product Owner stark abweicht.

Für den Product Owner ist alles ein Bug, was betriebsstörend ist - alles was er als Input von Dritten bekommt, ist ein Bug. Aha! Das ist so nicht richtig, obwohl dies aus Kundensicht durchaus richtig erscheinen mag. Dazu kommt die Tatsache, dass der Product Owner in der Vergangenheit gelernt hat, dass ein Bug mit "fix asap" immer gleich vom Team realisiert wird, während Features immer im Sprint geplant werden und daher länger brauchen, bis sie wirksam werden.

Ein Bug aus Sicht des Team ist, wenn etwas nicht so funktioniert, wie es implementiert sein sollte und dadurch Fehler/Fehlverhalten auftreten, z.B. "Wenn man die AGB's anklickt bekommt man eine Fehlerseite".

Kein Bug ist etwas, was wie gewünscht realisiert wurde, aber für Endbenutzer so nicht brauchbar ist (das sollte eigentlich nie vorkommen!), z.B. "Im Email wird der Name und Vorname nicht angezeigt". Wie auch, wurde so nie implementiert! Das ist nach der Defintion vom Team ein Change Request und damit wird es als User Story im kommenden Sprint geplant und priorisiert.

Eine nicht unwichtige Überlegung, die man in diesem Zusammenhang anstellen muss, ist das Release Management. Wenn das Team auf der Release Branch ein Feature realisiert, der als Bug gekennzeichnet ist, hat das teure Konsequenzen. Auf dem Release entwickelte Dinge müssen in den Trunk gemerged werden. Dieser ist aber nach der Release Freigabe bereits fortgeschritten und die Code Basis hat sich unter Umständen bereits markant verändert. Der Merge vom Release Branch in den Trunk kann sehr teuer werden. Wenn dann noch eine Datenbankänderung dazu kommt, ist die Auslieferung des kommenden Releases vom Trunk aus sehr aufwendig.

Sprint 5 Planning Meeting

Sprint 1 bis 5 wurden bisher nicht mit dem Ansatz von User Stories durchgeführt. Bisher wurden vom Kunden nur Abkürzungen, Satzfragmente order Stichworte ins Product Backlog aufgenommen. Daraufhin gab es sehr ausführliche Planning Meetings und das Team hat on-the-fly während des Meetings im Wiki quasi die Spezifikation geschrieben, während der Product Owner seine Gedanken ausführt.

Das hat in der Vergangenheit dazu geführt, dass das Team zwar nach agiler Methodik iterativ arbeitet, aber agile Software Entwicklung war das nicht. Dies und der dringende Wunsch User Stories einzuführen haben dazu geführt, dass Target Process eingesetzt wird.

Im Sprint 5 Planning Meeting heute hat das Team während der Präsentation der Wünsche des Product Owners im Target Process die Aufgaben zu User Stories umgewandelt. Das war recht einfach, denn das Verhaltensmuster des Product Owner war immer das gleiche:
Jeder Backlog Eintrag, z.B. "Performanceoptimierung" wurde vom Product Owner immer selbst kommentiert, z.B. "Der Hintergund ist folgender: Wir bekommen von unseren Benutzern immer ...." Eigentlich liegt die User Story bereits auf der Hand: "Ein Benutzer bekommt nach der Suche innerhalb von 5ms eine Trefferliste angezeigt".

Während der Product Owner mit Powerpoint seine Wünsche präsentiert, wurden zusätzlich noch Notes und Contraints in der Story definiert, z.B. "Note: bei mehr als 1000 Treffer wird keine Trefferliste anzeigt, sondern ein Hinweis", "Contraint: es wurde mindestens ein Suchkriterum eingegeben".

Test Cases pro Story wurden in dieser Sprint Planung noch nicht erfasst. Das ist der gute Vorsatz für das kommende Planning Meeting, wenn alle Beteiligten mehr Erfahrung mit User Stories haben.

Best Practice: Requirement Management

Heute war die Sprint 5 Demo und Sprint 5 Planning Meeting. Zum ersten Mal wurde die Planung vom Team mit Target Process durchgeführt. Der Product Owner hatte zuvor User Stories, die eigentlich keine User Stories sind, erfasst - sehr viele sogar.

Das Team hat sehr verhalten reagiert. Der Product Owner wusste teilweise nicht, was die Stories beinhalten. Nach vielen Fragen wurde das Problem eingegrenzt:

Das Team hatte zur Einführung von Target Process beim Kunden einen Workshop durchgeführt, wo erklärt wurde, wie das Tool funktioniert und wie man sich die Zusammerarbeit damit vorstellt.
Der Product Owner bekam einen Accout und jedes Teammitglied. Der Product Owner hatte seinen Account im Unternehmen des Auftraggebers "allen" zur Verfügung gestellt.

Der Effekt war, dass man das Requirement Engineering und Requirement Management mit Target Process abgedeckt hat. Der Kunde war im Glauben, dass Tool sei dafür da. Falsch! Target Process ist ein Projekt Management Tool für agile Software Entwicklung. Nicht mehr und nicht weniger.

Als das Team dem Product Owner beigebracht hatte, das dies so nicht funktioniert kam die Frage: "Wo machen wir das dann? Können Sie uns wieder einen Zugang zum Testdirector freischalten?"

Hintergrund der Frage: Das Team hatte fälschlicher Weise in der Vergangenheit dem Kunden einen speziellen Tag im Test Director eingerichtet: Optimisation. Der Kunde hatte neben Bugs auch neue Features und Change Request im Test Director erfasst. Als das Team das erkannt hatte, wurde mit Absprache des Kunden der Account stillgelegt.

Wie auch immer, die Antwort des Teams war deutlich: "Nein, natürlich nicht! Für Requirement Engineering und Requirement Management müssen Sie ein anderen Weg finden."

Das Team hat beschlossen, jede neu erfasste User Story vom Product Owner zu monitoren und zu prüfen. Wenn die Story keine User Story im Sinne von Agile ist, wird der Kunde kontaktiert und es wird umformuliert. Visionen und Requirement Engineering werden gelöscht.

Best Practice: Konzeptionelles und Co.

Wie plant man konzeptionelle Arbeit in einem Sprint?

Hintergrund: Aus Sicht des Product Owners ist nicht alles, was er dem Team als Wunsch für den kommenden Sprint präsentiert, eine User Story. Es kommt oft vor, dass der Product Owner vom Team ein Konzept mit Lösungsalternativen für ein Problem haben möchte, um bei seinem Auftraggeber eine Entscheidungsbasis zu präsentieren. Oft spielen hier Kosten und Nutzen von diversen Alternativen eine grosse Rolle. Da der Product Owner nur das "Was" in das Team bringt und das Team über das "Wie" entscheidet, kann nur das Team eine Entscheidungsgrundlage erbringen. Das Team analysiert den Ist-Zustand und definiert das Delta zum Soll-Zustand. Dann werden verschiedene Alternativen ermittelt, wenn möglich.

Wie schreibt man so eine Story? Wie plant man das in einem Sprint ein?
Man könnte argumentieren, dass alles was keinem Benutzer etwas bringt keine User Story ist.
Aus Sicht des Product Masters stellt die Sprint Planung das Auftragsverhältnis für den kommenden Sprint dar. Es kann nur das abgerechnet werden, was Teil des Sprints ist. Wenn es also keine User Story ist, trotzdem im Sprint geplant werden muss, was ist es dann?

Ein Epic! Das Team geht bei Konzeptarbeit folgendermassen vor:
Es wird ein Epic(=Feature im Target Process) angelegt, z.B. "Der Administrator kann den Content X der Homepage selbst gestalten". Das Team ist der Meinung, dass man eine Applikation gebaut hat. Diese Funktionalität liesse sich besser durch ein CMS realisieren. Damit ist dem Product Owner nicht geholfen. Er sagt, er braucht dass, das Team meint, das sollten wir nicht tun. Wir könnten das allerdings schon.
Der Product Owner meint, er wisse das schon, aber er brauche für den internen Entscheidungsprozess bei sich eine Entscheidungsgrundlage. Also erfasst das Team eine User Story für Konzeptarbeit innerhalb des Epic, z.B. "Der Product Owner erhält ein Lösungskonzept mit Entscheidungsalternativen". Dazu kommt eine weitere User Story innerhalb des Epic: "Der Administrator kann den Content X der Homepage selbst gestalten." Beide User Stories werden vom Team geschätzt und im Rahmen der Sprint Planung geplant.

Im Lösungskonzept werden pro Alternative Story Points geschätzt. Wenn der Entscheid gefällt wurde, kann man im kommenden Sprint sofort mit der Implementierung beginnen.

Target Process Einführung

Das Team hat beschlossen, die Excel Sheet Verwaltung von Product und Sprint Backlog fortan mit TargetProcess durchzuführen.

TargetProcess ist ein Tool für das Management von agile Software Projekten. Es ist nicht unbedingt auf Scrum abgestimmt, trotzdem aber einsetzbar.

Begrifflichkeiten:
Interationen im TargetProcess entsprechen Sprints. Ein Featrue ist ein Epic. Ein Task stellt Arbeit auf täglicher Basis dar (8h), was im Daily Scrum vom Scrum Master mit den Fragen "Was hast du gestern gemacht", "Was machst du heute" und "Was sind Deine Hindernisse" dokumentiert wird.

Was unterstützt das Tool:
Das Management ist stark an intertiven Prozessen orientiert. So beginnt alles mit einem Projekt, dem User mit bestimmten Rollen und Verfügbarkeit zugeordnet werden können, z.B. 3 Entwickler zu 100%, ein Tester zu 80% usw. Die Resourcenplanung ist nicht starr, kann pro Sprint neu definiert werden. Dann legt man Releases an und plant diese zeitlich. Dann werden Sprints angelegt, mit den Resourcen verknüft und Meta Daten, wie Velocity, angegeben. In der Sprint Planung werden dann User Stories und deren Tests erfasst und Sprints zugeordnet (Drag & Drop). Das Tool zeigt dabei stets an, wieviel User Stories noch angenommen werden können. Wenn zu viele angenommen wurden, bekommt man eine Warnung.

Das Team kann nun auf Sprint Basis die User Stories während der Estimation schätzen und User zuweisen. Die Schätzung kann, je nach Konfiguration, in Real Days oder Story Points erfolgen.

Was unterstützt TargetProcess nicht:
Daily Scrum Dokumentation. Es gibt zwar eine Today Ansicht mit allen Tasks, aber streng nach Scrum ist das nicht zu gebrauchen.
Desweiteren kann man keine Sprint Retrospective mit dem Tool durchführen, da dies auch Scrum spezifisch ist.
Das Team pflegt diese beiden Punkte weiter im Wiki. Hier werden pro Sprint zwei Pages angelegt: Daily Scrum (Excel) und Sprint Retrospective (Excel). Da das Confluence Wiki ein Excel Plug-in hat, wird das Excel Sheet auf der Wiki Page dargestellt. Man muss also nicht immer das File downloaden.

Zusätzliche Funktionen:
Bug-Tracking mit Subversion Intergration, d.h. man kann Bugs erfassen, Stunden aufschreiben und mit dem Check-In den Status des Bugs auf Fixed setzen. Der QA bekommt dann alle fixed Bugs in seinem Dashboard angezeigt.

Darüber hinaus bietet TargetProcess diverse Reports für das Projekt Reporting, z.B. Sprint Velocity, Release und Sprint Burndown Charts, Bug Reporting und Bug Process.

TargetProcess ist eine ASP.NET Implementierung. Es ist mit Atlas auf Web 2.0 ausgelegt und macht in der Anwendung echt Spass - wenig Page Reloads, viel Drag & Drop und vieles mehr...

Ab Sprint 6 setzt das Team das Tool ein. Erfahrungsberichte folgen ...

Sprint 5 Abschluss

Zum fünften mal trifft sich das Team vor der Sprint 5 Vorführung, morgen Vormittag.

Der letzte Sprint, der mit Excel geführt wurde, geht zu Ende.
Das Team geht nach dem Daily Scrum noch mal schnell die Liste der Tasks durch. Alles Done, bis auf einen Task. Damit sind von 26 geschätzten Story Points letztendlich 23 Done.

Done, bisher :( Velocity)
Sprint1:24
Sprint2:30
Sprint3:27
Sprint4:42

Done, durschnittlich: (Velocity)
29.2

Die Herausforderung für den kommenden Sprint besteht darin, die Anforderungen des Kunden in User Stories zu überführen.
Bislang hat das Team noch nicht mit User Stories gearbeitet - TargetProcess zwingt uns das auf und das Team begruesst das.

Obeya

.. so nennt man bei Toyota den Raum, der täglich 15-Minuten zum Abgleich des Projektstatus (Stand-Up-Meeting) aufgesucht wird.

Daily Scrum im Obeya. Nichts ist unmöglich.....

Auch eine Meinung

Ich hatte heute ein interessantes Gespräch mit einem Entwickler-Kollegen, der nicht in einem agilen Projekt arbeitet. Er hatte davon gehört und findet das irgendwie nicht so gut.

"Der Entwickler muss direkt mit dem Kunden aushandeln, was er haben möchte? Dafür gibts doch Consultants. Das wäre für mich ein Kündigungsgrund!"

Es ist ja bekannt, dass ca. 30% der Entwickler ein agiles Projekt verlassen. Naja...

Best Practice: Estimation

Im Sprint 5 hat das Team erstmalig begonnen mit "echten" User Stories zu schätzen. Keine Spezifikation, nur ein Satz nach dem Muster X kann Y machen, um Z zu tun.

Der Product Owner hatte das Team beauftragt, neben dem eigentlichen Produkt eine kleines Neben(Nischen)produkt zu konzipieren. Man bewegt sich quasi auf der grünen Wiese. Diese Situation kann man mit einem Projektstart vergleichen. Man hat kein Systemarchitektur, kein ERM, kein Domain Model, kennt keine Schnittstellen, das GUI ist nicht definiert, etc.

Ok, wir haben aber etwas - ca. 35 User Stories!
Das Team ist konfrontiert mit dem "Wie" in Form von User Stories und soll nun schätzen - das funktioniert nicht, wie wir bitter erkennen mussten.

Lessons learned (in zeitlicher Reihenfolge):

1. Systemkontext muss kurz visualisiert werden, um das System und Umsystem zu erkennen
2. User Story Writing Workshop mit dem Team durchführen, um Rollen und Funktionen a la Brainstorming im Team zu erarbeiten. Das Team macht sich dadurch frühzeitig mit der Aufgabenstellung verraut und "lernt", was zu realisieren ist.
   
3. Ein paar einfache Wireframes/Story Boards sollten erstellt werden, damit man sich das vorstellen kann
4. Fragebogen für Experteninterviews erstellen und Experteninterviews durchführen
5. Interview mit potenziellen Benutzern durchführen um herauszufinden, was diese eigentlich möchten. Die Top 5 Hindernisse finden.
6. Ergebnisse des Fragebogens und der Interviews als Feedback ins Team bringen und dann die bstehenden User Stories neu formulieren bzw. hinzufügen
7. Estimation

Das funktioniert und die Akzeptanz im Team ist da!

Best Practice: Experteninterview

Der meist verwendetste Ansatz zum Schreiben von User Stories ist Experteninterviews in Workshops durchzuführen. Ein wichtiger Schlüssel zum Erfolg ist die Auswahl der "Experten". Wenn immer möglich sollten "echte" Benutzer befragt werden, nicht Benutzer, die sich in die Rolle hineinversetzen. Experteninterviews sollten idealerweise mit allen Benutzern durchgeführt werden, nur so bekommt man ein abgestimmtes Portfolio von User Stories auf die Bedürfnisse.

Es ist nicht sinnvoll den Benutzer zu fragen, was er braucht. Die meisten Benutzer können diese Frage nicht richtig beantworten oder sich nicht richtig ausdrücken. Besser ist der Ansatz zu Fragen, wie Ihr Arbeitsprozess heute aussieht und was die grössten Probleme sind. Dann kann man sehr schnell die Frage stellen, was der Benutzer sich beim Problem X als Lösung vorstellen würde. Der Benutzer kennt seinen Arbeitsprozess in der Regel sehr gut und bei Problemen ärgert er sich immer wieder und hat sicher eine oder mehrer Lösungsansätze bzw. Wünsche.

Wichtig ist, wie man Fragen stellt. Es sollten keine Ja/Nein oder "abgeschlossene" Fragen gestellt werden. Hier kann leicht ein falscher Eindruck aufgrund der Frage entstehen. Ein gutes Beispiel von Mike Cohn hierzu: "Would you like our new application in a browser?". Die Antwort ist klar. Man könnte in seinem Lieblingsrestaurant von der Bedienung auch gefragt werden "Möchten Sie heute Ihr Lieblingsessen bestellen und gratis essen?". Die Antwort ist auch hier klar: "Natürlich!". Trotzdem sind Ja/Nein Fragen berechtigt und notwendig. Wenn die Prozesse dokumentiert und genügend hinterfragt sind, kann man solche Fragen stellen, um an die Details zu gelangen. Man sollte solche Fragen nur gegen Ende des Interviews stellen.

User Stories sollten nicht direkt im Interview geschrieben werden. Die Benutzer sind mit der Methodik nicht verwandt und werden nur irritiert.

Die Ergebnisse des Worshops sollten im Anschluss in User Stories umgewandelt werden.
Sie können als Input für Fragebögen einfliessen ...

Scrum tifft .Net

Die Dienstleister Conchango hat im November 2006 ein Scrum Plug-In fürs Visual Studio 2005 freigegeben. Es wurde in Zusammenarbeit mit Ken Schwaber und Microsoft entwickelt.

Was kann es?
Das add-in bietet eine volle Integration auf den MS Visual Studio Clients und dem Team Foundation Server. Es gibt ein Installation für den TFS und eine für die Clients. Jeder Developer kann sich anschliessend inScrum Projekte einklinken.

Es ermöglich einfaches Reporting und Monitoring von Sprint Retrospecitve, Sprint und Product Burndown Charts und Bugs. Darüber hinaus kann man auf einfache Weise auf Sprint Backlog, Product Backlog znd Tasks zugreifen.

Hier gibts mehr ...

[Quelle]

Lessons learned from Scrum implementation at Google

Jeff Sutherland

TechTalk

Der Scrum Master in dem Projekt, an dem ich gerade arbeite beim TechTalk:

http://blog.internet-briefing.ch/2007/01/10/agile-software-entwicklung-scrum-xp-etc/

Erfahrungsaustausch und Meinungen zum Thema Scrum.