Suche
Werkzeugkasten für agile Tools

Agile Tools im Vergleich: die Qual der Wahl

Martin Künkele

© iStock / Phecs

Für agiles Vorgehen in der Softwareentwicklung gibt es einige wichtige nicht technische und eine unüberschaubare Anzahl technischer Tools. Der folgende Beitrag gibt einen Überblick und eine Anleitung zur Auswahl der richtigen Werkzeuge.

Die Qual der Wahl beginnt gemäß der Diskussion „Best SCRUM tools in the market“ auf LinkedIn jenseits des einfachsten und effizientesten Tools: des Whiteboards mit Sticky Notes. Angebracht im Teamraum unterstützt dieses die Kommunikation innerhalb des Teams wohl am besten. Eine Variante ist das Whitedesk, das im einfachsten Fall aus einer oder mehreren Glasplatten besteht, die auf einem Tischgestell angebracht werden und auf die mit einem Marker gezeichnet werden kann. Im Gegensatz zum Whiteboard müssen nicht einmal Post-its beschrieben und auf dem Whiteboard angebracht werden, sondern die Information wird einfach auf die Glasplatte gemalt. Jeder kann sie sehen und verändern.

Nun gibt es aber doch die eine oder andere Konstellation, bei der die Vorteile dieser beiden Tools nicht direkt zum Tragen kommen, z. B. wenn das Team örtlich verteilt ist. Die entfernt arbeitenden Kolleginnen und Kollegen müssen dann mittels einer Bildübertragung auf dem Laufenden gehalten werden. Die direkte Interaktion gestaltet sich dagegen schwierig. Dabei funktioniert Scrum mit „co-located“ Teams am besten. Doch man sollte realistisch bleiben: Aus verschiedenen Gründen sind auf mehrere Orte verteilte Teams heutzutage keine Seltenheit mehr.

Exemplarisch für die Diskussion, die man vor der Einführung eines agilen Tools führen sollte, sei auf die oben erwähnte Konversation auf LinkedIn verwiesen. Im Folgenden beleuchten wir verschiedene Tools aus unterschiedlichen Blickwinkeln. Es kann sich aber nur um eine Auswahl aus der breiten Palette verschiedener Lösungen handeln – dieser Artikel erhebt keinen Anspruch auf Vollständigkeit. Immerhin sind durch die Recherche eine ganze Reihe von Hinweisen und Quellen für die Suche und der Auswahl von Tools zusammengekommen.

Hier findet man eine Zusammenfassung der Kriterien, die hilft, die große Vielfalt an Features, die die Tools bieten, etwas zu ordnen. Sie sind im Kasten „Features von Tools“ zusammengefasst. Die Scorecard auf derselben Seite ist nicht brauchbar, weil schwer leserlich. Sie ist leider in einer anderen Form nicht erhältlich.

Features von Tools
Centralized Story & Defect Management
Release and Sprint Planning
Online Storyboard, Taskboard
Project Tracking
Team Collaboration
Acceptance Test Management
Burndown, Velocity and Test Trends
Integrations (IDEs, CI, Sourcecode etc.)
Multi-Project Support
Sprint Review and Retrospectives
Impediment Management
Customizable Workflow and Views
Basic Reporting
Epic Management
Program Management
Themes, Goals, and Requests
Team Room
Customizable System Setup
Configurable Security
Advanced Reporting & Dashboards
Agile Portfolio Management
Regression Test Management
Customer Idea Management
Product Roadmapping
Agile Visualization
Custom Reporting and Analytics
Planning Room
Customer Support and Training

Nach der sorgfältigen Abwägung der Vor- und Nachteile der Anschaffung eines Tools, das die agile Vorgehensweise – und nicht nur Scrum – unterstützt, steht man vor der Frage: Wie finde ich überhaupt etwas Passendes? Naheliegend ist natürlich zu googeln: Mit Suchkriterien wie „Agile Tools“, „Agile Tools Comparision“ o. Ä. wird man auch fündig; allerdings sind die meisten Treffer schon etwas angestaubt – nur wenige sind aus dem Jahr 2014.

Ziemlich schnell findet man den Eintrag von Practices & Tools, also von VersionOne. Links oben auf dieser Seite findet sich ein Hinweis auf den „8th Annual State of Agile“ (der Link ist derselbe wie der auf die Homepage). Man kann sich diesen Report als PDF-Datei herunterladen, nachdem man seine Kontaktdaten eingegeben hat. Klar, die Firma möchte natürlich auch etwas davon haben.

Ist man auf der Suche nach freien Tools für Scrum, d. h. sucht man nach „Scrum Tools free“‚ so findet man die Quelle „Agile Tools“ aus dem Jahr 2013. Diese Seite bietet einen Überblick über Open Source Agile Project Management Software Tools, und wenn man die Probe aufs Exempel macht, so gelangt man auch bei jedem Vorschlag zum Hersteller des beschriebenen Tools. Bis auf XPStoryStudio: Dort erhält man den Hinweis „Site offline“. Die Seite „Agile Tools“ selbst wird vom Erfinder des agilen Tools „TargetProcess“ gepflegt, einem kommerziellen Hersteller von Agile Project Management und Bug Tracking Software Tool.

Einen Überblick über kommerzielle Scrum-Tools, die frei nutzbar sein sollen, liefert ganz aktuell „Scrum Expert“. Wenn man glaubt, bei den kommerziellen Tools zu landen, wenn man „commercial scrum tools“ googelt, so liegt man falsch. Die Trefferliste auf der ersten Seite führt kommerzielle Produkte auf, die in Grenzen frei benutzbar sind, also z. B. wieder „ScrumExpert“ direkt oder über Umwege wie LinkedIn, Xing oder Twitter.

Dass die Annahme, dass das Googeln doch belohnt wird, falsch ist – zumindest, was Produkte aus den USA anbelangt – merkt man, wenn man hierauf trifft. Das Datum in der Spalte „Last updated“ gibt den Zeitpunkt der letzten Bewertung für das Produkt an. Jeder kann hier eine Bewertung abgeben. Es ist also keine Aktualisierung seitens des Herstellers bzw. Verkäufers der Merkmale seines Produkts.

Mehr Glück hat man auch nicht bei SourceForge. Gibt man in das Suchfeld „Scrum“ ein, dann gelangt man zu einer Liste von Produkten, die irgendwo „Scrum“ stehen haben, entweder im Namen, in der Kurzbeschreibung unter dem Namen oder in der Beschreibung. Die Liste sollte zwar nach unterschiedlichen Kriterien sortiert werden können, aber das funktioniert z. B. nicht beim „Rating“. Die Liste wird zwar umsortiert, aber nicht unbedingt absteigend nach dem Rating. Auch ist das „Last updated“-Datum wieder davon abhängig, wer zuletzt einen Eintrag durchgeführt hat.

