Aktionen

Entwickleranforderungen dokumentieren

Aus PQWiki


Schnelligkeit
★☆☆
Einfachheit
★★☆
Agilität
★★★

Ziele

* Entwickleranforderungen in kleine Arbeitspakete aufteilen
  • Agilere Entwicklung

Motivation/Problemstellung

Die Fachsprache des Entwicklers unterscheidet sich häufig von derjenigen des Kunden, weswegen die Sprache des Kunden in diejenige des Entwicklers unter Beachtung von festen Regeln übersetzt werden muss. Sind einzelne Kunden-Anforderungen zu abstrakt, um sie direkt umsetzen zu können, müssen sie zusätzlich unterteilt und genauer spezifiziert werden.

Kurzbeschreibung

Entwickleranforderunge dokumentieren.jpg
Die Kunden-Anforderungen werden in technische Anforderungen übertragen, sodass definierte, klar strukturierte, zeitlich kleine Arbeitspakete (Tasks, Tickets) entstehen, die in ein Ticket-System eingepflegt und im Rahmen eines agilen Entwicklungsprozesses abgearbeitet werden können.

Input

Kunden-Anforderungen

Output

Definierte, klar strukturierte, zeitlich kleine Arbeitspakete (Tasks, Tickets)

Rahmenbedingungen

Rolle (Ausführender)

Technischer Projektleiter

Werkzeuge, Hilfsmittel

Ticketsystem

Vorkenntnisse und Erfahrungen

Kenntnis des Ticketsystems Maske zur Erfassung der Aufgabe

Ort und Umgebung

Arbeitsplatz, Besprechungsraum

Weitere Teilnehmer

Entwicklerteam

Voraussichtliche Dauer

30min - 2h pro Sprint

Vorgehensweise

Vorbereitung

Der Projektleiter teilt den Anwendungsfall (Use Case) in kleine Aufgaben (Tasks) auf und beschreibt zuerst grob, was von technischer Seite getan werden muss. Er dokumentiert auch die Abhängigkeit der einzelnen Aufgaben. Eine Aufgabe sollte immer dieselbe Struktur aufweisen, kann aber frei definiert werden.

Beispiel für eine Aufgabe: - Kunde: Postbank - Bereich: Datenbanken - Produktverantwortlicher (Product Owner): Walter Schmidt - Projektleiter (Project Leader): Hermann Weihrauch - Bearbeiter: Max Müller - Betreff: Datenimport der Postbank-Filialen - Kurzbeschreibung: Die im XML-Format gelieferten Daten sollen geocodiert und auf dem Test/Staging/Live-System eingespielt werden. - Risiko: gering - Priorität: hoch - Status: eingelastet - Codereview: Nein - Zeitschätzung: 3h - Aufgewendete Zeit: 0h - Ist abhängig von: Task 2 (Datenlieferung)

- Sprint: 2015-01

Durchführung


Der Projektleiter bespricht die technischen Hintergründe der Aufgaben mit seinem Team. Alle Gesichtspunkte, unter denen eine Aufgabe betrachtet werden soll, werden angesprochen. Der Projektleiter klärt offene Fragen, die sich während des Meetings ergeben, direkt mit dem Produktverantwortlichen. Im Idealfall ist der Produktverantwortliche während des Team-Meetings anwesend. Der Zeitaufwand und das Risiko werden vom Team gemeinsam geschätzt; der Projektleiter verfeinert die Aufgabenbeschreibung in Abhängigkeit von den Rückmeldungen der Teammitglieder. Die einzelnen Aufgaben werden auf diese Weise als ausgefüllte Tickets im Ticketsystem festgehalten. Jedes Ticket muss zwingend einem bearbeitenden Entwickler, einem Pro-jektleiter und einem Produktverantwortlichen zugewiesen sein. Der Projektleiter (im Idealfall das Regelwerk des Ticketsystem selbst) achtet darauf, dass die weiteren Pflichtfelder ausgefüllt und ergänzende Dokumentationen mit dem Ticket verknüpft sind.

Nachbereitung

Der Projektleiter sollte im Weiteren das Projekt beobachten und für Rückfragen zur Verfügung stehen. Die Entwickler geben zeitnah Rückmeldung über den Fortschritt der Umsetzung und die Schwierigkeiten, die die Umsetzung verzögern oder verhindern. Für das hier vorgestellte Best-Practice ist vor allem wichtig, festzustellen, ob Mängel der Dokumentation und Ungenauigkeiten der Spezifikation verantwortlich für Verzögerungen oder Missverständnisse während der Umsetzung waren.

Gütekriterien/Empfehlungen

Es ist empfehlenswert, die Maske zur Erfassung der einzelnen Aufgaben auf das Wesentliche zu beschränken. Essentiell ist die Angabe der verantwortlichen Ansprechpartner (Product Owner und Projektleiter). Zeitschätzungen nimmt das gesamte Team vor, weil auch das Team sich verantwortlich für die Erfüllung der Aufgabe zeichnet. In Abhängigkeit von der Komplexität der Aufgabe kann die geschätzte Zeit mit einem Korrekturfaktor multipliziert werden. Der Faktor beruht auf Erfahrungswerten.

Risiken

Unzureichend oder unvollständig erfasste Aufgaben können zu einer Zeitverzögerung des Projekts führen. Die Ursachen hierfür sind die zusätzlichen Aufwände der nicht eingeplanten Teilaspekte einerseits und die vermehrten Rückfragen (Meetings) andererseits.

Einordnung in das PQ4Agile-Qualitätsmodell

Schlagworte

Anforderungen, Arbeitspakete, Task, Ticket, Anwendungsfall, Zeitschätzung

Weiterführende Informationen

Literatur

- B. Oestereich: Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language, Oldenburger, Wien 2001