Was ist eine agile Methodik? Moderne Softwareentwicklung erklärt

Jede Technologieorganisation scheint heute die agile Methodik für die Softwareentwicklung oder eine Version davon zu praktizieren. Oder zumindest glauben sie es. Egal, ob Sie neu in der agilen Anwendungsentwicklung sind oder vor Jahrzehnten die Softwareentwicklung mithilfe der Wasserfall-Softwareentwicklungsmethode gelernt haben, heute wird Ihre Arbeit zumindest von der agilen Methodik beeinflusst.

Aber was ist eine agile Methodik und wie sollte sie in der Softwareentwicklung praktiziert werden? Wie unterscheidet sich die agile Entwicklung in der Praxis vom Wasserfall? Was ist der agile Softwareentwicklungslebenszyklus oder agile SDLC? Und was ist Scrum Agile im Vergleich zu Kanban und anderen agilen Modellen? 

Agile wurde 2001 offiziell ins Leben gerufen, als 17 Technologen das Agile Manifest entwarfen. Sie haben vier Hauptprinzipien für ein agiles Projektmanagement geschrieben, mit dem Ziel, bessere Software zu entwickeln:

  • Individuen und Interaktionen über Prozesse und Werkzeuge
  • Arbeitssoftware über umfassende Dokumentation
  • Kundenzusammenarbeit über Vertragsverhandlungen
  • Antworten auf Umstellung nach einem Plan

Vor der Agilität: Die Ära der Wasserfallmethode

Alte Hasen wie ich erinnern sich an die Tage, als die Wasserfallmethode der Goldstandard für die Softwareentwicklung war. Der Softwareentwicklungsprozess erforderte eine Menge Dokumentation im Voraus, bevor mit der Codierung begonnen wurde. Jemand, normalerweise der Geschäftsanalyst, hat zuerst ein Geschäftsanforderungsdokument geschrieben, das alles erfasst, was das Geschäft in der Anwendung benötigt. Diese Geschäftsanforderungsdokumente waren lang und enthielten alles: Gesamtstrategie, umfassende Funktionsspezifikationen und visuelle Benutzeroberflächendesigns.

Technologen nahmen das Geschäftsanforderungsdokument und entwickelten ihr eigenes technisches Anforderungsdokument. In diesem Dokument wurden die Architektur der Anwendung, Datenstrukturen, objektorientierte Funktionsdesigns, Benutzeroberflächen und andere nicht funktionale Anforderungen definiert.

Dieser Wasserfall-Softwareentwicklungsprozess würde schließlich die Codierung, dann die Integration und schließlich das Testen einleiten, bevor eine Anwendung als produktionsbereit angesehen wurde. Der gesamte Prozess kann leicht einige Jahre dauern.

Von uns Entwicklern wurde erwartet, dass sie „die Spezifikation“ kennen, wie die vollständige Dokumentation genannt wurde, genau wie die Autoren der Dokumente, und wir wurden oft bestraft, wenn wir vergaßen, ein auf Seite 77 eines 200- beschriebenen Schlüsseldetail ordnungsgemäß zu implementieren. Seitendokument.

Auch die Softwareentwicklung selbst war damals nicht einfach. Viele Entwicklungstools erforderten spezielle Schulungen, und es gab nicht annähernd die heute existierenden Open Source- oder kommerziellen Softwarekomponenten, APIs und Webdienste. Wir mussten die einfachen Dinge wie das Öffnen von Datenbankverbindungen und das Multithreading unserer Datenverarbeitung entwickeln.

Selbst für grundlegende Anwendungen waren die Teams groß und die Kommunikationsmittel begrenzt. Unsere technischen Spezifikationen haben uns ausgerichtet, und wir haben sie wie die Bibel eingesetzt. Wenn sich eine Anforderung ändern würde, würden wir die Unternehmensleiter einem langen Überprüfungs- und Abmeldeprozess unterziehen, da die Kommunikation von Änderungen im gesamten Team und die Korrektur von Code teuer waren.

