Über Schneemänner und mathematische Beweise, warum Agilität funktioniert

Letzte Woche hatte ich einen interessanten Kurs von Roger Sessions über Snowman Architecture. Die Vergänglichkeit von Schneemännern unter jeglichem ernsthaften Druck trifft glücklicherweise nicht auf seine Architekturprinzipien zu, aber als agiler Fundamentalist sind mir einige interessante Muster in der Mathematik aufgefallen, die der Schneemann-Architektur zugrunde liegen und die in den agilen Praktiken gut verwurzelt sind. Wenn Sie diese Prinzipien verstehen, können Sie Ihr Bauchgefühl über diese Philosophien mit Fakten untermauern und mathematische Beweise dafür liefern, warum Agile funktioniert.

Komplexität

"Was hat die Philosophie mit dem Messen zu tun? Es sind die Mathematiker, denen Sie vertrauen müssen, und sie messen den Himmel, wie wir ein Feld messen. " - Galileo Galilei, Concerning the New Star (1606). In seinem Buch "Facts and Fallacies of Software Engineering" hat Robert Glass angedeutet, dass sich die Komplexität eines Systems effektiv verdoppelt, wenn seine Funktionalität um 25% zunimmt. Also in Formelform: Diese Hypothese wird durch empirische Belege gestützt und erklärt auch, warum ein Planungspoker, der sich auf die Komplexität der Implementierung und nicht auf die gelieferte Funktionalität konzentriert, eine genauere Schätzung dessen ist, was ein Team in einem Sprint liefern kann. Grundsätzlich gilt: Je kleiner Sie die Funktionalität machen können, desto besser, und das ist für Sie besser hoch 3! Sobald Sie beginnen, die Funktionalität zu verkleinern, werden Sie feststellen, dass Ihre großartige kleine Funktionalität mit anderen Funktionalitäten in Verbindung stehen muss, um für den Endbenutzer nützlich zu sein. Diese Abhängigkeiten werden durch Rogers Modell benachteiligt. "Eine externe Abhängigkeit trägt genauso viel Komplexität bei wie jede andere Funktion, aber sie tut dies unabhängig von den Funktionen." Mit anderen Worten, die Aufteilung einer Funktionalität von sagen wir 4 Punkten (74 Komplexitätspunkte) in zwei gleichwertige separate Funktionen reduziert die Gesamtkomplexität auf 17 Komplexitätspunkte. Dieser Vorteil verschwindet jedoch, wenn jedes Modul mehr als 3 Verbindungen hat. Eine interessante Beobachtung, die man daraus ableiten kann, ist ein mathematisches Modell, das Ihnen hilft, herauszufinden, welche Funktionen zusammen "gehören". Es liegt auf der Hand, dass diese Funktionen, wenn sie unter technischen Schnittstellen leiden, auch unter menschlichen Schnittstellen leiden werden. Aber wie finden wir heraus, welche Funktionen "zusammengehören", und ist es wichtig, dass wir es ungefähr richtig machen?

Unendliche Möglichkeiten

"Fast richtig zählt nicht" - Dr. Taylor; über die Landung eines Raumschiffs nach einer 300 Millionen Meilen langen Reise 50 Meter von einem Ort mit ausreichendem Sonnenlicht für die Sonnenkollektoren entfernt. Die Partitionierung von Mathematik ist unglaublich komplex, und das Hauptproblem bei der Trennung von Funktionen und Schnittstellen ist, dass es massive Auswirkungen hat, wenn man es "gerade so richtig" hinbekommt. Dies wird durch die "Bell-Zahl"(Wiki Bell-Zahl) gut abgedeckt. Diese Zahlen wachsen recht schnell, z.B. kann eine Menge von 2 Funktionen auf 2 Arten aufgeteilt werden, aber eine Menge von 3 hat bereits 5 Optionen, bei 6 sind es 203 und wenn Ihre Anwendung nur 16 Geschäftsfunktionen umfasst, haben wir bereits mehr als 10 Milliarden Möglichkeiten, Mengen zu erstellen, und nur eine Handvoll wird die gewünschte niedrige Komplexitätszahl ergeben. Wie kann uns also die Mathematik dabei helfen, die optimale Mengenaufteilung zu finden? diejenige mit dem niedrigsten Komplexitätsfaktor?