Quintessenz: Es ist nicht einfach, mittels einer Google-Suche eine aussagekräftige Auswahl an agilen Tools oder Scrum-Tools zu finden. Wie sieht es also mit anderen Quellen aus?

Eine davon ist die Konferenz „Tools4AgileTeams“, die letztes Jahr Anfang November zum dritten Mal in Wiesbaden stattfand. Sie beschreibt sich selbst als „Eine Konferenz zum Austausch über den Sinn und Unsinn des Einsatzes von Tools in agilen Softwareentwicklungsteams sowie ihre optimale Nutzung. Dabei wollen wir von einem breiten Toolverständnis ausgehen und analoge Werkzeuge wie physische Boards, Timebox-Uhren und ähnliche Helferlein für die Arbeit agiler Teams ausdrücklich mit einbeziehen.“

In seiner Keynote machte Kurt Jäger auf der letztjährigen Konferenz eine interessante Unterscheidung zwischen den technischen und den fachlichen (prozeduralen?) Tools. Zu Letzteren gehören z. B. Community of Prcatice (CoP), Open Space, Magic Estimation usw. Diese werden im zweiten Teil des Beitrags vorgestellt. Zu den technischen Tools gehören folglich Microsoft Excel und Project, VersionOne, ScrumWise, Jira usw., auf die im Folgenden z. T. kurz eingegangen wird.

Weitere Quellen, um an Informationen und Empfehlungen zu Tools zu kommen, sind LinkedIn (s. o.) und Twitter. Die Suche in Xing ist nicht sehr ergiebig. Die Ausbeute bei Twitter bzgl. Werkzeugen, die das agile Vorgehen unterstützen, ist überschaubar. Oft sind die Gruppen schon etwas angestaubt, weil der letzte Eintrag vor einem halben Jahr gemacht wurde.

In LinkedIn dagegen gibt es eine ganze Reihe von Gruppen, die sich mit dem Thema Agile bzw. Scrum (Suchkriterien) befassen. Diese Gruppen sind z. T. sehr aktiv.

Agiles Manifest

Eine der zentralen Erkenntnisse des „Agile Manifesto“ lautet: „Individuals and interactions over processes and tools“. Zu Deutsch: „Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“. Hier sind sicher die technischen Werkzeuge gemeint. Bedeutet also die Suche nach einem technischen Tool und dessen Einsatz einen Rückschritt in längst vergessen geglaubte Zeiten?

Ich denke nicht, wenn man sich nicht zum Sklaven dieser Tools macht, sondern sehr sorgfältig überlegt, welchen Nutzen sie bringen können und wann man sie besser nicht einsetzt. Weniger ist mehr, heißt es im Chaos Manifesto 2013, Seite 41, für kleinere Projekte.

Wenn Tools z. B. das unterstützen, was laut Agilem Manifest wichtiger ist, nämlich die Interaktion zwischen den Menschen, kann es sinnvoll sein, sie einzusetzen. In großen Organisationen sind es zunehmend virtuelle Teams, die an einem Softwareentwicklungsvorhaben beteiligt sind, d. h. die Mitglieder der Teams arbeiten nicht zusammen an einem Ort, sind also nicht „co-located“. Das erschwert die Kommunikation (Interaktion) zwischen den Teammitgliedern. Wenn ein technisches Tool hier die Kommunikation verbessern hilft, dann ist dies möglicherweise eine sinnvolle Anwendung. Ist es nicht auch so, dass es zur Umsetzung der anderen Grundideen des Agilen Manifests sogar bestimmter Tools bedarf?

Die Erkenntnis, dass funktionierende Software wichtiger ist als umfassende Dokumentation, schließt möglicherweise die Notwendigkeit ein, Testtools einzusetzen. Ganz ohne Tools kommt man also nicht aus. Dieses Beispiel trifft es aber auch nicht ganz. Wir suchen Tools, die Abläufe von Scrum und/oder XP abbilden, also z. B. das Task Board und seine Aufteilung in Kategorien, wie „In Arbeit“ bzw. „Ready“. Dazu gehört dann auch das Umhängen der Tasks von einer Kategorie in die nächste. Bei einem elektronischen Product Backlog sollte es natürlich möglich sein, die User Stories zu priorisieren. Möglicherweise aber noch mehr, z. B. die Aufgliederung einer User Story in einzelne Tasks usw.

Welche Hersteller agiler Tools gibt es und wie beliebt sind sie?

Im bereits erwähnten „State of Agile“ findet man am Ende des Reports eine Erwähnung von Tools, zunächst „Agile Tool Uses & Preferences“ dann „Specific Agile Tools Used“ und schließlich „Satisfaction with Tools Choice“.

Unter „Agile Tool Uses & Preferences“ findet man an oberster Stelle Tools wie Bugtracker und automatische Build-Tools. Das sind technische Tools. An sechster Stelle steht dann „Taskboards“, ein Tool, das den Prozess bei Scrum unterstützt. Gleich danach sind es „Agile Project Management Tools“, dann, ein paar Stellen weiter, „Story Mapping“. Alles Tools, die in der fachlichen Ecke angesiedelt sein dürften.

Im nächsten Kapitel des Reports „Specific Agile Tools Used“ kommen die Werkzeuge zur Sprache. Interessant ist, dass Excel das am meisten benutzte Tool ist, gleich gefolgt von „Project“, auch aus dem Hause Microsoft. Letzteres ist ein Werkzeug, das vom klassischen Projektmanagement her bekannt sein dürfte. Wie wird es im agilen Umfeld eingesetzt? Diese Frage stellt sich noch mehr in Bezug auf Excel. Schaut man sich die Zufriedenheit dann auf dem dritten Schaubild an, dann erkennt man doch eine Diskrepanz zur Häufigkeit der Nutzung der beiden Microsoft-Tools. So richtig scheinen sie nicht zu passen. Eher noch der Team Foundation Server (TFS) aus dem gleichen Haus, der bei der Zufriedenheit und Häufigkeit der Nutzung auf dem ungefähr gleichen Niveau rangiert.

Selbstredend steht natürlich VersionOne als Produkt des Initiators des Reports bei der Zufriedenheit an erster Stelle. Ihm folgt ein Produkt des Mitbewerbers Atlassian, JIRA,/GreenHopper. Dann kommt ein Verkäufer, der nicht namentlich genannt werden will, und schließlich LeanKit und TargetProcess.

DevOps Docker Camp
Erkan Yanar

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Was möchte ich erreichen?

