Werkzeuge für Product Owner bei

Bosch RexrothWer als Produktmanager arbeitet oder die Rolle des Product Owner innehat, verwendet wahrscheinlich Microsoft Office Word, umAnforderungen aufzunehmen und zu dokumentieren, Excel, um Abschätzungen zu Kosten und Aufwand festzuhalten undPrioritäten zu vergeben, sowie ein Ticket-System oder Bug-Tracking-Tool, um mit Entwicklung und Qualitätssicherung zu kom-munizieren. Leider haben diese Systeme keine gemeinsame Datenbasis: neben der Tatsache, dass die Daten mehrfach angelegtund gepflegt werden müssen, bedeutet jeder Übergang einen Informationsverlust. Einige Informationen stehen nur in Word, eini-ge sind nur in Excel, andere sind nur im Ticket-System zu finden. Von den UML-Modellen, die mit Visio, Enterprise Architect oderähnlichen Werkzeugen erstellt wurden, ganz zu schweigen. Der Product Owner zerreißt sich also zwischen diesen verschiedenenTools der unterschiedlichen Ansprechpartner. Dieser Artikel zeigt, wie eine integrierte Werkzeugkette mit gemeinsamer, zentra-ler Datenbasis für die bekannten Tools aussehen kann.

Wünsche seiner Kunden in Produktinkre -mente zu verwandeln.

Im Wesentlichen muss er dazu:

■ Die zunächst häufig unstrukturiertenInformationen des Kunden als Anfor -derungen aufnehmen, konkretisierenund strukturieren.

■ Lücken in den Anforderung identifizie-ren und schließen.

Methodenkompetenz mit einer durchgän-gigen Datenbasis zu verknüpfen.

Abbildung 1 zeigt, wie aus einer Kunden -idee ein Eintrag im Backlog eines Ent -wicklungsteams wird. Bindeglied zwischenKunde und der Entwicklung ist der ProductOwner (auch Produktmanager genannt).Er hat die Aufgabe, seine Kunden von denentwickelten Produkten zu begeistern.Indem er die Vorgaben aufarbeitet, versetzter das Entwicklungsteam in die Lage, die

Menschliche und andere

Herausforderungen

Die größte Herausforderung in Entwick -lungs projekten ist die Kommunikation mitdem Kunden oder involvierten Fach -abteilungen.

Wenn Missverständnisse zwischen Auf -trag geber und Auftragnehmer erst spät imProjekt zutage treten, wird die Korrektureventuell kostspielig – je später, desto teu-rer. Aktuelle Projektdaten und passendeSichten auf diese sind somit eine wichtigeVoraussetzung für die Durchführung vonSoftwareprojekten. Beides hilft, Missver -ständnisse und Lücken in Annahmen,Spezifikationen und Planungen früh zuerkennen und zu beseitigen. Transparenz inder Planung schafft Vertrauen – Vertrauenzwischen Auftraggeber und Auftrag neh -mer, aber auch zwischen Entwicklung undManagement.

Passende Prozesse sind hierfür eine not-wendige Voraussetzung. Ein entscheiden-des Erfolgskriterium beim Etablieren dieserProzesse sind die passenden Tools. So nutztBosch Rexroth den Microsoft TeamFoundation Server (TFS), um die eigene

der au tor

Sven Hubert

(sven.hubert@aitgmbh.de)ist Bereichsleiter und Software Process Consultant im AIT TeamSystemPro-Team und MVP für Visual Studio ALM. Er hilft Teams bei der Verbesserung derSoftwareentwicklung und berät bei der Einführung und Anpassung des VisualStudio Team Foundation Server. Seine Erfahrungen vermittelt er zudem alsAutor des TFS-Blogs, in Magazinen und in Vorträgen.

Stefan Rauch

(stefan.rauch@boschrexroth.de)ist bei Bosch Rexroth in einem Entwicklungsbereich für die Einführung vonSoftwareentwicklungsprozessen verantwortlich. Er nutzt den TeamFoundation Server als Grundlage für die Umsetzung agiler Verfahren undeiner durchgängigen Toolkette.

1 www.objektspektrum.de

advertorial

Abb. 1: Informationspipeline – von der Idee bis zum Iterationsbacklog

■ Die Anforderungen priorisieren und ineine Abarbeitungsreihenfolge bringen.

