K1.1 - Welche Rolle spielt Evolvierbarkeit?

Der Begriff Evolvierbarkeit beschreibt eigentlich mehrere Eigenschaften von Software als Oberbegriff. Eine hohe Evolvierbarkeit ist dann gegeben, wenn Gütekriterien wie Erweiterbarkeit, Testbarkeit, Verständlichkeit oder Kohäsion in hohem Maße umgesetzt wurden. Ein Gütekriterium alleine führt noch nicht zu hoher Evolvierbarkeit, denn eine Software kann zwar letztlich einfach zu erweitern sein, jedoch sollte das auch in einer überschauberen Entwicklungszeit möglich sein. Es ist ein Indiz für geringe Evolvierbarkeit, wenn ein Feature in der Theorie- und Konzeptionsphase einfach zu integrieren ist, aber die Umsetzung mehr Zeit als geplant in Anspruch nimmt. Dieser ungeplante Mehraufwand ist meist der hohen Komplexität der Software zuzuschreiben.
Im Folgenden werden drei wichtige Themen behandelt, die ein Softwareentwickler anhand der Evolvierbarkeit beurteilen muss.

Aufwandschätzungen in Softwareprojekten

 

Die Aufwandschätzung ist Teil jeder Projektplanung und dient jedem Entwickler spätestens in der Nachbereitung und Phase der Selbstreflektion als Maßstab für Kontrollen.
Meine persönlichen Erfahrungen als Softwareentwickler sind die, dass die Aufwandschätzung zu einer eigenen Disziplin in der Softwareentwicklung geworden ist. Jede Aufwandschätzung, die nicht ernsthaft durchgeführt wurde, ist verschwendete Zeit gewesen. Eine Schätzung die nicht überprüft wird, ist ebenfalls von geringem Wert, da man nur durch Kontrolle erfährt, ob die Aufwände realistisch geschätzt wurden.

Ein Projekt kann trotz unrealistischer Aufwandschätzungen pünktlich fertiggestellt werden. Dies ist oft der Fall, wenn die Deadline bereits von Anfang an feststeht, statt die Deadline auf Basis der Aufwände festzulegen.

Welchen Mehrwert hat nun eine Aufwandschätzung für den Entwickler?

 

Ein Mehrwert liegt darin, dass man selbst an der eigenen Produktivität gezielt arbeiten kann, wenn man mit der Zeit merkt, dass man bestimmte Aufwände unterschätzt hat.
Ein weiterer Mehrwert ist, dass man von Kollegen, Projektmanagern und Vorgesetzten als ernsthafter Ansprechpartner angesehen wird, wenn man Aufwände richtig und realistisch einschätzen kann.

Es gibt diverse Techniken und Werkzeuge, um Aufwandschätzungen durchzuführen. In agilen Vorgehensmodellen wie Scrum gibt es das Mittel "Schätzkarten", um in einer Besprechung die niedrigste und höchste Schätzung zu diskutieren. Die Schätzung wird also durch Kommunikation ermittelt.
Nicht selten muss man eine Aufwandschätzung alleine durchführen. Selbstverständlich muss man auch dann noch mit anderen abhängigen Ressourcen kommunizieren, aber das Endergebnis ist letztlich die subjektive Schätzung des Entwicklers.

Es gilt also Mittel und Wege zu finden, um eine Aufwandschätzung auch im Alleingang durchführen zu können. Im klassischen Vorgehensmodell V-Modell hat sich für mich die Anforderungsanalyse nach dem IEEE 830 Standard als passendes Mittel erwiesen. Eine Aufwandschätzung muss auf Basis von Anforderungen durchgeführt werden. Das heisst, je genauer die Anforderungen definiert und verstanden sind, desto realistischer kann man die Aufwände schätzen.

Es wird sicher öfter vorkommen, dass man Aufwände nur grob schätzen kann, d.h. man schätzt den minimalen und maximalen Aufwand. Das ist besonders dann der Fall, wenn man es mit Legacy Code zutun hat. Schätzungen mit einer relativ großen Differenz zwischen Minimal und Maximal lassen den Entwickler auf den ersten Blick als unerfahren oder evtl. sogar etwas inkompetent darstehen. Solche Schätzungen wird es immer geben, egal wieviel Erfahrung man hat. Es gilt dabei stets konsequent zu bleiben gegenüber Projektmanagern und Vorgesetzten, denn diese Personen werden nicht zufrieden sein mit solchen ungenauen Schätzungen. Das ist verständlich, da die Wirtschaftlichkeit und Planbarkeit darunter leidet. Dennoch ist es professioneller seinen realistischen Schätzungen treu zu bleiben, statt durch unrealistische Schätzungen andere zufriedenstellen zu wollen. Das würde den eigenen Lern-, Weiterbildungsprozess verlangsamen, da man sich mehr darauf konzentriert andere zufriedenzustellen, statt diese Energie in die Selbstreflektion zu stecken.

