Follow my new blog

Dienstag, 7. Dezember 2010

Ein Traum von Softwareentwicklung

Lassen Sie für einen Moment mal alle eingefahrenen Vorstellungen von Objektorientierung und Agilität und Schichtenmodellen hinter sich. Folgen Sie mir einfach auf einer Traumreise in ein anderes Land der Softwareentwicklung…

Alles beginnt mit einem Unternehen. Das möchte eine Software in Auftrag geben. Es stellt sich den weltbesten online Shop vor, der es im Nu auf Augenhöhe mit Amazon, eBay und Expedia bringt. Das Budget hat der Vorstand schon fixiert. Die Wünsche wurden in den Fachabteilungen gesammelt. Und die IT hat auch schon ihren Senf dazu gegeben, denn irgendwer muss die Software hinterher ja auch betreiben. Es kann also losgehen…

Als Unternehmen, will es natürlich soviel wie möglich für sein Geld. Und als Teilnehmer an den komplexen Märkten des 21. Jahrhunderts will es gleichzeitig maximale Flexibilität auf dem Weg zum Maximum für sein Geld. Das scheint ein Widerspruch. Doch das Unternehmen hat einen Weg gefunden, beide Wünsche unter einen Hut zu bringen: Es vergleicht jeden Tag den Stand der Softwareentwicklung mit den Bedürfnissen der Anwender.

Jeden Tag ziehen sich die Anwender (bzw. ihre Vertreter für die Softwareabnahme während der Entwicklungsdauer) den aktuellen Stand der Software und probieren die hinzugekommene oder veränderte oder korrigierte Funktionalität aus. Das Entwicklungsteam stellt also jeden Tag ein neues Release bereit, das wieder etwas besser ist, als das vom Vortag. Und diese Verbesserungen sind immer anwenderrelevant; die Anwender können einen Unterschied erkennen, der ihnen wichtig ist – und sei der auch nur klein. So können sie jeden Tag feststellen, ob die Software noch auf Kurs zu ihrem Ziel ist. Sehen sie Abweichungen, steuern die Anwender nach, indem sie ihre Anforderungen verändern. Und das jeden Tag aufs Neue, wenn sie wollen.

Das Softwareentwicklungsteam unterstützt den Wunsch der Anwender, jeden Tag eine verbesserte Version testen zu wollen. Dafür hat es zunächst einen automatischen Build- und Deliveryprozess aufgesetzt, der dafür sorgt, dass alle Softwareartefakte jeden Tag gebaut, überprüft, verpackt und für den Download durch die Anwender bereitgestellt werden.

Die Überprüfung besteht aus automatisierten Tests und stellt vor allem sicher, dass die Software frei von Regressionsfehlern ist. Soweit möglich, sollen die Tests aber natürlich auch “beweisen”, dass hinzugekommene Funktionalität von vornherein keine Fehler enthält und den formalisierten Anforderungen (Akzeptanztests) entspricht.

Damit der automatische Build- und Deliveryprozess auch jeden Tag etwas zu tun hat, muss die Codebasis natürlich jeden Tag anwenderrelevante Änderungen aufweisen. Das Entwicklungsteam muss also jeden Tag etwas Auslieferbares fertigstellen. Ganze User Stories, wie sie das Unternehmen an das Entwicklungsteam heranträgt, sind natürlich viel zu groß, um sie in einem Tag umsetzen zu können. Auch Features herausgelesen aus User Stories passen noch nicht in einen Tag. Aber Features Slices, d.h. hauchdünne Längsschnitte durch Features, die lassen sich in einem Tag realisieren. Manchmal braucht es dafür ein wenig Phantasie, um sie in den Features zu erkennen, doch allermeistens klappt das.

So teilt das Team die Anforderungen in mehreren Schritten in Happen von Tagesumfang. Ob das 3, 4 oder 6 Arbeitszeitstunden sind, hängt vom Team und seiner Möglichkeit und Fähigkeit zur Fokussierung ab.