■ Fragen des Teams beantworten undEntscheidungen zu kurzfristigen Ände-rungen treffen.

■ Funktionale Lösungskonzepte mit demTeam erarbeiten.

■ Für eine passende Detaillierung sorgen.■ Akzeptanzkriterien für die formulierten

Anforderungen definieren.

Im Rahmen seiner Tätigkeiten erzeugt derProduct Owner eine Menge Informationen,die er irgendwo verwalten muss.

Aus Word in die Datenbank

Für die Verwaltung der Anforderungenwurde bei Bosch Rexroth nach einerMöglichkeit gesucht, neben den gängigenBearbeitungsmöglichkeiten über Excel oderein Webportal, die während des Projektsentstehenden Artefakte wie Requirements,Use Cases und Testfälle untereinander zuverknüpfen (vgl. Abbildung 2) .

Zu Beginn eines Entwicklungsvorhabenssieht sich ein Product Owner je nach Pro -jektart mit sehr unterschiedlichen Voraus -setzungen konfrontiert (vgl. Abbildung 1,Spalte 1). Während für die Weiterent wick -lung von bereits existierenden Produktendie Kunden oft schon sehr strukturierteund konkrete Anforderungen an dieEntwicklung übergeben, ist das Bild beineuen Produkten in der Regel deutlichunschärfer.

Egal mit welcher Form von Kunden -wünschen es der Product Owner zu tunhat, seine Aufgabe ist die Dokumentationund das Strukturieren der vorhandenen

Informationen. Als geeignetes Werkzeughierfür hat sich Word etabliert. Es gibtzunächst keine Struktur für Aufzeich -nungen vor und gewährt somit den erfor-derlichen Freiraum.

Im Rahmen der Anforderungserhebunghat es sich allerdings bewährt, gewisseVorlagen für aufzunehmende Punkte undStrukturen vorzugeben. Im schlechtestenFall wird der Freiraum von Word fürunstrukturierte Prosa „missbraucht“.Word ist durch seine Verbreitung aber einegute Grundlage für die Kommunikationund aktive Mitarbeit aller Projekt be -teiligten.

In Word vorstrukturierte Kunden -wünsche synchronisiert der Product Ownermit dem von AIT entwickelten, kostenlo-sen Word-Plug-in „WordToTFS“ bidirek-tional mit der Datenbank des TFS. Diese istdas zentrale Repository für alle Projekt -daten und beinhaltet die „einzige Wahr -heit“ im Projekt.

Die sogenannten „Work Items“ (Überbe-griff für alle Requirements, Workpackages,Use Cases usw.) werden in Word in Formvon Tabellen dargestellt, deren Format undLayout pro Projekt frei definiert werdenkann. Somit ist eine Anpassung an unter-nehmensinterne Vorgaben und Prozesseohne Weiteres möglich. Dokumenten -templates führen den Product Owner durchdie Anforderungsanalyse und dienen ihmals Checkliste, um alle wesentlichenInformationen zu den Anforderungen ein-zuholen.

Zur Beschreibung der Work Items ohneWeiteres können in Word auch Bilder undandere Elemente verwendet werden. Dies

versetzt den Product Owner in die Lage,zur Beschreibung von Anforderungenneben Text auch mit Skizzen und Kenn -feldern zu arbeiten, was besonders im tech-nischen Umfeld sehr wichtig ist

Ein Beispiel bietet Abbildung 3. Im lin-ken Bereich ist das Dokument mit Grafikenzu sehen. Die Anforderung ist als Tabelleim Word-Dokument hinterlegt und wirdmit dem TFS synchronisiert (rechts imBild). Eine allgemeine Übersicht über ande-re Werkzeuge zur Verwaltung vonAnforderungen und Aufgaben mit TFS2012 finden Sie unter [SvH12].

Lebendige Modelle

Um die im ersten Schritt vom Kunden auf-genommenen Informationen in einenProduct Backlog mit planbaren Arbeitsauf -trägen für die Entwicklung zu transformie-ren, baut der Product Owner ein Anfor -derungsmodell auf (vgl. Abbildung 1,Spalte 2). Für die Darstellung der funktio-nalen Anforderungen hat sich das Arbeitenmit Use Cases als adäquate Methode erwie-sen.