Zunächst zu den Tools, die das agile Vorgehen unterstützen: Laut dem „State of Agile“-Report bildet Scrum hier den Löwenanteil. Damit liegt der Fokus auf Tools, die z. B. den Scrum-Prozess abbilden. Zu Scrum gehören User Stories, Tasks, Sprint Planning, Sprint Review, Daily Standup, Retrospektiven, Backlog Grooming, Definition of Ready, Definition of Done, Velocity, Burndown Charts usw. Die Frage ist, wie gut diese Bestandteile von Scrum abgebildet werden und wie sie sich ergänzen bzw. zusammenarbeiten. Das wichtigste Ziel aber ist, am Ende eines Sprints ein Stück funktionsfähige Software abzuliefern. In Sachen Informationsquellen bleibt nicht viel übrig:

  • Die Google-Suche nach geeigneten Tools ist nicht unbedingt zielführend.
  • De sozialen Netzwerke bieten gute Möglichkeiten. Allerdings muss man etwas Zeit aufwenden, und zwar deshalb, weil man auf Reaktionen zu von einem selbst angestoßenen Diskussionen warten muss.
  • Die Konferenz „Tools4AgileTeams“ findet, wenn überhaupt, erst wieder im November 2015 statt.

Bleibt also der „State of Agile“-Report. Die Datenbasis von 3,501 Antworten ist sehr wahrscheinlich nicht repräsentativ für alle, die nach einem Tool Ausschau halten. Allerdings legt der Herausgeber VersionOne Wert darauf festzuhalten, dass die Auswertung der Daten vom unabhängigen Umfrageunternehmen Analysis.Net Research durchgeführt wurde.

Ohne Anspruch auf Vollständigkeit werden verschiedene Merkmale unterschiedlicher Tools im Folgenden in Augenschein genommen. Es geht los mit dem Ausprobieren unter mehreren Gesichtspunkten: Wie wird man von den verschiedenen Herstellern unterstützt, wenn man ihr Produkt kennenlernen möchte? Oder: Wie kann ich möglichst schnell überprüfen, wie gut die Kollaboration zwischen den Teammitgliedern funktioniert?

Technische Tools

Es sei vorweg geschickt, dass alle hier vorgestellten Tools sehr mächtig sind. Eine ausführliche Beschreibung und Gegenüberstellung einzelner Features würde den Rahmen dieses Beitrags sprengen. Deshalb sind lediglich einige Erfahrungen beschrieben.

VersionOne

VersionOne wirbt damit, dass das Produkt die Verbindung zwischen Portfolio-, Programm- und Teamebene herstellt und Scrum, Kanban, Lean, XP und SAFe unterstützt. Die Grafik auf der Internetpräsenz hat etwas Ähnlichkeit mit einem Wasserfallmodell. Der Kunde bekommt erst am Ende die Lieferung. Davon wollte man mit der agilen Vorgehensweise eigentlich weg. Die Firma bietet einen Testaccount an. Nach der Registrierung landet man auf der Seite, wie in Abbildung 1.

Abb. 1: Landingpage des Testaccounts bei VersionOne

Abb. 1: Landingpage des Testaccounts bei VersionOne

Auf der Seite unübersehbar gibt es einen Button Join a live Demo, über den man sich für Livedemos zu fest vorgegebenen Zeiten registrieren kann. Es gibt eine Demo für die Basic of VersionOne und eine Demo für das Agile Program & Portfolio Management in VersionOne.

Darüber hinaus kann man sich durch entsprechende Videos gleich vertraut machen mit dem Anlegen eines Backlogs, dem Planen eines oder mehrerer Sprints und der Verwaltung des Taskboards. Man ist Erschlagen von der Fülle an Informationen, die alle wichtig sein könnten bei der täglichen Arbeit. Es könnte auch sein, dass die Firma sich einen Bärendienst erweist, weil man zunächst viel Zeit benötigt, um überhaupt effizient mit dem Tool umgehen zu können.

Scrumwise

Scrumwise wirbt auf seiner Homepage mit dem intuitivsten Tool, das man je ausprobiert hat. Auch hier besteht die Möglichkeit, einen Testaccount zu bekommen. Man kommt ziemlich schnell zum Zug. Geht man auf folgenden Link und klickt den Try now-Button rechts oben an, dann öffnet sich ein weiteres Fenster mit der Ankündigung, dass ein Account angelegt wird und kurz darauf bekommt man ein Beispielprojekt angezeigt (Abb. 2).

Abb. 2: Beispielprojekt bei Scrumwise

Abb. 2: Beispielprojekt bei Scrumwise

Es gibt neben der Registerkarte für die Projects noch weitere für People, Backlog, Sprints, Task Board und Burndown. Das Backlog enthält bereits einige Items, die alle „Ready for Sprint“ sind. Der Doppelklick auf einen Eintrag öffnet ein Pop-up-Fenster, in dem man die Eigenschaften editieren kann. Man kann tatsächlich einen kompletten Sprint planen. Das ist aber eigentlich nur sinnvoll, wenn es die Kooperation mit anderen erlaubt. Ich kreiere also einen weiteren Testaccount und versuche diesen dann im Team des ersten Accounts, mit dem ich gestartet bin, einzutragen. Bei der Vergabe der E-Mail-Adresse scheitere ich, weil sie schon vorhanden sei. Richtig! Ich möchte ja auch genau diesen neuen Account in mein Team einbeziehen. Ich sende eine E-Mail an den Support von Scrumwise und bekomme innerhalb kurzer Zeit die Auskunft, dass es ein neuer Account sein muss, der noch nicht in Scrumwise vorhanden ist.

Dieser wird genauso angelegt, wie ich es versucht habe. Das klappt, und ich kann jetzt zwischen den beiden Accounts, die einem Team angehören, sehen, wie z. B. neu mit dem einen Account eingerichtete Tasks für ein Backlog Item auch vom anderen Account zu sehen sind.

Es bleibt die Frage: Was mache ich, wenn ich bereits einen Account habe, vielleicht vom ersten Projekt, und diesen dann im nächsten agilen Projekt verwenden will?

Microsoft Team Foundation Server (TFS)

Hier sagt Microsoft, dass der Visual Studio Team Foundation Server die Kollaborationsplattform ist, die der Application-Lifecycle-Management-Lösung von Microsoft (ALM) zugrunde liegt. TFS unterstützt agile Entwicklungsverfahren sowie mehrere IDEs und Plattformen vor Ort oder in der Cloud. Mit TFS erhalten Sie die notwendigen Tools, um Softwareentwicklungsprojekte während des gesamten IT-Lebenszyklus effektiv zu verwalten.

Man kann kostenlos starten. Nach dem Anlegen eines Accounts kommt man zu einer Auswahl für verschiedene Produkte. Ich wähle die Option „Web“, weil ich nicht will, dass etwas auf meinem Rechner installiert wird. Danach gelange ich zu einer Maske, über die es möglich ist, ein Projekt anzulegen. Dann wird das Anlegen des Projekts bestätigt. Ich möchte ausprobieren, wie ich ein Product Backlog anlegen kann, gehe also auf den Button Work, um das Backlog in wenigen Minuten anzulegen. Aber so einfach ist es nicht. Die nächste Seite gibt Erläuterungen zum Anlegen eines Backlogs oder sogar dem Anlegen eines Portfolios aus mehreren Backlogs. Dann werden die Schritte, die ich durchführen muss, aufgezählt.

