Freitag, 1. August 2014

Was soll ich zuerst tun? Die Qual der Wahl.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im einführenden Post habe ich eine Vielzahl von Managementaufgaben aufgezählt, die es zu beherrschen gilt. Eine davon ist das Priorisieren. Im Verlaufe der Entwicklung werden eine große Anzahl von Artefakten erzeugt, Anforderungen, Architekturen, Code, Abnahmetests und vieles mehr. Was davon soll zuerst getan werden? Was ist wirklich wichtig? Wie entscheiden wir das? Im Post Themenobjekte ordnen Ideen in eine Roadmap wurden finalisierte Themenobjekte durch ein Gremium priorisiert. Jedes Mitglied dieses Gremiums besaß einen Vorrat an Punkten, den es bestimmten Ideen anteilig zuordnen konnte. Die Summe der so zugeordneten Punkte brachte die Themenobjekte in eine Reihenfolge. In diesem Post erwähnte ich auch, dass andere Priorisierungsmethoden vorstellbar sind. Heute wird es um andere Priorisierungsmethoden gehen, aber auch um theoretische und organisatorische Grundlagen.

Priorisiert wird immer dann, wenn eine notwendige Reihenfolge bestimmt werden muss, in der Dinge zu erstellen oder abzuarbeiten sind. Manchmal hat man nur die Zeit das Wichtigste zu erledigen und muss somit das Unwichtige aussortieren. Wir priorisieren etwas also in Bezug auf eine bestimmte Menge von Objekten gleicher Art, z.B. Anforderungen, die durch Aufgaben erstellt werden. Die Artefakte bzw. die erstellten Objekte unterschiedlicher Art stehen in einem bestimmten Zusammenhang. So werden im beschriebenen Requirements-Engineering-Prozess User Stories erzeugt, aus denen Use Cases erwachsen, die wiederum mit Anforderungen gekoppelt sind. Dabei werden die User Stories in Bezug auf Ihre Abarbeitungsreihenfolge priorisiert. Dasselbe kann jedoch auch mit den Anforderungen geschehen. Es entsteht eine Priorisierungshirarchie. Wir arbeiten die Reihenfolge der User Stories ab und innerhalb der User Stories beachten wir die Abarbeitungsreihenfolge der Anforderungen.


Im Folgenden wollen wir uns zur Priorisierung einige notwendige vorbereitende Gedanken machen. [POHL08] zählt folgende Vorbereitungsaktivitäten auf: "
  • Bestimmung der bei der Priorisierung zu berücksichtigenden Stakeholder
  • Auswahl der zu priorisierenden Artefakte
  • Festlegung der Priorisierungskriterien
  • Auswahl einer geeigneten Priorisierungstechnik
" [S. 528, POHL08]

In Bezug auf Anforderungen sollte der Kunde ein gewichtiges Wort, wenn nicht das wichtigste Wort, mitzureden haben. In der von mir bevorzugten Scrum-Umgebung ist außerdem das bearbeitende Team und der Product Owner einzubeziehen. Die so gebildete Priorisierungsgruppe sollte nun wissen, was sie zu priorisieren hat. "Die Kunden können jedoch ohne Information vom Entwicklerteam nicht priorisieren." [S.119, COHN10]

In einer Sitzung sollten nur Objekte gleicher Art priorisiert werden. Nicht jedes zu erzeugende Artefakt muss diesem Prozess unterzogen werden. Die Menge der zu priorisierenden Objekte, ist meiner Meinung nach sogar auf ein notwendiges Minimum zu beschränken. In meiner Requirements-Engineering-Reihe priorisiere ich Ideen, Themenobjekte und User Stories. Alle Folgeobjekte, wie Use Cases, funktionale Anforderungen und Qualitätsanforderungen, werden nicht priorisiert. Muss eine User Story umgesetzt werden, sind diese Folgeobjekte wohl oder übel anzufertigen, zumindest wenn man eine vernünftige und langfristig benutzbare Dokumentation haben will. [POHL08] schreibt dazu: "Bei der Priorisierung von Anforderungen sollten nur Anforderungen auf annähernd gleichem Abstraktionsniveau priorisiert werden" [S.530, POHL08] und "In der Praxis hat sich bewährt, bei der Priorisierung mit den Anforderungen auf einem möglichst hohen Abstraktionsniveau zu beginnen (z.B. Ziele). Die Prioritäten dieser Anforderungen vererben sich entlang der Konkretisierungsbeziehungen auf die Anforderungen auf den darunter liegenden Abstraktionsniveaus (z.B. von Zielen zu Subzielen)." [S.530, POHL08] Diese wesentlichen Gedanken von [POHL08] gelten natürlich nicht nur für Anforderungen, sondern für alle zu erstellenden Artefakte.