Innerhalb der Lesson Learned Phase sollte man stets die Selbstkontrolle durchführen. Die Feststellung, dass alles so verlaufen ist wie man es eingeschätzt hat, ist ebenso wichtig, wie die Ermittlung von Verbesserungsmöglichkeiten. Letztlich gewinnt man an Erfahrung für zukünftige Projekte.

Produktivität und Effizienz des Softwareentwicklers

 

Ein Softwareentwickler kann in einem Projekt wirtschaftlich und technisch absolut nach Plan arbeiten, und in einem anderen Projekt völlig untergehen. Die Produktivität des Entwicklers ist abhängig von der Code Basis im Projekt. Jeder Entwickler wird früher oder später mit Code konfrontiert den er nur schwer verstehen kann. Das Verständnis ist aber entscheidend für Änderungen, z.B. neue Features.
In Projekten in denen die Code Basis nicht stimmt, muss man als Entwickler mit höchster Genauigkeit vorgehen. Das nimmt in der Regel mehr Zeit in Anspruch, als wenn das Feature von Anfang an implementiert worden wäre. Diesen Sachverhalt sollte man immer kommunizieren, auch wenn man dadurch indirekt die Arbeit des ursprünglichen Entwicklers kritisiert. Natürlich sollte man mit möglichst hoher Sozialkompetenz diese Dinge ansprechen, aber ein Ignorieren oder gar Schönreden der Code Probleme ist definitiv der schlechtere Weg, vorallem für einen selbst, denn oft führt das zu hoher Frustration.

Die eigene Produktivität kann man messen indem man die geleistete Arbeit der geplanten Arbeit gegenüberstellt. Die Effizienz lässt sich am besten beurteilen, wenn man die Arbeitsqualität als weiteres Kriterium hinzuzieht. Ein Projekt mit 10 Arbeitspaketen wurde produktiv umgesetzt, wenn alle 10 Pakete in der geplanten Zeit umgesetzt wurden. Eine Aussage über die Effizienz ist erst über den Code möglich. Das Projekt ist dann effizient umgesetzt, wenn man auf Qualitätsrichtlinien in Sachen OOD, OOA und vorallem Wiederverwendbarkeit geachtet hat. Ein Gegenbeispiel: Ein Entwickler war weniger effizient, wenn er doppelt soviel Code schreiben muss, um an sein Ziel zu gelangen, als notwendig. Er war dennoch produktiv, wenn er das Ziel trotzdem erreicht.

Die Produktivität beurteilen die Vorgesetzten und Projektmanager anhand der Aufwandschätzungen. Die Effizienz kann von technisch Fachfremden nicht beurteilt werden, dennoch versuchen es viele. Als Kriterium werden sinnlose Vergleiche mit Projekten aus der Vergangenheit herangezogen. Die Komplexität um Effizienz zu beurteilen ist sehr hoch. Man muss dazu Kennzahlen wie LOC, doppelter Code und weitere Code Metriken auswerten. In modernen Zeiten mit Continuous Integration kann man solche Qualitätssicherungsmaßnahmen relativ komfortabel automatisiert durchführen. Hinzukommt, dass Effizienz auch davon abhängig ist, welche weiteren Voraussetzungen im Projekt vorlagen. Der Einsatz von passenden Tools ist ein wichtiger Aspekt, wenn man Effizienz als Ziel hat. Ein simples Beispiel: Man sollte eine XML Datei mit einem XML Editor bearbeiten und validieren, statt mit einem normalen Texteditor.

Vorsicht vor Optimierungen der Software

 

Zum Schluss noch eine Warnung vor Code Optimierungen. Es ist zwar eine gute Eigenschaft eines Entwicklers, wenn man Code besser hinterlässt als man ihn vorgefunden hat, aber Änderungen sollten Sie dennoch nur kontrolliert durchführen. Auch eine einfache Änderung kann erhebliche Seiteneffekte haben.

Meine Erfahrung hat gezeigt, dass man in zeitkritischen Projekten (und das sind leider die meisten) besser die Finger still halten sollte, wenn es um Code Optimierung geht. Führt man Optimierungen durch, die nicht abgesprochen wurden, dann kommt man später schnell in Erklärungsnot, wenn es Fehler in eingeplanten Arbeitspaketen gibt, vorallem wenn diese Fehler Folge der Optimierung waren.
Sie arbeiten dennoch gewissenhaft in dem Sie eine Liste von möglichen Refactorings führen und diese zu einem passenden Zeitpunkt umsetzen.

Keine Kommentare:

Kommentar veröffentlichen