Kategorien
Das Core-Team
Heute möchte ich mal eine Organisationsform vorstellen, die ich in der Webentwicklung so noch nie erlebt habe. In der IT allgemein ist sie aber häufig zu finden. Es geht um ein Kern-Team, einem Team, dass sich um allgemeine Funktionalitäten kümmert.
Natürlich gibt es diese Idee in verschiedenen Ausprägungen. Ich möchte heute mal das Kern-Team als Art Basis-Bibliotheken-Team sehen. Nehmen wir als an, wir bauen ein spezielles Feature für die Webseite von web.de (keine Ahnung, wie ich gerade auf die komme). Dafür müssen wir sehr viel mit URLs hantieren. URLs sind Bestandteil der Kern-Bibliothek, wir sprechen also das Kern-Team an und spezifizieren unsere Anforderungen an die neuen URL-Klassen. Wenige Zeit später bekommt das umsetzende Team eine Bibliothek, die URL-Unterstützung mitbringt.
Der Vorteil liegt klar auf der Hand. Wir haben genau ein Team, dass sich um spezielle Grundfunktionalitäten kümmert. Redundante Implementierungen werden so minimiert oder ganz verhindert. Weiterhin kann man sich auf die wirkliche Businesslogik konzentrieren und muss sich nicht mit „Nebensächlichkeiten“ rumschlagen. Nachteile findet man auch. So muss man nun einfache Features gesondert spezifizieren und das kostet Zeit. Spaß muss es auch nicht jedem Entwickler machen.
Leider habe ich dieses Vorgehen im PHP-Umfeld noch nicht miterlebt. Vielleicht kann von euch jemand seine Erfahrungen, falls vorhanden, schildern. Gerne auch negative. Falls die Organisationsform so klappen sollte, kann man das Vorgehen ja noch ein wenig weiter spinnen. Das Kern-Team, falls es sich nur um wirklich allgemeine, nicht businessspezifischen Funktionalitäten, so kann hier Outsourcing funktionieren. Ich hätte zumindest Spaß daran solche Probleme zu lösen.
ist das nicht immer so? ich hab es bisher nicht anders erlebt…nur das meistens die basis klassen so allgemein sind, dass du sie fuer deine speziellen zwecke ableiten musst und eigene kleine sachen dazuschreiben…sollten die sich lohnen aufgenommen zu werden, werden sie in den basis source gepatched. bzw, die algorithmik verbessert.
wobei das core-team eigentlich wenig zu tun hat…es hat am anfang sehr viel zu machen, und laesst dann nach und ist nur noch patchen und verbessern…
wir haben unsere projekte immer so aufgeteilt 🙂 sogar noch einmal die core-klassen untereinander geteilt…und hat immer prima funktioniert.
spannender in der hinsicht team finde ich: pair-programming, das hab ich bisher im php bereich nicht gesehen…
@nuit: Also Pair-Programing machen wir hier sehr viel. Da kann ich ja dann mal drüber berichten.
Ich behaupte einfach mal, dass man eine solche Konstellation in jedem Unternehmen findet, welches neben dem Tagesgeschäft auch ein eigenes CMS-System entwickelt. So kenne ich es zumindest von meinen bisherigen Arbeitgebern, wenn auch das Core-Team nur aus wenigen Leuten besteht.
Ja, grade auch eines der Themen mit denen ich mich beschäftige. EIn Kernteam kann auch Funktionen übernehmen die nicht weiterentwickelt, sondern nur noch gefixt und versionsgeupgraded werden.
Evtl trifft man sich ja mal irgendwann, nettes Thema.
Ich kenne es durchaus umgekehrt: Das es ein „Operations“ Team gibt, das sich schief hängende Buttons und „dringende Kundenanforderungen“ kümmert, so daß das Entwicklungsteam dadurch nicht aus dem Tritt gebracht wird.
Core-Team wie du es beschreibst, kenne ich gar nicht. Nach deiner Beschreibung klingt es mir so, als sei das Core-Team weit vom Schuss entfernt…
Wenn ich diesen Aspekt rauslasse, erkenne ich hier das „OWNER files“-Modell, siehe http://www.chromium.org/developers/owners-files-1
Die Idee gefällt mir sehr gut. Denn wer kennt es nicht: Man hat eine Vision was eine Komponente leisten soll. Man stellt sich Fragen was genau sie kann und was genau nicht. Manchmal spielt auch noch die konkrete Implementierung eine Rolle – es gibt zwar oft viele Wege, aber manchmal doch nur einen…
Wenn es dann so einen Guru gibt, der alles über so eine Komponente weiß, den Weg der Design-Entscheidungen kennt… sehr hilfreich.
Da redest du aber über nicht viel Neues.
Grundsätzlich spielt das in die Richtung des Product Family Engineering. Engineering deshalb, weil Core-Komponenten geplant und verwaltet werden müssen/sollten.
Im Normalfall gibt es sogar drei Teams – was in größeren Firmen durchaus Sinn macht. Wir reden von „Core“, „Product“ und „Project“. Und im Engineering-Aspekt reden wir über die Anforderungen, wann ein Projekt-Feature in das Grundprodukt und wann ein Feature aus dem Grundprodukt in den Core wandert – oder umgekehrt.
Beispiel: Die Eclipse-Plattform ist ein Core-Element. Die Eclipse-IDE ist ein auf der Eclipse-Plattform basierendes Produkt. Das PDT für Eclipse ist ein Projekt, welches auf der Eclipse-IDE basiert.
Oder auch: Webkit als Engine ist ein Core-Element, Chrome und Safari (die auf Webkit basieren) sind Produkte und Safari für ein mobiles Endgerät ist ein Projekt.
Letztes Beispiel. In Eurer Firma könnte das heißen: ihr eine Basisplattform, auf der alle Produkte basieren und die euch u.a. Deployment und Testing liefert. Darauf aufbauend bietet ihr verschiedene Produkte, wie zum Beispiel Webshops und CMS an. Der spezielle Webshop für den Kunden X wäre dann ein konkretes Projekt.
Hier sieht man sehr deutlich die Dreiteilung der Entwicklungsteams.
Ausgeliefert wird immer das Projekt. Es ist logisch, dass die Qualität im Kern am Höchsten sein muss. Geht dort etwas schief, dann leiden alle. Dort sammelt man auch die besten Entwickler. Währenddessen kann man die Pflege der Produkte einer Mischung aus erfahrenen und Juniorentwicklern überlassen. Agile Einsatzteams kümmern sich derweil um die Projektrealisierung.
Die Teamzusammensetzung und Teamgröße verändert sich ebenfalls vom Kern zum Projekt: das Projektteam ist dynamischer besetzt, hat mehr Frontendentwickler und mehr Generalisten. Das Kernteam hat mehr Spezialisten.
Setzt man in einer solchen Struktur Scrum oder XP sein, so sind die Entwicklungszyklen im Kern länger – in den Projekten kürzer. Ich habe mal eine Einführung dazu geschrieben. Interessantes Thema.
Manche Firmen haben zusätzlich Rapid-Response-Teams – muss man aber nicht unbedingt. Man kann das durch geschickte Planung auch über Zeitkontingente abfangen. Rapid-Response lohnt sich erst ab einer gewissen Anzahl laufender Kundenprojekte und die Mitglieder sollten immer rotieren, da die Arbeit im RR-Team eine starke persönliche Belastung darstellt.
In Summe ist Product Family Engineering wieder ein Management-Framework für die Softwareentwicklung. Man kann Teile, oder alles daraus umsetzen und an den Bedarf der Firma anpassen. Es hat den großen Vorteil, dass es erlaubt, Wiederverwendung planbar zu machen.
So wie Scrum einen kontinuierlichen Verbesserungsprozess für personelle Organisationsmethoden bietet, bildet PFE das gleiche für technische Methoden. Und natürlich lassen sich beide Ansätze auch wunderbar kombinieren. Tut man das, kommt man schnell zur Matrixorganisation – aber das führt jetzt alles viel zu weit.
Jedenfalls habe ich deshalb die Unterstützung dieser Teamaufteilung und Methoden auch von Anfang an in meine Tools integriert. Ich wollte schon lange mal einen Vortrag dazu halten, hatte aber noch keine Gelegenheit dazu.