In wenigen Stunden muss und will das Team also Anwendernutzen auf die Straße bringen. Dafür ist maximale Geschwindigkeit in der Umsetzung nötig. Die erreicht das Team dadurch, dass es alle Entwickler auf das Feature Slice des Tages ansetzt. Alle arbeiten daran parallel, so wie beim Formel 1 Boxenstopp die Mechaniker an einem Rennboliden.

Dass sich dabei die Teammitglieder nicht ins Gehege kommen, also durch Konflikte Zeit verlieren, stellt die Komponentenorientierung sicher. Jedes Teammitglied bekommt für die Dauer einer Feature Slice Realisierung eine Anzahl von Komponenten zugeteilt, für die es allein verantwortlich ist. Alle Arbeit findet dann pro Entwickler konzentriert an einer Komponente zur Zeit statt. Die Kontrakte der Komponenten stellen dabei sicher, dass Änderungen keine unerwartete Reichweite haben. Die Komplexität hält sich durch kontraktuelle Entkopplung in Grenzen und automatisierte Tests in Isolation helfen, die Fehlerzahl gering zu halten.

Komponenten und Entwicklerzuordnung (Feature Team) sind das Ergebnis der Arbeitsorganisation des Teams. Vor Beginn der Feature Slice Realisierung identifiziert es die betroffenen Komponenten und weist sie Teammitgliedern nach Kompetenz, Erfahrung, Wunsch, Verfügbarkeit usw. zu.

Welche Komponenten aber überhaupt zur Auswahl stehen, ergibt sich aus den Bauteilen eines Event-BasedComponents (EBC) Modells, die innerhalb eines Architekturrahmens und im Sinne maximal paralleler Realisierbarkeit zu Komponenten zusammengefasst werden. Das Modell definiert die Funktionseinheiten auf verschiedenen Abstraktionsebenen, die die Anforderungen erfüllen. Das tut es unabhängig von der Implementierung, um die Lösungsplanung schneller und flexibler zu halten.

Das Team modelliert die Lösung also, um ganz präzise zu wissen, welche Funktionseinheiten zu implementieren sind. Die werden bestimmt durch die Funktionalität, die User Stories/Features beschreiben. Andererseits sind aber auch nicht-funktionale Anforderungen zu erfüllen. Dafür direkt Funktionseinheiten während der Modellierung zu finden, hieße jedoch, die Modellierung zu überfrachten. Deshalb entwirft das Entwicklungsteam vor dem Modell eine Softwarearchitektur. Sie definiert einen Rahmen von architekturellen Funktionseinheiten, in den sich das Modell mit seinen Funktionseinheiten einpassen muss.

Präzise Kenntnis der zu implementierenden Funktionseinheiten, die die funktionalen wie nicht-funktionalen Anforderungen dienen, ist Voraussetzung für die tägliche Feature Slice Realisierung in Höchstgeschwindigkeit.

So wichtig ein guter Entwurf jedoch auch sein mag, um den Anwender ihre Flexibilität zur Kursänderung zu geben, er reicht nicht aus. Mit Höchstgeschwindigkeit können nur Entwickler arbeiten, die genau wissen, was sie tun. Wie genau kann nun aber Wissen sein, wenn sich nicht nur die Domäne bewegt, sondern vor allem der Markt der technischen Realisierungsmöglichkeiten?

Das Entwicklerteam trennt deshalb ganz klar zwischen “Performance”, d.h. Zeit, in der es in Höchstgeschwindigkeit entwickelt, und “Übung”. Feature Slices realisiert das Team selbstverständlich in seiner Performance-Zeit. Da sitzt jeder Handgriff. Alle arbeiten wie geschmiert miteinander. Was zu tun ist, liegt klar auf der Hand bzw. ist aus Architektur, Modell und Arbeitsorganisation für jeden abzulesen.

