Aktionen
Entwickleranforderungen dokumentieren
Aus PQWiki
SE-Disziplin
Bereich
Aktivität
- 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
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-01Durchfü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
Informationen im Internet
Literatur
- B. Oestereich: Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language, Oldenburger, Wien 2001