3 Amigo - eine Art der Kommunikation, um ein Qualitätsprodukt zu schaffen

Stellen Sie sich eine Situation vor - der Tester findet einen Fehler und beginnt, ihn mit dem Entwickler zu besprechen - und besteht darauf, dass dies kein Fehler ist, da in der Spezifikation nicht über diese Funktionalität gesprochen wurde. Ist das bekannt?

Oder weil die Anforderungen nicht eindeutig waren und er sie missverstanden hat. Oder umgekehrt, es waren so viele Informationen in ihnen, dass der Fokus verloren ging und einige der Informationen während der Entwicklung aus den Augen verloren wurden.

Und in dieser Situation ist der Entwickler kein Schädling, der absichtlich einen Fehler gemacht hat. In der Praxis wird die Anzahl der Fehler, die Tester finden, auf Null gehen, wenn Sie ihm einfache, verständliche und vor allem kurze Anforderungen stellen.

Sie sind wahrscheinlich auch mit Streitigkeiten zum Thema "Fehler oder Funktion" vertraut. Kunden haben Fehler entdeckt und der Product Owner kommt mit Kommentaren zum Team. Der Tester und der Entwickler verteidigen sich und erklären dies damit, dass in der ursprünglichen Einstellung nicht über die Implementierung dieser Funktion gesprochen wurde. Und solche Momente beginnen dann im Rückstand.

Ich glaube, dass alle derartigen Aufgaben, die nach der Veröffentlichung eingeleitet wurden und das Ergebnis einer schlecht entwickelten Spezifikation sind, ebenfalls Fehler sind. Fehler, die die Qualität Ihres Produkts charakterisieren.

Es stellt sich heraus, dass Geschäftsanalysten bestimmen, welche Funktionen erstellt werden müssen. Entwickler erstellen sie. Tester finden Mängel in der Arbeit beider. So funktioniert der traditionelle Entwicklungsansatz. Aber Sie können diesen drei beibringen, zusammenzuarbeiten, um ihre Arbeit besser und sofort zu erledigen, ohne zusätzliche Änderungen vorzunehmen. Und diese Art der Kommunikation heißt 3 Amigo. Auch als Story Kick Off Huddles oder Triad bezeichnet.

3 Amigo ist ...

3 Amigo ist eine Praxis, die ein universelles Verständnis dafür liefert, was an den Kunden geliefert wird. Es hilft, die Stimme des Teams zu vermitteln, nicht die Verflechtung verstreuter Meinungen.

Diese Kommunikationsmethode innerhalb des Teams hilft:

• vor der Entwicklung eine gemeinsame Einigung über die Erwartungen erzielen
• eine Vereinbarung darüber treffen, wie man sofort das Richtige tut

Es hilft auch zu verstehen:

• Welches Problem lösen wir?
• Was sind die Lösungen
• Was müssen wir tun, damit die Aufgabe fertig ist?

Das Treffen der drei Amigo ist eine Art des gemeinsamen Denkens, die die Lücke beim Verständnis von Geschäftsspezifikationen schließt. Sie hilft bei der Entwicklung cooler User Stories.

Das Ziel ist es, die Arbeit pünktlich zu erledigen, aber gleichzeitig nicht im Voraus zu planen, damit die Details Zeit haben, obsolet zu werden.

Warum 3? Wer bewirbt sich?

Der Name der Praxis beschränkt uns nicht auf drei Kontexte, sondern schafft nur einen minimalen Rahmen. Um sicherzustellen, dass bei der Entwicklung der Anforderungen alle technischen Nuancen, expliziten und impliziten Fälle berücksichtigt wurden, dass die Spezifikation die tatsächlichen Bedürfnisse des Kunden widerspiegelt, sind 3 verschiedene Denkweisen / Kontexte erforderlich: Unternehmen, Entwickler, Tester. Darüber hinaus ist das Treffen nicht nur auf diese Personen beschränkt. Es bezieht alle ein, die an der Umsetzung der Anforderung beteiligt sind. Wenn Ihre Aufgabe beispielsweise nicht nur das Web, sondern auch das Handy umfasst, benötigen Sie zusätzlichen Kontext. Das heißt, die Person, die die Implementierung in der mobilen Anwendung vornimmt. In unseren Teams nehmen meistens 4 Entwickler (1 iOS, 1 Android, 1 Rückseite, 1 Vorderseite), ein Tester und ein Geschäftsanalyst an dem Meeting teil.