Damit Performance-Zeit möglich ist, reflektiert das Entwicklerteam jedoch ständig darüber, was es noch nicht genau weiß. Es hinterfragt ständig sein Wissen in Bezug auf Domäne und Technik. Und wo es Wissenslücken auftut, da setzt es ausdrückliche Übungszeit an, um sie zu schließen. Ist die Wissenslücke projektspezifisch technisch, dann wird sie im Rahmen einer Spike Solution angegangen. Ist die Wissenslücke allgemein, dann wird sie durch Fortbildung geschlossen.

Domänenwissenslücken schließlich trägt das Entwicklerteam an die Anwender heran. So schließt sich der Kreis. Der Anwender repräsentiert durch die Rolle ProductOwner ist die entscheidende Klammer um die Softwareentwicklung.

Der Anwender “zieht täglich am Team”, weil er den Fortschritt der Entwicklung kontinuierlich gegen seine Anforderungen halten will. Nur so kann er schnell reagieren. Nur so bekommt er auch das Maximum für sein Geld.

Und das Team “zieht täglich am Anwender”, um dessen Anforderungen von vornherein möglichst genau zu treffen. Das heißt, der Anwender steht immer für Rückfragen zur Verfügung, um das Team in seiner täglichen Feature Slice Produktion nicht zu behindern.

Damit der gegenseitige Zug wirklich funktioniert, braucht es abschließend natürlich eines: Verlässlichkeit. Das Entwicklerteam muss verlässlich Anforderungen in Software mit Anwendernutzen transformieren. Der Anwender muss die Software verlässlich sofort abnehmen. Und der Anwender muss verlässlich für Rückfragen zu den Anforderungen bereitstehen.

Ohne Verlässlichkeit ist die ganze Softwareentwicklung nichts. Oder wenn sie etwas ist, dann zumindest nichts, das wie geschmiert und mit Höchstgeschwindigkeit abläuft.

Und ohne Verlässlichkeit kein Vertrauen. Denn Vertrauen kann man nicht befehlen; es entwickelt sich nur, wo Verlässlichkeit erfahren wird.

Das hat das Unternehmen begriffen und verzichtet daher auf den üblichen Festpreismodus für die Entwicklung des online Shops. Es hat sein Budget fixiert, es hat Wünsche gesammelt – und dann überträgt es die Realisierung einem Entwicklungsteam, zu dem es Vertrauen hat, dass es die Realisierung in Höchstgeschwindigkeit beherrscht.

Da Vertrauen immer gegenseitig sein muss, stellt das Unternehmen natürlich sicher, dass es selbst dem Entwicklungsteam ein verlässlicher Partner ist, der die erwartete Höchstgeschwindigkeit mittragen will und kann.

Und so wird am Ende der Traum wahr: Das Unternehmen bekommt ohne Budgetüberschreitung das immer wieder flexibel neu bestimmte Maximum.

Jetzt können Sie die Augen wieder öffnen. Lassen Sie den Traum aber noch etwas nachwirken. Vielleicht bewirkt er ja etwas bei Ihnen. Vielleicht machen Sie sich ja auf den Weg, aus dem Traum Realität werden zu lassen… Ich glaube, das ist möglich.

7 Kommentare:

Florian Mätschke hat gesagt…

Klingt sehr vielversprechend und mit EBC könnte ich mir dies sicher gut vorstellen.
Leider herrscht in vielen Projekten oftmals eine andere oder alt eingefahrene Realisierungsstrategie vor, und/oder der Kunde ist nicht gewillt so zu agieren.
Wie bringt man ihn oder seine Kollegen dazu?

Ralf Westphal - One Man Think Tank hat gesagt…

@Florian: Alle Änderung muss beim Kunden (bzw. seinem Vertreter) ansetzen. Wenn das nicht passiert, stehen Veränderungen in der Softwareentwicklung auf tönernden Füßen. Deshalb war es mir wichtig, den Traum ausgehend vom Kunden zu formulieren. Der zieht... und jede weitere Stufe wird damit zur Anpassung veranlasst und zieht wiederum an einer vorgelagerten.

