Ich bin sehr positiv in Richtung agiler Entwicklung und habe seit etwa 13 Jahren an agilen Projekten gearbeitet. Aber ich habe eine Sorge, die ich nie wirklich ansprechen konnte. Es scheint nicht immer zu manifestieren, aber es hat mich ein paar Mal gebissen.
Agile scheint in gewisser Weise ein "gieriger Algorithmus" zu sein. Beginne mit der Geschichte mit dem höchsten Wert, optimiere das System, um genau diese Geschichte zu erfüllen und wiederhole es.
Tatsächliche gierige Algorithmen sind anfällig dafür, dass sie zu lokal optimalen Lösungen konvergieren, während sie eine global optimale Lösung verpassen.
War das die Erfahrung der Leute?
Ist das eigentlich ein Problem?
Wenn ja, mit welchen Techniken vermeiden Sie solche lokalen Optima und bleiben dennoch agil?
Tatsächliche gierige Algorithmen sind anfällig dafür, dass sie zu lokal optimalen Lösungen konvergieren, während sie eine global optimale Lösung verpassen.
Dies gilt, wenn die technische User Story und die Leitlinie von EPIC nicht zusammen mit der normalen EPIC-Benutzergeschichte erstellt werden.
War das die Erfahrung der Leute?
Manchmal war es meine Erfahrung. In einem Fall wurden die User Stories, an denen wir arbeiteten, zu sehr aufgeteilt, und die Lösung bestand darin, sie zu erweitern, um unsere Designs globaler zu gestalten. Und manchmal waren es verschiedene Enterprise-Scrum-Teams im selben Projekt, die sich mit den verschiedenen technischen Rahmenbedingungen und Ansätzen widersprechen.
Ist das eigentlich ein Problem?
Es ist nur ein Problem, wenn Sie die technische EPIC User Story oder Richtlinie ignorieren.
Wenn ja, welche Techniken verwenden Sie, um solche lokalen Optima zu vermeiden und dennoch agil zu bleiben?
Hier ist ein agiler Ansatz, um das zu lösen: Während der Agile Release-Planung sollten Sie nicht nur eine Business EPIC User Story erstellen, sondern auch eine Technical EPIC User Story erstellen. Die technische EPIC User Story würde die Produktvision von einem technischen Standpunkt aus haben, in Bezug auf technische Architektur, Anwendungsrahmen, Qualitätsstandards und globale Designüberlegungen etc. Diese könnten in kleinere technische User Stories zerlegt werden und ein Scrum Team haben das funktioniert, damit diese User Storys funktionieren. Ein Beispiel für eine User Story könnte sein: "Als technischer Projektmanager möchte ich das gesamte Unternehmensprojekt mit A-, B-, C-Framework und Kodierung nach X-, Y- und Z-Kodierungsstandards, so dass es eine einheitliche Projektentwicklung gibt Arbeit. Wenn Sie nicht separat ein Scrum-Team bilden möchten, halten Sie sie als Erinnerungstafeln neben Rückständen für Entwicklungsteams als Richtlinien fest.
Als Testleitfaden hatten wir erfolgreiche Integrationstests als Fertigkriterium für jeden Rückstand. In einer Integrationsumgebung wurde ein globaler Test durchgeführt, bei dem die gesamte von allen Unternehmensteams bereitgestellte funktionierende Software als lieferfähig eingestuft wurde. Das Thema ist also von Anfang bis Ende des Backlogs auf global arbeitende Software und nicht nur auf lokale Arbeitssoftware ausgerichtet.
Bei der agilen Entwicklung geht es schließlich darum, die Qualität ständig im Auge zu behalten. Eines der Qualitätsprobleme könnte ein schlechtes Design oder ein zu lokales Design sein. Wenn dies entdeckt wird, sollte es innerhalb dieses Backlogs selbst neu gestaltet werden und für andere Backlogs nach vorne gehen.
Ich war bei einem Projekt, das dieses Problem hatte und es nicht effektiv behandelt hat.
Die lokale Qualität des Codes - sagen wir über die Größenordnung eines Pakets - war nicht schlecht. Aber es gab Probleme in größeren Skalen; Dinge wie die Duplizierung von Logik (aber nicht Code) zwischen Paketen, die Verwendung von Batch-Neuberechnung-Jobs, bei denen wir ereignisgesteuerte Ansätze verwenden sollten, die Aufteilung des Systems in separate Dienste am falschen Ort, etc.
Keines dieser Probleme konnte durch Refactoring einer einzelnen Klasse oder eines einzelnen Pakets behoben werden. Infolgedessen sind sie nie im normalen Verlauf der Ereignisse passiert. Wir haben Refactorings in kleinerem Maßstab durchgeführt - wenn wir ein Feature hinzufügten, wurden wir in diesem Bereich umgestaltet, bevor wir anfingen und wieder nach dem Abschluss (und wir haben uns auch bemüht, guten Code zu schreiben, während wir gingen). Aber das hat nie dazu geführt, größere, architektonische Probleme zu überdenken.
Wir waren uns alle der Probleme bewusst, wir hatten einfach nichts in unserem Prozess, das uns reparieren ließ.Ein bemerkenswerter Sieg, den wir hatten, war, wo es zwischen zwei entfernt verwandten Modulen Doppelungen gab. Im Wesentlichen gab es Code zum Rendern einer Webseite, auf der die Ergebnisse einiger Berechnungen dargestellt wurden, sowie einen Hintergrundjob zum Generieren von Berichten, die ähnliche Berechnungen ausführen. Der Berechnungscode wurde freigegeben, der Code zum Einrichten der Berechnungen jedoch nicht. einer wurde von den Benutzereinstellungen eines Benutzers gesteuert, während der andere von einem konfigurierten Berichtsjob gesteuert wurde. Wir hatten eine zu implementierende Funktion, die das Hinzufügen eines neuen Aspekts zu den Berechnungen beinhaltete, was bedeutete, dass mehr Elemente zu beiden Arten der Konfiguration hinzugefügt werden mussten und dann Geschäftslogik zu beiden Sets des Berechnungs-Setup-Codes hinzugefügt wurde. Wir haben es geschafft, dass der Produktmanager (unser Kunden-Proxy) zustimmte, genügend Zeit für die Arbeit einzuplanen, die wir umgestalten konnten, um die Ideen der Benutzeransichtspräferenzen und des konfigurierten Berichtsjobs zu vereinen und so eine der Seiten der Duplizierung wegzuwerfen Implementieren Sie das Feature. Das dauerte länger als nur zweimal zu implementieren, aber der Produktmanager war klug genug, um zu erkennen, dass wir damit zukünftige Funktionen, die sowohl Seiten als auch Berichte umfassten, schneller implementieren konnten.
Der Mechanismus, mit dem wir das gemacht haben, war das Schreiben von Geschichten für den Refactoring-Job. Im Wesentlichen etwas wie "Als Produktmanager möchte ich, dass Seiten und Berichte einen allgemeinen Berechnungs-Setup-Code verwenden, damit ich Funktionen schneller hinzufügen kann". Dies ist absolut keine richtige Art von Geschichte, aber es passte in das System und es hat seinen Zweck erfüllt.
Ich denke, wenn dieses Projekt etwas gesünder gelaufen wäre, hätte es einen stetigen Strom von Geschichten wie diesem gegeben. Wir würden anerkennen, dass wir eine Menge architektonischer Schulden hatten, und dass die Arbeit, um sie abzuzahlen, einen Wert hatte und einen festen Anteil unserer Zeit, vielleicht ungefähr 20%, zuweist (was wirklich ein Paar zu einem Zeitpunkt bedeuten würde). Wir hätten dann Features / Epen, Stories und Aufgaben genauso generieren können wie für kundenorientierte Arbeit. Diese stammen eher vom Team selbst als von den Produktmanagern.
Leider gab es nicht genug Kommunikation und Vertrauen zwischen den Entwicklungs- und Produktmanagement-Seiten, dass dies machbar war; wir könnten dem Produkt sagen, dass wir ein Problem hatten, dass es wichtig war und dass es so lange dauern würde, es zu reparieren, und sie konnten nicht wissen, ob das stimmte oder nicht. Daher waren sie im Allgemeinen nicht bereit, Zeit dafür zu veranschlagen. Das Traurige war, dass alle übereinstimmten, dass es Probleme gäbe, und es wäre gut, sie zu beheben, wir hatten nur eine Sackgasse darüber, es tatsächlich zu tun.
in meiner Erfahrung, wenn Sie einen Projektkontext mit festen Zeit / Anforderungen arbeiten dann ja, die meisten Male Agile führt zu lokalen Optima.
Aber mein Punkt ist, dass sich in einem komplexen Unterfangen die Anforderungen, das Team selbst und sogar die Ziele ändern. Agile geht es auch um Veränderungen. Paradoxerweise erscheint diese gierige Strategie als vernünftige Option für die globale Optimierung im Umgang mit beweglichen Zielen.
Tags und Links agile