Da die Software auf der Grundlage der technischen Architektur entwickelt wurde, wurden zuerst Artefakte auf niedrigerer Ebene und danach abhängige Artefakte entwickelt. Die Aufgaben wurden nach Fähigkeiten zugewiesen, und es war üblich, dass Datenbankingenieure zuerst die Tabellen und andere Datenbankartefakte erstellten, gefolgt von den Anwendungsentwicklern, die die Funktionalität und Geschäftslogik codierten, und schließlich wurde die Benutzeroberfläche überlagert. Es dauerte Monate, bis irgendjemand sah, dass die Anwendung funktionierte, und bis dahin wurden die Stakeholder nervös und oft schlauer darüber, was sie wirklich wollten. Kein Wunder, dass die Implementierung von Änderungen so teuer war!

Nicht alles, was Sie den Benutzern vorlegen, hat wie erwartet funktioniert. Manchmal verwendeten Benutzer eine Funktion überhaupt nicht. In anderen Fällen war eine Funktion weitgehend erfolgreich, erforderte jedoch ein Reengineering, um die erforderliche Skalierbarkeit und Leistung zu unterstützen. In der Wasserfallwelt haben Sie diese Dinge erst nach der Bereitstellung der Software nach einem langen Entwicklungszyklus gelernt.

In Verbindung stehendes Video: Wie die agile Methodik wirklich funktioniert

Alle scheinen über agile Softwareentwicklung zu sprechen, aber viele Unternehmen haben keine genaue Vorstellung davon, wie der Prozess funktioniert. Sehen Sie sich dieses fünfminütige Video an, um schnell auf den neuesten Stand zu kommen.

Der Dreh- und Angelpunkt für eine agile Softwareentwicklung

Die 1970 erfundene Wasserfallmethode war revolutionär, da sie die Softwareentwicklung disziplinierte, um sicherzustellen, dass eine klare Spezifikation eingehalten werden konnte. Es basierte auf der Wasserfall-Herstellungsmethode, die aus den Fließbandinnovationen von Henry Ford aus dem Jahr 1913 abgeleitet wurde und die Sicherheit für jeden Schritt im Produktionsprozess bot, um sicherzustellen, dass das Endprodukt den Spezifikationen entsprach.

Als die Wasserfallmethode in die Softwarewelt kam, waren Computersysteme und ihre Anwendungen in der Regel komplex und monolithisch und erforderten eine Disziplin und ein klares Ergebnis. Die Anforderungen änderten sich im Vergleich zu heute ebenfalls langsam, sodass groß angelegte Anstrengungen weniger problematisch waren. Tatsächlich wurden Systeme unter der Annahme gebaut, dass sie sich nicht ändern würden, sondern ewige Schlachtschiffe wären. Mehrjährige Zeitrahmen waren nicht nur in der Softwareentwicklung, sondern auch in der Fertigung und anderen Unternehmensaktivitäten üblich. Aber die Starrheit des Wasserfalls wurde zu einer Achillesferse im Internet-Zeitalter, in dem Geschwindigkeit und Flexibilität erforderlich waren.

Die Methodik der Softwareentwicklung begann sich zu ändern, als Entwickler anfingen, an Internetanwendungen zu arbeiten. Ein Großteil der frühen Arbeiten wurde bei Startups durchgeführt, bei denen die Teams kleiner waren, zusammengeschlossen waren und häufig keinen traditionellen Hintergrund in der Informatik hatten. Es gab finanziellen und Wettbewerbsdruck, um Websites, Anwendungen und neue Funktionen schneller auf den Markt zu bringen. Die Entwicklungstools und -plattformen änderten sich schnell.

Dies führte dazu, dass viele von uns in Startups die Wasserfallmethode in Frage stellten und nach Wegen suchten, effizienter zu sein. Wir konnten es uns nicht leisten, die gesamte detaillierte Dokumentation im Voraus zu erstellen, und wir brauchten einen iterativeren und kollaborativeren Prozess. Wir haben immer noch über Änderungen der Anforderungen diskutiert, waren jedoch offener für Experimente und für die Anpassung an die Bedürfnisse der Endbenutzer. Unsere Organisationen waren weniger strukturiert und unsere Anwendungen waren weniger komplex als Unternehmens-Legacy-Systeme. Daher waren wir viel offener für das Erstellen und Kaufen von Anwendungen. Noch wichtiger ist, dass wir versucht haben, Unternehmen auszubauen. Als unsere Benutzer uns sagten, dass etwas nicht funktioniert, haben wir uns meistens entschieden, ihnen zuzuhören.