Äquivalenzbeziehungen

Um Geschäftsfunktionen zu finden, die zusammengehören oder zumindest so viele Gemeinsamkeiten haben, dass die Anzahl der Schnittstellen die funktionale Komplexität überwiegt, können wir auf die Äquivalenzrelation zurückgreifen(Wiki Äquivalenzrelation). Sie ist sowohl die Stärke als auch der Schwachpunkt der Snowmen-Architektur. Sie bietet einen genialen Algorithmus zur Aufteilung einer Menge in die optimalsten Teilmengen (und das in O(n + k log k) Zeit). Die Äquivalenzbeziehung, die Session vorschlägt, lautet wie folgt: Zwei Geschäftsfunktionen {a, b} haben dann, und nur dann, eine Synergie, wenn aus geschäftlicher Sicht {a} ohne {b} nicht sinnvoll ist und umgekehrt. Der Schwachpunkt ist die subjektive Messung in der Gleichung. Wenn sie auf einem zu hohen Niveau gespielt wird, wird alles erforderlich sein, und auf einem zu niedrigen Niveau keine wertvollen Geschäftsergebnisse liefern. In meinem letzten Projekt haben wir eine große eCommerce-Plattform in den kundenorientierten Teil und den Teil der Auftragsabwicklung aufgeteilt. Das funktionierte so gut, dass sich die Teams zu beschweren begannen, dass die Trennung ihre Kenntnisse über die Codebasis des jeweils anderen Teams verringert hatte, da nur sehr wenige Funktionen in beiden Teilsystemen kodiert werden mussten. Wir hatten die Komplexität tatsächlich erheblich reduziert, hätten aber noch einen Schritt weiter gehen können. Das System für die Auftragsabwicklung kommunizierte mit vielen anderen Systemen, um den Auftrag zu erfüllen. Aus geschäftlicher Sicht hätten wir eine weitere Trennung vornehmen und die Komplexität noch weiter reduzieren können. Mit dem Glass'schen Gesetz bewaffnet werden wir die Anwendung überarbeiten, um sie noch besser zu machen als sie heute ist.

Wozu die Mühe?

Nun, polynomial wachsende Probleme können nicht mit linearen Lösungen gelöst werden. [caption id="attachment_14407" align="aligncenter" width="480"] Polynomielle Probleme vs. lineare Lösungen aufgetragen gegen die Zeit[/caption] Solange die Komplexität unterhalb der Lösungskurve liegt, läuft alles gut. Doch irgendwann kommt der Punkt, an dem die Komplexität unsere Fähigkeit übersteigt, sie zu lösen. Natürlich können wir ein Team oder eine neue Technologie hinzufügen, aber wenn wir die Art des Problems nicht ändern, verschieben wir nur das Unvermeidliche. Das ist der Grund, warum Ihre User Stories die Sprintgrenzen nicht überschreiten sollten. Scrum zwingt Sie dazu, die Funktionalität in kleinere Teile zu zerlegen, die das Team in eine Phase bringen, in der die lineare Entwicklungsleistung die Komplexität des Problems verdrängt. In der Praxis haben wir in fast jedem Fall, in dem wir ein Team gesehen haben, das gegen diese Regel verstoßen hat, irgendwann den "Oh-Oh-Moment" erlebt, die Phase, in der es keine sauberen Lösungen mehr gibt. Glauben Sie also an die Mathematik und unterteilen Sie Ihre Komplexitätskurve in kleinere Stücke, in denen Ihre Lösungskapazität die Komplexität des Problems übersteigt. (Als Bonus erhalten Sie ein glückliches und florierendes Team.)

Möchten Sie mehr über den Einsatz von Kampfsportarten im Produktmanagement erfahren? Bestellen Sie das Buch bei bol.com, wenn Sie in den Niederlanden oder Belgien leben, oder melden Sie sich an, um die internationale Ausgabe zu erhalten.