Der Start eines Softwareprojekts ist immer eine Weichenstellung für die Zukunft. Gemeinsam formulieren wir ein klar messbares Ziel, welches Sie mit Ihrer neuen Software erreichen möchten. Für Sie bedeutet dieser Schritt auch eine Überprüfung des Potentials Ihrer Investition.

Ausgehend von der gemeinsamen Vision wird im nächsten Schritt eine Liste der gewünschten Funktionen erstellt. Diese sollte so umfänglich wie möglich sein, dies schärft sogleich das gemeinsame Verständnis der langfristigen Ziele. Klar ist zu diesem Zeitpunkt, dass nicht alle Wünsche  im vorhandenen Projektbudget realisiert werden können. Hier bietet es sich an, sich auf die Funktionalitäten zu fokussieren, welche den größten Nutzen erzielen.

Bevor das Entwicklerteam beginnt zu programmieren, sollten die gemeinsamen Projektspielregeln von allen Beteiligten definiert werden. Aus Entwicklersicht gesprochen, gibt es nämlich nichts Ineffizienteres als ständige Arbeitsunterbrechungen und wechselnde Arbeitsaufgaben. Dennoch hat die Vergangenheit gezeigt, dass starre Projektpläne nicht zum Erfolg führen. Anforderungen und Priorisierungen können sich im Laufe des Projektes ändern und müssen dann an die neuen Gegebenheiten angepasst werden. Gute Erfahrungen habe ich in diesem Zusammenhang mit den agilen Methoden Scrum und Kanban gemacht. Welche der beiden Methoden zum Einsatz kommt ist von den Rahmenbedingungen Ihres  Projektes und dessen Umfeld abhängig.

Bevor die erste Zeile Quellcode dann geschrieben werden kann, muss noch die Entwicklungsumgebung durch das Entwicklerteam eingerichtet werden. Das beinhaltet grob gesagt die Quellcodeverwaltung, das Projektmanagement-Tool (meist JIRA), den ContinousIntegration/ContinousDelivery Server (meist Jenkins) und die Auswahl der eingesetzten Programmiersprache(n).

Alle Voraussetzungen sind geschaffen, die Kernarbeit des Entwicklungsteams beginnt! Das Team beginnt mit der Umsetzung der spezifizierten Funktionalität. Hierbei haben Sie in regelmäßigen Abständen die Möglichkeit, den Fortschritt selber zu überwachen. Bei Scrum erfolgt dies nach jedem Sprint (2-3 Wochen) oder bei Kanban nach jedem fertigstellten Feature. Dies erlaubt ein schnelles Gegensteuern, sollte etwas nicht dem gewünschten Ziel entsprechen. Es kann zudem schnell reagiert werden, falls sich Anforderungen ändern oder verschieben.

Im Rahmen der Qualitätssicherung und des Wissensaustausch macht es Sinn, einen Code-Review Prozess zu etablieren. Alle Änderungen, welche ein Entwickler im Rahmen der Implementierung einer Funktionalität durchführt, müssen durch ein anderes Teammitglied überprüft und freigegeben werden. Diese Art der Selbstkontrolle der Entwickler fördert enorm den Wissensaustausch im Team. Des Weiteren steigert es die Effizienz im Team, da Fehler in einer frühen Entwicklungsphase entdeckt werden, in welcher sie noch leicht zu beheben sind. Das Feststellen von Fehler erst in der Produktion ist meist mit hohen Entwickleraufwänden verbunden. Ein weiterer Pluspunkt ist, dass der kontinuierliche Wissensaustausch im Team keine weitere erklärende Dokumentation erforderlich macht. Meine bisherige Projekterfahrung war immer, dass diese Art der Dokumentation enorme Arbeitsaufwände verursacht und dennoch häufig nicht dem entspricht, was wirklich implementiert worden ist. Ich bin davon überzeugt, dass die wirklich nutzenbringende Wahrheit im gut strukturierten und klar verständlichen Quellcode liegt. Aus diesem Grund ist es zielführend, nur Architekturentscheidungen sowie die Technologieauswahl zu dokumentieren, Dies gilt im Besonderen für die zugrunde liegenden Annahmen und Begründung für die Entscheidung. Somit kann jeder zu einem späteren Zeitpunkt nachvollziehen, aus welchen Beweggründen etwas in einer bestimmten Form realisiert worden ist.

Neben der Entwicklungsarbeit hat das Team in dieser Phase auch die Aufgabe, gemeinsam mit der Fachabteilung die Funktionalität im Detail zu spezifizieren und abzustimmen. Hierbei sehe ich meine Rolle immer als vermittelndes Glied zwischen beiden Welten. Bei Wünschen oder Anregungen der Fachabteilung habe ich in der Vergangenheit häufig die Erfahrung gemacht, dass hier auch mal klare Worte gesprochen werden müssen. Hier erlaubt mir meine langjährige Erfahrung in der Softwareentwicklung kombiniert mit meinem Verständnis für Geschäftszusammenhänge, eine schnelle Einschätzung bzgl. etwaiger Aufwände zu treffen. Meiner Meinung nach zeigt sich gerade in Bezug auf Funktionen, dass eine sehr enge Zusammenarbeit mit der Fachabteilung zum Erfolg führt. Diese Chance möchte ich für Sie nutzbar machen!