Vor den 2000er Jahren wurde die Softwareentwicklung hauptsächlich nach einem Wasserfall-Ansatz durchgeführt. Das bedeutete, dass ein Softwareprojekt ausgeliefert wurde, nachdem es einige lange Phasen wie Analyse, Entwicklung und Qualitätssicherung durchlaufen hatte, um nur einige zu nennen. Dies führte zu langsamen Softwareentwicklungszyklen und folglich wurden in den frühen Phasen des Lebenszyklus falsche Entscheidungen getroffen, was zu schlechter oder ungeeigneter Software führte.
Heutzutage werden die meisten großartigen Projekte agil entwickelt, wobei Philosophien wie SCRUM oder Extreme Programming verwendet werden. Diese Methoden fördern eine schnelle Softwareentwicklung, in der Regel durch Verkürzung der Zyklen und durch häufiges Versenden.
Dennoch verlassen sich einige Branchen bei der Bereitstellung von Software immer noch auf Waterfall, da dies immer noch der beste Ansatz für ihr Ziel ist. Nehmen wir zum Beispiel die Luft- und Raumfahrt. Wenn Sie einen Satelliten mit einem integrierten Code starten, können Sie ihn nicht aktualisieren, wenn die integrierte Aktualisierungssoftware defekt ist.
Dies war auch einer der Gründe, warum Waterfall so beliebt war. Der Versand von Software war im Vergleich zu den heutigen Verfahren teurer, da in der Regel eine Kassette oder Diskette magnetisiert oder eine CD gebrannt wurde, bevor die Software weltweit versendet und auf Computern installiert werden musste, die während ihrer gesamten Lebensdauer niemals eine Verbindung herstellen würden.
Ich habe an vielen Projekten teilgenommen und mehr Teams beim Versand von Software geholfen, als ich mich erinnern möchte. Ich hatte das Glück, mit Unternehmen zusammenzuarbeiten, die großartige Software herausgebracht haben, und mit anderen, die Schwierigkeiten hatten, das Tempo in Bezug auf Qualität, Zeitplan und Budget zu halten. Mir ist aufgefallen, dass der Schlüssel zur Entwicklung großartiger, vorhersehbarer Software nicht in der verwendeten Methodik liegt, da einige das in Agile gut gemacht haben, während andere sie in Waterfall beherrschten. Der Schlüssel zum Erfolg lag in ihren Entwicklungsprozessen, und bei einigen gab es keinen schriftlichen. Ihr Produktteam befolgte lediglich eine Reihe von Aufgaben, um neue Dinge auf sich wiederholende Weise bereitzustellen, sodass sie kontrollieren konnten, wo Dinge funktionierten, und diejenigen, die nicht funktionierten, verbessern konnten.
Diese Prozesse waren von Team zu Team unterschiedlich, und die Anzahl der Schritte, um ein Feature fertig zu stellen, war in der Regel nicht dieselbe. All diese Prozesse hatten jedoch Gemeinsamkeiten in Bezug auf die Art und Weise, wie ihre Teams den Entwicklungszyklus angegangen sind. Das haben sie nicht getan.
Es ist leicht, sich für eine neue Idee zu begeistern, und jeder möchte sofort ein Stück vom Kuchen abhaben. Dieser Versuchung zu widerstehen ist schwierig und oft der Schlüssel, um Dinge schneller zu erledigen. Dies ist manchmal schwer zu verstehen, insbesondere wenn Sie sich in den ersten Jahren Ihrer Karriere als Softwareentwickler befinden.
Wenn Sie genau überlegen, kann die Implementierung einer Funktion, deren Definition einen halben Tag und das Design ein paar Tage gedauert hat, leicht eine Woche dauern. Dies folgt der natürlichen Reihenfolge, in der Dinge leichter gesagt als getan sind.
Gute Teams verbringen Zeit damit, ein Problem zu analysieren und einen Lösungsansatz zu definieren. Es gibt eine Abwägung darüber, wie viel Sie in der Denkphase ausgeben sollten. Dies kann von der Wichtigkeit des Produkts und den Kosten für den Versand einer neuen Version abhängen. Gute Teams verbringen jedoch immer Zeit damit, eine Lösung zu entwerfen, bevor sie mit der Implementierung einer neuen Funktion oder der Behebung eines Fehlers beginnen.
Wir waren alle dort. Der Product Owner sagt, dass eine Funktion nicht mehr relevant ist, Sie gehen den Code durch, um sie zu entfernen, und ein paar Wochen später bittet jemand darum, die Funktion wieder hinzuzufügen. Wir wissen nie, wann der Code, der jetzt nutzlos ist, wieder benötigt wird, und es scheint eine gute Idee zu sein, ihn zu kommentieren oder dort zu belassen. Toter oder kommentierter Code kann nicht schaden, oder? Außerdem sparen wir Zeit, wenn wir den Code dort belassen, da wir nicht mehr wissen müssen, ob andere Abhängigkeiten davon bestehen.
Leider erzeugt alter oder kommentierter Code das, was oft genannt wird technische Schulden. In Zukunft werden andere Entwickler auf den toten Code stoßen und das wird sie verlangsamen. Dateien werden größer, Code wird schwieriger zu lesen sein und das Chaos legt sich.
Es gibt eine bessere Alternative, um zu vermeiden, dass eine funktionierende Funktion entfernt wird, ohne den Code irgendwo zu speichern. Mit moderner Versionskontrollsoftware (z. B. git) ist es sehr einfach zu erkennen, wann und welche Änderungen vorgenommen wurden, und bei Bedarf den alten Code abzurufen. Es gibt einen guten Grund, warum Tools wie Git hervorheben, wie viele Codezeilen bei jedem Commit gelöscht wurden. Das Entfernen von Code ist genauso wichtig wie das Hinzufügen eines neuen Codes.
Niemand spricht darüber im College oder an der Universität, und niemand spricht darüber in den vielen Softwareentwicklungskursen, die es gibt. Aber Leute, die regelmäßig in der Produktion arbeiten, lernen das, sobald sie mit der Arbeit an ihrem ersten Projekt beginnen, und sie hören es oft auf die harte Tour...
Wenn es in der Produktion schief geht, klingelt das Telefon von jemandem. Und ich wette, dass es für diese Person schwieriger ist, das Projektteam zusammenzustellen und alles am Wochenende zu reparieren als an einem Wochentag. Manche Leute gehen sogar am Wochenende gerne vom Netz und wünschen viel Glück, sie zu erreichen.
Es ist einfacher, einem Product Owner zu erklären, warum es an Freitagen oder vor Feiertagen keine Deployments gibt, als ein Problem ohne ein funktionierendes Entwicklungsteam zu beheben, wenn es passiert. Und glauben Sie mir, es spielt keine Rolle, wie viele Tests Sie durchführen, bevor Sie den Code versenden. Wenn Sie häufig bereitstellen, treten Probleme auf, sobald der Code live ist.
Ich sehe, dass viele Teams die Testautomatisierung vernachlässigen. Manchmal, weil es manuelle Qualitätssicherung gibt, andere, weil es einfach keinen Zeitplan für die Entwicklung von Tests gibt.
Automatisierte Tests garantieren, dass alles einwandfrei läuft, wenn sie bereitgestellt werden, und stellen außerdem sicher, dass neue Funktionen alten Code nicht kaputt machen. Wenn die Codebasis klein ist, können Sie ohne automatisierte Tests auskommen. Code altert jedoch nicht gut und Onkel Bob schrieb ein ganzes Buch um diesen Satz zu bekräftigen.
Wenn Sie keine automatisierten Tests entwickeln, wird es schwieriger sein, Änderungen vorzunehmen, die Leute werden Probleme haben, Ihrem Projekt beizutreten, wenn es wächst, neue Funktionen werden immer schwieriger bereitzustellen sein und am Ende wird es so viele Fehler in der Produktion geben, dass Ihr Bugreport schneller wächst, als Sie Patches bereitstellen können.
Stellen Sie immer sicher, dass automatisierte Tests bereits in den frühen Phasen der Entwicklung durchgeführt werden. Und wenn Sie fragen, „wie viel ist genug“, schauen Sie ruhig nach mein Artikel über das Thema.
Seit den ersten Ansätzen zur kontinuierlichen Integration Ende der 90er Jahre ist viel passiert (siehe Kent Beck's berühmte Buch Extreme Programming, neben anderen Veröffentlichungen aus dieser Zeit). Aber es gibt immer noch viele Teams, die diesen Ansatz nicht vom ersten Tag an anwenden und am Ende manuelle Bereitstellungsprozesse haben.
Der Weg, auf dem ein Feature oder ein Patch von einem Code-Repo zur Produktion gelangt, sollte ein klar definierter und automatisierter Prozess sein. Abgesehen davon, dass menschliche Fehler vermieden werden, gibt es dem Team das Selbstvertrauen, häufig zu implementieren, sodass die Produktverantwortlichen regelmäßig Feedback darüber erhalten, in welche Richtung sich das Produkt entwickelt, was auch die Erfolgschancen verbessert.
Ein Teil davon wurde bereits behandelt, als wir durchgingen, warum automatisierte Tests wichtig sind, aber das war nur ein untergeordneter Teil des QA-Prozesses. Automatisierte Tests per si stellen Sie einfach sicher, dass der Code bis zu einer bestimmten Abdeckung getestet wird und nichts weiter.
Ein guter QA-Prozess stellt sicher, dass der Code verifiziert wurde und gültig ist. Diese Phasen werden häufig als Überprüfungs- und Validierungsphasen des QA-Verfahrens bezeichnet.
Damit dies richtig implementiert wird, müssen wir sicherstellen, dass die Person, die den Code schreibt, ihn nicht verifiziert oder validiert. Auf diese Weise wird der Tunnelsichteffekt vermieden, der verhindert, dass Menschen ihre eigenen Fehler erkennen. Idealerweise sollte die Überprüfung (z. B. Code-Review) von einem anderen Entwickler und die Validierung (z. B. Feature-Demo) vom Product Owner durchgeführt werden.
Einer der großen Durchbrüche der Agiles Manifest war es, „Menschen über Prozesse“ zu stellen. Dies ist in der Tat der Schlüssel, um sicherzustellen, dass wir das volle Potenzial jedes einzelnen Mitglieds des Entwicklungsteams ausschöpfen. Aber Menschen über Prozesse zu stellen, heißt nicht, dass es überhaupt keine Prozesse geben sollte. Manche Leute sagen, dass sie keine Prozesse haben, aber nachdem sie einige Zeit miteinander gearbeitet haben, haben sie bestimmt eine Art, Dinge zu tun. Dies wird durch die Kombination persönlicher Erfahrungen definiert und entwickelt sich bei jeder Iteration weiter, bis es sich stabilisiert. Es ist der natürliche Prozess einer Gruppe, viel Wissen darüber zu sammeln, was für sie funktioniert und was nicht.
Wenn Sie einen Prozess von einem anderen Team übernehmen, verstehen Sie tatsächlich, was dieses Team gelernt hat. Prozesse existieren, weil Mitarbeiter herausfinden, welche Schritte oder Aufgaben in welcher Reihenfolge am besten funktionieren. Aus diesem Grund sind Prozesse Wissen. Außerdem entwickeln sich alle guten Prozesse weiter und ändern sich, wenn sich die Bedürfnisse ändern. Wenn Sie jedoch den Entwicklungsprozess Ihres Teams oder Projekts entwerfen, definieren Sie am besten zunächst, was Sie bereits tun, und überprüfen Sie dann anhand dieser Liste, ob Sie alle Punkte abgedeckt haben.
Hier, bei Imaginary Cloud, das haben wir immer im Hinterkopf, wenn wir eine Web- oder Mobil-App für unsere Kunden erstellen. Wenn Sie eines dieser digitalen Produkte entwickeln, helfen wir Ihnen gerne weiter! Schreiben Sie uns eine Nachricht hier!
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
