Wie kann ich Qualitätsmerkmale auf dem Kanban meines Teams verfolgen?

Mein Team verwendet ein Kanban-System zur Verfolgung des täglichen Fortschritts und es ist sehr gut ausgearbeitet, um den Fortschritt der Funktionen zu verstehen (als User Storys erfasst). Wir haben unser Systemdesign weitgehend zugelassen, da wir Funktionen entwickelt haben, die bis vor kurzem gut funktioniert haben. In den letzten zwei Wochen haben wir mehrere Diskussionen über architektonische Kompromisse geführt, die sich speziell auf die Eigenschaften von Leistung und Modifizierbarkeit beziehen.

Ich denke, wir treffen implizit Entscheidungen über die Architektur, während wir Features implementieren und das System entwerfen, ohne diese Entscheidungen im Hinblick auf unsere bekannten Qualitätsattributanforderungen zu berücksichtigen. Es wäre wirklich großartig, wenn ich verfolgen, erfassen und visuell darstellen könnte, wie diese wichtigen Entwurfsentscheidungen getroffen werden, damit die Teammitglieder eine bessere Chance haben, keine zusätzliche Spannung in der Architektur des Systems zu erzeugen, während es implementiert wird. Und um die Sache noch komplizierter zu machen, sind die Funktionen auf unserer Platine nicht ausschließlich funktionsfähig und verbergen manchmal die Komplexität der Architektur!

Wie kann ich den Fortschritt in Bezug auf Qualitätsattribute (oder andere architektonisch relevante Entscheidungen) visuell auf dem Kanban meines Teams verfolgen?

Wir treffen implizit Entscheidungen über die Architektur, berücksichtigen diese Entscheidungen jedoch nicht im Hinblick auf unsere bekannten Qualitätsattributanforderungen.

Ich denke, Sie können dies visualisieren, indem Sie einen Schritt zur Überprüfung der Architektur in Ihrem Workflow erstellen. Der Schritt würde durch eine Kanbad-Board-Spalte mit einem eigenen WIP-Limit dargestellt. Das WIP-Limit hängt davon ab, wie viele Architekten / Designer an diesen Überprüfungen teilnehmen müssen.

Das Entwicklungsteam ist für den horizontalen Fluss von User Stories von links nach rechts verantwortlich. In den meisten Fällen berühren die Architekten die Geschichten nur, wenn sie sich in der Spalte für architektonische / technische Überprüfungen befinden. Der Schnittpunkt der Säule mit einer horizontalen Schwimmbahn visualisiert das Zusammentreffen von Entwickler (n) und Architekt (n).

Eines der Teams, in dem ich arbeite, führt in einem ähnlichen Schritt eine Datenbankschemaüberprüfung mit dem Chefdatenarchitekten durch. Sie verwenden kein Kanban, aber wenn doch, würden sie diese Spalte sehr wahrscheinlich auf ihrem Brett haben.

Die bekannten Qualitätsattribute könnten dann dargestellt werden als:

• die Definition von erledigt für den architektonischen Überprüfungsschritt.
• Akzeptanztests rund um die bereits durchgeführten User Stories, die nichtfunktionale Anforderungen darstellen. Dann würde die Definition von erledigt für eine neue User Story beinhalten, diese Tests nicht zu brechen.

HINZUGEFÜGT : Der Workflow-Schritt "Architekturprüfung" kann auf ein Problem zurückzuführen sein, das als Tragödie der Allgemeinheit bezeichnet wird . Hier ist ein großartiger Blog-Beitrag darüber, wie die Kanban-Visualisierung helfen kann, damit umzugehen, und mögliche Lösungen.

Diese Frage besteht aus zwei Teilen. Ein Teil ist: Woher wissen wir, wann sich die Architektur ändert? Der zweite Teil ist: Woher wissen wir, dass die Architektur immer noch gut ist.

Für diesen ersten Teil: Woher wissen Sie, wann sich die Architektur ändert?

Das Ziel hier ist, etwas, was implizit getan wird, explizit zu machen

• Alexeis Vorschlag ist eine Option. Erstellen Sie eine Spalte an der Tafel zur Überprüfung der Architektur. Verschieben Sie dann eine Karte dorthin, wenn architektonische Entscheidungen erforderlich sind
• Eine andere Möglichkeit besteht darin, eine explizite Richtlinie zu erstellen, die beschreibt, wie damit umzugehen ist: "Wenn wir die Architektur ändern müssen, müssen wir uns mit jemand anderem paaren", ist ein Beispiel für eine solche Richtlinie. In einem Projekt hatten wir die Richtlinie, dass Codeänderungen an bestimmten Spezialmodulen durch Pairing mit bestimmten Personen durchgeführt werden mussten. Wenn jemand dort den Code ändern wollte, rief er nach einem Paar und schloss sich zusammen. Der Rest der Arbeit wurde alleine erledigt. Ähnliches kann man mit der Architektur machen.

