Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Eine wichtige Aufgabe des Produktowners ist es dafür zu sorgen, daß das Team eine angemessene Anzahl von Aufgaben erhält: Nicht zuviel, und nicht zuwenig.
Da der Aufwand eines Entwicklungsprojekts oft nicht einfach einzuschätzen ist, und einem vielfach die notwendigen (kompletten) Informationen fehlen, sind Verfahren notwendig, mit denen man den Backlog schnell abschätzen kann, obwohl die Genauigkeit fehlt.
Hierbei geht es auch darum, daß man sinnvoll mit typischen Fallstricken umgehen kann. Im Scrum-Entwicklungsmodus ist das Entwicklungsteam zusammen mit dem Produktowner für die Abschätzung verantwortlich.
Ein Fallstrick ist zum Beispiel, daß sich einzelne Mitarbeiter (ungewollt) durchsetzen, und so falsche Abschätzungen entstehen. Man benötigt daher Verfahren, bei denen sich die Teammitglieder nicht gegenseitig beeinflussen.
Ein anderer Fallstrick ist, daß die verschiedenen Teammitglieder eine unterschiedliche Auffassung von Messkriterien haben. Man benötigt daher ein Verfahren das zum Beispiel keine Absolutaufwände abfragt, sondern sich auf Relativangaben beschränkt (Menschen fällt es leichter, Größenverhältnisse abzuschätzen, als Absolutbeträge).
Der sogenannte „Planning Poker“ hilft bei der Abschätzung einzelner Backlog Items. Ein Verfahren mit Namen „Magic Estimation“ wird eher für größere Backlogs verwendet. Beide Verfahren adressieren die üblichen Fallstricke.
Grundlage einer genauen Abschätzung ist die genaue Kenntnis der Anforderungen, denn nur wenn das Team genau weiß, was verlangt ist, kann es schätzen, was notwendig ist, um diese Anforderungen zu erfüllen. Hierzu dienen insbesondere konkret formulierte Anforderungen. Die Frage ist, wie man hierzu kommt.
Zentral für eine funktionierende Abschätzung sind klar und präzise formulierte Anforderungen. Hierfür lohnt es sich, in die entsprechenden Definitionen zu schauen.
Software Requirements Specifications sind im IEEE Standard 830 erstmalig definiert worden. In dieser Norm kann man die Anforderungen nachlesen, die an Anforderungen, bzw Spezifikationen generell zu stellen sind (siehe z.B. in Wikipedia → Software Requirements Specification). Dort werden Requirements, bzw Anforderungen wie folgt definiert:
„Mit Requirements (deutsch: Anforderungen) ist sowohl die qualitative als auch die quantitative Definition eines benötigten Programms aus der Sicht des Auftraggebers gemeint. Im Idealfall umfasst eine solche Spezifikation ausführliche Beschreibung von Zweck, geplantem Einsatz in der Praxis sowie dem geforderten Funktionsumfang einer Software. Hierbei sollte fachlichen – „Was soll die Software können?“ – wie auch technischen Aspekten – „In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden?“ – Rechnung getragen werden.“ – siehe Wikipedia
Generell ist es für die spätere Planung wichtig, dass man die Anforderungen eindeutig und nachprüfbar formuliert. Eine zu vage Formulierung erkennt man oft daran, dass man bereits Schwierigkeiten damit hat, Testfälle zu formulieren (eine spezielle Methode, die hier ansetzt, nennt sich „Specification by Example„).
Um diesen Zusammenhang zu verstehen schauen Sie sich ein Beispiel für eine zu vage Formulierung und den passenden Testfall an:
An diesem Beispiel erkennt man, wie wichtig es ist, die Begriffe „Karte“ und „Daten“ genauer zu spezifizieren. Anderenfalls besteht die Gefahr, daß nicht einmal ein Test diese Fehler findet geschweige denn, daß man genau weiß, was und wie man zu entwickeln hat, und welchen Aufwand dies verursacht.
Die folgenden Beispiel zeigen sinnvollere Formulierungen:
• Grundanforderungen an das Produkt formuliert man konkret wie „Bei clicken des Buttons „Hilfe“ wird die Software ein Hilfefenster mit Informationen anzeigen“
• Funktionale Anforderungen mit Schnittstelle als beispielsweise „Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung.“
• Funktionale Anforderungen mit Schnittstelle/Einschränkungals zum Beispiel „Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung, nachdem der Nutzer „Ok“ gedrückt hat“
• Nichtfunktionale Anforderungen mit Schnittstelle/Einschränkung: „Die Software soll innerhalb von 10 Sekunden auf die Eingabe des Nutzers reagieren“
• Nichtfunktionale Prozessanforderungen mit Einschränkung: „Der Administrator soll die fehlerfreie Datei innerhalb der nächsten Stunde transportieren“
• Nichtfunktionale Prozessanforderungen: „Die Dokumentation soll zum Projektende in Deutsch und Englisch vorliegen“
• Nichtfunktionale Prozessanforderungen mit Projektrandbedingungen: Das verantwortliche Scrum Team wird aus einem Produktowner, einem Scrum Owner, 7 Entwicklern, und einem Qualityexperten bestehen“
Für die Planung und das Planning Poker reicht es oft, daß man die Anforderungen zwar präzise, jedoch auf einem höheren Niveau kennt. Zur Not teilt man das Backlog Item in die beiden separaten Teile „Konzept“, und „Entwicklung/ Test“, wobei man im ersten Backlog item genau die Klärung vornimmt, die man dann später benötigt, um genauer zu schätzen.
In einem Planningpoker präsentiert der Produktowner jeweils ein Backlog Item/ User Story, und erklärt die Anforderungen im Detail (Poker deshalb, weil man hier z.B. Karten benutzt, und „bietet“). Sobald die Fragen beantwortet sind, schätzen die Teammitglieder den Aufwand ab, den die Umsetzung erfordern wird. Oft redet man an dieser Stelle auch über eine konkrete Umsetzung, jedoch nur insoweit, wie es notwendig ist, um zu Verstehen, was zu tun ist. Es bietet sich jedoch an, die Aufgaben konkret zu notieren, die sich aus der Diskussion ergeben.
In der stillen Schätzrunde schätzt jedes Teammitglied den Aufwand für sich selbst ein, und wählt eine Spielkarte, die den Aufwand repräsentiert. Normalerweise wird hierfür ein spezielles Kartenspiel verwendet, das Werte, wie 1/2, 0, 1, … 100, unendlich kennt. Man kann allerdings auch ein x-beliebiges anderes Kartenspiel verwenden, oder andere normbare Werte.
Sobald jedes Teammitglied die Karte gewählt hat, wird der Wert gezeigt. Normalerweise kommt es zu Abweichungen, die dann diskutiert werden. Sobald geklärt ist, wer, warum und wieviel schätzt, erfolgt eine weitere Abschätzrunde. Im Streitfall entscheidet der Scrum Master, z.B. den größten Wert zu nehmen.
Dabei sollte man bei allem Eifer nicht vergessen, daß es hierbei darum geht, eine erste Schätzung zu haben, um so besser planen zu können. Die Aufwände sind weder in Beton gegossen, noch ist es verboten, die Aufwände später in der Planung zu korrigieren, wenn neue Erkenntnisse hinzukommen.
Das Planning Poker verwendet man, um einzelne Backlog Items genauer zu Umreißen. Das Verfahren der Magic Estimation wird benutzt, um größere Backlogs einzuschätzen. Hierbei wird z.B. eine Wand gerastert (Flipboard,..), und jedem Raster ein Wert gegeben, der die unterschiedlichen Klassen von Story Points repräsentiert. Weiterhin wird das Verfahren geklärt. Wichtig ist, daß es während der Schätzung keine verbale/nonverbale Kommunikation zwischen den Teammitgliedern gibt, damit es zu keinen Absprachen kommt.
Der Produktowner präsentiert jedes Backlog Item, und verteilt die Items dann gleichmäßig an alle Teammitglieder. Jeder Teilnehmer schätzt seine Items, und ordnet sie dem entsprechenden Raster zu.
Anschliessend kann jedes Teammitglied die Items der anderen umsortieren, von denen er der Meinung ist, daß sie im flachen Raster liegen.
Stories, die vor- und zurückgeschoben werden, werden aus der Schätzung entfernt, und im Anschluss an die Schätzrunde gemeinsam geklärt, da es sich hierbei offenbar um Projekte handelt, die sich nicht so einfach klären lassen.
Die genannten Methoden helfen dabei, den Produktbacklog zu strukturieren, und zu klären. Die Vorgehensweise hat jedoch noch weitere Vorteile:
Ich persönlich habe solche Meetings und Pokersessions stets als sinnvoll empfunden. Daher lege ich Ihnen nahe, die Methode bei sich einmal auszuprobieren.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