Als Erstes benötige ich ein Team Project. Entweder kann ich es neu anlegen oder mich zu einem bestehenden hinzufügen. Ich gehe mal davon aus, dass das vorhandene Projekt bereits ein Teamprojekt ist, und möchte mich dem hinzufügen. Die nächste Seite hat dann auch die Überschrift „Add team members“. Darunter die Erläuterung, dass ich jetzt ein Team Project habe und Visual Studio Online dazu verwenden kann, meine Arbeit mit anderen zu teilen. Auf dieser Seite ist dann grafisch unterstützt eine ausführliche Beschreibung zu finden, wie ich in Visual Studio zunächst das Team Project finde und diesem dann Benutzer hinzufüge. Ich breche ab, weil es mir zu ausufernd wird. Ich erinnere mich aber, dass ich einen Link „Backlog“ bereits gesehen habe, nämlich auf der Seite, auf der ich gestartet bin. Ich gehe also zurück und drücke auf diesen Link. Aha, ein Backlog mit der Möglichkeit, Items oder Bugs einzutragen (Abb. 3). Add öffnet ein neues Fenster für die Eigenschaften und Abnahmekriterien des zu erzeugenden Backlog-Items.

Abb. 3: Product Backlog Item bei Microsoft TFS

Abb. 3: Product Backlog Item bei Microsoft TFS

Zurück auf der Seite mit den aufgelisteten Items gehe ich rein intuitiv vor und ziehe das gerade angelegte Item auf einen Sprint in der Liste der Sprints, die links angezeigt werden – und siehe da, das Item ist diesem Sprint zugeordnet. Unter der Überschrift dieser Seite sehe ich noch einen weiteren Link „Board“. Es wird doch nicht etwa das Task Board sein? Tatsächlich, ein Task Board mit den vier Spalten New, Approved, Committed und Done. Das Item lässt sich mit Drag and Drop in die einzelnen Spalten schieben.

Fazit: Mit dem Testprojekt kann man schnell beginnen. Ob das genauso schnell geht, wenn man alles neu anlegen muss? Der Versuch des Anlegens eines neuen Product Backlogs gab mir eine Vorstellung, dass es etwas länger dauern könnte.

Atlassian JIRA/Greenhopper

Atlassian wirbt auf seiner Homepage mit dem Spruch „Dream big, work smart, deliver fast“. Es sind verschiedene Produkte der Firma erhältlich, deren Helden die Softwareteams sind. Folgende Tools finden sich im Portfolio:

  • JIRA
  • JIRA Service Desk
  • Confluence
  • Confluence Questions
  • HipChat
  • Bitbucket
  • Stash
  • Git Essentials
  • Agile Ready

Nachdem ein Demoaccount eingerichtet wurde und man sich damit angemeldet hat, wird man begrüßt – mit der Anzeige der Lizenz und dem Hinweis, dass man noch keine Kreditkarte hinterlegt hat. Ganz unten auf der Seite hat man die Chance, sich für „Evaluations“ einer ganzen Anzahl von Produkten zu entscheiden (Abb. 4).

Abb. 4: Produktauswahl bei Atlassian

Abb. 4: Produktauswahl bei Atlassian

Ich entscheide mich für „JIRA Agile“, bekomme eine Lizenz angeboten und auch die Möglichkeit, eine JAR-Datei herunterzuladen. Woraus ich schließe, dass bereits etwas installiert sein muss, wofür ich dieses JAR verwenden kann. Es ist der JIRA-Server, den ich testweise herunterladen und installieren kann. Auf der Downloadseite steht dann auch, dass ich JIRA Agile hinzufügen kann, nachdem ich den Server installiert habe.

Es wird eine Datenbank eingerichtet, und dann kann ich auswählen, wofür ich JIRA einsetzen will. Natürlich wähle ich Neues Board erstellen aus der Auswahl zwischen Scrum und Kanban aus. Es besteht die Wahl zwischen einem agilen vereinfachten Ablauf, der empfohlen wird, und dem JIRA-Standardablauf und endlich die Option, das Board erstellen zu können. Ich bin etwas irritiert, weil ich im leeren Board scheinbar nur „Issues“ anlegen kann. Die Lösung ist, dass sich oben in der Navigationsleiste ein Button befindet, über den ich neben anderen Typen von Einträgen wie Bug, neue Funktion, Verbesserung und Aufgabe eine neue Story anlegen kann. Über dem neuen Backlog-Item befindet sich der Button zum Anlegen eines Sprints. Danach ziehe ich das Backlog-Item durch Drag and Drop in den Sprint und starte den Sprint. Doch halt, ich muss noch eine Schätzung für den Backlog-Eintrag abgeben. Dann wechselt die Anzeige zum Board mit drei Einträgen: Aufgaben, In Arbeit und Fertig. Ich ziehe meine User Story in die Spalte In Arbeit. Dann gehe ich rechts oben auf Bericht und sehe das Burndown-Diagramm.

Das geht alles sehr intuitiv. Das Schöne ist, dass die Daten lokal vorhanden sind, also nicht irgendwo in der Cloud verschwinden, ohne Kontrolle darüber, ob möglicherweise sonst noch jemand darauf zugreift. Immerhin wird mit den Tools Softwareentwicklung betrieben, d. h. es entsteht ein Produkt oder mehrere Produkte. Die Informationen darüber bergen unter Umständen Geschäftsgeheimnisse, über die ich die Kontrolle behalten will.

Etwas mehr Aufmerksamkeit widme ich Confluence Questions. Ich kenne Wikis, die dazu dienen, anderen Know-how zur Verfügung zu stellen. Leider haben Wikis die Tendenz, dass sie über die Zeit veralten und man dann doch wieder auf der Suche nach aktuelleren Informationen ist.

Ich lade also Confluence herunter, werde gefragt, wo meine JIRA-Installation ist, und lande dann auf einer Seite mit einer großen Anzahl an Möglichkeiten. Ich wähle Anleitungsartikel aus und kann in einem Editor arbeiten und speichern. In der linken Navigationsleiste wird der Artikel verlinkt, und rechts oben bekomme ich einen Button Extras angezeigt, der mich neugierig macht. Die Änderungshistorie zeigt die Artikel tabellarisch mit einem Änderungsdatum. Immerhin. Schön wäre es jetzt, wenn man nach dem Änderungsdatum sortieren könnte, um so die ältesten Kandidaten zu finden. Ich finde aber die Auswahl Überwachungen rechts oben neben dem Symbol für meinen Account. Ich schalte die Überwachung für meinen Artikel ein und frage mich, was passiert. Es muss etwas mit E-Mail-Benachrichtigungen zu tun haben, weil am unteren Ende der Seite steht, dass ich die Einstellungen dazu ändern kann. Ich werde fündig unter E-Mail-Einstellungen mit einer ganzen Reihe von verschiedenen Ereignissen, die auslösen, dass ich per E-Mail benachrichtigt werde. Schön wäre es jetzt noch, wenn es auch die Möglichkeit gäbe, dass ich nach einer einstellbaren Zeitdauer erinnert würde, einen von mir erstellten Artikel mal wieder zu aktualisieren.

