Agil, Scrum, ausgefallene Worte zum Schreiben von Software, die Ergebnisse bringt
Unabhängig davon, aus welcher Sicht man es betrachtet, haben Entwickler von Geschäftsanwendungssoftware im Allgemeinen einen schlechten Ruf. Systeme werden fast zwangsläufig verspätet oder gar nicht geliefert. Der durchschnittliche Benutzer in einem durchschnittlichen Unternehmen verbringt jede Woche buchstäblich Stunden damit, über die Computersysteme zu meckern, denen er ausgesetzt ist. „Warum wurde das getan?“ „Was zum Teufel bedeutet das?“ sind einige der Dinge, die ich täglich höre.
Ich habe Jahre damit verbracht, Geschäftssysteme zu schreiben, und die meisten Benutzer waren positiv über das, was sie bekamen und nutzten. Systeme, die nach einer anfänglichen Spezifikation geschrieben, auf Herz und Nieren getestet und dann bei Bedarf und bei Bedarf zu einem vereinbarten Preis angepasst werden. Kontinuierlicher Support für den Kunden und nachhaltige Einnahmen für das Softwareunternehmen waren eine gewinnbringende Kombination. Die anfängliche Spezifikation, die auf einer detaillierten Anforderungsanalyse basiert, wäre immer eine Funktionsübersicht und würde keine Code-Spezifika enthalten. Ich glaube, ich habe einmal Pseudocode verwendet (als ich Spiele geschrieben habe). „Das ist es, wofür wir es brauchen“ war für mich normalerweise gut genug. Abgesehen davon waren es noch ein paar Benutzeroberflächen-Mock-ups und viel Datenbankdesign und schon ging es los. Die Test- und Optimierungsphase des Entwicklungslebenszyklus war von entscheidender Bedeutung. Die Systeme wurden im Allgemeinen pünktlich geliefert und funktionierten.
Heutzutage (ich hätte nie gedacht, dass ich das jemals sagen würde) geht es bei allem, was mit Systemen zu tun hat, um Planung, noch mehr um Planung und dann um Wiederverwendbarkeit. Was mir so fremd vorkommt, ist, dass ein Großteil dieser Planung nicht darauf abzielt, eine funktionale Anforderung zu erfüllen, sondern vielmehr detailliert darzulegen, wie und warum wir schreiben werden, was wir schreiben, wenn wir es schreiben. Hoffe das macht Sinn? Warum etwas in 10 Zeilen schreiben, das man in 1000 Zeilen schaffen könnte, wenn es die Möglichkeit gibt, dass man es zwei Jahre später „vielleicht“ wiederverwenden muss? Persönlich habe ich noch nie etwas geschrieben, das ich zwei Jahre später nicht besser umschreiben könnte. Ich lerne ständig dazu und verbessere mich. Wenn ich auf Code zurückblicke, der selbst 12 Monate alt ist, zucke ich oft zusammen. Wenn man sich Stellenanzeigen ansieht, kann man sich leicht in den Methoden und Fähigkeiten verlieren, nach denen gefragt wird. Ist es menschlich möglich, dass eine Person so viel weiß, frage ich mich oft? Eine andere Frage ist, ob sie jemals ein Produkt produzieren. Wird bei all dieser Planung und Sorge um die Wiederverwendung von Code jemals etwas erledigt? Ich kenne ein Unternehmen, das akademische Entwickler eingestellt hat, die sich so sehr auf das Design konzentrierten, dass das Unternehmen unterging, bevor überhaupt ein Produkt fertig war, im Ernst! Wie viele Verzögerungen können wir von den Leuten erwarten, die Testphase war dort nie ein Problem! Warum sollte von dem Unternehmen, das uns für ein Produkt bezahlt, erwartet werden, dass es für Code bezahlt, der in späteren Projekten immer wieder verwendet wird, nicht für das Unternehmen?
Verstehen Sie mich nicht falsch, ich sage nicht, dass Planung schlecht ist, sie ist ein wesentlicher Teil der Systementwicklung, aber nicht der einzige. Vielleicht bin ich altmodisch, aber der Teil, der mir Spaß macht, besteht darin, das System tatsächlich zu schreiben und dafür zu sorgen, dass es funktioniert. Ok, ich weiß, dass Systeme immer größer und komplexer werden. Große Entwicklerteams sind die Norm. Ich denke nur, dass, egal wie viel man plant, visualisiert und Brainstorming betreibt, immer etwas übersehen wird. Wir streben nach dem Unmöglichen, nach perfekten Systemen, aber im schlimmsten Fall liefern wir tatsächlich kein System. Glauben Sie mir nicht? Schauen Sie sich Microsoft an. Stellen Sie sich vor, wie viele Arbeitsstunden in die Planung ihrer Anwendungen fließen? Wie oft wird ein neuer Fehler oder eine neue Schwachstelle entdeckt? Warum wurden diese nicht bereits in der Entwurfsphase ausgearbeitet? Dem Entwicklungsteam kam es nie in den Sinn, dass „Schwachstelle X“ überhaupt auftreten könnte. Einfach ausgedrückt ist es mit mehr als den einfachsten Systemen fast unmöglich, für alle Eventualitäten zu planen, egal wie logisch Sie sind. Wie kommt es, dass sie beim Testen nicht gefunden werden? Liegt hier die Lösung in der Old-School-Entwicklung, weniger Zeit für Planung (Reden), mehr Zeit für Schreiben und Testen? Weniger Zeit damit, sich Gedanken über die Wiederverwendung von Code zu machen, mehr Zeit damit, dem Kunden ein funktionierendes Produkt zu bieten? Wäre es für Microsoft besser oder schlechter, wenn sie weniger Zeit für die Planung und mehr Zeit für Tests aufwenden würden? Zur Verteidigung von Microsoft muss man sagen, dass sie sehr gut im Patchen sind. Ich nehme an, man könnte sagen, dass sie uns als Tester eingesetzt haben. Nur wenn sie mehr Zeit damit verbringen würden, ordnungsgemäße Tests durchzuführen, müssten wir vielleicht keine Tests für sie durchführen?
Das schlimmste Beispiel für Überplanung, das mir bisher begegnet ist, ist ein Finanzsystem, das ich täglich nutze. Die Implementierung dieses Systems hat Millionen Dollar gekostet, jahrelange Planung und wer weiß wie viele Berater. Es wurde von einem der größten Player der Softwarebranche geschrieben und von einer spezialisierten Softwareberatung angepasst. Das Endergebnis ist ein System, das praktisch unbrauchbar ist und nicht mehr weit davon entfernt ist, durch ein Standardprodukt ersetzt zu werden. Auf der niedrigsten Ebene ist es so schlimm, dass selbst ein falsch platzierter Mausklick die Anwendung zum Absturz bringt. Ich kann nicht glauben, dass dieses System vor der Übergabe jemals getestet wurde. Die Lieferung erfolgte bereits sehr spät, der Grund dafür war ein länger als erwarteter „Planungszyklus“. Was es tut, ist nicht so komplex, es ist nur offensichtlich so weit geplant, dass die Umsetzung nur noch in Eile erfolgt. All diese Planungen haben nicht einmal zu einem System geführt, das die grundlegenden Funktionsanforderungen seiner Benutzer erfüllen würde, aber heh, ich bin mir sicher, dass sie diesen Code irgendwann später wiederverwenden werden.
Wie auch immer, ich habe gerade mit einem Diplom begonnen, um zu verstehen, warum die Verwendung verschiedener Planungsstrategien so wichtig ist. Warum an einem Tag schreiben, was ich einen Monat lang „richtig“ tun könnte? Ich weiß, dass ich das in ein paar Jahren noch einmal lesen werde und mich fragen werde, was ich gedacht habe; Entweder das, oder ich sage mir: „Wow, da war ich tatsächlich fertig mit dem, was ich geschrieben habe.“ Aber im Ernst, ich bin mir sicher, dass ich am Ende erkennen werde, wo ich falsch liege. In der Zwischenzeit schreibe ich einfach weiterhin Bewerbungen in meinem RAD-Stil (ich bin froh, dass er einen Namen hat!). Obwohl es nicht jedermanns Geschmack ist, funktioniert es für mich ganz gut.
Hinweis: Wer hätte gedacht, dass mein Entwicklungsansatz einen Namen hat, er wird als agile Methodik klassifiziert! Hier ist ein ausgezeichneter Artikel, der es erklärt agile Methoden im Detail.