Um gleich ein Missverständnis aus dem Weg zu räumen: Nein, es geht heute nicht darum, wie Sie mit drei spanischen Freunden ein agiles Projekt durchführen. Obwohl dieser spezielle Fall natürlich auch eintreten mag. Vielmehr handelt es sich bei den 3 Amigos um ein Konzept, das in der agilen Entwicklung Anwendung findet.
Es wird z.B. auch in der Agile Extension to the BABOK Guide v2 angesprochen. Dieses Dokument behandelt die Business Analyse aus agiler Sicht – Rainer Wendt hat hier vor Kurzem darüber geschrieben. Da das Konzept also recht populär ist, klären wir heute die Frage: Worum geht es bei den 3 Amigos?
Die Problemstellung: Unklarheiten, Verwirrung, Fragen
Die Erfindung des Konzepts beruht auf folgende Problemstellung (vielleicht kennen Sie diese aus persönlichen Erfahrungen):
Der Sprint ist gestartet und die Entwickler sind fleißig an der Arbeit. Doch dann stutzen sie: Wie ist die Anforderung genau gemeint? Was soll in speziellen Fällen passieren, die sie nicht anspricht? Manchmal finden sie kaum verständliche Spezifikationen, weil sie einem wirren Copy-Paste-Zusammengeschreibsel alter oder ähnlicher Anforderungen begegnen. Sie müssen nachfragen oder setzen die Anforderung nach eigenem Ermessen um. Dann meldet sich später der Tester mit den Worten: „Soll das wirklich so sein?“ Verwirrung bricht aus, das Projekt gerät ins Stocken. Schlimmer: Ergebnisse, die nicht erwünscht waren, werden geliefert. Und alle wundern sich: Hätten wir diese Fragen nicht vor der Umsetzung klären können?
Hätte man die Fragen nicht vorher fragen können?
Genau solche Fragen sollen die Three Amigos klären. Das Konzept hat George Dinwiddie ca. 2009 in einem Beitrag erstmals angesprochen [1].
Die Lösung: 3 Amigos, 3 Perspektiven
Was sind nun die 3 Amigos? Stellen Sie sich drei Perspektiven auf das Projekt vor, die alle unterschiedliche, aber notwendige Informationen zu einer Anforderung liefern. Diese drei Perspektiven oder auch Rollen sind:
- Business Analyst (als Vertreter des Product Owner bzw. der Stakeholder),
- Entwickler,
- Tester bzw. QA-Verantwortliche.
Bevor die Entwicklung beginnt, besprechen diese Rollen die bisher spezifizierten Anforderungen und lassen Ihre Perspektiven aus dem jeweiligen Fachbereich einfließen:
Der Business Analyst ist daran interessiert, die Ziele der Organisation zu erfüllen und in den Anforderungen wiederzufinden. Die Entwickler wissen, wie sie diese Ziele technisch umsetzen können und u.a. welche Informationen sie dafür brauchen; und die Tester haben ein Gespür dafür, was schiefgehen könnte und wie getestet werden muss.
Ziel der 3 Amigos ist es immer, ein gemeinsames Verständnis für eine Anforderung bzw. User Story zu erhalten, ihre Qualität sicherzustellen, sodass sie umsetzbar sind, und einig darüber zu werden, welche Tests notwendig sind.
Aber Achtung!
Three Amigos bedeutet nicht, dass es auch genau drei Leute sein müssen. Die Amigos lassen sich von mehreren Projektbeteiligten repräsentierten. Außerdem können Sie weitere Amigos hinzuziehen, z.B. UX-Verantwortliche. So lässt sich auch die Anwendersicht auf die Anforderungen einbeziehen. Trotzdem sollte die Gruppe nicht zu groß werden und nur diejenigen einschließen, die tatsächlich an der Entwicklung und dem Test einer Anforderung beteiligt sind.
Die 3 Amigos-Session: So geht‘s
Um zu diskutieren, treffen sich die Freunde in einer 3 Amigos-Session (auch als Spezifikationsworkshop bezeichnet). Dieses Treffen findet nicht in regelmäßigen Abständen statt wie z.B. das Sprint Planning-Meeting in Scrum-Projekten. Stattdessen setzten Sie es dann an, wenn es nötig ist – üblicherweise vor der Umsetzung der Anforderungen. Sie können das Konzept also als Technik für Ihr Backlog Grooming nutzen. Da die Interessen der einzelnen Rollen kontinuierlich während des Projekts gewahrt werden müssen, können Sie sich auch während und nach der Implementierung treffen. So ziehen Sie den größten Nutzen aus dem Workshop. Für das Meeting können Sie eine Timebox von 30 Minuten bis eine Stunde ansetzen.
Findet die 3 Amigos-Session vor der Entwicklung statt, stellt als erstes der Business Analyst das gewünschte Feature und die Anforderungen, sie sich daraus ergeben, vor. Business Analyst, Entwickler und Tester detaillieren die Spezifikationen so lang, bis die Qualität der Anforderungen stimmt. Dann diskutieren sie die Test-Szenarios und treffen Vorbereitungen für die Umsetzung und das Testen. Diese Arbeitsschritte setzen natürlich voraus, dass sich jeder Amigo auf das Treffen vorbereitet und seinen Teil der Arbeit entsprechend liefert, also z.B. Test-Szenarios bereits geschrieben hat.
Während der Implementierung sorgen die Amigos dafür, dass die Umsetzung der Anforderung auch so wie erwünscht stattfindet. Wenn das Meeting nach der Implementierung stattfindet, prüfen die Freunde u.a., ob die Akzeptanzkriterien erfüllt sind, damit der Product Owner sein OK geben kann.
Fazit
Mit einer 3 Amigos-Session schaffen Sie also ein gemeinsames Verständnis für die Arbeit, die Sie erledigen müssen. Verwirrung oder Missverständnisse lassen sich vermeiden, sodass die Entwicklung reibungslos stattfinden, weniger Bugs bei Tests gefunden und ein Ergebnis geliefert werden kann, das alle Beteiligten zufriedenstellt. Dafür unterziehen die Amigos die Anforderungen kontinuierlich einer Qualitätskontrolle – immer in einem Gespräch von Angesicht zu Angesicht. Aber was ist, wenn ein Amigo doch einmal nach Spanien reist und nicht am Workshop teilnehmen kann?
Die 3 Amigos mit Tool unterstützen
Mit objectiF RPM können Sie einen integrierten Review-Workflow nutzen, um die Amigos trotzdem zusammenzubringen. Die Anforderung ist noch zu unpräzise? Dann hinterlassen Sie einen Kommentar. Wenn Sie den aktuellen Stand ablehnen, können Sie den entsprechenden Zustand setzen. Genauso sieht es andersherum aus: Entspricht die Anforderung Ihren Qualitätsansprüchen, lässt sich der Spezifikation zustimmen und sie ist bereit zur Umsetzung.
Übrigens: Ändert sich ein Status, können Sie automatisch eine E-Mail-Benachrichtigung an die Reviewer verschicken lassen. So schaffen Sie für alle Beteiligten Transparenz und Nachvollziehbarkeit.
Neugierig geworden? Welche Features objectiF RPM für die Qualitätssicherung außerdem bietet, können Sie hier nachlesen.
Hinweise:
[1]: Dinwiddie, G. (2009). If you don’t automate acceptance tests? Von George Dinwiddie’s blog: Effective software development http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests/ abgerufen.