Kategorien
Starte leichgewichtig
Ich bin ein Freund von Regeln … wobei … ich bin ein Freund von sinnvollen Regeln. Von mir auch könnte es in PHP auch mehr Einschränkungen geben, was die Sprache angeht. Aber eigentlich will ich heute gar nichts übers Programmieren reden, sondern um das ganze drumherum: den Prozessen.
Ich bin gerade dabei an den Prozessen für ein wichtiges Projekt zu basteln. Dabei wurde so ziemlich alles durchdacht, jedes mögliche Problem wurde kurz durchgesprochen und der Prozess so definiert, dass er alles abdeckt. Natürlich ist das ganze nicht mehr so leicht handhabbar. Ist ja klar, er ist ja schließlich die eierlegende Wollmilchsau. Wenn dieses Projekt zu Ende ist, wird das was ganz tolles rauskommen. Wahrscheinlich sollte ich besser sagen, falls das Projekt zu Ende geht, denn der Prozess war so schwer, dass damit kaum jemand frei atmen, geschweige denn arbeiten konnte.
Man kann also nicht nur Produkte nach Wasserfall bauen, sondern auch Prozesse. Das gute daran ist, dass die Lösung für Produkte die gleiche ist, wie für Prozesse. Wir arbeiten iterativ und fangen mit einem „leeren“ Prozess an. Nehmen wir zum Beispiel den Entwicklungsprozess. Leer würde hier bedeuten:
- Anforderung kommt rein.
- Feature wird implementiert.
- Feature wird abgenommen.
Klar muss aber sein, dass dies schon ein Prozess ist, an den man sich halten muss. Am Ende der Iteration wird dann geschaut, ob irgendwelche Probleme aufgetaucht sind. Wenn nicht, super, dann haben wir unseren Prozess. Falls zum Beispiel die Codequalität schlecht ist, dann instanziieren wir im nächsten Schritt Code-Reviews. Führen also zwischen Implementierung und Abnahme noch mal einen Punkt ein. So kann man sich sicher sein, immer den möglichst einfachen Prozess zu haben, der einen wirklich nur unterstützt und keinen unnötigen Overhead produziert.
Wahrscheinlich denken jetzt einige: „Oh alter Hut, so macht das doch jeder, der Scrum und Co. macht“. Joa das hatte ich auch gedacht, aber sogar unser offizieller Scrum-Coach von damals wollte in den Entwicklungsprozess schon Dinge einbringen, die er für nötig hielt, aber nachweislich gar keinen Effekt auf das Projekt hatten.
Man braucht auf jeden Fall Strukturen Arbeit in gleichbleibender Qualität zu liefern und diese dann auch immer wieder zu messen. Und ich denke hier ist dann die Iteration: Arbeit liefern, Review und Retrospektive was verbessert werden muss im Prozess. So nähert man sich dem für das Projekt idealen, von allen Teammotgliedern akzeptierten und funktionierenden Entwicklungsprozess.
Schöne Idee auch an der Stelle iterativ zu arbeiten.
Genau so wird das bei uns auf der Arbeit gehandhabt mit Scrum und passen dann nach und nach den Prozess an. Wichtig finde ich in dem Zusammenhang, zuerst das möglichst einfachste in den Prozess mit aufzunehmen und nicht zu versuchen, die perfekte Lösung sofort versuchen herauszuarbeiten. So kann man sich iterativ dem nähern, was für alle am Besten ist und nicht plötzlich alles auf den Kopf stellt.
Ein interessanter und durchaus oft versuchter Ansatz. Erst einmal auf das Wichtigste konzentrieren und die anderen Themen angehen, wenn sie nötig werden.
„Wir überqueren den Fluss, wenn wir da sind“ ist in dem Fall die Losung.
Das Problem ist, wenn man dann zum Fluss gelangt ist da nicht so sehr eine geordnete Überfahrt, mehr so ein ungeordnetes Chaos. Die einen nehme die Fähre („ich finde Schiffe toll“), die anderen laufen über die Brücke („ich hasse Wasser“) und wieder andere schwimmen durch („ich brauche keine Tools ich mache alles selber“). Ohne Vorstellung und Idee wie man gemeinsam an einem Projekt arbeiten möchte und ohne gemeinsamen Nenner, dass man auch gemeinsam arbeiten kann, wird es schwierig Herausforderungen, die mit Sicherheit im Laufe eines komplexen Projektes in Erscheinung treten, zu meistern. Man muss nicht alles im Vorfeld implementieren und bis in das kleinste Detail beschreiben mit welchen Mitteln man Prozesschritte realsieren möchte, aber für die Schritte sollte es ein gemeinsames Verständnis geben (eben einen Prozess).
in Anlehnung an „Empowering a QA Culture“
@Martin: Ich hätte vielleicht nicht sagen sollen, dass wir mit einem „leeren Prozess“ beginnen. Es sollte der minimale Prozess sein. Dann können auch alle im Boot sitzen.