Verlockung und Fallstricke bei Code-First, SCRUM & Co. Ein Gastbeitrag von Harald Zumpf, Professor an der HTL Spengergasse und Experte für Software Engineering und Projektmanagement.
Eine seriöse Ausbildung zum Software-Engineer beinhaltet nicht nur das Erlernen von Programmiersprachen und das Testen von entwickelter Software, sondern deckt wesentlich mehr ab. Das Verständnis von Geschäftsprozessen, des Umfelds des Kunden und die sogenannten „Soft Skills“ sind ebenso wichtig. Kaum eine Aufgabenstellung ist klein genug, um von einem einzelnen Entwickler gestemmt werden zu können.
So gelangt man unweigerlich zu einem Punkt, wo nicht nur die eigenen Fähigkeiten in Sourcecode gegossen werden müssen, sondern auch Schnittstellen zu den Kollegen bedacht werden müssen.
Dies ist eine der essenziellsten Komponenten der modernen Software-Entwicklung.
Aller Anfang ist natürlich das klassische Wasserfallmodell. Dieses Vorgehensmodell unterteilt ein Entwicklungsprojekt in sequenziell aneinandergereihte Phasen, die abgearbeitet werden. Die Ergebnisse jeder Phase sind als bindende Vorgaben für die jeweils nächste zu verstehen. Natürlich wird diese Vorgangsweise durch ein Requirements Engineering ergänzt, wobei mittels einer SWOT-Analyse – Akronym für Strengths (Stärken), Weaknesses (Schwächen), Opportunities (Chancen) und Threats (Risiken) – die Entscheidungen bezüglich der gewählten Technologie und der Features dargestellt werden. Hier findet Scoring statt, das nicht nur bei den Entscheidungen unterstützen soll, sondern auch als Rechtfertigungsgrundlage dient. Um Feedback vom Kunden als auch intern – in unserem Fall von den betreuenden Lehrkräften – bestmöglich erhalten zu können, ist es notwendig laufend Status-Reports durchzuführen. Am Ende eines Projektes steht natürlich die hoffentlich positive Abnahme durch den Projektpartner und die Beurteilung durch die Lehrkräfte.
So viel zur Theorie. Da der Drang sofort mit dem Coding loszulegen oft der Nervosität eines Rennpferdes vor dem Start gleicht, tendieren Anfänger oftmals zur „Code-First“-Strategie. Die notwendige Dokumentation wird hier maximal als lästiges Beiwerk verstanden und oft im Nachhinein „dazu gebastelt“, um den lästigen Betreuer ruhig zu stellen. Man möge sich vorstellen ein Haus einfach darauf los zu bauen und die Baupläne im Nachhinein zu erstellen. Das Ergebnis kann manchmal als abstrakte Kunst eingestuft werden, beinhaltet oft funktionsfähige Features, aber geht so gut wie immer an den Bedürfnissen des Kunden vorbei. Nichtsdestotrotz ist die beschriebene Vorgangsweise bei Schülern durchaus beliebt und weit verbreitet, da das Erstellen von Dokumenten so populär ist, wie das frühe Aufstehen an Montagen.
Durch die Verbreitung von modernen, agilen Projektmanagement- und Entwicklungsmethoden wie SCRUM zeichnete sich in den letzten Jahren so etwas wie Licht am tristen Horizont der Struktur- und Dokumentationsskeptiker ab.
Das „echte Arbeiten“ von Entwicklern wird ja nur selten von den klassischen Vorgangsweisen abgebildet. Dies führt unweigerlich zur Grundsatzfrage, ob die Organisationsmethode den Mitarbeitern gerecht werden soll, oder die Mitarbeiter der Methode.
Natürlich gibt man Projektteams die Möglichkeit sich mit ihrer Struktur den internen Abläufen des Projektpartners anzupassen und ihnen somit die Wahl ihre Vorgangsweise hinsichtlich Projektmanagement selbst zu wählen. Diese „falsche Freiheit“ führt dann oft zu amüsanten Begebenheiten, wie der Antwort eines Schülers auf die Frage nach Dokumenten: “Haben wir nicht, weil wir arbeiten agil.“ Leider verschwindet die vor Stolz geschwellte Brust des jungen Projektleiters relativ schnell, wenn er sich der Realität seiner gewählten Vorgangsweise bewusst wird. Was bedeutet agil und SCRUM nun wirklich?
Der agile Atlas von SCRUM beinhaltet nur wenige Komponenten, nämlich Rollen, Artefakte und Ereignisse. Große und komplexe Entwicklungsprojekte sind ja wirklich oftmals schwer von Anfang bis zum Schluss planbar. Diesem Problem nimmt sich SCRUM an, indem Zwischenergebnisse definiert werden, die wiederum Rückschlüsse auf fehlende Anforderungen liefern sollen. Somit lässt sich die Planung eines Projektes iterativ entwickeln. Dieser sich aufbauende langfristige Plan wird Product Backlog genannt. Das Hinarbeiten zu den genannten Zwischenergebnissen, definiert im Sprint Backlog, wird in Sprints durchgeführt, die oftmals nur wenige Wochen andauern. Wie bei jeder Projektmanagementmethode muss auch die Einhaltung des Systems gewährleistet werden, was die Aufgabe des sogenannten SCRUM-Masters ist. Für den endgültigen Erfolg des Projekts und die Eigenschaften des Produkts zeichnet sich der sogenannte Product Owner verantwortlich. Die dritte Rolle wird von den Entwicklern selbst besetzt. Diese sind für die operative Tätigkeit innerhalb des Sprints verantwortlich.
Für große Verwunderung sorgt oft, dass während des Sprints keine Änderungen erlaubt sind. Dinge, die nicht wie gewünscht abgelaufen sind, werden am Ende jedes Sprints beim sogenannten Sprint-Review (Retrospektive) erläutert. Der „Agilität“ sind so zumindest innerhalb dieser Prozesse Grenzen gesetzt. Die Visualisierung wird gerne über ein sogenanntes Kanban Board gemacht, das ein Projekt wiederum in einzelne Phasen aufteilt und die Elemente des Product Backlogs diese Stufen durchwandern lässt.
Agile Methoden folgen also einem durchaus komplexeren Regelwerk, als man meinen möchte und eignen sich somit natürlich nicht als Rechtfertigung für Anfänger die notwendige Dokumentationspflicht zu umschiffen.
Abgesehen davon, dass prinzipiell Dokumentation nicht nur dem Monitoring-Zweck dient, sondern auch eine große Notwendigkeit bezüglich der Haftung und Compliance darstellt. Freiheit und Flexibilität im Projektmanagement bedeutet nicht zwangsweise mehr Zeit für das geliebte Coding zu haben, sondern auch eine Notwendigkeit zu häufigerem Controlling und einer hochfrequenteren Adaption der Feature-Definitionen, was natürlich wiederum „mühsam“ niedergeschrieben werden muss. Ein Sportwagen eignet sich auch nicht immer als Auto für Fahranfänger. Ein Rennen gewinnt man schließlich immer nur, wenn man auch ins Ziel kommt.
Über den Autor:
Mag. Harald Zumpf unterrichtet Software Engineering, Betriebswirtschaft und Management sowie Projektentwicklung an der HTL-Spengergasse. Er leitet dort die Hochbegabtenförderung und fungiert als Business Relation Koordinator.
Daneben ist er als Berater tätig und Fachgruppenobmann für Personalberatung und Betreuung der Wirtschaftskammer. Als langjähriger Geschäftsführer der Absolut-Bildungsmanagement GmbH und als diplomierter psychologischer Berater liegen seine Schwerpunkte auf dem Bildungssektor und dem Personalbereich. Außerdem ist der langjährige Universitätslektor der TU Wien als Consultant in IT-Projekten aktiv.
Fotos: Lisa Resatz