Scrum-Team folgt nicht dem YAGNI-Prinzip

Bei einem SCRUM-Meeting diskutierte das Produktteam über eine Funktion einer API, die von der mobilen App genutzt wird. Wir hatten ein Modell, das zeigte, wie der Bildschirm aussehen sollte und welche Schlüsselelemente er enthalten sollte (ein "Layout").

Auf dieser Grundlage und der Diskussion mit dem Produktbesitzer habe ich einen Prototyp für eine API-Antwort (HAL + JSON) erstellt. Es war sehr einfach, HAL-konformes JSON, das nichts anderes tat, als die Dinge darzustellen, die auf den Mockups standen. Ich ließ mich nicht von den Zukunftsideen beeinflussen, die von Geschäftsleuten vorhergesehen wurden, da diese dazu neigen, ihre Ideen häufig zu ändern, und entschied mich für einen minimalistischen Ansatz. Mein Vorschlag wurde vom Team abgelehnt und ich wurde mit 7 zu 1 überstimmt.

Das Team entschied sich für eine komplexere, nicht semantische abstrakte JSON-Struktur, die mehr Flexibilität bei der Anordnung des Layouts ermöglicht. Der Nachteil dieses Ansatzes besteht darin, dass wir eine Reihe von einheitlichen Objekten haben, die vom Design her null und leere Eigenschaften haben können. Sie dachten auch, es wäre schön, A / B-Tests zu ermöglichen, aber sie basierten nur auf ihren Vorhersagen, da wir keine solchen Anforderungen hatten.

Die meiste Zeit diskutierten wir über Dinge, die weder Teil des Sprints waren noch in den Mockups erwähnt wurden. Die beschriebenen Probleme lauteten "Was wäre, wenn das Marketing in Zukunft ...", "Was wäre, wenn das Unternehmen dies wünscht ...".

Ich und der Produktbesitzer sind erfahrene Programmierer, und wir haben solche Probleme in der Vergangenheit gesehen. Wir versuchen, den YAGNI- und KISS- Prinzipien zu folgen . Der Rest des Teams ist etwas weniger erfahren und obwohl sie diese Prinzipien kennen, scheinen sie sie nicht zu verstehen.

Wir haben uns auf ihre Lösung geeinigt, da das gesamte Team für uns wichtiger ist und wir nicht über etwas streiten wollten, das nicht so wichtig ist. Aber ich fürchte, ob so etwas ein Präzedenzfall für bevorstehende, kompliziertere Debatten werden kann? Wie gehe ich mit einem solchen Verhalten um? Was kann ich als Teamleiter besser?

Erwähnenswert ist, dass es sich bei dem Produkt um ein MVP im Frühstadium handelt.

Ich fühle deinen Schmerz, war dort. IMHO diese Art von Problemen werden durch die Tatsache verursacht, dass Sie ein Team von 8 Personen haben, das bereits zu groß ist, um Sie immer zu den besten strategischen Entscheidungen kommen zu lassen.

In einem Team mit einer Größe von 8 oder mehr ist die Anzahl der mittelmäßigen Programmierer höher als die Anzahl der erfahrenen. Das führt oft zu Situationen, in denen die besseren Entscheidungen von mittelmäßigen überstimmt werden. Das hört sich nicht zufriedenstellend an, besonders wenn Sie einer der erfahreneren Typen sind (oder glauben, dass Sie einer von ihnen sind), aber zumindest gilt das oft auch für wirklich schlechte Entscheidungen.

Tatsache ist, dass man nicht viel dagegen tun kann, solange sich das Team nicht ändert , zumindest wenn die Dinge demokratisch bleiben sollen

