Ich habe gerade ein Buch von Michael Lopp gelesen, das mir ganz gut gefällt: “Managing Humans. Biting and humorous tales of a software engineering manager” (auf den Amazon Affiliate Link verzichte ich erstmal, hui, die Geldströme die ich hier verpasse). Das Buch liest sich ein bisschen wie eine Sammlung ausgedruckter Blogbeiträge, was es auch ist. Aber für eine Bahnfahrt ohne funktionierendes UMTS ok.
Ein Kapitel hat mir besonders gut gefallen.
Michael Lopp (auch Rands genannt) teilt die Arbeitswelt in zwei Gruppen: incrementalisits und completionists.
Die groben Eigenschaften:
Incrementalists sehen ein Problem, überlegen wie es am schnellsten gelöst werden kann, angesichts der verfügbaren Ressourcen, und legen los. Es geht darum schnell und effizient zu sein. Notfalls wird ein Pflaster über das Loch geklebt, wenn gerade kein Mörtel da ist. Incrementalists lieben es vor allem, Veränderungen zu initieren. Hauptsache es geht vorwärts!
Completionists denken gerne über Probleme nach. Tritt ein Problem auf, wird das Problem erst analysiert, strukturiert und zerteilt. Dann wird das Problem abstrahiert und eine Lösung gefunden, die dieses Problem für immer lösen wird. Erst wenn die Lösung perfekt ist, wird sie auch umgesetzt.
Auf der Arbeit kommen Incrementalists häufig sehr aktiv rüber. Sie denken, diskutieren und brainstormen. Completionists sitzen eher da und denken nach. Wenn man sie auffordert eine Antwort zu geben, kommt erstmal nichts, weil das Problem noch nicht zu Ende durchdacht wurde. Wenn die Antwort dann kommt, dann sitzt die auch.
Als Leiter eines Teams braucht man sowohl Incrementalists wie auch Completionists. Wer die Überhand hat, muss je nach Projektphase entschieden werden. Die Completionists bauen Architekturen und Frameworks, die Incrementalists die Funktionen und die schnellen Lösungen, die man auch braucht.
Ich denke insbesondere am Anfang ist die Phase der Completionists. Ruhig über das Gesamte nachdenken, sich auf ein generalisiertes Vorgehen einigen, Strukturen besprechen. Irgendwann (wenn der release date näher kommt) muss es dann aber schnell gehen. Dann rücken eher die Incrementalists in den Vordergrund und die Completionists müssen leiden, weil dann einfach mal gebaut wird.
Mir hat es geholfen, mal drüber nachzudenken wer in meinem Team eher Incrementalist und wer eher Completionist ist. Das beeinflusst auch die Kommunikationsformen und die Herangehensweise an Probleme. Ich denke im IT-Bereich ist die Teilung in Is & Cs stärker als in anderen Bereichen, weil Probleme so unterschiedlich angegangen werden können. Es ist in keinem anderen Bereich möglich, entweder so abstrakt und starr zu denken, oder aber einfach ad-hoc los zu programmieren. Wobei beide Ansätze definitiv Vor- und Nachteile haben und die Lösung wie so oft in der Mitte liegen muss.
Und hier für interessierte nochmal die Originalquelle im Blog: Incrementalists & Completionists. Ganz gut ist auch die persönliche Einschätzung von Wayne Allen.
Gute und nachvollziehbare Unterteilung - auch in Anbetracht der Notwendigkeit in verschiedenen Projektphasen die jeweils andere Gruppe im Vordergrund zu benötigen.
In der Originalquelle gefällt mir diese Feststellung: “As an aside, let me say that email is never ever ever never ever the right way to resolve controversy” - wie wahr, wie wahr.
Adam
August 15th, 2007
hier ein kleines Beispiel von einem Incrementalist wie man sein Team testen kann
public testDev(Developer dev) {
delta=dev.cnt_commits/dev.cnt_files)
if (delta > 0 ) {
return Incrementalist;
}
else {
return Completionist;
}
}
diez
August 15th, 2007
[…] Tech schreibt über die zwei vorherrschenden Entwicklerarten: incrementalists und completionists, eine Klassifizierung, die sehr interessant und einleuchtend […]
incrementalists oder completionists » Code Candies
August 16th, 2007
@diez: wenn du zeitlang keine commits machst, wirst du dadurch noch kein Cs
wedro
Dezember 9th, 2007