Ich werde oft (meist von größeren Firmen) angesprochen, wie wir uns denn das Aufschreiben von Anforderungen mit JIRA vorstellen und wie wir das bei Atlassian handhaben. Jetzt ist es so, dass bei uns die verschiedenen Teams auch verschiedene Vorgehensweisen haben, deshalb kann es sein, dass man auf bei Atlassian auf Teams trifft, die eine andere Vorgehensweise bevorzugt… und das ist völlig in Ordnung (Agiles Manifesto: Individuen und Interaktionen über Prozesse und Werkzeuge)
User Story Doku – so machen wir es
Wir schreiben meistens nur einen Einzeiler als User Story auf (Als (A) möchte ich (B) machen, so dass (C)…). Dann erzeugen wir damit einfach einen Issue in GreenHopper/JIRA und bauen darauf auf. Wir vermeiden es, Spezifikationen zu schreiben. Wenn man das Problem in kleine Häppchen zerteilt und Einzelheiten dokumentiert, fällt meistens auf, dass man ziemlich offensichtliche Sachen dokumentiert, die entweder für jeden im Team klar sind oder die viel einfacher durch ein Mockup beschrieben werden können.
Aber gerade wenn man mit einem größerem, nicht mehr ganz frischen Softwareprojekt zu tun hat, muss man mehr Sachen berücksichtigen, als in einer Zeile in einer User Story steht. Also packen wir mehrere User Stories in eine Wiki-Seite und diskutieren diese.
Hier sind die Vorteile, die wir mit diesen Ansatz sehen:
1. Eine Seite, eine Quelle, ein Problem
Keep it simple! Normalerweise haben wir eine Seite mit dem Epic. In dieser Seite werden alle User Stories zu diesem Epic aufgeführt. Alles auf einer Seite zu haben, hilft dem Auffinden von Informationen ungemein.
Zusätzlich pflegen wir noch eine “Machen wir nicht”-Liste auf dieser Seite. Dies ist extrem wichtig, damit alle den Umfang des Epics verstehen. Dadurch versuchen wir zu vermeiden, dass falsche Erwartungen geweckt werden und es hilft dem Team beim Fokussieren und dem Management besser zu verstehen, was gemacht wird und was nicht!
2. Flexible Struktur
Der Vorteil von einem Wiki gegenüber einem Tool zum Anforderungsmanagement, ist die Agilität in der Dokumentation. Man muss nicht immer alles machen, was ein Tool einem vorschreibt. Mach, was du auch wirklich nur benötigst und sei agil!
3. In Details eintauchen
Verlinken ist eine Basisfunktion eines Wikis. Wir benutzen es häufig. Man könnte beispielsweise zu folgenden Details verlinken:
- Kunden Interviews, um den Kontext darzustellen
- Seiten und Blogposts von ähnlichen Ideen
- vorausgegangene Diskussionen oder technische Dokumente
- Links auf externe Informationen
Damit kann man ein einfaches Dokument erstellen und der Benutzer kann in die Tiefe der Informationen eintauschen.
4. Lebendige Dokumentation = Lebendige Stories
Auch unsere Kunden nutzen dieses Feature häufig: Ist erst mal das Gerüst für ein Story fertig, wird oft die JIRA Integration von Confluence genutzt: Aus der Seite heraus werden GreenHopper Stories erzeugt. Diese werden dann automatisch in Confluence angezeigt und man kann den Fortschritt von hier aus beobachten. Wenn also die Entwickler die Storie fertig haben, kann man das direkt con der Wiki Seite aus sehen.
5. Die Weisheit der Masse
Gerade in größeren Unternehmen erreicht man mit einer Dokumentation in einem Wiki, dass Mitarbeiter aus anderen Abteilungen an Diskussionen teilhaben und ihre Ideen teilen können. Es ist immer wieder faszinierend zu sehen, dass Kollegen aus anderen Teams tolles Feedback geben und Anregungen einbringen, an die man noch gar nicht gedacht hat.
6. Zusammenarbeit!
Der wahrscheinlich wichtigste Aspekt an dieser Vorgangsweise ist der, dass alle involviert sind. Schreibe niemals eine Spezifikation allein. Teile deine Ideen mit dem Team und sammle das Feedback. Kommentiere, stell Fragen, involvier andere in die Diskussion. Besonders wichtig ist dies für verteilte Teams!
7. Gestalte deine Stories ansprechend
Benutze Tools wie Gliffy oder Balsamiq, um besser Probleme darzustellen oder füge Bilder, Videos oder anderen interaktive Inhalte hinzu. Tu was immer notwendig ist, um das Problem klarer mit deinen Team zu kommunizieren.
Herausforderungen – das haben wir gelernt
Und jetzt einige Herausforderungen, die wir mit dieser Vorgehensweise haben:
1. Dokumentation hat die Tendenz veraltet zu sein
Was passiert, wenn du Feddback für ein Feature bekommst und du es daraufhin änderst. Passt du die Dokumentation an? Das ist ein große Herausforderung mit jeder Art von Dokumentation.
2. Eine offene Diskussionskultur
“Wie schaffe ich es, dass Leute meine Seite kommentieren?”, “Wie motiviere ich Mitarbeiter, mehr Spezifikationen und Stories im Wiki festzuhalten?”. Dies kann wirklich schwierig sein. Wir haben eine Seite mit Tipps, die vielleicht helfen können, eine bessere Akzeptanz für das Wiki zu generieren.
3. Fang an
Auch wenn wir dazu raten, dass jeder sein eigenes Format wählen sollte, brauchen einige Leute doch manchmal ein Richtlinie oder ein Template. Also fang an und schreib eine Anleitung oder auch schon das erste Beispiel-Epic ins Wiki und versuch deine Kollegen bei der Erstellung zu beteiligen.
Vielen Dank an Sherif Mansour für die vielen internen Infos.
Sven Peters 