• lerne damit zu leben
• Arbeiten Sie ein oder zwei Jahre mit dem Team zusammen, teilen Sie Ihr eigenes Fachwissen und hoffen Sie, dass sie mit der Zeit den Wert von YAGNI und KISS erfahren
• Arbeiten Sie an Ihren eigenen Fähigkeiten, Design oder strategische Entscheidungen an das Team zu "verkaufen"
• Versuchen Sie, zu einem anderen (vielleicht kleineren) Team zu wechseln, dessen eigenes Fachwissen eher dem Durchschnitt des gesamten Teams entspricht

Ich denke, der einzige Weg, den wahren Wert eines minimalistischen Ansatzes und von YAGNI zu lernen und zu verstehen, besteht darin, einige Erfahrungen aus erster Hand zu machen. Zum Beispiel, indem man sich auf die Aufrechterhaltung eines Altsystems einlässt, das eine Menge falscher "Was-wäre-wenn" -Vorhersagen, falsche Entwurfsentscheidungen aufgrund von "nur-für-den-Fall" -Argumenten enthält oder eine Menge übergenerierten Framework-Codes enthält, die eigentlich nie benötigt wurden. Aber das ist nichts, was Sie Ihren Teammitgliedern in zwei Tagen beibringen können. Einige Erfahrungen müssen die Leute selbst machen.

Die Aufwärtskompatibilität ist ein berechtigtes Anliegen

Wenn einer der sieben Entwickler, die Sie überstimmt haben, der Architekt ist, hat er das Recht, NFRs nach Bedarf einzuführen , und einer dieser NFRs könnte "Vorwärtskompatibilität" sein, insbesondere wenn Sie eine Remote-Systemkomponente unterstützen, die möglicherweise eine spärlichere Version aufweist Release-Zeitplan. Sie möchten nicht, dass Benutzer eine neue Version einer App installieren müssen, weil Sie nicht vorausgedacht haben.

Wie bei anderen Anforderungen benötigen Sie Akzeptanzkriterien

Abgesehen davon müssen alle NFRs als Anforderungen dokumentiert sein und definierte Akzeptanzkriterien haben . Außerdem müssen Sie ein Mittel finden, um sie zu testen . Aus diesem Grund ist YAGNI wichtig - Sie möchten keinen Code schreiben, der nicht getestet werden kann. Wenn der einzige Zweck des Codes darin besteht, eine Funktion zu unterstützen, die von niemandem verwendet wird, ist das Testen schwierig.

Es sollte kein Urteilsspruch sein

Ich würde vorschlagen, dass Sie das Team dazu bringen, sich auf die unausgesprochene Anforderung zu einigen, die Sie anscheinend verpasst haben, und sie aufschreiben zu lassen. Sobald Sie ein Mittel zum Testen definiert haben, sollte Ihre Implementierung mindestens einen Test nicht bestehen und es sollte daher nicht um eine Abstimmung gehen.

Es hört sich so an, als ob Ihr Entwicklungsteam versucht, das Produktteam zu unterstützen, indem es ein Framework erstellt, das es ihm ermöglicht, schnelle Tests durchzuführen. Das würde das Produktteam anscheinend sehr gerne haben. Ihr Ansatz ist eher wie "Geben Sie ihnen buchstäblich das, wonach sie fragen und denken Sie nicht für sie".

Wenn ich der Product Owner wäre, wäre ich mit einem Entwicklerteam, das den ersten Ansatz wählt, viel glücklicher als das letztere.

Meiner Meinung nach funktioniert Demokratie nicht richtig - weder im politischen System noch in einem Team, in dem die meisten Programmierer jünger oder mittelmäßig sind.

Ihr Wort als Teamleiter und eine der erfahrensten Personen in einem Team sollte eine größere Wirkung haben als der Rest des Teams. Wenn YAGNI für Sie wichtig ist, sollten Sie eine Präsentation darüber halten. Besprechen Sie es und zeigen Sie ihnen, warum es gut ist.

Immerhin ist Ihre Verantwortung höher als für andere Menschen. Es geht nicht nur darum, Code zu schreiben, sondern auch Menschen anzuleiten.

Es gibt ein wenig Verwirrung um YAGNI.