Unsere Fähigkeiten und unsere Innovationsfähigkeit wurden strategisch wichtig. Sie könnten das Geld sammeln, das Sie wollten, aber Sie könnten keine talentierten Softwareentwickler gewinnen, die mit sich schnell ändernden Internet-Technologien arbeiten können, wenn Sie sie als unterwürfige Programmierer behandeln würden, die sklavisch „der Spezifikation“ folgen. Wir lehnten Projektmanager ab, die End-to-End-Zeitpläne vorlegten, in denen beschrieben wurde, was wir entwickeln sollten, wann Anwendungen ausgeliefert werden sollten und manchmal sogar, wie der Code strukturiert werden sollte. Wir waren schrecklich darin, die Drei- und Sechsmonatspläne einzuhalten, die die Wasserfall-Projektmanager entworfen und unaufhörlich aktualisiert hatten.

Stattdessen haben wir ihnen erklärt, wie Internetanwendungen entwickelt werden müssen, und wir haben Ergebnisse nach einem Zeitplan geliefert, den wir iterativ erstellt haben. Es stellte sich heraus, dass wir nicht so schlecht darin waren, das zu liefern, was wir versprochen hatten, als wir uns in kleinen Intervallen von einer Woche bis vier Wochen dazu verpflichtet hatten.

Im Jahr 2001 kam eine Gruppe erfahrener Softwareentwickler zusammen und stellte fest, dass sie gemeinsam Softwareentwicklung praktizieren, die sich von der klassischen Wasserfallmethode unterscheidet. Und sie waren nicht alle in Startups. Diese Gruppe, zu der die Technologiegrößen Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber und Jeff Sutherland gehörten, entwickelte das Agile Manifest, das ihre gemeinsamen Überzeugungen darüber dokumentierte, wie ein moderner Softwareentwicklungsprozess funktionieren sollte. Sie betonten die Zusammenarbeit in Bezug auf Dokumentation, Selbstorganisation statt strenger Managementpraktiken und die Fähigkeit, ständige Veränderungen zu bewältigen, anstatt sich auf einen starren Wasserfallentwicklungsprozess festzulegen.

Aus diesen Prinzipien entstand die agile Methodik für die Softwareentwicklung.

Die Rollen in der agilen Methodik

Ein agiler Softwareentwicklungsprozess beginnt immer damit, die Benutzer zu definieren und eine Vision zu einer Reihe von Problemen, Chancen und Werten zu dokumentieren, die angegangen werden müssen. Der Product Owner erfasst diese Vision und arbeitet mit einem multidisziplinären Team (oder Teams) zusammen, um diese Vision umzusetzen. Hier sind die Rollen in diesem Prozess.

Nutzer

Agile Prozesse beginnen immer mit Blick auf den Benutzer oder Kunden. Heutzutage definieren wir sie häufig mit Benutzer-Personas, um verschiedene Rollen in einem von der Software unterstützten Workflow oder verschiedene Arten von Kundenbedürfnissen und -verhalten zu veranschaulichen.

Product Owner

Der agile Entwicklungsprozess selbst beginnt mit jemandem, der die Stimme des Kunden sein muss, einschließlich aller internen Stakeholder. Diese Person destilliert alle Erkenntnisse, Ideen und Rückmeldungen, um eine Produktvision zu erstellen. Diese Produktvisionen sind oft kurz und unkompliziert, vermitteln jedoch ein Bild davon, wer der Kunde ist, welche Werte angesprochen werden und wie diese angegangen werden können. Ich kann mir vorstellen, dass Googles ursprüngliche Vision ungefähr so ​​aussah: "Machen wir es jedem mit Internetzugang einfach, relevante Websites und Webseiten mit einer einfachen, schlüsselwortgesteuerten Oberfläche und einem Algorithmus zu finden, der seriöse Quellen in den Suchergebnissen höher einstuft."

Wir nennen diese Person den Product Owner . Seine oder ihre Verantwortung ist es, diese Vision zu definieren und dann mit einem Entwicklungsteam zusammenzuarbeiten, um sie zu verwirklichen.

Um mit dem Entwicklungsteam zusammenzuarbeiten, unterteilt der Product Owner die Produktvision in eine Reihe von User Stories, in denen detaillierter dargelegt wird, wer der Zielbenutzer ist, welches Problem für ihn gelöst wird, warum die Lösung für ihn wichtig ist und Welche Einschränkungen und Akzeptanzkriterien definieren die Lösung? Diese User Stories werden vom Product Owner priorisiert und vom Team überprüft, um sicherzustellen, dass sie ein gemeinsames Verständnis darüber haben, was von ihnen verlangt wird.