Sie würden sich wahrscheinlich für die erstere entscheiden, wenn viele Karten überprüft werden müssen oder wenn der Architekt nicht Teil des Teams ist und eine Übergabe erforderlich ist oder die Überprüfung detailliert genug ist, um einige Zeit in Anspruch zu nehmen, die Sie nachverfolgen möchten Die Tafel. Letzteres ist eine Option, wenn nur wenige Karten die Architektur berühren und ein Paar bei Bedarf leicht zu finden ist.

Nun zur zweiten Frage: Woher wissen wir, dass die Architektur immer noch gut ist?

Ich bin ein großer Fan von Visualisierung. Auf dem Whiteboard befindet sich möglicherweise ein Diagramm mit Haftnotizen, in denen die Komponenten und die Architektur beschrieben werden.

Es gibt auch statische Analysatoren, die die Codebasis analysieren und ein Bild mit Abhängigkeitsgraphen verschiedener Komponenten generieren. Sie könnten es ausführen, einen Ausdruck erstellen und es etwa einmal pro Woche an die Wand kleben. Möglicherweise hängen die letzten beiden Ausdrucke an der Wand, sodass Sie sehen können, ob sich in der letzten Woche etwas geändert hat.

Damit können Sie Ihre Architektur und Ihr Design sichtbar machen. Die Teammitglieder werden hin und wieder einen Blick darauf werfen und ihn kommentieren, wenn etwas geändert oder überarbeitet oder besser gemacht werden könnte.

Ich habe dieses Problem auch gesehen. Implizite Entscheidungsfindung! Wenn die implizite Aussage das Problem ist, wird es das Problem dann so deutlich wie möglich lösen? Ich schlage vor, den Architekturprozess ein wenig zu optimieren, um die impliziten Gedanken, aus denen Entscheidungen entstehen, zu „erklären“. Der Zweck des zusätzlichen Schritts im Prozess besteht darin, den Teammitgliedern klar zu machen, dass jeder dazu neigt, implizite Architekturentscheidungen zu treffen. Dieser Schritt wird nur die implizite Entscheidung von der Strecke fernhalten.

Es könnte hilfreich sein, die "Expliziten impliziter Entscheidungen" als Teil des Kanbans für jedes der Szenarien beizubehalten.

Was ich vorschlagen werde, könnte umständlich sein. Wenn der Prozess jedoch auf eine Reihe von Kanban-Elementen abgebildet wird und diese für jedes Bogenszenario an die Tafel gebracht werden, hilft es Ihnen nicht, sie zu verfolgen. Ich schlage vor, Sie können sie auch der sechsteiligen Szenariovorlage zuordnen und die Kanbantafel improvisieren, um die Ergebnisse zu berücksichtigen. Die QAs können nachverfolgt werden.

Vikram.

Es ist eines der Risiken, Architekturentscheidungen in agilen Teams zu verzögern. Offensichtlich ist es am verantwortungsvollsten, Architekturentscheidungen bis zum letzten verantwortungsvollen Moment aufzuschieben . Aber die Chancen stehen gut, dass der letzte verantwortliche Moment frühzeitig eintreten kann (oder muss).

Eine Sache, die hilft, ist es, frühzeitig klar zu definieren, welche Fahranforderungen wichtig sind. Dinge, von denen Sie eindeutig wissen, dass Sie sie haben müssen (aber nicht unbedingt sofort implementieren müssen). Ihre sich entwickelnde Architektur (die versucht, minimalistisch und flexibel zu sein) sollte die vorhandene oder zukünftige Unterstützung für solche Anforderungen berücksichtigen.

Noch wichtiger ist jedoch, dass Ihre sich entwickelnde Architektur KEINE Artefakte implementiert, die die Unterstützung dieser wichtigen Treiberanforderungen beeinträchtigen (oder beeinträchtigen können), selbst wenn diese Artefakte zur Lösung der aktuellen Anforderungen gedacht sind. Wir können solche Artefakte als störende Artefakte bezeichnen , Artefakte, die einen echten Wert liefern (da sie eine Lösung für bestehende Anforderungen implementieren), deren Vorhandensein es jedoch schwierig / kostspielig macht, eine zukünftige Schlüsselanforderung für das Fahren zu implementieren.

In Fällen, in denen Sie ein störendes Artefakt implementieren müssen, besteht Ihre Aufgabe darin, dessen Entfernung zu einem bestimmten Zeitpunkt zu planen (damit Sie die wichtigsten Treiberanforderungen implementieren können, die gestört werden.)

Offensichtlich ist dies alles esoterisch ohne einen tatsächlichen, greifbaren Kontext (wie ein echtes Projekt). Aber mehr oder weniger müssen Ihr Entwicklungsprozessmodell und Ihre sich entwickelnde Architektur diese Überlegungen berücksichtigen.

Implizite Anforderungen sind der Tod von Architekturen. Es muss alles explizit angegeben werden, sowohl die wichtigsten als auch die zusätzlichen Anforderungen. Sie müssen eine Anforderung nicht frühzeitig implementieren. Sie müssen nur in der Lage sein, das zu erklären.

PS. Unter Anforderung verstehe ich die Architekturanforderungen auf Systemebene und nicht unbedingt die vorübergehenden Anforderungen auf Anwendungsebene, die ohne wesentliche Änderungen an der Architektur erfüllt werden können. Ich hoffe es hilft.