Haggy hat gesagt…

Ein schöner Traum und ein tolles Ziel.

Wie du auch schon sagst, der entscheidende Punkt ist, dass der gesamte Prozess beim Kunden und Product Owner beginnt.

Gerade da sehe ich aber auch das schwerste Stück Arbeit.

Bei vielen Entwicklern rennt man mit dem Thema Qualität offene Türen ein.

Bei Kunden / Product Owner ist das nicht immer der Fall. Gerade dann wenn es eben auch Struktur und zuverlässigkeit einfordert.

Auch der Respekt vor Grenzen tendiert of in eine Richtung.

Entwickler akzeptieren es wenn ein Product Owner seine ergebnisse liefert. Da ist i.d.R. vertrauen vorhanden.
Product Owner möchten oft einfluss auf die Technik nehmen ohne sich aber in diesen Bereichen auszukennen.
Hier herscht oft mißtrauen und Grenzen werden verschoben.

"Warum wollt ihr das Refaktorisieren. Das ist doch nicht nötig. Statt dessen könnten wir 2 weitere Features schaffen."
Dass ein Product owner nicht zwingen den Sinn von Codequalitäts maßnahmen versteht finde ich noch ok. Allerdings sollten diese Entscheidungen auch dem Team überlassen sein.

Damit zusammenhängen sieht man in Projekt häufig implizite Hierarchien. Bei denen es dann weniger ein Mitaneinander, als mehr eine OneWay Richtung gibt in der etwas gefordert werden darf.

Etwas überspitzt:
Kunde / Product Owner ist König , der Entwickler ist das Bauernopfer...

Das funktioniert zwar nicht, aber diese Denke ist weit verbreitet.

Der Product Owner fordert Qualität und zeitnahe Ergebnisse von dem Entwicklerteam, die Entwicklern dürfen aber eben diese Qualität, z. Bsp. bei Dokumentation und zeitnahes Feedback zu den Funktionen nicht fordern.

Für viele Kunden / Product ohne ist nicht klar, dass die Qualität des Outputs eines Entwicklerteams direkt an die Qualität des Inputs durch Kunde / Product Owner gekoppelt ist.

Und genau da da muss der Ansatz liegen.
Weniger implizite Hierarchien, mehr explizite und klar definierte einforderbare Arbeit und respektieren von Grenzen (mit dem von dir genannten Vertrauen ) auf allen Ebenen.

Diese Entscheidungen, die das maßgeblich Unternehmen in seiner Struktur beeinflussen können nur vom Product Owner getroffen werden.

Deswegen müsste hier am dringensten Sensibilisierungsarbeit geleistet werden, welche bei vielen Entwicklern bereits abgeschlossen ist.

Nichts desto trotz tat es gut sich in das beschriebene Szenario zu versetzen und es mal gedanklich durchzuleben.

Ralf Westphal - One Man Think Tank hat gesagt…

@Haggy: Beim PO sollst du nicht Qualität verkaufen, sondern Flexibilität und Nutzen.

Wenn der dann so wie erträumt am Team zieht, kommt es automatisch zu Qualität. Es kann dann nicht mehr ohne Qualität Code herstellen. Das ist ja der Trick an dem Traumszenario.

POs verstehen ihre Rolle falsch, wenn sie Einfluss auf Technik nehmen wollen oder gar können. Da ist ein Riegel vorzuschieben.

Genausowenig ist einem PO zu sagen, ob und wann man ein Refactoring durchführt. That´s none of his business. Der Chirurg wird mir auch nicht erzählen, welches Garn er für eine Naht verwendet und ich hab dazu dann ne eigene Meinung als Patient.

Ich nehme mir für 2011 vor, mehr Einfluss auf ProductOwner und solche, die es werden wollen, zu nehmen. Spreche daher sogar auch Konferenzen, die nix für Entwickler sind ;-)

Dirk Matuschek hat gesagt…