Die im Folgenden beschriebenen Tools sind bis zu bestimmten Limits frei benutzbar. Die Limits können sein:

  • Anzahl Mitglieder im Scrum-Team
  • Anzahl Projekte

Jenseits dieser Limits kostet auch die Nutzung dieser Tools etwas.

Rational Team Concert

Das Tool für „Task tracking, source control, agile planning“ steht zum Zeitpunkt der Erstellung dieses Beitrags als Version 5.0.2 als Download zur Verfügung. Es gibt zehn freie Lizenzen für ein kleines Team. Zusätzlich steht eine Version in der Cloud zur Verfügung. Wenn ich Software für das Web, für mobile Geräte oder PCs baue, bekomme ich einen Hinweis, wie lange der aktuelle trial cycle noch dauert. Dieser wird ca. alle sechs Monate neu gestartet, weil am Ende alte Projekte aufgeräumt werden, die nicht länger benutzt werden.

tinyPM

tinyPM ist ein leichtgewichtiges und smartes agiles Kollaborationstool für das Produktmanagement, Backlog, Taskboard, User Stories und Wikis. Nach Drücken des Buttons Download on-site tinyPM werden zwei Versionen angeboten, wobei die Empfehlung ist, die Version 3.1.8 zu verwenden, wenn man damit beginnt. Die ersten fünf Benutzerlizenzen sind frei. Wenn das Team größer als fünf Personen wird, muss man für jeden zusätzlichen Benutzer weitere Lizenzen kaufen.

Acunote

Acunote beschreibt sich selbst als Projektmanagement- und Scrum-Software. Einen Eindruck, wie Acunote wirkt, vermittelt der Link „How it works“ auf der Homepage. Wie die Beschreibung andeutet, ist es wirklich eine Mischung aus klassischem Projektmanagement und Scrum. Es werden verschiedene Begriffe aus beiden Welten kombiniert, wie z. B. eine List of Tasks, die als Projektplan bezeichnet wird. Ein Backlog scheint nicht die priorisierte Liste der User Stories zu sein, sondern eine Liste zukünftiger Tasks, über die man noch nicht weiß, wann sie beginnen sollen. Eine Besonderheit ist die Source Control Integration, die Code Reviews ermöglicht und es dem Reviewer erlaubt, Kommentare abzugeben.

Acunote bietet drei verschiedene Accounts, die allesamt zunächst dreißig Tage kostenlos sind. Die Accounts unterscheiden sich in der Art der Verwendung. Der günstigste Account, „Business“, ist ideal für ein einzelnes Team. Die nächste Stufe, „Corporate“, ist bestens für mehrere Teams geeignet, und der „Enterprise“-Account ist auf Matrixorganisationen ausgerichtet. Jeder Account kann von maximal sieben Benutzern verwendet werden, jeder weitere Benutzer kostet dann extra. Die weiteren Accounts sind je nach Kategorie unterschiedlich teuer.

Agilefant

Agilefant, das Teams oder „freischaffende Codekrieger“ (freelance code warriors) in die Lage versetzt, innerhalb von fünf Minuten mit Projekt- oder Taskmanagement loslegen zu können. Es passt sich dem Unternahmen an und erlaubt Produkt-Portfolios, Projekte, Sprints und die Entwicklung in mehreren Teams.

Der Zugang für bis zu fünf Teammitglieder ist kostenlos und einfach zu bewerkstelligen. Domäne der E-Mail-Adresse und Accountname vergeben, und schon kann es losgehen. Das ist dann der so genannte Cloud-Account, der ab dem sechsten Nutzer etwas kostet. Es sind maximal 25 Mitglieder erlaubt. Die zweite Stufe ist der Enterprise-Account, der ein Reporting einschließt, professionelle Services anbietet und darüber hinaus die Option, die Software auf einem eigenen Rechner zu installieren. Welche Services angeboten werden, wird zunächst nicht klar. Interessanterweise kann man Agilefant auch unter Android verwenden.

easyBacklog

easyBacklog beschreibt sich selbst in Form von unterschiedlichen User Stories mit zugehörigen Abnahmekriterien. Exemplarisch: Als Scrum Master will ich Backlogs und Sprints verwalten, damit ich die agile Vorgehensweise wirkungsvoll umsetzen kann. Genau das wird durch das Produkt erfüllt. Stories können zu Themen zusammengefasst werden, die Priorität der Stories kann durch Drag and Drop verändert werden, es gibt Burndown und Burnup Charts und noch einiges mehr.

easyBacklog ist zunächst frei. Es ist nicht ausgeschlossen, dass irgendwann eine Bezahlversion vorgestellt wird. Aktuell ist es aber wichtiger, Feedback von den Anwendern zu erhalten, um ein noch besseres Produkt zu bauen. Es wird versprochen, dass man nicht hinausgeworfen wird und dass der Zugriff auf die eigenen Daten immer gewährleistet ist. Der Gründer Matthew O’Riordan und andere erläutern das Produkt auch in einem Video, das auf der Startseite eingebettet ist.

Quickscrum

Quickscrum gibt es sowohl als Lösung in der Cloud als auch als installierbare Version, beides zunächst kostenlos. Nachdem man sich einen Account besorgt und die Fragen nach der Anzahl der Arbeitstage, dem ersten und dem zweiten arbeitsfreien Tag beantwortet hat, bekommt man die Gelegenheit, sich in einem Video die Funktionsweise von Quickscrum erläutern zu lassen. Man kann sich aber auch ein einstündiges Scrum-Training reservieren, wenn man noch nichts über das Scrum-Framework weiß.

Quickscrum scheint aus der klassischen Projektmanagementecke zu kommen. So wird unter „How to implement“ das Scrum-Framework vorgestellt und dort der Projektmanager als derjenige bezeichnet, der das Projekt leitet. Es ist auch von einem Projekt die Rede, das die Ausgangsbasis für alles Weitere ist.

Danach legt man Teammitglieder an, die mittels E-Mail über ihre Teilnahme am Projekt informiert werden. Eines der Teammitglieder kann als Product Owner definiert werden, der damit für die Kommunikation mit den Kunden verantwortlich ist. Die Teammitglieder werden dann einem Projekt zugeordnet.

Es wird das Product Backlog angelegt und mit User Stories versehen. Schließlich wird ein Sprint erzeugt und mit User Stories durch Drag and Drop bestückt. Innerhalb des Sprints werden aus User Stories Tasks erzeugt, die dann sofort in „To Do“ landen. Den Tasks wird automatisch eine Dauer in Stunden zugeordnet. Also keine Storypoints.