Softwareentwicklungsteam

In Agile unterscheiden sich das Entwicklerteam und die Verantwortlichkeiten seiner Mitglieder von denen in der traditionellen Softwareentwicklung.

Die Teams sind multidisziplinär und setzen sich aus einer vielfältigen Gruppe von Personen zusammen, die über die erforderlichen Fähigkeiten verfügen, um ihre Arbeit zu erledigen. Da der Schwerpunkt auf der Bereitstellung funktionierender Software liegt, muss das Team durchgängig funktionierende Anwendungen ausführen. Daher werden die Datenbank, die Geschäftslogik und die Benutzeroberfläche eines Teils der Anwendung entwickelt und anschließend vorgeführt - nicht die gesamte Anwendung. Dazu müssen die Teammitglieder zusammenarbeiten. Sie treffen sich häufig, um sicherzustellen, dass jeder darauf ausgerichtet ist, was er baut, wer was tut und wie die Software genau entwickelt wird.

Neben Entwicklern können Softwareentwicklungsteams je nach Art des Softwareprojekts Qualitätssicherungsingenieure, andere Ingenieure (z. B. für Datenbanken und Back-End-Systeme), Designer und Analysten umfassen.

Scrum, Kanban und andere agile Frameworks

Viele agile Frameworks, die Einzelheiten zu Entwicklungsprozessen und agilen Entwicklungspraktiken enthalten und auf einen Lebenszyklus der Softwareentwicklung abgestimmt sind.

Das beliebteste agile Framework heißt Scrum . Es konzentriert sich auf eine Zustellungskadenz, die als Sprint- und Besprechungsstrukturen bezeichnet wird und Folgendes umfasst:

  • Planung - wo Sprint-Prioritäten identifiziert werden
  • Engagement - Hier überprüft das Team eine Liste oder einen Rückstand von User Stories und entscheidet, wie viel Arbeit in der Sprintdauer geleistet werden kann 
  • Tägliche Standup-Meetings - damit Teams Updates zu ihrem Entwicklungsstatus und ihren Strategien kommunizieren können)

Sprints enden mit einem Demo-Meeting, in dem dem Product Owner die Funktionalität gezeigt wird, gefolgt von einem retrospektiven Meeting, in dem das Team bespricht, was gut gelaufen ist und was in seinem Prozess verbessert werden muss.

Viele Organisationen beschäftigen Scrum-Master oder Coaches, um Teams bei der Verwaltung des Scrum-Prozesses zu unterstützen.

Obwohl Scrum dominiert, gibt es andere agile Frameworks:

  • Kanban arbeitet als Fan-In- und Fan-Out-Prozess, bei dem das Team User Stories von einem Aufnahmebrett abruft und sie durch einen abgestuften Entwicklungsprozess führt, bis sie abgeschlossen sind.
  • Einige Organisationen verfolgen einen hybriden Agil- und Wasserfall-Ansatz, bei dem agile Prozesse für neue Anwendungen und Wasserfall für ältere Anwendungen verwendet werden.
  • Es gibt auch verschiedene Frameworks, mit denen Organisationen die Praxis auf mehrere Teams skalieren können.

Während agile Frameworks Prozesse und Zusammenarbeit definieren, sind agile Entwicklungspraktiken spezifisch für die Bewältigung von Softwareentwicklungsaufgaben, die in Übereinstimmung mit einem agilen Framework ausgeführt werden.

Also zum Beispiel:

  • Einige Teams verwenden die Paarprogrammierung, bei der zwei Entwickler gemeinsam Code entwickeln, um Code mit höherer Qualität zu erzielen und mehr erfahrenen Entwicklern die Betreuung von Junior-Entwicklern zu ermöglichen.
  • Fortgeschrittenere Teams setzen testgetriebene Entwicklung und Automatisierung ein, um sicherzustellen, dass die zugrunde liegende Funktionalität die erwarteten Ergebnisse liefert.
  • Viele Teams übernehmen auch technische Standards, sodass die Interpretation einer User Story durch den Entwickler nicht nur zu der gewünschten Funktionalität führt, sondern auch Sicherheit, Codequalität, Namenskonventionen und andere technische Standards erfüllt.

Warum die agile Methodik besser ist