Steve Alexander hat über die Entwicklungsmethoden berichtet, die für Launchpad und Bazaar benutzt werden. Steve und ich haben lustige handgeschrieben Folien gebaut, die wir abfotografiert haben.
Eins der Hauptprobleme mit denen man sich in der Entwicklung bei Canonical, speziell bei den Launchpad- und Bazaar-Teams, beschäftigt ist die Frage wie man "Corporate-Style Development" mit einem völlig verteilten Team unter einen Hut bekommt.
Der von Canonical verfolgte Ansatz lautet dabei: aus Methoden von agilen Prozessen und der Community-getriebenen Open-Source-Entwicklung ein Emulgat zu erzeugen, das sie "Community Agile" nennen.
Um diese Prozessentwicklung intern fortlaufend zu gestalten, verwendet Canonical ebenfalls Elemente des "LEAN"-Prozesses. Dieser stammt ursprünglich aus der Autoproduktion von Toyota und und dem Kaizen: der kontinuierlichen Verbesserung von Produkten, der Organisation und der Prozesse.
Werte
Die konkrete Ausgestaltung der Prozesse berücksichtigt einige feste Elemente, die Canonical als "Werte" bezeichnet. Diese Werte werden mit den Werten "klassischer" agiler Entwicklung kontrastiert dargestellt und beruhen auf den eigenen Erfahrungen:
Wissen und Motivation über Co-Lokation
Canonical möchte die besten Leute zusammenbringen und hat die Erfahrung gemacht, dass es produktiver ist die besten Leute miteinander über große Entfernungen arbeiten zu lassen, statt darauf zu bestehen, dass alle vor Ort arbeiten und dabei weniger gute Entwickler im Team zu haben.
Patches integrieren über Sprintplanung
Canonical entwickelt die meisten Produkte gezielt als Open-Source. Dadurch kommt es zu Code-Spenden, die nicht unbedingt in die eigene Planung passen. Um das Gesamtprodukt für so viele Anwender wie möglich interessant zu machen ist man bestrebt Patches so schnell wie möglich in die Hauptlinie des Codes zu überführen.
Gemeinschaft über In-House-Entwicklung
Software profitiert in verschiedenen Aspekten davon, wenn sich um Sie eine Gemeinschaft bildet, die sie aktiv benutzt, erweitert und entwickelt. Dazu ist es nicht immer notwendig, dass die eigene Software Open-Source ist - extensive Schnittstellen und Plugin-Systeme helfen einer Community ebenfalls, sich zu etablieren und zur Entwicklung einer Software beizutragen.
Im Vergleich zur agilen Entwicklung ist dies eigentlich eine konsequente Fortführung des Kunde-vor-Ort-Prinzips.
Hochwertige Builds
Ebenfalls ein aus der agilen Entwicklung fortgeschriebener Ansatz: Hochwertige Releases.
Selbst bei zusammensitzenden Teams ist defekter Code problematisch. Wenn sich bei stark verteilten Teams ein Fehler einschleicht, kann dieser aufgrund der Zeitunterschiede schnell gesamte Arbeitstage vernichten, während man auf die Fehlerbehebung wartet. Daher müssen alle Tests nach jedem Checkin laufen. Und eigentlich ist man dann sowieso in der Lage nach jedem Checkin ein hochwertiges Release.
LEAN
Eine weite Frage bei LEAN ist auch, wie viel Arbeit verschwendet wird, um vom Beginn der Implementation eines Features zum Kunden zu kommen?
Mit LEAN versucht man hohe Entwicklungsgeschwindigkeit zu erreichen, um Funktionen so schnell wie möglich zum Kunden zu bringen, denn solange eine Funktion in Arbeit ist, verursacht sie nur Kosten: die Spezifikationen können sich ändern, es erfordert Aufmerksamkeit der Entwickler, es fehlt dem Kunden. Je länger dieser Zustand dauert, desto teurer wird die Funktion am Ende.
Ebenfalls ist es Verschwendung, wenn eine Funktion einmal bereitgestellt wurde, und wieder in die Entwicklung muss. Beispielsweise aufgrund fehlender Qualitätssicherung oder zu großer Arbeitspakete.
Canonical versucht Verschwendung durch einige Methoden zu reduzieren:
Feste Release-Zyklen
Launchpad hat einen Release-Zyklus von einem Monat, bei einem Planungshorizont von 4 Monaten. Ubuntu hat einen Release-Zyklus von 6 Monaten. Dadurch wird es einfacher für die verschiedenen Unternehmensbereiche (Marketing, Testing, Entwicklung) miteinander zu kommunizieren.
Gleichmäßige Arbeitsbelastung
Gegenbeispiel: Wenn man einfach nur einen 1-Monatszyklusansetzt, passiert in der dritten Woche folgendes: Qualitätssicherung muss passieren. Dadurch versucht jeder seinen Code noch irgendwie ins Release zu bekommen, was für erhöhten Stress in dieser Woche führt (eigenen Code schreiben, Tests schreiben, anderer Leute Code reviewen, ...).
Um dies zu umgehen, hat Canonical jeden Code-Reviewer einen Tag in der Woche auf Bereitschaft (jeweils an verschiedenen Tagen). Dadurch kann jeder Programmierer den bereitstehenden Reviewer sofort ansprechen und muss nicht auf die Qualitätssicherung in der dritten Woche warten. Durch synchrone Kommunikation (IRC, Voip) wird hier ebenfalls Verschwendung vermieden, da sowohl Reviewer als auch Entwickler Code und Konzepte gerade im Kopf haben und nicht "swappen" müssen.
Weiterhin werden die Arbeitspakete bewußt kleingehalten: jeder Patch darf maximal 500 Zeilen inklusive Diff-Kontext sein. Ist er größer muss er in mehrere kleinere Einheiten zerteilt werden.
Zum Schluss werden Änderungen so schnell wie möglich auf den Trunk gespielt um erneute Konflikte zu und damit Verschwendung zu vermeiden.
Weiterführendes
Steve hat außerdem auf ein Paper von Ian Clatworthy hingewiesen, in dem die Gedanken zur Community-getriebenen Entwicklung noch einmal vertieft dargestellt werden.
Eins der Hauptprobleme mit denen man sich in der Entwicklung bei Canonical, speziell bei den Launchpad- und Bazaar-Teams, beschäftigt ist die Frage wie man "Corporate-Style Development" mit einem völlig verteilten Team unter einen Hut bekommt.Der von Canonical verfolgte Ansatz lautet dabei: aus Methoden von agilen Prozessen und der Community-getriebenen Open-Source-Entwicklung ein Emulgat zu erzeugen, das sie "Community Agile" nennen.
Um diese Prozessentwicklung intern fortlaufend zu gestalten, verwendet Canonical ebenfalls Elemente des "LEAN"-Prozesses. Dieser stammt ursprünglich aus der Autoproduktion von Toyota und und dem Kaizen: der kontinuierlichen Verbesserung von Produkten, der Organisation und der Prozesse.
Werte
Die konkrete Ausgestaltung der Prozesse berücksichtigt einige feste Elemente, die Canonical als "Werte" bezeichnet. Diese Werte werden mit den Werten "klassischer" agiler Entwicklung kontrastiert dargestellt und beruhen auf den eigenen Erfahrungen:
Wissen und Motivation über Co-Lokation
Canonical möchte die besten Leute zusammenbringen und hat die Erfahrung gemacht, dass es produktiver ist die besten Leute miteinander über große Entfernungen arbeiten zu lassen, statt darauf zu bestehen, dass alle vor Ort arbeiten und dabei weniger gute Entwickler im Team zu haben.
Patches integrieren über Sprintplanung
Canonical entwickelt die meisten Produkte gezielt als Open-Source. Dadurch kommt es zu Code-Spenden, die nicht unbedingt in die eigene Planung passen. Um das Gesamtprodukt für so viele Anwender wie möglich interessant zu machen ist man bestrebt Patches so schnell wie möglich in die Hauptlinie des Codes zu überführen.
Gemeinschaft über In-House-Entwicklung
Software profitiert in verschiedenen Aspekten davon, wenn sich um Sie eine Gemeinschaft bildet, die sie aktiv benutzt, erweitert und entwickelt. Dazu ist es nicht immer notwendig, dass die eigene Software Open-Source ist - extensive Schnittstellen und Plugin-Systeme helfen einer Community ebenfalls, sich zu etablieren und zur Entwicklung einer Software beizutragen.
Im Vergleich zur agilen Entwicklung ist dies eigentlich eine konsequente Fortführung des Kunde-vor-Ort-Prinzips.
Hochwertige Builds
Ebenfalls ein aus der agilen Entwicklung fortgeschriebener Ansatz: Hochwertige Releases.
Selbst bei zusammensitzenden Teams ist defekter Code problematisch. Wenn sich bei stark verteilten Teams ein Fehler einschleicht, kann dieser aufgrund der Zeitunterschiede schnell gesamte Arbeitstage vernichten, während man auf die Fehlerbehebung wartet. Daher müssen alle Tests nach jedem Checkin laufen. Und eigentlich ist man dann sowieso in der Lage nach jedem Checkin ein hochwertiges Release.
LEAN
Eine weite Frage bei LEAN ist auch, wie viel Arbeit verschwendet wird, um vom Beginn der Implementation eines Features zum Kunden zu kommen?
Mit LEAN versucht man hohe Entwicklungsgeschwindigkeit zu erreichen, um Funktionen so schnell wie möglich zum Kunden zu bringen, denn solange eine Funktion in Arbeit ist, verursacht sie nur Kosten: die Spezifikationen können sich ändern, es erfordert Aufmerksamkeit der Entwickler, es fehlt dem Kunden. Je länger dieser Zustand dauert, desto teurer wird die Funktion am Ende.
Ebenfalls ist es Verschwendung, wenn eine Funktion einmal bereitgestellt wurde, und wieder in die Entwicklung muss. Beispielsweise aufgrund fehlender Qualitätssicherung oder zu großer Arbeitspakete.
Canonical versucht Verschwendung durch einige Methoden zu reduzieren:
Feste Release-Zyklen
Launchpad hat einen Release-Zyklus von einem Monat, bei einem Planungshorizont von 4 Monaten. Ubuntu hat einen Release-Zyklus von 6 Monaten. Dadurch wird es einfacher für die verschiedenen Unternehmensbereiche (Marketing, Testing, Entwicklung) miteinander zu kommunizieren.
Gleichmäßige Arbeitsbelastung
Gegenbeispiel: Wenn man einfach nur einen 1-Monatszyklusansetzt, passiert in der dritten Woche folgendes: Qualitätssicherung muss passieren. Dadurch versucht jeder seinen Code noch irgendwie ins Release zu bekommen, was für erhöhten Stress in dieser Woche führt (eigenen Code schreiben, Tests schreiben, anderer Leute Code reviewen, ...).
Um dies zu umgehen, hat Canonical jeden Code-Reviewer einen Tag in der Woche auf Bereitschaft (jeweils an verschiedenen Tagen). Dadurch kann jeder Programmierer den bereitstehenden Reviewer sofort ansprechen und muss nicht auf die Qualitätssicherung in der dritten Woche warten. Durch synchrone Kommunikation (IRC, Voip) wird hier ebenfalls Verschwendung vermieden, da sowohl Reviewer als auch Entwickler Code und Konzepte gerade im Kopf haben und nicht "swappen" müssen.
Weiterhin werden die Arbeitspakete bewußt kleingehalten: jeder Patch darf maximal 500 Zeilen inklusive Diff-Kontext sein. Ist er größer muss er in mehrere kleinere Einheiten zerteilt werden.
Zum Schluss werden Änderungen so schnell wie möglich auf den Trunk gespielt um erneute Konflikte zu und damit Verschwendung zu vermeiden.
Weiterführendes
Steve hat außerdem auf ein Paper von Ian Clatworthy hingewiesen, in dem die Gedanken zur Community-getriebenen Entwicklung noch einmal vertieft dargestellt werden.
Keine Kommentare:
Kommentar veröffentlichen