Dann werden den Tasks „Resources“ zugeordnet. Gemeint sind Teammitglieder. Schließlich können Tasks priorisiert werden, indem sie zwischen den Spalten To Do, In Progress und Completed verschoben werden. Im Desktop (Dashboard?) sieht man dann das Burndown Chart, das Activity Log, das Velocity Chart, den Resource Workload und die Task Summary. Bei der Erläuterung des Velocity Charts ist plötzlich die Rede von Storypoints. Woher kommen denn diese plötzlich? Zuvor basierte die Schätzung ja auf Arbeitsstunden.

Will man die aus dem Video gewonnenen Erkenntnisse anwenden, ist man zunächst verloren. Wo lege ich denn das Projekt an? Der als „Admin“ bezeichnete Administrator hat diese Möglichkeit. Die Adminfunktion kann abgeschaltet werden. Dies ändert erstaunlicherweise nichts am Funktionsangebot. Es besteht weiterhin die Möglichkeit der „Userstory Configuration“, Projekte anzulegen, Teammitglieder anzulegen und zuzuordnen und Kunden zu erzeugen. Die Hoffnung auf etwas mehr Information durch Drücken des Fragezeichens trügt. Es erscheint die Übersichtsseite des Produkts, die mit allgemeinen Informationen zu Scrum aufwartet. Man fühlt sich etwas alleine gelassen.

ScrumDo

Bei der Erzeugung eines Testaccounts wird man zuerst nach der Firma gefragt und nach dem Namen des Projekts, dem man dann durch Angabe der E-Mail-Adresse auch gleich Mitglieder zuordnet. Dann kann man entscheiden, ob man ein Scrum- oder ein Scrumban-Projekt anlegen möchte. Zu dieser Unterscheidung bietet ScrumDo ein „read more here“ an, und tatsächlich öffnet sich eine Seite mit einer Vergleichsmatrix zur Erläuterung der Unterschiede der beiden Vorgehensweisen.

Die Startseite wartet mit einer Tour auf, die darin besteht, dass Hinweistexte über die Seite wandern und zu jedem Menü oder Link eine kurze Erläuterung geben. Nach sieben Hinweistexten ist allerdings schon Schluss mit der Tour. Für weitere Informationen werden auf der Welcome-Seite zwei Videos angeboten, eines zu Scrum und das andere zu Scrumban, sowie zwei Links; einer zur Dokumentation und ein weiterer zum Tech-Support.

Klickt man eines der Videos, so wird YouTube in die Seite eingebettet, und die anderen Informationen sind zunächst einmal weg. Man kommt nur über den Back-Button des Browsers zurück. Der Ablauf ist ähnlich dem der bereits beschriebenen Tools, nur dass ScrumDo mit Epics startet, die in User Stories oder Sub-Epics untergliedert werden. Eine Taskebene fehlt ganz. Im Scrumboard werden die einzelnen User Stories zwischen ToDo, Analysis, Doing und Reviewing hin- und hergeschoben, wobei diese Status frei definiert werden können.

Dann kommt der Hinweis auf andere Videos für weitere Informationen. Dieses Video endet mit einer Übersicht über die letzten YouTube-Aktivitäten, die nicht unbedingt etwas mit ScrumDo zu tun haben. Wie gesagt, der Back-Button des Browsers hilft weiter. Es gibt außer dem Video für Scrumban kein weiteres Video, zumindest nicht offensichtlich, weil die Navigation doch sehr zu wünschen übrig lässt. Mal existiert auf der rechten Seite eine Navigationsleiste, mal verschwindet sie wieder. Allerdings wird man dann doch fündig: ganz unten auf der Seite, wo man eigentlich nur Links zum Impressum oder Kontakt oder anderen organisatorischen Informationen erwartet. Dort gibt es tatsächlich einen Link „Tutorial Videos“ mit dem Ergebnis, weitere YouTube-Videos zu verschiedenen Themen wie „Organizations, Projects and Teams“ oder „Scrum Board“ usw. aufrufen zu können. Dieser Umweg vermittelt dann doch den Eindruck, dass alles etwas mit der heißen Nadel gestrickt wurde.

Yodiz

Die Firma aus dem Land der „Angry Birds“ (Finnland) beschreibt ihr Produkt als „All-in-one Agile project management solution. Powered with all the features you would love“. Unter Kontakt auf der Homepage bekommt man noch einen Hinweis, wo Yodiz in Finnland zu finden ist, mehr aber auch nicht.

Nachdem man sich angemeldet hat, werden die Details zu dem Projekt, das man anlegen muss, abgefragt. Interessant ist, dass Yodiz tatsächlich die Estimation entweder in „Points“ oder „Hours“ erlaubt. Wenn man Storypoints auswählt, wird zusätzlich die Skala für die Punkte vorgegeben, entweder linear oder nach Fibonacci-Zahlen, nach einer „Scale-100“ benannten Skala oder T-Shirt-Größe, d. h. in fünf Abstufungen von XS bis XXL. Als letzten Schritt der Registrierung kann man sich eine mobile App von Yodiz entweder für das iPhone, das iPad oder ein Android-Gerät beschaffen. Zusätzlich kann man noch die Integration mit verschiedenen anderen Projekten und Produkten wählen, die da sind: Zendesk, Uservoice, GitHub, Assembla, Jenkins oder auch Subversion (SVN), dem Sourcecode-Management-System. Es wird auch Hilfe angeboten; hier erhält man endlich das obligate Video. Die „All-in-one Agile Management Platform“ wird wortlos (!) in einem atemberaubenden Tempo vorgestellt. Dabei kommen drei Tools zum Zuge: das beste Agile-Management-Tool, der Issue Tracker und der Group Chat. Man muss sich das Video mindestens zweimal anschauen, beim zweiten Mal immer mit der Maus auf dem Stop-Button von Vimeo, um die gerade vorgestellten Merkmale zu verstehen. So ist es auch mit den anderen Videos, die in der Knowledgebase angeboten werden.

Aber zurück zur Registrierung, die noch auf den Abschluss wartet. Danach kommt man sofort in das Product Backlog und wird durch einen nicht zu übersehenden Button aufgefordert, eine User Story einzugeben. Diese kann man dann mit Tasks versehen. Die Tasks landen in der Spalte ‚New‘ des Sprint Boards. Sie können durch Drag and Drop zwischen den einzelnen Spalten verschoben werden (Abb. 5).

Abb. 5:Taskboard bei Yodiz

Abb. 5:Taskboard bei Yodiz

Yodiz bietet ein Dashboard mit einer ganzen Reihe verschiedener Kennzahlen, die man sich grafisch aufbereitet anzeigen lassen kann. Der Issue Tracker ist vierspaltig aufgebaut, um die Issues in unterschiedlichen Status verfolgen zu können. Die Anzeige der Sprints ist zweistufig; zunächst bekommt man die Liste aller Sprints und kann daraus selektieren. Es besteht die Möglichkeit, Releases zu planen. Releases bestehen aus User Stories, die sich wahlweise im Status Open, Completed oder Ready To Release befinden können. Man muss eine User Story in den Status Completed versetzen, damit sie von Open nach Completed wandert bzw. in den Status Accepted, um sie in Ready To Release zu schieben. Die User Stories in der Auswahl Backlog werden in verschiedenen Farben angezeigt, je nachdem, in welchem Status sie sich befinden, also entweder Unscheduled, In Development oder Accepted.