Business Analyst oder PO

Ein Unternehmensvertreter weiß (fast immer), was er am Ende erhalten möchte und welchen Wert der Kunde und das Unternehmen davon erhalten. Es ist wichtig, über dieses Team zu sprechen.
Bei der Teilnahme am Amigo 3-Meeting teilt der Business Analyst Informationen mit den Teilnehmern, sodass jeder im Team das gleiche Verständnis und die gleichen Erwartungen an die User Story hat. Außerdem kann nur er den Umfang der Annahmekriterien einschränken, nach denen die Annahme dann erfolgt.

Entwickler

Der Entwickler weiß, wie er die Anforderungen aus dem Geschäft umsetzt, welche Möglichkeiten dies bietet. In der Regel denkt er über die Details nach, die er wissen muss, um mit der Implementierung zu beginnen. Durch das Stellen von Fragen, die auf seiner Erfahrung und seinem Wissen über das System basieren, hilft der Entwickler, verschiedene Nuancen bereits in der Phase der Diskussion der Anforderungen aufzudecken.

Tester

Der Tester hilft, wie andere Teammitglieder, die Anforderungen mit verschiedenen Testfällen zu bereichern. Aufgrund seiner Erfahrung bezweifelt er immer häufiger Aussagen des Teams. Daher ist es besser, Extremfälle, implizite Szenarien zu finden und sich zu fragen, was schief gehen könnte, worauf zu achten ist.

Wann wird die Praxis angewendet?

Ich habe selten einen Entwicklungsprozess gesehen, in dem Anforderungen explizit dargestellt wurden. In den meisten Fällen wurden die Anforderungen bereits in der Entwicklungs- oder Testphase untersucht, und erst dann wurden einige Inkonsistenzen festgestellt.

Eine nicht getestete Spezifikation hat wahrscheinlich mehrdeutige, widersprüchliche, unvollständige, doppelte und manchmal sogar veraltete Anforderungen. Dies liegt daran, dass jeder versteht, was er auf seine eigene Weise gelesen und gehört hat. Daher ergeben sich Unterschiede in der Interpretation.

Wenn die Dokumentation umfangreich und detailliert ist, kann das Lesen länger dauern als der Test- oder Entwicklungsprozess.

In unserem Geschäftsbereich haben wir uns entschlossen, diese Praxis anzuwenden, als die Aufgaben beim Testen zu verweilen begannen. Wir haben 3 Hauptprobleme identifiziert:

1. In der Testphase gab es aufgrund der Klärung der Anforderungen viele Rückgaben. Dies waren konkrete Pausen beim Testen und Entwickeln, als ein Geschäftsanalyst festlegte, wie es funktionieren sollte.
2. Das Testen der Aufgabe wurde aufgrund einer zu detaillierten Spezifikation verzögert. Fälle waren häufig, in denen der Tester 3-6 Stunden damit verbringen konnte, nur die Anforderungen zu studieren und Testfälle zu entwickeln, und der Test selbst etwa 30 Minuten dauerte. Und der ungeheuerlichste Fall war der Fall, als der Test nach 2 Wochen des Studiums der Spezifikation begonnen wurde, es war so kompliziert und detailliert.
3. Das häufigste Problem war, dass es beim Abnahmetest viele Fehler gab. Diese Fehler, die hätten vermieden werden können, wenn sie vor der Entwicklung bedacht worden wären.

Es stellt sich also heraus, dass es trotz agiler Entwicklung noch eine Phase der Arbeit mit der technischen Spezifikation gibt. Und wenn Sie einige Fälle nicht berücksichtigt haben, weil der Kunde nichts darüber gesagt hat oder Sie nicht das getan haben, was er wirklich meinte, werden nach dem Besuch des Produkts eine Reihe von Aufgaben zur Überarbeitung oder sogar Änderung in den Rückstand aufgenommen.

