HEC Blog: Technik & Methoden
Verfasst von Christian Seedig am 10. April 2018

Um das Verständ­nis agiler Vorge­hens­wei­sen zu fördern hat es sich als sinn­voll heraus­ge­stellt, Agili­tät mit ihren abstrak­ten Metho­den durch klei­nere Spiele erleb­bar zu machen. Aus diesem Grunde haben wir in der letz­ten Woche bei einem unse­rer Kunden mit Katzen gewor­fen.

Bevor die Tier­schüt­zer unter uns nun Schnap­pat­mung bekom­men, möchte ich beto­nen, dass wir natür­lich keine echten Tiere gewor­fen haben sondern ledig­lich die Heraus­for­de­rung einer solchen Aktion gedank­lich aufbe­rei­tet haben.

Warum dieses Spiel?

Konkret geht es bei dem Spiel „Thro­wing a Cat“ darum, obwohl die Anfor­de­run­gen noch nicht ausrei­chend detail­liert sind, zu einer Schät­zung des damit verbun­de­nen Aufwan­des zu kommen. Eben so, wie es in jedem erdenk­li­chen Soft­wa­re­ent­wick­lungs-Projekt zu Beginn der Fall ist. Bekannt­lich wird in agilen Projek­ten bewusst auf eine zeit- und kosten­in­ten­sive Analy­se­phase verzich­tet, da die mglw. erst spät im Projekt umsetz­ba­ren detail­liert ausge­ar­bei­te­ten Anfor­de­run­gen sich bis dahin noch mehr­mals ändern können.

Wir vermei­den ganz agil jede Kraft­ver­schwen­dung, und nähern uns dem Thema Komple­xi­tät prag­ma­tisch und unter Berück­sich­ti­gung einer beste­hen­den Fehler­to­le­ranz – und lernen mit dieser Unge­nau­ig­keit umzu­ge­hen. Wie die Erfah­rung zeigt werden einige Anfor­de­run­gen aufgrund eines nicht eintre­ten­den Risi­kos zu hoch geschätzt wobei andere deut­lich mehr Aufwand erzeu­gen werden. Diese Effekte rela­ti­vie­ren sich in der Regel gegen­sei­tig – man muss nur die Ruhe bewah­ren.

Spielverlauf beim Kunden

Beim dem Spiel „Thro­wing a Cat“ haben die Teil­neh­men­den die Aufgabe, den Aufwand für den Bau einer Maschine zu bewer­ten, die einen bestimm­ten Gegen­stand mindes­tens einen Meter weit werfen soll. Neben der schon beschrie­be­nen Katze ging es konkret auch um den Bau von Wurf­ma­schi­nen für, zum Beispiel, einen Ball, Papier, einen Ballon, ein Flam­berge oder eine Feder. Jede Maschine ist von den Teil­neh­men­den bezüg­lich Ihres Aufwan­des in der Herstel­lung zu kalku­lie­ren. Genauere Details zu den Gegen­stän­den sind vorerst nicht bekannt. Nun ist es zur Bewer­tung sicher­lich nicht uner­heb­lich zu wissen ob es sich um eine leben­dige Katze handelt und welchen Grad an Koope­ra­ti­ons­be­reit­schaft diese mitbringt sich werfen zu lassen. Ebenso muss bei „Papier“ genauer hinter­fragt werden in welcher Form und Menge dieses vorliegt und ob man z.B. diese verän­dern kann, denn ein Blatt Papier zu einem Flie­ger zu falten und zu werfen bedeu­tet weni­ger Aufwand beim Bau der Maschine als eine 1000kg Rolle Papier oder ein DIN A4 Blatt, welches nicht in seiner Form verän­dert werden darf.

Während des Spiels bewer­ten zwei Teams unab­hän­gige Para­me­ter. Ein Team bewer­tet das Gewicht des Gegen­stan­des und ein ande­res den Aufwand diesen Gegen­stand zu werfen. Die einzel­nen Gegen­stände werden dabei in Clus­ter von ähnli­chem Aufwand oder Gewicht einge­teilt. Man verwen­det dabei die ange­passte Fibo­nacci-Folge um die Zuord­nun­gen darzu­stel­len. Diese ist in der agilen Soft­wa­re­ent­wick­lung ein gern genom­me­nes Mittel, da man dabei ledig­lich Verhält­nisse bewer­tet. Zum Beispiel A ist doppelt so groß wie B, oder C ist 10 mal so schwer wie D.

Während der Bildung von Clus­tern finden sehr span­nende und kurz­wei­lige Diskus­sio­nen darüber statt, welche Para­me­ter die Schwie­rig­keit der Aufgabe beein­flus­sen könn­ten. Am Ende kommen beide Teams zusam­men und glei­chen ihre Ergeb­nisse ab. Dabei wird schnell offen­sicht­lich, dass hier keiner­lei Paral­le­len zwischen Gewicht und Aufwand beste­hen. So wirken sich auf den Bau der Maschine z.B. die Unbe­kann­ten bei der Katze deut­lich weni­ger stark aus als beim Papier oder dem Ballon. Gespielt wird in zwei Runden, wobei in der ersten Runde kein Product Owner für weitere Fragen zur Verfü­gung steht. In der zwei­ten Runde kann dieser aller­dings Details zu den Gegen­stän­den preis­ge­ben.

Der Effekt des Spiels

Im Anschluss an das Spiel wurde mit den neu erwor­be­nen Erfah­run­gen ein komplet­tes Entwick­lungs­pro­jekt in nur einer Stunde vom Team disku­tiert und kalku­liert. Aufgrund der vorhe­ri­gen Zuord­nung zu Verhält­nis­sen und der bewuss­ten Inkauf­nahme der Unschärfe müssen weder Risi­ko­zu­schläge noch sons­tige Korrek­tur­fak­to­ren berück­sich­tigt werden. Durch die Ausein­an­der­set­zung des komplet­ten Teams mit allen bisher bekann­ten Anfor­de­run­gen des Projek­tes werden Aufwands­trei­ber und risi­ko­be­haf­tete Anfor­de­run­gen sofort trans­pa­rent. So können sie bereits zu Beginn des Projek­tes zur Bear­bei­tung oder zur genaue­ren Analyse des Risi­kos prio­ri­siert werden. Dadurch lassen sich böse Über­ra­schun­gen während des Projek­tes weit­ge­hend vermei­den.

Sofern die Anfor­de­rung besteht, eine Kalku­la­tion auch in Euro zu erzeu­gen, müssen ledig­lich die Clus­ter mit Euro-Werten bewer­tet werden. Anhand der jeweils zuge­ord­ne­ten Anfor­de­run­gen lässt sich daraus dann das problem­los das erfor­der­li­che Projekt­bud­get für die Umset­zung ablei­ten. Als einzi­ger Zuschlag müsste man noch die Projekt­steue­rung betrach­ten, sämt­li­che ande­ren Zuschläge sind ja bereits enthal­ten.

Weiterführende Links

Agile Bera­tung der HEC

Anfor­de­rungs­ma­na­ge­ment der HEC

Diese und weitere Ideen zu agilen Spie­len