Das macht alles einen sehr aufgeräumten Eindruck. Interessant ist die Kollaboration mit weiteren Usern. Ein neuer User wird per E-Mail benachrichtigt und ist dann sofort dem aktuellen Projekt und der Firma zugeordnet. Wenn man mit dem einladenden Benutzer ins Dashboard geht, sieht man den eingeladenen Benutzer als Mitglied im Projektteam. Neue User Stories, die einem Release zugeordnet werden, sind sofort durch den anderen Benutzer sichtbar. Einen kleinen Wermutstropfen gibt es allerdings: Yodiz wird vom Internet Explorer 11 nicht komplett unterstützt.

YouTrack

JetBrains hat verschiedene Produkte im Portfolio. YouTrack gehört zur Teamware. Es ist eigentlich ein Fehlerverfolgungssystem (Issue Tracking System), das durch das Agile Board für die Entwicklung mit Scrum oder Kanban erweitert wurde. Die Erläuterung im Video zu diesen beiden Themen ist etwas kurz.

Es ist frei für zehn Benutzer – sowohl für die Cloud- als auch für die Standalone-Lösung. Für Letztere kann man bei der Installation die deutsche Sprache wählen. Die Installation geht allerdings nicht ohne Reboot. Nach der Installation unter Windows fragt man sich, wie es weitergeht. Kein Eintrag unter „Programme“, kein Hinweis, dass irgendwo etwas ausgeführt werden müsste. Allerdings wurde unter „Benutzer“ ein weiterer mit Namen angelegt „JetBrainsYouTrack“ angelegt; in der Benutzerverwaltung von Windows ist aber kein weiterer Eintrag zu finden. Unter einem Verzeichnis, das bei der Installation festgelegt werden konnte, finde ich youtrack.bat. Das Anklicken führt auch nicht weiter. In einem Kommandofenster bekommt man Hinweise, wie das Bat-File auszuführen ist, und endlich: mit dem Parameter rerun tut sich etwas. Erneut die Installation? Da ich denke, dass ich das bereits getan hätte, gehe ich zurück auf die Homepage und finde dort „Installation instructions“.

YouTrack ist eine Java-Applikation, d. h. man muss ein JAR-File verwenden und Jetty für JavaScript-Anteile. Es sind verschiedene Beispiele angegeben, wie man das JAR starten kann. Dazu benötige ich eine bestimmte Datei, deren Name beschrieben ist als youtrack-<version>.jar, die ich aber nirgendwo finde. Ich vermute also, dass ich ein Upgrade durchführen muss. Das habe ich gesehen, als ich YouTrack aus dem Kommandofenster startete. Im Browserfenster wird nach Anklicken des Update-Buttons ein Verzeichnis angeboten, in dem eine Datenbank liegen sollte. Dieses Verzeichnis ist aber leer.

Also doch die Alternative, obwohl ich der Meinung bin, dass ich diesen Schritt bereits einmal ausgeführt hatte: die Installation. Ich gebe die bereits einmal vergebenen Werte erneut ein und lande jetzt auf einer Seite, auf der ich verschiedene Parameter setzen kann. Ich akzeptiere den Standard und lande endlich auf der angekündigten Seite für das Anlegen eines Projekts.

YouTrack ist so schlau zu erkennen, dass es bereits eine JIRA-Installation gibt und bietet mir eine Integration damit an. Ich entscheide mich aber, ein neues Projekt manuell zu erstellen. Statt die Kommunikation zu Team-City aufzubauen, entscheide ich mich für die allgemeinen Einstellungen und habe dort die Chance, ein Agile-Board anzulegen, das ich gleich mit meinem Testprojekt verknüpfe.

Das Agile Board wird durch wesentliche Elemente gestaltet: Board-Spalten, Board-Felder und Swimlanes. Es gibt bereits ein Angebot von Spalten; man kann jedoch noch weitere hinzufügen. Durch Anklicken einer Checkbox wird die jeweilige Spalte aktiviert. Ich belasse es bei den bereits ausgewählten: Offen, In Bearbeitung und Behoben. Dann besteht die Möglichkeit, für jeden Board-Eintrag Felder festzulegen, wie z. B. den Sprint oder ein Feld für die Zeitschätzung. Diese Board-Elemente werden dann in Swimlanes angeordnet. Es gibt noch eine ganze Reihe weiterer Tools:

  • Rally – Community Edition
  • ScrumHalf, Flying Donut
  • Kerika
  • Mingle
  • ScrumNinja
  • Silver Catalyst
  • ly
  • TargetProcess

Jedes Tool in der gezeigten Weise zu testen und die Ergebnisse zu beschreiben würde jedoch den Umfang des Artikels sprengen.

Nicht technische Tools

Im Folgenden soll ein kurzer Überblick über die nicht technischen – prozeduralen – Tools gegeben werden. Ohne Anspruch auf Vollständigkeit fallen folgende Tools in diese Kategorie:

  • Community of Practice (CoP)
  • Magic Estimation
  • Release Planning Meeting
  • Story Mapping

Community of Practice (CoP)

CoPs sind die Spezialisten aus den einzelnen Scrum-Teams mit jeweils einem bestimmten Schwerpunkt, die sich treffen, um Erfahrungen auszutauschen und neues Know-how zu lernen. So können in einem Unternehmen etwa CoPs für Quality Assurance (QA) und/oder User Experience (UX) entstehen.

Die CoPs sind selbstorganisierte Gruppen unterschiedlicher Größe, die sich in regelmäßigen oder unregelmäßigen Abständen treffen. Die Unternehmen, in denen CoPs existieren, können unterschiedlich groß sein. Andere Namen für CoPs sind z. B. Special Interest Group (SIG) oder Professional Community.

Hier geht einer der Teilnehmer sogar so weit zu postulieren, dass „community-based coding“ in dem Zusammenhang als CoP zu sehen ist. Community-based coding ist eine Methode der heutigen Softwareentwicklung. Hierbei handelt es sich um eine Art Open-Source-Projekt, das von mehreren Entwicklungsteams innerhalb eines Unternehmens gemeinsam vorangetrieben wird. Es hilft zu verhindern, dass das Rad neu erfunden wird, indem bereits implementierte und getestete Software aus einem Team anderen Teams zur Verfügung gestellt wird.

Magic Estimation

Magic Estimation wählt beim Schätzen von User Stories nicht die allgemein übliche, sondern die umgekehrte Vorgehensweise: Es wird nicht mehr jede einzelne User Story diskutiert, sondern sofort mit dem Schätzen begonnen. Das hat den Effekt, dass es schneller gehen kann.