Und schließlich lohnt es sich, das Problem mit der Bewertung zu äußern.
Es ist schwierig, eine Aufgabe zu bewerten, wenn Sie wirklich nicht verstehen, wie viel Arbeit noch daran zu erledigen ist. Wie viele Tests müssen geschrieben werden, wie viele Rückgaben sind auf Fehler oder Änderungen aufgrund von Ungenauigkeiten in der Spezifikation zurückzuführen? Selbst wenn der Entwickler die Entwicklungszeit selbst genau einschätzt, werden Sie fast nie erraten, wie viel Zeit die unvorhersehbare Testphase in Anspruch nehmen wird.

Schritte zum Üben von AC

1. Wir formulieren Anforderungen als User Story

Ich empfehle, mich zu bewerben, um Anforderungen basierend auf User Stories zu entwickeln. Und als Grundlage, um eine Geschichte zu nehmen und bei einem Treffen von 3 Amigo nur sie zu studieren.

Ein sehr wichtiger Punkt hierbei ist, dass die Anforderung des Unternehmens wirklich als User Story formuliert ist. Das heißt, es enthielt in sich 3 Teile, nämlich:

Ich als <Rolle>, ich möchte <Aktion>, damit <Motivation>

Dies ist tatsächlich die beliebteste benutzerdefinierte Storytelling-Vorlage namens Connextra. Es gibt auch andere Vorlagen, aber ich empfehle diese zu verwenden. Und warum, jetzt werde ich erklären.

Traditionell gibt es zwei Probleme beim Erstellen einer User Story:

• Geben Sie bei der Aufnahme entweder nicht die Rolle an und lassen Sie Aktion und Motivation
• Oder sie zeigen die Rolle und Handlung an und werfen Motivation aus.

Dies verursacht tatsächlich Probleme, und ich werde versuchen, anhand einfacher Beispiele zu erklären, welche Beispiele verwendet werden.

1. Wenn Sie die "Rolle" kennen, werden Sie als Teammitglieder die Grenzen der Akzeptanzkriterien, die Sie formulieren müssen, besser verstehen. Wenn Sie sich der Person, die an dieser User Story beteiligt ist, nicht vollständig bewusst sind, können Sie dies entweder über das hinaus tun, was Sie benötigen, oder umgekehrt eine Art von Funktionalität ausführen.
   
   • Beispiel : Das Team hat die Rolle in der User Story nicht verstanden und bei der Arbeit an dem Problem beschlossen, drei Methoden für die API auszuführen: Hinzufügen, Bearbeiten und Löschen. Und vorne werden Schaltflächen hinzugefügt, die diese Methoden aufrufen. Als sie dem Unternehmen ihre Entscheidung vorstellten, erhielten sie eine Rückmeldung, dass ihr Kunde tatsächlich ein bestimmter Geschäftsanalyst ist, der eine Methode zum Hinzufügen benötigt. Und er wird nicht löschen und bearbeiten. Ja, und er kann diese Methode über den Postboten aufrufen.
2. Das Team versteht die Motivation der "Rolle", für die sie eine User Story erstellen, nicht. Aufgrund von Missverständnissen sind die Grenzen der User Story selbst schlecht umrissen. Außerdem lösen Akzeptanzkriterien am Ende möglicherweise nicht das endgültige Kundenproblem, obwohl sie der Aktion entsprechen, die in der User Story geäußert wurde.
   
   • Beispiel : Ein Team stellte eine User Story ein, in der ein Business Analyst die Motivation nicht klar artikulieren konnte. Einerseits sollte sie den Kunden loyal lassen und eine Verbesserung für ihn vornehmen. Zum anderen Kostensenkung für die Bank. In diesem Fall waren die Implementierungsmethoden und Akzeptanzkriterien radikal unterschiedlich. Denn im ersten Fall konzentrierte sich das Team auf Benutzerakzeptanzkriterien. Im zweiten Fall achtete das Team darauf, wie die einfachste und schnellste Implementierung möglich wird.

Die Formulierung im obigen Format ist jedoch keine Voraussetzung. Ich kenne Teams, die Meetings im Amigo 3-Format und ohne User Story abhalten. Und als Basis verwenden Sie TK. In diesem Fall gibt es Fallstricke, aber es war eine bewusste Entscheidung des Teams.

Treffen 3 Amigo beginnt mit der Vorbereitung. Zur Vorbereitung werden Anforderungen so formuliert, dass sie für das gesamte Team verständlich sind. Diese Anforderungen werden für die Arbeitsbereitschaft validiert.

Die Validierung umfasst die Bewertung des Verlaufs anhand von INVEST-Kriterien. Sowie die Qualität des Wortlauts der Geschichte selbst. Hier ist jede Mehrdeutigkeit und Ausführlichkeit ausgeschlossen, und bei der Bewertung durch INVEST wird besonderes Augenmerk auf die Größe der Geschichte gelegt. Wenn das Team versteht, dass die Anforderung episch ist, erfolgt eine Zersetzung.

Nachdem die Anforderung die Phase der Umwandlung in eine User Story und der Validierung durch das Team (3 Amigo) durchlaufen hat, können wir mit der Ausarbeitung der Akzeptanzkriterien fortfahren.

2. Wir ergänzen die Akzeptanzkriterien zur User Story beim Treffen von 3 Amigo

Zuerst müssen Sie entscheiden, welche Akzeptanzkriterien alle gleich sind.

Akzeptanzkriterien sind also Anforderungen des Kunden; Spezifikation, anhand derer das / user story System überprüft werden kann.

Sie haben einen alternativen Namen, Bedingungen der Zufriedenheit - Bedingungen für die Erfüllung der Erwartungen (Autor Mike Cohn).

Bei einem Treffen von 3 Amigo-Teams sind bereits vorbereitet. Sie haben bereits eine validierte User Story, die möglicherweise bereits einige Akzeptanzkriterien enthält, die der Unternehmensvertreter unabhängig formuliert hat.

Während des Meetings besteht die Aufgabe der Teilnehmer darin, die Historie mit einer ausreichenden Anzahl von Akzeptanzkriterien für die spätere Implementierung zu ergänzen / zu bereichern.

Die Akzeptanzkriterien sollten keine Implementierungsdetails enthalten. Tatsächlich sind Akzeptanzkriterien Geschäftsregeln, die eine in der Entwicklung befindliche User Story regeln. Implementierungsdetails werden in Abnahmetests aufgezeichnet, jedoch nachdem alle Abnahmekriterien formuliert wurden.

Es lohnt sich nicht, Implementierungsdetails mit Akzeptanzkriterien zu verwechseln, schon allein deshalb, weil Sie als Team mit begrenzten Zeitplänen immer einen Kriterienbereich „rauswerfen“ können, der für das Geschäft in naher Zukunft nicht so wichtig ist. Wenn die Kriterien Details zur technischen Implementierung enthalten, besteht die Gefahr, dass wichtige Informationen und Zeit verloren gehen, die bereits für die Erörterung der Implementierungsdetails aufgewendet wurden. Ihre Implementierungsdetails hängen direkt vom Umfang der Kriterien ab, die Sie ausführen müssen.

Vermeiden Sie außerdem eine sequentielle Beschreibung des Szenarios mit einer Reihe von Schritten (klassisches Testfallverwaltungssystem). Jede Ihrer Aussagen sollte atomar sein. Es ist besser, einen beschreibenden Stil des erwarteten Verhaltens der erstellten Funktion zu verwenden.

Zum Beispiel:

*     ,     .*> 

3. Wir halten das Timing ein

Eine gut zerlegte US enthält normalerweise nicht mehr als 10 Akzeptanzkriterien. Wenn im Diskussionsprozess eine große Anzahl von Akzeptanzkriterien gefunden wird und alle implementiert werden müssen, muss diese Geschichte in mehrere Geschichten mit einem anderen Pool von Akzeptanzkriterien zerlegt werden.

Wenn dies nicht getan wird, wird sich das Treffen von 3 Amigo stark verzögern.

Die optimale Zeit für ein Meeting mit 3 Amigo liegt zwischen 30 Minuten und 1 Stunde.

Akzeptable Steigerung ganz am Anfang des Weges - wenn das Team gerade lernt, diese Praxis zu kommunizieren und anzuwenden.

Wenn ein Team eine große Geschichte zur Arbeit bringt, ist es unwahrscheinlich, dass es in einer Sitzung alle Kriterien und Abnahmetests erarbeiten kann. Weil Fokus und Aufmerksamkeit verloren gehen. In diesem Fall müssen Sie die Sitzung in mehrere Besprechungen aufteilen. In diesem Fall besteht jedoch die Gefahr, dass der Kontext verloren geht, und bei einem zweiten Treffen kann ein zusätzliches Eintauchen erforderlich sein.

4. Um die Untersuchung der Kriterien abzuschließen, verwenden wir die USR-Heuristik

Wenn ich Teams diese Übung beibringe, empfehle ich, zu Beginn ihres Weges Heuristiken zu verwenden, um den Mangel an Erfahrung auszugleichen. Mit der Erfahrung verfügt das Team über eigene Heuristiken und Checklisten, nach denen bei der Entwicklung von Kriterien gesucht werden muss.

Mit der USR-Heuristik können Sie die Kriterien auf allen Ebenen berücksichtigen, die erforderlich sind, um die besten Informationen über die Wünsche des Kunden zu erhalten.

Also

1. USER - Was möchte der Benutzer mit dem System tun?
2. SYSTEM - Was soll das System tun?
3. RISIKEN - Welche Probleme können auftreten?

Es ist wichtig, zuerst alle Kriterien der USER-Gruppe zu erarbeiten und dann nur auf Systemebene zu gehen. Hier werden Front- und Backend-Entwickler einbezogen, und auf der Ebene ihrer Systeme können sie Akzeptanzkriterien für das formulieren, was geschehen soll, um die Kriterien der USER-Gruppe zu implementieren.

Und schließlich die RISIKO-Band. Meistens wird die Ausarbeitung von Anforderungen vergessen, obwohl dies nicht weniger wichtig ist. Es werden verschiedene komplexe Fälle behandelt, die Sie möglicherweise nicht implementieren können. Aber um als Team die Risiken auszusprechen und zu akzeptieren, ist es erforderlich.

Möglichkeiten, die Praxis anzuwenden, um Testfälle vor der Entwicklung zu entwickeln

Die empfohlene Methode zur Formalisierung von Anforderungen sind Anwendungsfälle. In der russischen IT werden diese Testfälle genannt.
Es gibt ein praktisches Tool zum Ausarbeiten von Testfällen bei einem Treffen von 3 Amigo, das als Beispiel-Mapping bezeichnet wird. In diesem Artikel habe ich kurz darauf eingegangen. Im nächsten Artikel werden wir detaillierte Informationen zu diesem Tool und seiner Verwendung im Rahmen des Triaden-Meetings veröffentlichen.

Testfälle können als automatisierte Abnahmetests für die Historie implementiert werden. Wenn Sie an Testfällen arbeiten, müssen Sie diese auch gruppieren. Das Aufteilen von Testfällen in Gruppen ist eine Möglichkeit, die Geschichte in mehrere kleinere zu unterteilen.
In Testfällen erfolgt die Zerlegung einer Geschäftsregel genau auf der Systemebene, auf der sie implementiert wird, und nicht vom Benutzer.
Alle Implementierungsdetails müssen sich in Ihren Testfällen befinden, damit sie sich auf Entwickler im Implementierungsprozess konzentrieren.

Wie es im allgemeinen Prozess aussehen kann (wenn Sie dieses Meeting abhalten müssen)

Es wird empfohlen, dass Sie in einer einzigen Besprechung Anforderungen für nur eine User Story erarbeiten. Mehr ist erlaubt, vorausgesetzt, es handelt sich um sehr kleine Geschichten oder sie sind in ihrer Bedeutung miteinander verbunden.

Da Sie im Sprint arbeitsbereite Geschichten aufnehmen, sollte vor der Planung ein Treffen mit 3 Amigo-Geschichten stattfinden. Andernfalls besteht die Gefahr, dass Sie mit der vorläufigen Schätzung einen großen Fehler machen. In der Praxis unterscheidet sich die Bewertung der Geschichte nach dem Treffen von 3 Amigo stark vom Original.

Es ist auch sinnvoll, dem DOD ein neues Element hinzuzufügen, um die Bereitschaft zu überprüfen, dass die Story bereit ist, im Sprint daran zu arbeiten.

Zum Beispiel haben einige Teams, die begonnen haben, diese Praxis anzuwenden, vereinbart, dass sie den Sprint während der Planung nicht absolvieren, wenn es keine Akzeptanzkriterien und Abnahmetests für die Aufgabe gibt.

Und im Sprint-Review wird die Akzeptanz der Geschichte anhand der Akzeptanzkriterien dargestellt.
Gleichzeitig passt das Treffen mit 3 Amigo auch in den Prozess, wenn das Team arbeitet und nicht scrum, sondern zum Beispiel Kanban verwendet. In diesem Fall wird die Aufgabe erst entwickelt, nachdem sie ein Meeting von 3 Amigo durchlaufen hat.

Was ist das Ergebnis des Treffens 3 Amigo?

• Skripte / Beispiele (offensichtliche Antworten)
• festgelegte Regeln / Akzeptanzkriterien
• neue / zerlegte Geschichten
• gemeinsames Verständnis des Problembereichs
• Empathie (Empathie, Partizipation)

Das Hauptergebnis der drei Amigo sind Abnahmetests, die im Format „ Gegeben / Wann / Dann“ geschrieben wurden . Tatsächlich kann das Schreiben länger dauern, als wir möchten. Daher wird nicht empfohlen, alle Anforderungen bei einem Meeting zu formalisieren, wenn alle zusammen sind. In der Regel wird ein Entwickler oder Tester sofort daran arbeiten. Und sobald alle Kriterien und Testfälle aufgezeichnet wurden, schauen sich 3 Amigos kurz an, was passiert ist, um sicherzustellen, dass alle mit den aufgezeichneten übereinstimmen.

Profit aus der Praxis von 3 Amigo

Die Amigos 3-Strategie kann einen großen Einfluss auf die Effektivität des gesamten Teams sowie auf die Qualität und Nachhaltigkeit Ihrer Projekte haben und die Manövrierfähigkeit und Flexibilität bei Änderungen erhöhen.

Hier sind einige weitere Boni:

• Bei der Planung verbringen wir nicht viel Zeit damit, uns in die Bedeutung der Geschichte zu vertiefen.
• Erkennt frühzeitig Verwirrung und Missverständnisse, was eine schnellere Lieferung ermöglicht
• Stellt sicher, dass das Team den erforderlichen Arbeitsaufwand bespricht
• Hilft bei der Suche nach allen Akzeptanzkriterien und anderen Qualitätsmerkmalen.
• Die Entwicklung von Testfällen ist viel einfacher.
• Wir provozieren Entwickler, den Code mit Tests abzudecken
• Wir kommen schnell zu dem Schluss, dass diese Funktion nicht benötigt wird

Unsere Teams konnten mithilfe von Übung die Aufgabenrendite aufgrund ungenauer Spezifikationen reduzieren. Die Backend-Aufgaben, die die Jungs gelernt haben, "beim ersten Mal" zu entwickeln. Das heißt, ohne Bugs und sofort auf dem Prod.

Fallstricke

• Beschränken Sie sich nicht auf nur drei Personen. Wenn Sie mehr brauchen - rufen Sie an.
• Treffen Sie nicht das ganze Team. In dieser Besprechung muss eine Mindestanzahl von Personen vorhanden sein, um die Funktion zu implementieren.
• Betrachten Sie es nicht als ein regelmäßiges Treffen - ein Ritual. Andernfalls hat das Team einen negativen Einfluss auf die Erhöhung der Anzahl der Besprechungen.

Meisterkurs auf der QualityConf- Konferenz

Vom 27. bis 28. Mai werde ich im Rahmen des RIT ++ - Festivals auf der QualityConf-Konferenz eine Meisterklasse über die Entwicklung von Anforderungen unter Verwendung der Praxis von 3 Amigo durchführen.
Wenn Sie an dem Ansatz interessiert sind und Fragen haben, können Sie mich auch unter dem Telegramm @Travieso_nastya kontaktieren.

Annäherungsgeschichte

Der Autor des Ansatzes: George Dinwiddy, 2009.

Er beschrieb diesen Ansatz in seinem Interview und erwähnte in einer Reihe von Artikeln die Links, an die ich angehängt habe. Als zusätzliches Material habe ich alle Verweise auf englischsprachige Ressourcen angehängt, nach denen ich diese Praxis studiert und gelernt habe.

https://www.agilealliance.org/glossary/three-amigos/

https://www.infoq.com/interviews/george-dinwiddie-three-amigos

https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories

https://www.stickyminds.com/better-software-magazine/three-amigos