Aufgrund der hohen Anzahl von Stakeholder-Konflikten litt das Projekt unter einer schweren Krankheit: “Design by Committee”. Dieser besondere Fall von “Design by Committee” war besonders abscheulich: Anforderungen an wichtigere Merkmale enthielten auch eher Widersprüche, da verschiedene Akteure stärker in ihre eigene bevorzugte Richtung zu lenken versuchten. Ab und zu kam eine Einheit von Anforderungen hinzu, die die Entwickler zum Nachdenken brachte: "Das wird in 3 Monaten ein Debugging-Albtraum sein". Natürlich hatten die Entwickler, die am längsten im Projekt waren, eine defensive Programmierstrategie entwickelt. Sie würden zusätzliche Geschäftslogik in die Lücken zwischen der Geschäftslogik der offiziellen Anforderungen einfügen, um ein Versagen des Produkts zu verhindern. Diese Sicherheitsvorkehrungen waren bis auf Codekommentare undokumentiert, da es sich um offizielle plattformspezifische Implementierungsdetails handelte.
Der hohe Grad an Stakeholder-Konflikten führte auch zu einem geringen Maß an interdisziplinärem Vertrauen. Niemand hat sich wirklich gegenseitig vertraut, um gute Arbeit zu leisten, aber Programmierer sind der Engpass im Laufe der Software-Herstellung und ihr Misstrauen kann sehr störend sein. Wenn der Programmierer einen konstanten Strom von schlechten Anforderungen erlebt, könnte jedes Verhalten wie unerwünschtes Verhalten erscheinen, das den Instinkten des Implementierers unterliegt. Vielleicht haben Marketingleute einmal eine beliebige Dateneingabe vermasselt und ein bestimmter Programmierer hatte deswegen eine wirklich schlechte Zeit? Oder vielleicht bestand die Geschäftspartnerbetreuung auf zu vielen zusätzlichen Geschäftsregeln, um einige rechtliche und vertragliche Verpflichtungen zu umgehen und gleichzeitig einen Wettbewerbsvorteil zu wahren, und drei Geschäftsregeln wurden in einem schwer zu fassenden Edge Case auf subtile Weise widersprüchlich, und 5 Personen mussten ein Mob-Programm starten, um es herauszufinden? Hat dir der letzte Satz Kopfschmerzen bereitet? So fühlt es sich auch real an.
Der Entwickler in unserer Geschichte bemerkte, dass eine Kombination aus zwei Merkmalen die App unter bestimmten Bedingungen in eine blockierende offene Schleife zwingen würde. Und er führte einen sehr langen Timeout ein, der die App vor diesem Zustand schützen würde. Das ist eine vernünftige Entscheidung, da es sich bei dem Produkt um ein eingebettetes System handelte und eingebettete Systeme sehr unversöhnlich sind, wenn es um eine schlechte Interrupt-Verwaltung geht. Allerdings wurden die beiden Funktionen für genau dieses Ergebnis entwickelt, einige Anwendungen des Produkts waren sehr betrugsanfällig und die Interessenvertreter auf der Rechtsseite suchten aktiv nach der Möglichkeit, die App für potenzielle Marker vor Betrug zu schützen. Am Ende brach die kleine Vergoldung, die normalerweise als Implementierungsdetail durchlaufen würde, einen Regressionstest.
Der menschliche Mechanismus hinter all dem ist einfach. Kompetente Programmierer sind gut darin, Muster zu erkennen, sie werden eine mentale Liste von wiederkehrenden Ausfallmodi der vorgelagerten Teams erstellen. Da Programmierer an dysfunktionalen Projekten wie den oben beschriebenen arbeiten, werden die Listen länger und die Programmierer werden mit der Zeit zynischer. Irgendwann wird der Programmierer feststellen, dass gerade die Gründe, die Fehler in die Anforderungen einbringen, auch die Feedbackschleifen für Korrekturen beschädigen. Abhängig von ihrem Grad an Zynismus werden Programmierer früher oder später anfangen, die wahrgenommenen Probleme proaktiv und stillschweigend durch Hinzufügen von nicht spezifiziertem Code zu "beheben". Natürlich ist dies keine echte Lösung, da der Programmierer nur rät. Es ist auch wahrscheinlich, dass Programmierer ein akzeptiertes Verhalten fälschlicherweise als problematisch identifizieren und tatsächlich einen Bug einführen, indem sie versuchen, einen nicht existierenden Bug zu beheben.
Die Art und Weise, wie ich es erklärt habe, klingt nicht soooo schlecht, Programmierer implementieren falsche Fail-Safes für einige Edge Cases. Edge Cases sind standardmäßig selten. Wie stark können die Auswirkungen sein? Programmierer-Zynismus ist es, was die Produkte im Feld am Laufen hält. Nun, was ist, wenn sich die Ad-hoc-Fix-Strategie versehentlich über einen langen Zeitraum als erfolgreich erweist und die Programmierer immer mutiger, zynischer und eifriger werden, um das Produkt vor den Stakeholdern zu schützen? Ich habe einige solcher Fälle in realen kommerziellen und sehr teuren Projekten gesehen. Die Produkte entwickelten sich schließlich zu einem Haufen von Hacks und wurden nicht mehr wartbar. Der spezifische Entwickler, den ich im Titel erwähnte, kuratierte auch eine Liste von Flags für inoffizielle Features, die entwickelt wurden, um eine Reihe von Anforderungen zu verwalten, die alle sechs Monate ein- und ausgeschaltet werden.
Also, was ist zu tun? Die zusammenfassende Lösung besteht darin, Vertrauen aufzubauen. Aber wie ich bereits sagte, ist das Fehlen von Vertrauen in diese Klasse von Problemen eigentlich gerechtfertigt. Unterhaltsame Teamspiele wie Eisbrecher-Aktivitäten und Vertrauen-Fallenlassen-Spiele werden in solchen Fällen nicht wirklich helfen. Es muss eine Art Strukturreform durchgeführt werden, und die Programmierer müssen darauf achten, dass die Anforderungen ordnungsgemäß verwaltet werden.
Die kleinstmögliche Strukturreform besteht darin, eine Person als Product Owner im Sinne von Scrum zu benennen. Die Rolle Scrum PO wurde speziell entwickelt, um die sozialen und politischen Aspekte des Anforderungsprozesses von den Entwicklern fernzuhalten. (Zusammenfassung: Eine einzelne Person holt Meinungen von allen Beteiligten ein, erstellt dann eine Liste von Prioritäten und ist befugt, Entscheidungen für die App zu treffen. Entwickler müssen mit einer einzigen Person sprechen und können hoffentlich kohärente Antworten erhalten.) Du brauchst nicht den gesamten Tingeltangel von Scrum, um einen PO zu haben. Ein PO braucht einfach die institutionelle Macht, um zu wichtigen Personen Nein zu sagen, ohne entlassen zu werden.
Meine persönliche Lösung wäre, die Toxizität am Arbeitsplatz loszuwerden. Aber ich würde lieber nicht in das Wespennest stechen.
trendig
