Читать книгу Scrumster - Achim Schneider - Страница 13
ОглавлениеPlatz 10 - Working Software
Funktionierende Software ist schon im agilen Manifest proklamiert und eine Grundvoraussetzung agiler Methoden, um ermitteln zu können oder besser gesagt, um messen zu können, was man schon erreicht hat.
Bewährtes in neuem Look
Ganz neu ist diese Erkenntnis allerdings nicht. Ins klassische Projektmanagement übertragen handelt es sich hierbei um „earned values“ oder auf Deutsch den „Fertigstellungsgrad“, ein Werkzeug des Projektcontrollings, um den Projektfortschritt zu verfolgen. Eine Bewertung des Projektfortschritts erfolgt in agilen Methoden wie Scrum am Ende jedes Sprints.
Die agile Grundannahme
Jeder Sprint stellt eine Investition dar und verfolgt das Ziel, dem erhofften Ergebnis einen Schritt näher zu kommen.
Abbildung 5 Die agile Grundannahme
Nach jedem Sprint soll in agilen Vorgehensmodellen überprüft werden, was tatsächlich erreicht wurde. Das so entstandene agile Artefakt ist „working software“. Unsichtbar und nur in der unbewussten Wahrnehmung der Beteiligten befindet sich die agile Grundannahme. Es wird grundsätzlich davon ausgegangen, dass Investitionen, die „funktionierende Software“ als Ergebnis haben, dauerhaft erhalten bleiben, weil Software, die einmal funktioniert, keinem „Verschleiß“ unterliegt. Einmal von der Wartung dieser Software abgesehen, ist das die agile Grundannahme.
Trifft das eigentlich zu?
Ob diese Grundannahme tatsächlich zutrifft, hängt nun im Wesentlichen von Ihrem Umfeld ab, in dem Sie sich bewegen. Ein Sprint wird in aller Regel zunächst in einer Entwicklungsumgebung entstehen. Ob in dieser Umgebung auch die Bewertung hinsichtlich „working software“ angestellt wird oder nicht, bestimmt maßgeblich, ob schon alle nötigen Investitionen getätigt sind oder nicht.
Tipps zu Working SoftwarePrüfen Sie, welche unausgesprochenen Annahmen in Ihrem Umfeld existieren und finden Sie einen transparenten Umgang damit.
Legen Sie es doch fest
Der Begriff „working software“ muss also für Ihre Verhältnisse definiert werden, damit jedem klar ist, was er bedeutet und was eben nicht. Ein Beispiel hierfür könnte sein:
Working software bedeutet für uns, dass das Produkt in der Entwicklungsumgebung installiert und benutzbar ist.
Will man das noch deutlicher formulieren, kann man auch beschreiben, was nicht unter „working software“ zu verstehen ist:
Working software hat bei uns die Eigenschaften, dass diese noch nicht auf einer „Staging-Umgebung“ (Test-, Integrations-, Referenz- oder Produktivumgebung) bereitgestellt wurde, noch nicht an den späteren Betreiber übergeben wurde und noch nicht mit einem Bestell- und Abrechnungsprozess versehen ist und damit noch keinen kommerziellen Beitrag zum Geschäftsergebnis liefern kann.
Weitere „working“ Aspekte
Abhängig von Ihrem Umfeld treffen hier weitere oder andere Aspekte zu. Sofern keine klare und von allen Beteiligten verstandene und akzeptierte Definition von „working software“ vorhanden ist, bewegen Sie sich auf höchst riskantem Boden.
Tipps zu Working SoftwareDefinieren Sie „working software“. Holen Sie in Ihrem Umfeld die Akzeptanz zur Definition von „working software“ ein und ergänzen Sie damit Ihre Definition of Done. Stimmen Sie zusätzliche Backlog-Einträge für „working software“ aus Entwicklungssicht mit dem Product Owner ab.
Extreme Programming
Der Begriff „working software“ wurde durch die agile Methode des Extreme Programming geprägt. Dort bedeutet er, dass eine Software voll integriert, getestet, zum Kunden ausgeliefert oder in der Produktionsumgebung installiert werden kann.
Abbildung 6 Extreme Programming
Das bedeutet aber nicht, dass diese Software fehlerfrei läuft und frei von Abstürzen ist. Es bedeutet nur, dass Unit Tests gemacht und grundlegende Qualitätssicherung betrieben wurden und man sich davon überzeugt hat, dass sie grundsätzlich läuft. Ob diese „extreme“ Festlegung eine für Ihre Verhältnisse adäquate Definition von „working software“ ist, müssen Sie für sich prüfen.
Mogeln ist verlockend
Viele Scrum Teams machen zusätzlich den Fehler, bei der Bewertung ihres Sprintergebnisses zu mogeln. Beispielsweise wird halbfertige Software, die z.B. mit technischen Schulden („technical debt“) belastet ist, als „working software“ deklariert, ohne dass eine User Story zur Beseitigung der technischen Schuld mit dem Product Owner vereinbart und in den Product Backlog eingestellt wird. Das ist dann so, als hätte das Team die technische Schuld unter den Teppich gekehrt.
Abbildung 7 Technical debt
Das führt dazu, dass das Management annimmt, dass etwas abgeschlossen ist und keine späteren Investitionen mehr benötigt, was real betrachtet nicht stimmt.
Transparenz gewinnt
Die Gründe dafür, dass die Software am Ende eines Sprints nicht wirklich fertig ist, sind vielschichtig, aber letztlich doch unerheblich. Entscheidend für alle Beteiligten ist, dass das Scrum Team am Ende jedes Sprints schonungslos transparent macht, was funktioniert und was nicht. Schönreden ist zwar verlockend, aber nicht die Lösung. Das holt einen später wieder ein.
Tipps zu Working SoftwareSorgen Sie für Transparenz bei der Bereitstellung von working software.
Typisch „working“
Auf dem Bild „Working Software“ ist eine typische, als „working“ deklarierte Software abgebildet. Diese wird von allen Seiten gestützt, ist zusammengeflickt, weist Lücken oder Löcher wie ein Schweizer Käse auf und passt an den Schnittstellen kaum zusammen. Wird dies nicht transparent gemacht, so löst dies eine Kettenreaktion aus.
Push oder Pull
Wie kommt es eigentlich in agil arbeitenden Teams dazu, dass etwas fertig wird? Der wesentliche Unterschied zur gängigen Arbeitsweise ist, dass Arbeit nicht „zugewiesen“ wird (Push-Prinzip). Es gibt niemanden, der den Teammitgliedern eine Aufgabe zuteilt. Vielmehr holen sich die Teammitglieder die Aufgaben aus dem Backlog, sobald sie dafür Kapazitäten zur Verfügung haben (Pull-Prinzip). Wann eine Aufgabe zur Bearbeitung ausgewählt wird, hängt damit vom individuellen Fortschritt der Teammitglieder und vom Fortschritt des ganzen Teams ab.
Abbildung 8 Push- oder Pull-Prinzip
Unfertiges vermeiden
Aus der traditionellen Fertigungsindustrie wissen wir, dass unfertige Produkte gebundenes Kapital darstellen. Daher ist jedes Fertigungsunternehmen bestrebt, den Bestand an nicht fertiggestellten Erzeugnissen möglichst gering zu halten. Ein anderes Beispiel wäre: Es soll eine Brücke über einen Fluss gebaut werden. Ungefähr zur Hälfte der Bauzeit beschließt das Team, mit dem Bau einer zweiten Brücke zu beginnen. Das führt dazu, dass der Bau an der ersten Brücke langsamer vorangeht und an der zweiten Brücke nicht mit voller Kraft gebaut werden kann. Die in die Brücken investierte Arbeit kann nicht dazu genutzt werden, den Fluss zu überqueren. Sie können sich vorstellen, was passiert, wenn Sie den Bau einer dritten Brücke parallel beginnen.
Übertragen auf die agile Softwareentwicklung bedeutet dies, dass eine angefangene Aufgabe Kapital bindet. Solange die Aufgabe nicht fertiggestellt wurde, kann die in die Aufgabe investierte Arbeit in keinen Nutzen umgewandelt werden. Der Nutzen hat hier natürlich zwei Aspekte. Zum einen ist der Nutzen gemeint, den potentielle Kunden aus dem fertiggestellten Produkt erzielen können, und zum anderen ist natürlich der potentielle Gewinn gemeint, der mit der Vermarktung des fertigstellten Produkts erzielt werden kann. Daher sind unfertige Tasks sozusagen eine „Verschwendung“. Je länger eine Aufgabe im Zustand „unfertig“ verbleibt, umso größer wird diese „Verschwendung“. Genau das ist mit dem agilen Begriff „waste“ gemeint.
Abbildung 9 Ständig neue Brücken bauen
Agile Teams sollen daher das Prinzip verfolgen, Aufgaben eher fertigzustellen, statt immer neue Aufgabe anzufangen. Das wird mit „start finishing – stop starting“ einprägsam auf den Punkt gebracht.
Work in Progress
Im vorigen Abschnitt wurde dargestellt, dass unfertige Tasks vermieden werden sollen, da unfertige Aufgaben Kapital binden. Ein Instrument agiler Methoden zur Vermeidung von „waste“ ist daher die Begrenzung der Anzahl gleichzeitig „in Bearbeitung“ befindlicher Aufgaben. Das bezeichnen die agilen Methoden mit „Limit Work in Progress (WiP)“. Rein wirtschaftlich betrachtet stellt eine Begrenzung der gleichzeitig in Arbeit befindlichen Tasks eine wirksame Maßnahme zur Begrenzung des gebundenen Kapitals dar. Für ein agiles Team bedeutet dies aber die Möglichkeit, sich auf die wesentlichen Dinge zu konzentrieren. Es ist nicht einfach, die wesentlichen Dinge zu identifizieren, daher sollte das Team sich darüber austauschen und zumindest die wesentlichen Aspekte in „working software“ verwandeln.
Tipps zu Working SoftwareSchaffen Sie ein Klima, in dem man wieder stolz auf seine Arbeit sein kann.
Das Dilemma aus Don‘t Waste und Don’t Debt
Ein Entwicklungsteam, das für produzierte Verschwendung und für produzierte technische Schuld gerügt wird, steckt in einem fast ausweglosen Dilemma. Das ist gleichbedeutend mit: Der Eimer, in dem normalerweise „waste“ landet, wird mit einem Schloss versehen und die technische Schuld muss vom Team daher unter den Teppich gekehrt werden. Da aber beides in der Natur der Softwareentwicklung begründet ist, muss ein offener Umgang mit diesem Dilemma gefunden werden, anstatt es totzuschweigen.
Abbildung 10 Don’t Waste und Don’t Dept
Sei stolz drauf
Ein wichtiger Gradmesser zur Bewertung von „working software“ darf an diese Stelle nicht unterschlagen werden. Das Entwicklungsteam weiß am besten, unter welchen Entbehrungen ein Inkrement entstanden ist. Wenn das Team stolz auf seine Arbeit sein kann, dann ist das ein starker Indikator für „working software“.