Im Anforderungsmodell hat er die Mög -lichkeit, die Informationen weiter zu struk-turieren und Verbindungen in Form vonGeneralisierungs- und Abhängigkeits be -ziehungen in das Modell aufzunehmen. DieDiagramme im Modell eignen sich als sehrgute Arbeitsgrundlage für Diskussionenmit Kunden und Entwicklern.

Der Product Owner orientiert sich dabeian den zu spezifizierenden Attributen füreinen Use Case, wie Vor- und Nachbe din -gungen, essenziellem Ablauf usw. Bei derSpezifikation der Use Case-Attribute sowie

2Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 advertorial

Abb. 2: TFS als Rückgrat für alle ProductOwner-Werkzeuge

Abb. 3: WordToTFS in Aktion

„Child“-Beziehung an das entsprechendübergeordnete Product Feature gebunden.

Zur weiteren Detailierung eines Use Casestehen dem Product Owner mehrere Mög -lichkeiten offen. Er kann z. B. weitereUML-Diagramme (State- oder Activity-Diagramme usw.) nutzen, um Abläufedetailliert zu beschreiben. Diese Vorgehens -weise ist empfehlenswert, wenn er mitKunden oder der Entwicklung noch Dis -kus sionen führen muss: es steht eine visuel-le Diskussionsgrundlage zur Verfügung.

Eine andere Möglichkeit ist, die Akzep -tanzkriterien direkt in Form von Test-Case-Work-Items zu formulieren und diese alsweitere Spezifikationselemente mit demUse Cases zu verknüpfen.

Ob ein Product Owner Anforderungenzunächst frei aufnimmt und daraus zueinem späteren Zeitpunkt Use Cases ablei-tet oder die Kundenanforderungen direktals Use Cases formuliert, erfordert eingewisses Maß an Fingerspitzengefühl. DieErfahrung hat gezeigt, dass bei „Green -field“-Anwendungen mehr Spiel raumerfor derlich ist, während bei der Erwei -terung von bestehenden Applika tionenKunden oft schon selbst in Use Cases den-ken.

Im Zusammenspiel mit WordToTFS[AIT] bietet die Visual Studio Model -lierungsumgebung dem Product Ownereine professionelle Arbeitsumgebung fürdie Erfassung und Dokumentation vonKundenanforderungen. Durch die Vor -

auch die Informationen zur Verfügung, dieer in seinem UML-Anforderungsmodellerstellt hat.

Beispiel aus Abbildung 5: Das UML-Subsystem „Kundenverwaltung“ wird aufdas gleichnamige Work Item vom Typ PF(Product Feature) abgebildet. Die drei UseCases aus dem UML-Diagramm werdenauf jeweils ein Work Item vom Typ UC(Use Case) abgebildet und mit einer

beim Verknüpfen von Use Cases unterein-ander oder mit Akteuren werden häufignoch weitere Use Cases entdeckt, an die bisdahin niemand gedacht hatte.

Als Werkzeug hierfür werden die Visual-Studio-Modeling-Tools genutzt, die in derUltimate Edition von Visual Studio dasErstellen von UML-Diagrammen ermög-lichen. Die so modellierten Use Cases kön-nen mit Work Items im TFS verknüpft wer-den. Somit werden die UML-Modelle zueiner weiteren „Sicht“ auf die Daten imTFS-Repository.

Die Standardfunktionalität der VisualStudio Modeling Tools erlaubt es demProduct Owner, einzelne UML-Modell -elemente wie Subsysteme oder Use Casesselbst mit Work Items im TFS zu verknüp-fen. Leider werden dabei die Beziehungen,wie z. B. Abhängigkeiten oder Generali -sierung zwischen UML-Modellelementen,nicht auf die verbundenen Work Itemsübertragen, sondern müssen nochmalsmanuell nachgepflegt werden.

Zur Lösung dieses Problems wurde inZu sammenarbeit mit AIT für BoschRexroth ein Visual-Studio-Plug-in entwik-kelt, das diese Lücke schließt. Das Plug-inerzeugt automatisch für jedes Diagramm -element ein entsprechendes Work Iteminklusive der gewünschten Verknüpfungen,die die modellierten Beziehungen repräsen-tieren (siehe Abbildung 4). So stehen demProduct Owner in seinem Product Backlog

advertorial

