Die meisten Softwareschmieden haben das gleiche Problem: Die Softwareentwicklung durchläuft keinen klar definierten Prozess. Egal ob Feature, Bug oder Idee. Alles fließt in eine einige Datenhalde, die dann abgearbeitet wird. Prioritäten werden in den wenigsten Fällen vergeben. Ebenfalls finden sich oft kaum Beschreibungen, genaue Fehlerhinweise oder gar Konkretisierungen der gewünschten Anforderungen.
Immer wieder gerate ich in Unterhaltungen, in denen dieses Thema aufgegriffen wird. Meist ist man sich einig, dass am jeweiligen Software-Prozess Änderungen vorgenommen werden müssen. So einfach es theoretisch ist, treten doch in der Praxis zahlreiche Probleme auf. Wie kann man dem also entgegen wirken?
Eine der wichtigsten Aufgaben ist wohl, zu identifizieren was schief läuft und wo Handlungsbedarf besteht. Auch das klingt einfach und ist es schlussendlich nicht. Wo finden sich Ansatzpunkte?
Projektverantwortliche (unabhängig ob der Geschäftsführer, der Program Manager, der Project Manager usw.) finden sich immer wieder in der Situation, dass sie den aktuellen Entwicklungsstand nicht beurteilen können. So wird an der Businesslogik geschraubt, mit kaum sichtbaren Ergebnissen oder Erweiterungen finden ihren Weg in die Software, die auch erst im letzten Schritt eine Auswirkung auf das User Interface haben. Meist sehr unbefriedigend für denjenigen, der das Produkt seinen Kunden schmackhaft machen soll.
Die Entwickler auf der anderen Seite sehen sich damit konfrontiert, dass die Software im halbfertigen Zustand begutachtet wird, wobei doch gemachte Erweiterungen noch gar nicht sichtbar sein können. Aufgaben mit höchster Priorität werden verteilt, die aktuell nicht zum Entwicklungsstand passen und daher auch nicht wahrgenommen werden können. Zustätzlich werden in ein etwaiges vorhandenes System alle Punkte eingepflegt, sodass sie für jeden Entwickler sichtbar sind (eventuell sogar noch mit Benachrichtigung). Dies bringt definitiv Unruhe in das Entwickler-Team, da man sich automatisch Gedanken über Dinge macht, die zum aktuellen Zeitpunkt nicht relevant sind.
Resultat sind langwierige Diskussionen. Entwickler in ihrer technischen Welt auf der einen Seite und der wirtschaftliche Bereich auf der anderen. Wie gesagt: Stundenlanges Gerede. Jeder "spricht in seinen Worten". Die Annäherung geht gegen null. Schlussendlich glaubt jeder, die andere Seite verstanden zu haben, um bei nächster Gelegenheit zu merken, dass dem nicht der Fall ist.
Nun die entscheidende Frage: Wie kann Ordnung in dieses Chaos gebracht werden?
Es gilt den Wildwuchs von Informationen Herr (oder Frau) zu werden. Der Entwickler soll für ihn relevante Informationen zu Gesicht bekommen und nicht mehr. Dies bedeutet, dass - wie in agilen Prozessen üblich - Releasetermine definiert werden müssen. Jedes Release enthält eine klar abgegrenzte Feature-Liste. Diese wird mit Prioritäten versehen und entsprechend abgearbeitet. Zusätzliche (neue) Anforderungen werden für das aktuelle Release nicht mehr aufgenommen, sondern neuen Releases zugewiesen. Wichtig ist hier, dass die neuen Funktionalitäten klar definiert werden (genaue Spezifikationen müssen definitiv vorhanden sein, ebenfalls Use Cases usw.).
Wird ein Releaseplan zusammengestellt obligt es dem Entwickler eine Machbarkeitsanalyse durch zu führen und entsprechend Rückmeldung zu geben. Bei Machbarkeit erfolgt eine Aufwandsschätung. Darauf hin kann der "Auftraggeber" seine Prioritäten vergeben und festlegen, für welches Release dieser Punkt Relevanz hat.
Der Vorteil liegt klar auf der Hand:
Der Projektverantwortliche hält einen klaren Releaseplan in der Hand. Er weiß zu jeder Zeit, welche Features umgesetzt werden können und welche aus Zeitgründen in ein anderes Release verschoben werden müssen. Zusammen mit entsprechenden Auswertungen und Erfahrungswerten gelangt er zur Information, wieviel tatsächlich von seinem Team umgesetzt werden kann.
Der Entwickler erhält eine Liste von Punkten die umzusetzen sind. Änderungen (manche lassen sich leider nicht vermeiden, Blocker o.ä.) sind nicht vorgesehen. Er kann sich auf seine Aufgaben konzentrieren und muss sich mit neuen Aufgaben erst bei der Erstellung des nächsten Release-Planes beschäftigen. Er hat den Kopf für aktuelle Aufgaben frei.
Einer muss schließlich die Software verkaufen. Er hat aussagekräftige Informationen zur Hand, die er dem Kunden vorlegen kann. Zudem ist jedoch auch klar, dass mal eben ein Feature nicht untergeschoben werden kann. Dieses muss durch den Prozess durch und wird je nach Priorität und Aufwand einem bestimmten Release zugeordnet. Schwerwiegende Fehler sind davon natürlich ausgenommen. Natürlich kann sich durch die Wichtigkeit des Kunden bzw. des Punktes auch der nächste Release-Plan entsprechend verändern. Der aktuell vorliegende Plan sollte davon jedoch unberührt bleiben.
Dieser Prozess ist natürlich nur einer von vielen. An allen Ecken und Enden muss gefeilt werden. Idealerweise setzen sich jedoch Projektverantwortliche und Entwickler an einen Tisch und versuchen einen gangbaren Weg zu finden. Die Bedürfnisse sind auf beiden Seiten die gleichen:
Jeder möchte wissen, was im nächsten Release implementiert ist und was nicht.
Wie sieht es mit den nächsten Schritten aus? Was ist für zukünftige Releases geplant?
Wann sind wir fertig?
usw.
Fragen über Fragen. Ein sauberer Prozess kann nicht auf alles eine Antwort geben. Aber viele Antworten können erleichtert werden und durch zusätzliche Messungen kann festgestellt werden, wieviele Manntage tatsächlich innerhalb eines Monats umgesetzt werden können, was das für die Roadmap des Produktes bedeutet und viele weitere Angaben, welche die Planung erheblich erleichtern.
Vielleicht sind Projektverantwortliche und Entwickler in ihren Wünschen doch nicht so weit voneinander entfernt ...
Previous Topic