Entwickler denken oft, dass sie YAGNI folgen, wenn sie Abstraktionen weglassen, die das System "für Änderungen geschlossen und für Erweiterungen offen" halten.

Sofern Sie das System nicht mit einer "offensichtlich" nicht angeforderten Funktionalität "erweitern", beschäftigen Sie sich nicht mit YAGNI. Das Einführen von Abstraktionen, bei denen eine Erweiterung auftreten könnte, ist die bereits erwähnte "Aufwärtskompatibilität".

Meine persönliche Meinung ist, dass nur ein profundes Wissen über die Domäne dazu beiträgt, Entscheidungen über die Abstraktion zu treffen und wo sie zu lokalisieren ist.

Das Problem bei YAGNI AND KISS ist, dass sie völlig subjektiv und vage sind.

json ?? YAGNI! Sende einfach einen CSV-String!

Objekte? KISSTUPID !!! benutze einfach gotos !!

Die Rolle des "Teamleiters" ist nicht genau definiert, aber ich würde vorschlagen, dass Sie sich davon distanzieren, subjektive Meinungen zu den technischen Entscheidungen Ihres Teams zu äußern. Auch wenn Sie das Gefühl haben, dass sie falsch sind. Halten Sie sich an eine kurze Liste klar definierter Anforderungen.

• Unit-Tests für Code
• Integrationstests für apis
• automatisierte UI-Tests für das Endprodukt
• Leistungs- und Skalierungsanforderungen

Wenn das Team Tests für alle geschäftlichen Anforderungen und die grundlegenden Leistungsmerkmale gemäß den technischen Anforderungen bestehen kann, verfügt es über ein funktionsfähiges Produkt.

Danach ist es einfach drängend, dasselbe zu tun, aber schneller

Jeder im Team muss sich auf die Definition von erledigt einigen . Ohne dies neigen Sie zu massivem Umfang an Scope Creep, Sichtweisen und einer Verfälschung der Kernanforderungen.

Alles, was darüber hinaus geliefert wird, muss im Rückstand sein, der selbst auch eine eigene Definition von erledigt hat.

Wie für Prioritäten, die Moskau hat Methode uns immer gut bedient - YMMV.

Mein erster Gedanke ist ... Warum ist das Team besorgt über Veränderungen? Verfügen sie über ein historisches Verständnis des Product Owners, sodass sie das Gefühl haben, die erste Lösung erstellen zu müssen, die ein bisschen konfigurierbarer ist, um zukünftige Verbesserungen zu vereinfachen? Wenn Ihre Lösung 2 Tage und ihre 5 Tage dauern würde, ist sie mehr als doppelt so lang. Wenn die Änderung Ihres Plans jedoch jedes Mal 2 Tage dauern würde, eine Verbesserung jedoch 1 Tag dauern würde, scheint der Plan auf lange Sicht effizienter zu sein. Ich glaube nicht, dass es in dieser Frage eine RICHTIGE oder FALSCHE Entscheidung gibt. Es hängt von anderen Faktoren ab, IMHO. Sie sind jedoch RICHTIG in Bezug auf diese Denkweise, wenn sie bei anderen Lösungen den LOE verdoppeln, ohne dass Sie dazu direkt aufgefordert werden (ein Hinweis darauf, dass die zusätzliche Komplexität für Skalierbarkeit, Robustheit usw. erforderlich ist). Mein Vorschlag wäre, den Produktbesitzer in diese Gespräche einzubeziehen, da er bei der Priorisierung helfen muss. Wenn Ihre Lösung 5 Punkte hat und den Bedarf jetzt decken würde, aber was sie tun möchten, würde 50 Punkte und zwei Sprints oder mehr erfordern, könnte die PO sagen: "Moment, wir haben eine Veröffentlichung dieses MVP mit hoher Priorität geplant und Ich kann nicht zwei Wochen damit verbringen, Funktionen zu entwickeln, die nicht auf der Roadmap stehen! "