3 www.objektspektrum.de

Abb. 4: Use Case-Modell mit verknüpften Work Items

Abb. 5: Use Case-Diagramme mit einem Klick mit dem TFS synchronisieren.

gehensweise mit Use Cases wird derProduct Owner zusätzlich methodischbeim Aufbau des Anforderungsmodellsunter stützt.

Product Backlogs

Da Anforderungen schon als Work Itemsim TFS erfasst sind, können sie alsGrundlage für den Aufbau des ProductBacklogs verwendet werden ohne eine wei-tere Toolgrenze überwinden zu müssen.

Damit ein Team Anforderungen in Formvon Use-Case- oder Product-Feature-Work-Items umsetzen kann, müssen diesebestimmte Bedingungen erfüllen: sie sollenSMART sein (Specific/Spezifisch, Mea -surable/Messbar, Attainable/Machbar, Re -sour ced/Zu gewiesen, Timely/Terminierbar(vgl. [Ral12]).

Sind die Anforderungen noch zu grob,um diese Kriterien zu erfüllen, stehenProduct Owner und Entwicklungsteam vorder Herausforderung einen passendenZuschnitt zu finden. Eine Möglichkeit die-se Aufgabe methodisch durchzuführen, istdie Anwendung der Hamburger Methode(siehe [goj12]).

Ein Use Case verwandelt sich dann ineinen „Hamburger“, dessen essenzielleSchritte durch den Belag repräsentiert wer-den. Ein Biss am Hamburger entsprichteinem Arbeitspaket in einem Sprint. DasTeam hat die Aufgabe, den Burger Biss fürBiss zu „verspeisen“. Ein Blick in diesesVorgehen lohnt sich und macht Spaß.

Keine Gewähr ohne

Bestätigung

Es wird immer wichtiger, schon währenddes Designs oder der Entwicklung allewichtigen Projektbeteiligten einzubinden.Der Product Owner zum Beispiel wirdzwar ständig in Entscheidungen zu dennicht spezifizierten Details einbezogen.Doch auch die Fachabteilung sollte schonvor dem Release Feedback geben und soEinfluss auf die Funktionen nehmen kön-nen.

Mit TFS 2012 können Anfragen fürFeed back gezielt via Mail an Projekt -beteiligte versendet werden. Diese enthal-ten einen Link auf die Installation desFeedback-Tools. Das Werkzeug erlaubt esdem Benutzer, unkompliziert Kommentareabzugeben, Screenshots zu erstellen sowieein Video (natürlich mit Ton) aufzuzeich-nen. Sämtliches Feedback wird in Formvon Work Items in der Datenbasis des TFSgesammelt – versandet also nicht in irgend-einer Inbox. Der Product Owner kann sospäter das Feedback auswerten und miteiner neuen oder bestehenden Anforderungverknüpfen.

Damit werden späte Änderungen anAnforderungen transparent und die Ent -scheidungen auch lange nach der Umset -zung nachvollziehbar.

Fazit

Eine durchgängige Toolkette gewährleisteteine gemeinsame Planungsbasis – in frühe-ren Phasen erstellte Artefakte werden nichtmehr verwendet, weil sie in einem unbe-kannten, sprich „veralteten“, Zustandsind. Eine integrierte Werkzeugkette stelltfür alle Disziplinen geeignete Editoren zurVer fügung und arbeitet auf einer zentralenDatenbasis. Word2TFS, die Anbindung derVisual Studio Modellierumgebung sowiedie Standardeditoren des TFS sind eineumfassende, integrierte Umgebung für dieEntwicklung und Verwaltung von An -forderungen. Die durchgängige Toolkettehilft auch bei der Umsetzung der An -forderungen und der Nachverfolgung derEntwicklungsaktivitäten. ■

4Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 advertorial

Abb. 6: Feedback kann mit demFeedback-Tool gegeben werden, welchesan den Desktop andockt und z. B. dieAktionen des Nutzers am Bildschirm auf-zeichnet.

Links

[SvH12] http://de.slideshare.net/SvenHubert/tfs-2012-whats-new-in-alm-with-team-foundation-server-overview

[AIT] http://www.aitgmbh.de/index.php?id=222

[Ral12] http://blog.ralfw.de/2012/06/smarte-nutzenpakete.html

[goj12] http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/