Für mich wäre das ein Albtraum! Jeden Tag unter dem Stress zu stehen, am Abend ein vorher definiertes Ergebnis abliefern zu müssen. Sicher kann der Kunde etwas für sein Geld verlangen. Und ich bin auch bereit, gute Leistung abzuliefern. Aber im Alltag funktioniert "da sitzt jeder Handgriff; alle arbeiten wie geschmiert miteinander" einfach nicht. Da ruft die Personalabteilung an, dass man heute unbedingt noch die Reisekostenbrechnung fertig machen muss. Da muss der Kollege wegen eines Arzttermins heute schon mittags Schluss machen. Oder er fällt wegen Krankheit gleich ganz aus. Da stört alleine, dass Frühaufsteher und Langschläfer ihre Arbeitszeit nicht deckungsgleich haben. Ein gemeinsamer Start und Abschluss wird schon dadurch vereitelt. Oder der Kollege, an den ich eine Frage habe, ist schon weg.

Man könnte drüber reden, dass man jede Woche was abliefert. Das schafft die dringend benötigten Pufferzeiten. Weil dann nicht alles auf Kante genäht ist, hat man mehr Flexibilität. Und verschleißt die Mitarbeiter deutlich weniger.

Außerdem senkt man den Stress und den Aufwand bei den Anwendern. Die sind nach meiner Erfahrung sowieso nicht dazu in der Lage, sich jeden Tag Zeit zu nehmen. Sie können nicht mal die kurzen Reaktionszeiten garantieren. Selbst wenn sie wollten; was sie aber nicht tun.

Mag sein, dass dein Traum ein Extrem zeigen sollte, um aufzurütteln. Denn dieses Extrem so umzusetzen wäre sicher nicht erstrebenswert.

Ralf Westphal - One Man Think Tank hat gesagt…

@Dirk. Tut mir leid, dass ich Albtraumgefühle bei dir ausgelöst habe.

Aus einer gewissen Perspektive kann ich dein Zucken verstehen. Aber glaub mir: Es funktioniert. Und das ganz ohne Stress. Sogar mit Spaß, nein, mit mehr Spaß als bisher.

Denn nur, weil jeden Tag ein Feature Slice geliefert werden soll, heißt das nicht, dass irgendjemand außer Atem kommen muss.

Aber dazu musst du es erlebt haben, wie das ist mit der Modellierung und der parallelen Entwicklung im Team an Komponenten. Ich nehme an, dass du diese Erfahrung nicht gemacht hast.

Haggy hat gesagt…

@Dirk:
Ich kann Ralf nur zustimmen, wird das ganze von der Firma als ganzes getragen (auch wenn ich das bisher noch nicht oft erlebt hatte) ist es toll.

Gerade durch das gegenseitige Vertrauen und die konstruktive Ausgangssituation.

@Ralfw:
Dass der PO sich raushalten sollte ist klar. Allerdings haben einige fürher selbst mal programmiert, da fällst loslassen schwer und der von die genannte Punkt vertrauen hängt damit direkt zusammen.
Allem fremden wird zunächst mal nicht vertraut. Und so zu programmieren ist nicht gerade das von damals gewohnte...

Das (nicht) Kommunizieren eines Refactorings ist schwierig.

Gäbe es z.bsp. eine Anforderung A und man weiß dass diese in Komponenten erfolgen muss, welche dringend refaktorisiert werden muss. So addiert man in seiner Schätzung die benötigte Zeit auf folgt skepsis was den Aufwand angeht.
Zum einen weil ein Refaktorisierung eben Zeit kostet und zum anderen weil der verklärte Blick "Damals war das nur ein Selekt" gar keinen Aufwand für UnitTests, Struktur arbeit etc kannte...

Der zugrunde liegende Punkt ist Vertrauen. Vertrauen in die eigenen Entwickler und vertrauen in das System.

Das Halbwissen der PO ist hierbei nur schädlich.

Auf welchen Konferenzen bist du denn genau ? Vielleicht kann ich ja den ein oder anderne überreden hinzugehen ;)