Nachdem wir wissen wer priorisiert und was zu priorisieren ist, fragen wir uns, was ist das Ziel der Priorisierung? "Das Ziel der Priorisierung legt fest, welche Kriterien der Priorisierung berücksichtigt werden müssen." [S.530, POHL08] Wie wichtig ist die Umsetzung des Artefaktes? Wie hoch sind die Kosten für die Erstellung? Verursacht die Umsetzung einen Schaden? Wie lange dauert die Umsetzung? Welches Risiko birgt die Umsetzung? Wird sich das Artefakt im Laufe der Zeit oft ändern? [POHL08] nennt die Kriterien, die sich hinter diesen Fragen verstecken: Wichtigkeit, Kosten, Schaden, Zeitdauer, Risiko und Volatilität. Haben wir die Kriterien festgelegt, für die wir die Prioritäten bestimmen wollen, ist uns bewusst, warum wir die Artefakte in eine Ordnung bringen wollen. Im Post Die Geschichten der Benutzer - User Stories erstellen priorisieren wir User Stories. [COHN10] spricht in diesem Zusammenhang nicht von Kriterien, sondern von Dimensionen. Er nennt die folgenden Dimensionen, nach denen wir priorisieren bzw. sortieren können: "
  • das Risiko, das die Story nicht wie gewünscht fertiggestellt werden kann (beispielsweise mit bestimmten Performance-Eigenschaften oder einem neuartigen Algorithmus),
  • die Auswirkungen, die die Story auf andere Stories haben wird, wenn sie verschoben wird (wir wollen nicht bis zur letzten Iteration warten, um zu erfahren, dass es eine dreischichtige Multithread-Anwendung sein muss).
  • Interesse der breiten Masse der Nutzer oder Kunden an der Story,
  • Interesse einer kleinen Zahl von Nutzern oder Kunden der Story,
  • Schlüssigkeit der Story im Verhältnis zu anderen Stories (beispielsweise eine Story zu >>Vergrößern<< hat an sich vielleicht keine hohe Priorität, kann aber als solche behandelt werden, weil sie die Story zu >>Verkleinern<< ergänzt, die eine hohe Priorität hat).
" [S.119, COHN10]


Jetzt fehlt nur noch die Methode, mit der wir die Ordnung schaffen, in die wir die Artefakte bringen wollen. Einige der vielen Priorisierungsmethoden möchte ich im nächsten Post dieser Reihe erläutern und diskutieren. Abschließend kann man folgende Fragen im Kopf behalten:
  • Was ist wert priorisiert zu werden?
  • Wer sollte das tun?
  • In Bezug auf welche Kriterien sollte priorisiert werden?
Die Sache verkompliziert sich, wenn in Bezug auf mehrere Kriterien priorisiert werden muss. Welchen Einfluss hat welches Kriterium? Mit bestimmten Methoden können wir verschiedene Arten von Kriterien wichten. Der Nachteil ist jedoch eine Komplexität, deren Sinn in jedem Fall zu hinterfragen ist. Wie bei allen Dingen darf man eine Methode nicht sklavisch befolgen. Es ist immer wichtig das Ziel und den Sinn zu erkennen und die beste Methode sinnvoll anzuwenden.

  • [COHN10] Mike Cohn: "User Stories", 1. Auflage, mitp, Heidelberg, 2010
  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen