Synchronisieren Sie das Team

Wie können Sie als Scrum Master die Chancen verbessern, dass das Scrum-Team von Anfang bis Ende des Sprints eine gemeinsame Vision und ein gemeinsames Verständnis sowohl der User Story als auch der Lösung hat? Das Problem In der Planungssitzung sollte sich das Team über das Verständnis der Benutzergeschichte abstimmen und sich darauf einigen, wie die Lösung erstellt werden soll. Aber es gibt keine wirkliche Bestätigung dafür, dass alle Teammitglieder auf derselben Seite stehen. Das Team neigt dazu, sich recht schnell in die technischen Details zu vertiefen, um die Aufgaben zu identifizieren und zu dimensionieren. Die technischen Details werden oft nur von einigen wenigen Teammitgliedern und mit wenig oder gar keinem funktionalen oder geschäftlichen Kontext besprochen. Sobald das Team die Sitzung verlässt, gibt es keine Garantie dafür, dass es im weiteren Verlauf des Sprints synchronisiert bleibt. Das einzige andere Ritual zur Synchronisierung des Teams, das der Scrum-Prozess vorschreibt, ist das tägliche Scrum oder Stand-up. In den meisten Teams ist das tägliche Scrum so kurz wie möglich und vermeidet semantische Diskussionen. Auch ich ziehe es vor, dass die Stand-ups kurz und bündig sind. Wie können Sie oder das Team also feststellen, dass das Team (noch) synchronisiert ist? Spezifizieren Sie die Story In der Planungssitzung, nachdem eine Story als reif genug angesehen wird, um in den Sprint aufgenommen zu werden, beginnen wir mit der Analyse der Story. Dies ist der Teil der Spezifikation, bei dem eine Technik namens 'Specification by Example' zum Einsatz kommt. Die Idee ist, testbare funktionale Spezifikationen mit konkreten Beispielen zu schreiben. Wir zerlegen die Story in Spezifikationen und definieren die Bedingungen für Erfolg und Misserfolg anhand von Beispielen, damit sie getestet werden können. Wenn Sie an Beispiele denken, wird die Spezifikation konkreter und die Interpretation der Anforderungen spezifischer. Wenn das gesamte Team die Spezifikationen und Beispiele ausarbeitet, kann sich das Team länger und detaillierter auf den funktionalen Teil der Geschichte konzentrieren, bevor es sich den Entwicklungsaufgaben zuwendet. Das Verfassen der Spezifikationen hilft auch dabei, festzustellen, ob eine Story bereit genug ist. Während der Sprint voranschreitet und alle Tests grün sind, sollte die Story für den Teil der Funktionserstellung fertig sein. Sie können ein Tool wie Fitnesse oder Cucumber verwenden, um testbare Spezifikationen zu schreiben. Die Tests werden gegen den tatsächlichen Code ausgeführt, so dass sie einen genauen Überblick über den Fortschritt geben. Wenn alle Tests bestanden sind, hat das Team die Funktionalität erfolgreich erstellt. Zusätzlich zum Scrum Board und den Burn Down Charts bieten die funktionalen Tests einen guten und genauen Überblick über den Fortschritt des Sprints. Entwerfen Sie die Lösung Sobald die Geschichte in klare und testbare Spezifikationen zerlegt wurde, beginnen wir mit der Erstellung eines Entwurfs auf einem Whiteboard. Das Hauptziel ist es, ein gemeinsames, sichtbares Verständnis der Lösung zu schaffen. Vermeiden Sie daher (technische) Details, um zu verhindern, dass große Entwürfe im Voraus erstellt werden und die weniger technischen Teammitglieder nicht eingebunden werden. Sie können das Format verwenden, das für Ihr Team am besten geeignet ist (z.B. UML), aber stellen Sie sicher, dass es für alle Teammitglieder verständlich ist. Die Erstellung des Entwurfs, die eine Anstrengung des gesamten Teams ist, regt die Diskussion eher an. Anstatt sich auf die Konsistenz der nicht sichtbaren mentalen Bilder in den Köpfen der Teammitglieder zu verlassen, gibt es ein greifbares Bild, das von allen geteilt wird. Das Whiteboard-Design ist ein guter Ausgangspunkt für die Verfeinerung, wenn das Team während des Sprints Erkenntnisse gewinnt. Das Whiteboard sollte während des Sprints immer sichtbar und in Reichweite des Teams sein. Die Verwendung eines Whiteboards macht es einfach, das Design anzupassen oder zu ergänzen. Sie werden feststellen, dass das Team oft um das Whiteboard herumsteht oder in Diskussionen darauf zeigt. Das Design kann leicht in ein digitales Artefakt umgewandelt werden, indem Sie eine Fotokopie davon erstellen. Eine digitale Kopie kann für jeden wertvoll sein, der das System in Zukunft erlernen möchte. Der Entwurf könnte auch in der Sprint-Demo verwendet werden, falls die Zuhörer an einem technischen Überblick interessiert sind. Fazit Das Team verlässt die Sprintplanung nun mit einer Reihe von Funktionstests und einem Whiteboard-Entwurf. Die Tests sind nützlich, um die funktionalen Ziele zu validieren und zu synchronisieren. Die Whiteboard-Entwürfe sind nützlich, um die technischen Ziele zu validieren und zu synchronisieren. Das gemeinsame Verständnis des Teams ist besser sichtbar und kann während des gesamten Sprints validiert werden. Das Team ist transparenter geworden.Es könnte eine gute Praxis sein, die Entwickler die Spezifikationen schreiben zu lassen und die Tester oder Analysten die Entwürfe an die Tafel zu zeichnen. Dadurch wird die Kommunikation gefördert, indem die Mitarbeiter aus ihrer Komfortzone herausgeholt und gezwungen werden, mehr Fragen zu stellen. Es gibt zwingendere Gründe, so etwas wie Spezifikation nach Entwurf einzuführen (oder nicht) oder das Team Designübersichten erstellen zu lassen. Aber es hilft dem Team auch, auf derselben Seite zu bleiben, wenn es sichtbare und testbare Artefakte gibt, auf die man sich während des Sprints verlassen kann.