Im Detail läuft es so ab, dass zunächst die Karten für den Schätzpoker auf den Boden im Teamraum gelegt werden. Dann werden die User Stories an die Teammitglieder verteilt. Es müssen nicht alle sein, sondern vielleicht die zwanzig bis dreißig am höchsten priorisierten. Jeder Einzelne schätzt jede User Story, indem er sie einer der auf dem Boden liegenden Karten zuordnet. Dabei vergewissert er sich, dass die meisten anderen die jeweilige Story ebenso geschätzt haben. Wenn nicht, spricht er mit den anderen, und gegebenenfalls muss die Story einer anderen Karte zugeordnet werden; oder man nimmt sie ganz heraus, wenn keine Einigung erzielt werden kann. Dann muss diese User Story gesondert behandelt werden.

Sind alle User Stories geschätzt worden und gibt es keine Bewegung mehr oder ist der Timer abgelaufen, so müssen die Storypoints nur noch auf die User Stories übertragen werden, und fertig ist die Schätzung.

Der Vorteil dieser Schätzmethode ist, dass man sehr viele Stories sehr schnell schätzen kann. Jedes Teammitglied ist engagiert dabei.

Release Planning Meeting

Das Release Planning Meeting ist eine Besonderheit von SAFe, dem Scaled Agile Framework. Die Planung eines Releases eines Softwareprodukts findet während eines eineinhalb bis zwei Tage dauernden Meetings statt, bei dem mindestens alle Mitglieder der Programmebene, aber auch andere dabei sind. Das Meeting wird vom so genannten „Release Train Engineer“ veranstaltet. Er ist der Scrum Master der Teams auf Teamebene, also der Ebene unterhalb der Programmebene.

Das Release Planning Meeting ist essenziell für SAFe. Dean Leffingwell sagt, dass SAFe ohne dieses Meeting nicht funktionieren kann. Wichtige Eckpunkte des Meetings sind, dass eine direkte Kommunikation stattfindet, die hilft, Abhängigkeiten zu erkennen und die Koordination zwischen den Teams fördert. Hier wird eine ausführliche Begründung gegeben.

Story Mapping

Jeff Patton wird das Pattern „Story Map“ zugeschrieben. Ausgangspunkt ist das flache Product Backlog, in dem die User Stories priorisiert sind. Beim Story Mapping wird unterschieden zwischen den User Stories und den Tasks, die eine feinere Beschreibung der Merkmale einer User Story darstellen. Jeff Patton schlägt vor, die User Stories horizontal aufzutragen und die zugehörigen Tasks darunter anzuordnen, priorisiert nach Wichtigkeit. Wenn man jetzt diese Tasks der einzelnen User Stories horizontal zusammenfasst, dann bekommt man die Merkmale, die ein Release ausmacht.

Es ist eine Tabelle mit den User Stories als Überschriften. Diese beschreiben die wichtigen großen Funktionsblöcke, die unbedingt benötigt werden. Jeff Patton bezeichnet die Ebene der User Stories als „Backbone“. Er sagt, dass es wenig sinnvoll ist, eine Priorität festzulegen, weil alle wichtig sind. Die Ausprägung, wie eine User Story im Detail aussieht, die durch die Tasks beschrieben wird, kann man aber priorisieren, und damit entstehen nacheinander Releases, die ein MVP – ein Minimum Viable Product – als Ergebnis haben.

Story Mapping hilft, das entstehende Softwaresystem als Ganzes zu sehen und nicht aufgebrochen in möglicherweise zusammenhanglose User Stories. Eine Story Map ist wie ein Information Radiator und sie sollte für alle sichtbar angebracht sein. Sie wird zum Planungsinstrument für die Sprints bzw. Iterationen und ist Grundlage für Diskussionen über das Produkt und seine Merkmale. Während der Implementierung wandert das Team am Backbone – oder „Walking Skeleton“, wie es Alistair Cockburn bezeichnet, entlang – und es entsteht peu à peu das System, nicht nur einzelne Merkmale.

Zusammenfassung

Agil vorzugehen heißt Transparenz zu schaffen. Das geht oft mit den einfachsten Mitteln, wie mit dem Whiteboard oder mit dem Whitedesk. Dazu gibt es auch elektronische Vertreter wie z. B. das eteoBoard, im Grunde ein großer Touchscreen mit Bediensoftware, die den Scrum-Prozess abbildet. Das machen die meisten Tools, die man entweder als Cloud-Lösung oder installierbare Version nutzen kann. Oft bieten sie einen kostenlosen Zugang für eine bestimmte Anzahl an Benutzern, bevor man zur Kasse gebeten wird.

Man sollte sich im Klaren sein, wo man seine Geschäftsgeheimnisse speichert, die mit der Entwicklung eines Softwareprodukts einhergehen. Andere Auswahlkriterien für agile Tools wurden angesprochen und zusammengefasst. Die Spanne der Features ist sehr groß und die Suche nach einem geeigneten Produkt nicht einfach.

Die Beschreibung der technischen Tools wurde um die Erläuterung der fachlichen Tools, wie Release Planning Meeting oder Story Mapping ergänzt. Während der Erstellung dieses Beitrags wurde ich noch aufmerksam auf Tools, die die Retrospektive unterstützen und die ich dem Leser nicht vorenthalten will.

Zum Schluss wünsche ich dem Leser eine gute Wahl nach der sorgfältigen Abwägung der Vor- und Nachteile. Es gilt: Weniger ist oft mehr.

Verwandte Themen:

Geschrieben von
Martin Künkele
Martin Künkele
  Martin Künkele ist Inhaber der Firma SMK Software Management Kommunikation GmbH. Mit seiner Firma entwickelt er Webapplikationen und mobile Apps auf der Basis von JDeveloper/ADF. Er ist zertifizierter Projektmanager nach P.M.I. und Certified Scrum Master der Scrum Alliance. Er beschäftigt sich mit der Frage, wie man ADF-Projekte agil durchführen kann und welche Aspekte aus Sicht des Projektmanagements zusätzlich zu berücksichtigen sind, um ein Projekt erfolgreich abzuschließen. Sein Blog befindet sich auf http://martinkuenkele.blogspot.de.
Kommentare
  1. Jessica L.2018-02-09 10:46:28

    Ein toller Beitrag, der viele Einblicke in Scrum gibt. Man hätte sicher noch viel mehr schreiben können, aber die Punkte hier bringen das Wichtige auf den Punkt. Ergänzen würde ich allerdings für Neueinsteiger einen Beitrag meiner Kollegin bei uns im Startup. Dort hat sie agiles Projektmanagement und die einzelnen Schritte erklärt. Eventuell auch gut für Personen, die ihre eigenen Kriterien schreiben, als grundlegendes Verständnis des Vorgangs.
    Hier übrigens der Artikel: https://blog.zenkit.com/agile-project-management-a-beginners-guide-cf2a574f9c3c

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.