Ilker hat eine interessante Aussage auf Twitter getätigt, die eine kleinere Diskussion ausgelöst hat. Da meine Meinung zu diesem Thema allerdings nicht auf 140 Zeichen transportiert werden kann, möchte ich diese etwas ausführlicher beschreiben.
Many software developers are too strict about requirements to the software and too loose about programmed code for the software.
— Ilker Cetinkaya (@ilkerde) July 24, 2013
Auf die Nachfrage, was er denn genau mit “too strict about requirements” meint, kam diese Antwort:
@norberteder I mean the level of detail and certainty for a requirement. Many developers are asking for too many specifications.
— Ilker Cetinkaya (@ilkerde) July 24, 2013
Ok, Entwickler wollen also ein Zuviel an Spezifikationen. Sicher?
Ich denke, dass man hier keine Verallgemeinerung treffen kann. Aus meiner Erfahrung kann das von Ilker angesprochene Problem sowohl beim Entwickler selbst, aber auch an der Spezifikation liegen.
Entwickler
Immer wieder beharrt der eine oder andere auf die begriffliche Trennung zwischen Programmierer und Entwickler. Ersterer braucht strikte Vorgaben, die er abarbeitet. Zweiterer zeichnet sich durch Selbständigkeit und Verständnis für das Business aus. Da treffen sich also unterschiedliche Herangehensweisen, die auch auf das Verständnis (ob nun tatsächlich oder gewollt) von Spezifikationen Auswirkung zeigen.
Der “Programmierer” braucht Details. Lücken zu füllen, das WIE der Spezifikation (also die eigentliche Umsetzung) zu formulieren ist nicht sein Thema und damit möchte er sich auch nicht wirklich beschäftigen. Er braucht also detaillierte Spezifikationen an Hand derer eine Implementierung stattfinden kann.
Der “Entwickler” ist freiheitsliebender. Er möchte wissen, worum es geht, was das Ziel ist und um “den Rest” kümmert er sich selbständig. Hierfür braucht es keine detailgetreue Spezifikation. Wunsch und Mehrwert (grob gesagt) sind ausreichend.
In der Realität findet sich dann auch noch eine Mischform zwischen Entwickler und Projektmanager. Sie wollen zwar Softwareentwickeln, aber auch Spezifikationen schreiben, oder zumindest an diesem Prozess beteiligt sein. Das ist eine gefährliche Kombination, da die Gefahr besteht, dass beides in der täglichen Arbeit vernachlässigt wird.
Die meisten Teams sind in ihrer Gesamtheit nicht vollständig einer dieser “Gruppen” zuordenbar, vielmehr besteht entweder eine gute Mischung oder aber es befindet sich erst gar kein “Programmierer” darin. In diesen Fällen sehe ich die Ursache für das durch Ilker beschriebene Problem zu großen Teilen in den Spezifikationen.
Spezifikation
Eigentlich müsste an dieser Stelle der Ursprung der Spezifikation näher betrachtet werden, bzw. in welchem Umfeld das Unternehmen, das Team, das Projekt zum Zuge kommt. Ich möchte jedoch im Allgemeinen auf diese Thematik eingehen.
Ich habe in meiner bisherigen Laufbahn in vielen Unternehmen unterschiedlicher Branchen gearbeitet und mit zahlreichen anderen Projekte durchgeführt. Dadurch hat man zwangsweise mit unterschiedlichen Charakteren, Arbeitsweisen, Anschauungen und Prozessen zu tun. Großteils soll das Resultat immer dasselbe sein – ein funktionierendes Produkt zur Arbeitserleichterung (gut, manche müssen ein Projekt durchführen, torpedieren es jedoch, da sie davon nicht überzeugt sind – diesen Fall lasse ich hier mal aus). Der Weg dorthin unterscheidet sich jedoch immer, eben durch die verschiedenen Rahmenbedingungen.
Es gibt allerdings noch einen Punkt, der fast überall gleich ist: Man weiß was man ungefähr will, aber so wirklich dann doch auch nicht. So nach dem Motto: Ich möchte ein Auto. Ich weiß allerdings noch nicht welche Marke, welche Farbe und über die genaue Ausstattung habe ich mir auch noch keine Gedanken gemacht.
Diese vagen Informationen werden nun in ein Dokument (oder in viele davon) gegossen und dem Entwicklungsteam vorgestellt. D.h. die Informationen kommen nicht tröpfchenweise, sondern auf einmal. Behält man nun im Hinterkopf, dass der Kunde ja selbst nicht genau weiß, was er möchte, kann ein Vorurteil bezüglich der Qualität der “Spezifikation” getroffen werden. Es fehlt an allen Ecken und Enden an “fertig gedachten Funktionalitäten”. Es tun sich also Fragen auf, denn diese Lücken müssen geschlossen werden, um die Anforderung vollständig verstehen zu können. Der Schrei nach mehr Spezifikation. Warum?
- Gerade bei zahlreichen Dokumenten (die vielleicht zusätzlich von unterschiedlichen Personen verfasst wurden) finden sich an allen Ecken und Enden Inkonsistenzen. Diese müssen ausgeräumt werden. Wiedersprüche lassen sich schwerlich umsetzen.
- Gesamtspezifikationen neigen dazu, oberflächlich sehr gut zu beschreiben, in den Detailfragen jedoch sehr zurückhaltend zu sein. Es entstehen massive Lücken, die es zu klären gilt.
- Schlussendlich sind auch häufig Wünsche enthalten, die sich so nicht umsetzen lassen, aus unterschiedlichsten Gründen.
Wer wirklich möchte, wird aus seiner Erfahrung noch den einen oder anderen Punkt hinzufügen können. Die Diskussionen sind jedoch zahlreich und Stundenfresser.
Man mag geneigt sein, mit der “agilen Keule” zu argumentieren, damit könnte man ja diese Probleme in den Griff bekommen. Ja, man könnte. Die Realität sieht aber meist anders aus. Großteils auf Grund mangelndem Vertrauen, Interessenskonflikten, das schnelle Geld oder wie die “Rechtfertigungen” sonst noch benannt werden können.
Ein weiteres Problem besteht darin, dass viele Spezifikationen nicht nur beschreiben WAS umgesetzt werden soll, sondern auch WIE es zu funktionieren hat. Das mag in einigen Fällen sinnvoll sein, beispielsweise wenn Prozesse eines Unternehmens abzubilden sind. Das mag wenig sinnvoll sein, wenn es um Abläufe innerhalb der Software (nennen wie es mal Usability) geht und die Erfahrungen des Spezifikationsschreibers auf Word und Excel beschränkt ist. Noch schlimmer: Eine Uralt-Applikation aus den späten 90ern soll abgelöst werden und der damalige Usability-Stand (also gar keiner) spiegelt sich in der Spezifikation wider.
Vielfach bringt das Entwicklungsteam in derartigen Fällen Vorschläge ein. Je nach Projektmanager werden diese an den Kunden weitergeleitet und diskutiert. Oftmals aber auch nicht. Oftmals kann er aber auch – teilweise durch fehlendes Verständnis seinerseits – den Kunden nicht überzeugen. Was bleibt ist Frust in der Entwicklerschar, denn man hätte es ja weit besser lösen können (das bedeutet nicht automatisch, dass der Aufwand höher wäre).
Zusammenfassend muss sich der Entwickler als mit folgenden Dingen beschäftigen:
- Unvollständigen Wünschen
- Inkonsistenzen
- Kein klarer Plan
- Nicht angenommenen Verbesserungsvorschlägen
Nun behaupte ich einmal, dass es viele Entwickler gibt, die ihre Arbeit nicht einfach nur des Verdienens wegen tun, sondern um tolle, coole und vor allem hilfreiche Lösungen zu schaffen. Läuft es wie beschrieben, ist der Frustfaktor groß und es stellt sich die Frage, warum sich der Entwickler – wenn er mit derart unfertigen Vorgaben konfrontiert wird – überhaupt Gedanken über Codequalität und Co. machen sollte. Gut, eine Argumentationslinie könnte Professionalität sein. Kann man die nicht auch von den “Vorarbeitern” erwarten? Jeder engagierte Softwareentwickler gibt sein Bestes und hakt daher auch bei schlechten Spezifikationen ein, obwohl es seine Aufgabe eigentlich nicht ist.
Soll der Entwickler seien Job bestmöglich machen, müssen die Arbeitsbedingungen passen. Eine der wichtigsten ist die erhaltene “Arbeitsanweisung”. Ist diese möglichst kurz, prägnant und beschreibt den gewünschten Mehrwert, kann er seiner Aufgabe nachkommen, eine passende Lösung finden und sich um eine hochwertige Umsetzung bemühen.
Unter Anbetracht der aufgeführten Problemstellen ist die Aussage von Ilker für eben nur teilweise richtig. Um dies wirklich bewerten zu können, muss man das Umfeld und die Einflüsse kennen. Wie sehr kann sich ein Entwickler auf seine tatsächliche Aufgabe kümmern? Welche weiteren Aufgaben besitzt er? Muss er sich in die Konzeptionsphase involvieren oder bekommt er von seinem Projektmanager, dem Product Owner oder wie sie alle heißen mögen, das was er braucht um “funktionieren” zu können. Bekommt er dies nicht, wird er nicht funktionieren, da er Aufgaben anderer erfüllen wird, um ein halbwegs brauchbares Ergebnis (möglicherweise) zu schaffen.
Fazit
Es gibt Entwickler die sich nicht weiter entwickeln. Es gibt Entwickler, die lieber über unwichtige Aspekte von Spezifikationen diskutieren und weitere Details einfordern, um nur nicht selbst nachdenken zu müssen. Diese Fälle sind aber durchaus nicht so häufig, wie oftmals behauptet. Natürlich gehen beim Thema der Codequalität die Meinungen auseinander, Menschen sind nun einmal unterschiedlich. Ein großer Hemmschuh kann jedoch die Businessebene sein. Agiert diese falsch, wird den Entwicklern jegliche Motivation entzogen – und das wirkt sich aus. Negativ. Da kann man dem Entwickler noch so viel Professionalität unterstellen, leistet der Vorarbeiter keine bestmögliche Arbeit ab, dann zieht sich dieser Kreis immer weiter. So ist der Mensch.