Adaptive S / W-Entwicklung - Kurzanleitung

Adaptive S / W-Entwicklung - Einführung

Was ist agil?

Literarisch bedeutet das Wort „agil“ jemanden, der sich schnell und leicht bewegen kann, oder jemanden, der schnell und klar denken und handeln kann. In der Wirtschaft wird „agil“ zur Beschreibung von Arbeitsplänen und -abläufen verwendet, bei denen Änderungen nach Bedarf ein wichtiger Bestandteil der Arbeit sind. Geschäftliche „Agilität“ bedeutet, dass ein Unternehmen immer in der Lage ist, den Marktveränderungen Rechnung zu tragen.

In der Softwareentwicklung wird der Begriff "agil" so verstanden, dass er "die Fähigkeit zum Reagieren auf Änderungen - Änderungen aufgrund von Anforderungen, Technologie und Mitarbeitern" - beschreibt.

Agiles Manifest

Das Agile Manifest wurde von einem Team von Softwareentwicklern im Jahr 2001 veröffentlicht. Dabei wurde die Bedeutung des Entwicklungsteams unter Berücksichtigung sich ändernder Anforderungen und der Kundenbeteiligung hervorgehoben.

Das Agile Manifest ist -

Wir entdecken bessere Wege, um Software zu entwickeln, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit sind wir zu Wert gekommen -

  • Individuen und Interaktionen über Prozesse und Werkzeuge.
  • Arbeitssoftware über umfangreiche Dokumentation.
  • Zusammenarbeit der Kunden bei Vertragsverhandlungen.
  • Reaktion auf eine Umstellung nach einem Plan.

Das heißt, während es Wert in den Gegenständen auf der rechten Seite gibt, schätzen wir die Gegenstände auf der linken Seite mehr.

Eigenschaften der Beweglichkeit

Es folgen die Merkmale von Agility -

  • Agility in Agile Software Development konzentriert sich auf die Kultur des gesamten Teams mit multidisziplinären, funktionsübergreifenden Teams, die gestärkt und selbstorganisierend sind.

  • Es fördert die gemeinsame Verantwortung und Rechenschaftspflicht.

  • Ermöglicht eine effektive Kommunikation und kontinuierliche Zusammenarbeit.

  • Der gesamte Teamansatz vermeidet Verzögerungen und Wartezeiten.

  • Häufige und kontinuierliche Lieferungen gewährleisten eine schnelle Rückmeldung, die es dem Team ermöglicht, sich an die Anforderungen anzupassen.

  • Die Zusammenarbeit erleichtert das zeitnahe Kombinieren verschiedener Perspektiven bei der Implementierung, das Beheben von Fehlern und das Eingehen auf Änderungen.

  • Fortschritt ist konstant, nachhaltig und vorhersehbar und betont Transparenz.

Agile Methoden

Zu den frühen Implementierungen agiler Methoden gehören Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development und Dynamic Systems Development Method (DSDM). Diese werden nach der Veröffentlichung des Agile-Manifests im Jahr 2001 nun gemeinsam als Agile-Methoden bezeichnet.

In diesem Tutorial lernen wir die Agile Methodik - Adaptive Softwareentwicklung .

Was ist adaptive Softwareentwicklung?

Die adaptive Softwareentwicklung ist ein Schritt in Richtung adaptiver Praktiken, wobei die deterministischen Praktiken im Kontext komplexer Systeme und komplexer Umgebungen bleiben. Die adaptive Softwareentwicklung konzentriert sich auf die Zusammenarbeit und das Lernen als eine Technik zum Aufbau komplexer Systeme. Es basiert auf den Best Practices von Rapid Application Development (RAD) und Evolutionary Life Cycles. Die adaptive Softwareentwicklung wurde dann um adaptive Ansätze für das Management erweitert, wobei die Spekulation die Planung ersetzte.

ASD-Lebenszyklus

Jim Highsmith veröffentlichte im Jahr 2000 ein Buch über adaptive Softwareentwicklung. In Highsmiths Worten -

„Die adaptive Softwareentwicklung verläuft zyklisch wie das Evolutionsmodell, wobei die Phasennamen Spekulieren, Zusammenarbeiten und Lernen den unvorhersehbaren Bereich immer komplexerer Systeme widerspiegeln. Adaptive Entwicklung geht in zweierlei Hinsicht über das evolutionäre Erbe hinaus. Erstens ersetzt es den Determinismus ausdrücklich durch die Entstehung. Zweitens geht es nicht nur um eine Änderung des Lebenszyklus, sondern auch um eine tiefgreifende Änderung des Managementstils. “

SDLC-Modelle - Evolution

Ein SDLC-Modell (Software Development Life Cycle) ist ein Framework, das die Aktivitäten beschreibt, die in jeder Phase eines Softwareentwicklungsprojekts ausgeführt werden.

In einem Software Development Life Cycle werden die Aktivitäten in fünf Phasen ausgeführt:

  • Anforderungserfassung - Die Anforderungen für eine zu entwickelnde Software werden erfasst. Diese Anforderungen werden in einer Sprache abgefasst, die vom Kunden / Benutzer verstanden wird. Eine domänenspezifische Terminologie wird empfohlen.

  • Analyse - Die gesammelten Anforderungen werden unter dem Gesichtspunkt der Implementierung analysiert und die Softwarespezifikationen werden geschrieben, um sowohl die funktionalen Anforderungen als auch die nicht funktionalen Anforderungen abzudecken.

  • Design - In dieser Phase werden die Softwarearchitektur und die Implementierungsspezifikationen basierend auf der für die Entwicklung ausgewählten Technologie festgelegt.

  • Konstruktion - In dieser Phase wird der Code entwickelt, die Einheit getestet, integriert, die Integration getestet und der Build erstellt.

  • Testen - In dieser Phase werden Funktionstests der erstellten Software durchgeführt. Dies schließt auch die Prüfung nichtfunktionaler Anforderungen ein.

Es gibt zwei Ansätze, um diese Aktivitäten durchzuführen:

  • Prescriptive - Die SDLC-Modelle, mit denen Sie die Aktivitäten auf vorgeschriebene Weise ausführen können, wie im Framework definiert.

  • Adaptiv - Die SDLC-Modelle, die Ihnen Flexibilität bei der Durchführung der Aktivitäten bieten und bestimmte Regeln enthalten, die befolgt werden müssen. Die agilen Methoden folgen meist diesem Ansatz, wobei jeder seine Regeln hat. Ein adaptiver oder agiler Ansatz bedeutet jedoch nicht, dass die Software ohne jegliche Disziplin entwickelt wird. Dies würde zu einem Chaos führen.

Sie müssen verstehen, dass wir nicht sagen können, dass ein bestimmtes SDLC-Modell gut oder schlecht ist. Jeder von ihnen hat seine eigenen Stärken und Schwächen und eignet sich daher in bestimmten Zusammenhängen.

Wenn Sie ein SDLC-Modell für Ihr Projekt auswählen, müssen Sie Folgendes verstehen:

  • Ihr Organisationskontext
  • Ihr Technologiekontext
  • Ihre Teamzusammensetzung
  • Ihr Kundenkontext

Wenn die Softwareentwicklung beispielsweise vorhersehbar ist, können Sie einen präskriptiven Ansatz verwenden. Wenn andererseits die Softwareentwicklung nicht vorhersehbar ist, dh die Anforderungen nicht vollständig bekannt sind oder das Entwicklungsteam nicht zuvor mit der aktuellen Domäne oder Technologie usw. vertraut ist, ist der adaptive Ansatz die beste Wahl.

In den folgenden Abschnitten werden die gängigsten SDLC-Modelle erläutert, die während der Ausführung von Softwareentwicklungsprojekten in der gesamten Branche entwickelt wurden. Sie lernen auch die Stärken und Schwächen jedes einzelnen von ihnen kennen und in welchem Kontext sie geeignet sind.

SDLC - Wasserfallmodell

Das Waterfall-Modell ist ein klassisches SDLC-Modell, das weithin bekannt ist, verstanden und allgemein verwendet wird. Es wurde 1970 von Royce eingeführt und wird in verschiedenen Organisationen der Branche immer noch als gemeinsamer Ansatz für die Softwareentwicklung verfolgt.

Im Wasserfallmodell kann jede Lebenszyklusphase erst nach Abschluss der früheren Lebenszyklusphase gestartet werden. Somit ist es ein lineares Modell ohne Rückkopplungsschleifen.

Wasserfall-Lebenszyklus

Wasserfallmodell - Stärken

Die Stärken des Wasserfallmodells sind:

  • Einfach zu verstehen, einfach zu bedienen.
  • Bietet dem unerfahrenen Entwicklungsteam Struktur.
  • Meilensteine sind gut verstanden.
  • Legt die Anforderungsstabilität fest.
  • Ideal für die Management-Kontrolle (Planung, Überwachung, Berichterstattung).
  • Funktioniert gut, wenn Qualität wichtiger ist als Kosten oder Zeitplan.

Wasserfallmodell - Schwächen

Die Schwächen oder Nachteile des Waterfall-Modells sind:

  • Idealisiert - Es passt nicht gut zur Realität.

  • Unrealistisch - kann keine genauen Anforderungen zu Beginn des Projekts erwarten.

  • Spiegelt nicht den häufigeren iterativen Charakter der explorativen Entwicklung wider.

  • Änderungen sind schwierig und teuer.

  • Die Software wird erst am Ende des Projekts geliefert. Aus diesem Grund -

    • Verzögert die Entdeckung schwerwiegender Mängel.

    • Möglichkeit der Lieferung von veralteten Anforderungen.

  • Erheblicher Verwaltungsaufwand, der für kleine Teams und Projekte kostspielig sein kann.

  • Benötigt in jeder Phase erfahrene Ressourcen - Analysten, Designer, Entwickler, Tester.

  • Das Testen beginnt erst, nachdem die Entwicklung abgeschlossen ist und die Tester an keiner der früheren Phasen beteiligt sind.

  • Die Expertise der funktionsübergreifenden Teams wird nicht geteilt, da jede Phase in Silos ausgeführt wird.

Wann wird das Wasserfallmodell verwendet?

Sie können das Wasserfallmodell verwenden, wenn -

  • Anforderungen sind sehr bekannt.

  • Die Produktdefinition ist stabil.

  • Technologie ist gut verstanden.

  • Neue Version eines vorhandenen Produkts.

  • Portierung eines vorhandenen Produkts auf eine neue Plattform.

  • Große Organisation mit strukturierten funktionsübergreifenden Teams.

  • Die Kommunikationskanäle sind sowohl innerhalb der Organisation als auch mit dem Kunden gut etabliert.

Evolutionäres Prototyping-Modell

Bei der Softwareentwicklung mit dem Evolutionary Prototyping-Modell erstellen die Entwickler während der Anforderungsphase einen Prototyp. Die Endbenutzer bewerten dann den Prototyp und geben Feedback. Das Feedback kann eine Korrektur des Prototyps oder eine zusätzliche Funktionalität sein. Basierend auf dem Feedback verfeinern die Entwickler den Prototyp weiter.

So entsteht das Produkt aus den Prototypen → Rückmeldungen → Verfeinerten Prototypenzyklen und daher der Name Evolutionary Prototyping. Wenn der Benutzer mit der Funktionalität und Funktionsweise des Produkts zufrieden ist, wird der Prototypcode auf die erforderlichen Standards für die endgültige Produktlieferung gebracht.

Endgültige Produktlieferung

Evolutionäres Prototyping-Modell - Stärken

Die Stärken oder Vorteile eines Evolutionary Prototyping-Modells sind:

  • Kunden / Endbenutzer können die Systemanforderungen anhand des Prototyps visualisieren.

  • Entwickler lernen von Kunden und damit keine Unklarheiten in Bezug auf Domäne oder Produktionsumgebung.

  • Ermöglicht flexibles Design und Entwicklung.

  • Die Interaktion mit dem Prototyp regt das Bewusstsein für zusätzlich benötigte Funktionalität an.

  • Unerwartete Anforderungen und Änderungen der Anforderungen können problemlos berücksichtigt werden.

  • Es entstehen stetige und sichtbare Zeichen des Fortschritts.

  • Lieferung eines genauen und wartbaren Endprodukts.

Evolutionäres Prototyping-Modell - Schwächen

Die Schwächen oder Nachteile des Evolutionary Prototyping-Modells sind:

  • Tendenz, die strukturierte Entwicklung in der Code-and-Fix-Entwicklung aufzugeben, obwohl dies vom Modell nicht vorgeschrieben wird.

  • Dieses Modell erhielt einen schlechten Ruf für die Quick-and-Dirty-Methoden.

  • Die allgemeine Wartbarkeit kann möglicherweise übersehen werden.

  • Der Kunde kann möglicherweise die Lieferung des Prototyps als endgültiges Produkt verlangen, ohne den Entwicklern die Möglichkeit zu geben, den letzten Schritt, dh die Standardisierung des Endprodukts, durchzuführen.

  • Das Projekt kann für immer fortgesetzt werden (mit kontinuierlichem Umfangschleichen) und das Management schätzt es möglicherweise nicht.

Wann ist das evolutionäre Prototyping-Modell zu verwenden?

Sie können das Evolutionary Prototyping-Modell verwenden -

  • Wenn Anforderungen instabil sind oder geklärt werden müssen
  • Als Anforderungsklärungsstufe eines Wasserfallmodells
  • Entwicklung von Benutzeroberflächen
  • Für kurzlebige Demonstrationen
  • Für Neu- oder Originalentwicklung
  • Zur Implementierung einer neuen Technologie

SDLC - Iteratives inkrementelles Modell

In einem iterativen inkrementellen Modell wird zunächst eine Teilimplementierung eines Gesamtsystems so konstruiert, dass es sich in einem lieferbaren Zustand befindet. Erhöhte Funktionalität wird hinzugefügt. Eventuelle Mängel aus der Vorlieferung werden behoben und das Arbeitsprodukt geliefert. Der Vorgang wird solange wiederholt, bis die gesamte Produktentwicklung abgeschlossen ist. Die Wiederholungen dieser Prozesse werden als Iterationen bezeichnet. Am Ende jeder Iteration wird ein Produktinkrement geliefert.

Iterationen

Iteratives inkrementelles Modell - Stärken

Die Vorteile oder Stärken des iterativen inkrementellen Modells sind:

  • Sie können zuerst priorisierte Anforderungen entwickeln.

  • Die Erstlieferung des Produkts erfolgt schneller.

  • Kunden erhalten frühzeitig wichtige Funktionen.

  • Senkt die anfänglichen Lieferkosten.

  • Jede Version ist ein Produktinkrement, sodass der Kunde jederzeit ein funktionsfähiges Produkt zur Hand hat.

  • Der Kunde kann zu jedem Produktschritt eine Rückmeldung geben und so Überraschungen am Ende der Entwicklung vermeiden.

  • Anforderungsänderungen können problemlos berücksichtigt werden.

Iteratives inkrementelles Modell - Schwächen

Die Nachteile des Iterativen Inkrementellen Modells sind:

  • Erfordert eine effektive Planung von Iterationen.

  • Erfordert ein effizientes Design, um die erforderliche Funktionalität zu gewährleisten und spätere Änderungen vorzusehen.

  • Erfordert die frühzeitige Definition eines vollständigen und voll funktionsfähigen Systems, um die Definition von Inkrementen zu ermöglichen.

  • Gut definierte Modulschnittstellen sind erforderlich, da einige lange vor anderen entwickelt werden.

  • Die Gesamtkosten des Gesamtsystems sind nicht niedriger.

Wann ist ein iteratives inkrementelles Modell zu verwenden?

Iteratives inkrementelles Modell kann verwendet werden, wenn -

  • Die meisten Anforderungen sind im Vorfeld bekannt, werden sich jedoch voraussichtlich im Laufe der Zeit weiterentwickeln.

  • Die Anforderungen werden priorisiert.

  • Grundlegende Funktionen müssen schnell bereitgestellt werden.

  • Ein Projekt hat lange Entwicklungszeiten.

  • Ein Projekt hat neue Technologien.

  • Die Domain ist neu im Team.

SDLC - Rapid Application Development Model

Das Rapid Application Development (RAD) -Modell besteht aus den folgenden Phasen:

  • Anforderungsplanungsphase - In der Anforderungsplanungsphase muss ein Workshop durchgeführt werden, um Geschäftsprobleme strukturiert zu diskutieren.

  • Benutzerbeschreibungsphase - In der Benutzerbeschreibungsphase werden automatisierte Tools verwendet, um Informationen von Benutzern zu erfassen.

  • Bauphase - In der Bauphase werden Produktivitätswerkzeuge wie Codegeneratoren, Bildschirmgeneratoren usw. in einer Zeitbox mit dem Ansatz „Bis zum Ende erledigen“ verwendet.

  • Cut-Over-Phase - In der Cut-Over-Phase werden die Installation des Systems, Benutzerakzeptanztests und Benutzerschulungen durchgeführt.

RAD-Phasen

Rapid Application Development Model - Stärken

Die Vorteile oder Stärken des Rapid Application Development-Modells sind:

  • Reduzierte Zykluszeit und verbesserte Produktivität mit weniger Teammitgliedern würden niedrigere Kosten bedeuten.

  • Die Einbeziehung des Kunden über den gesamten Zyklus hinweg minimiert das Risiko, die Kundenzufriedenheit und den Geschäftswert nicht zu erreichen.

  • Der Fokus bewegt sich in einem WYSIWYG-Modus (What-you-see-is-what-you-get-Modus) zum Code. Dies bringt Klarheit darüber, was gebaut wird, ist das Richtige.

  • Verwendet Modellierungskonzepte, um Informationen zu Unternehmen, Daten und Prozessen zu erfassen.

Rapid Application Development Model - Schwächen

Die Nachteile oder Stärken des Rapid Application Development-Modells sind:

  • Ein beschleunigter Entwicklungsprozess muss dem Benutzer schnelle Antworten geben.

  • Das Risiko, niemals geschlossen zu werden.

  • Schwer mit Legacy-Systemen zu verwenden.

  • Entwickler und Kunden müssen sich in einem verkürzten Zeitrahmen zu Sofortmaßnahmen verpflichten.

Wann sollte das Rapid Application Development Model verwendet werden?

Rapid Application Development-Modell kann verwendet werden, wenn -

  • Der Benutzer kann während des gesamten Lebenszyklus einbezogen werden.
  • Projekt kann zeitgesteuert werden.
  • Die Funktionalität kann in Schritten geliefert werden.

Obwohl die Stärken des Rapid Application Development-Modells geschätzt werden, wird es in der Industrie nur sparsam eingesetzt.

SDLC - Spiralmodell

Das Spiralmodell erweitert das Wasserfallmodell um Risikoanalyse und RAD-Prototyping. Jeder Zyklus umfasst dieselbe Abfolge von Schritten wie das Wasserfallmodell.

Spiralmodell

Das Spiralmodell hat vier Quadranten. Lassen Sie uns sie im Detail besprechen.

Quadrant 1 - Bestimmen Sie Ziele, Alternativen und Einschränkungen

  • Ziele - Funktionalität, Leistung, Hardware- / Software-Schnittstelle, kritische Erfolgsfaktoren usw.

  • Alternativen - Erstellen, Wiederverwenden, Kaufen, Untervertragen usw.

  • Einschränkungen - Kosten, Zeitplan, Schnittstelle usw.

Quadrant 2 - Alternativen bewerten, Risiken identifizieren und lösen

  • Studienalternativen in Bezug auf die festgelegten Ziele und Einschränkungen.

  • Identifizieren Sie Risiken wie mangelnde Erfahrung, neue Technologien, enge Zeitpläne usw.

  • Beheben Sie die identifizierten Risiken, indem Sie ihre Auswirkungen auf das Projekt bewerten, die erforderlichen Minderungs- und Notfallpläne ermitteln und diese umsetzen. Risiken müssen immer überwacht werden.

Quadrant 3 - Produkt der nächsten Stufe entwickeln

Typische Aktivitäten sind:

  • Erstellen Sie ein Design
  • Überprüfen Sie das Design
  • Code entwickeln
  • Code überprüfen
  • Produkt testen

Quadrant 4 - Planen Sie die nächste Phase

Typische Aktivitäten sind:

  • Projektplan entwickeln
  • Konfigurationsmanagementplan entwickeln
  • Entwickeln Sie einen Testplan
  • Entwickeln Sie einen Installationsplan

Spiralmodell - Stärken

Die Vorteile oder Stärken der Spiralmethode sind:

  • Bietet eine frühzeitige Erkennung der Risiken, ohne dass hohe Kosten anfallen.
  • Benutzer können das System aufgrund der Rapid-Prototyping-Tools frühzeitig anzeigen.
  • Kritische Hochrisikofunktionen werden zuerst entwickelt.
  • Das Design muss nicht perfekt sein.
  • Benutzer können in alle Lebenszyklusschritte eng einbezogen werden.
  • Frühes und häufiges Feedback von Nutzern.
  • Häufige kumulative Kosten.

Spiralmodell - Schwächen

Die Nachteile oder Schwächen der Spiral-Methode sind:

  • Es kann schwierig sein, Ziele und überprüfbare Meilensteine zu definieren, die auf die Bereitschaft hinweisen, die nächste Iteration zu durchlaufen.

  • Zeitaufwand für Planung, Zurücksetzen von Zielen, Risikoanalyse und Prototyping kann ein Aufwand sein.

  • Die für die Risikobewertung aufgewendete Zeit kann für kleine oder risikoarme Projekte zu lang sein.

  • Das Spiralmodell ist für neue Teammitglieder komplex zu verstehen.

  • Risikobewertungsexpertise ist erforderlich.

  • Die Spirale kann unbegrenzt weiterlaufen.

  • Entwickler müssen während der Aktivitäten außerhalb der Entwicklungsphase neu zugewiesen werden.

Wann wird das Spiralmodell verwendet?

Das Spiral-Modell kann verwendet werden, wenn:

  • Die Erstellung eines Prototyps ist angemessen.
  • Risikobewertung ist wichtig.
  • Ein Projekt ist von mittlerem bis hohem Risiko.
  • Benutzer sind sich ihrer Bedürfnisse nicht sicher.
  • Anforderungen sind komplex.
  • Die Produktlinie ist neu.
  • Während der Exploration werden signifikante Änderungen erwartet.
  • Langfristiges Projektengagement aufgrund möglicher geschäftlicher Veränderungen unklug.

SDLC - Agile Methoden

Agile Methoden basieren auf dem Agile-Manifest und sind adaptiver Natur. Agile Methoden sorgen für -

  • Gruppenarbeit.
  • Zusammenarbeit mit Kunden.
  • Ständige und kontinuierliche Kommunikation.
  • Reaktion auf Änderungen.
  • Bereitschaft eines funktionierenden Produkts.

Es entstanden mehrere agile Methoden, die die iterative und inkrementelle Entwicklung mit zeitlich begrenzten Iterationen förderten. Obwohl die agilen Methoden adaptiv sind, können die Regeln der spezifischen Methode nicht umgangen werden und erfordern daher eine disziplinierte Implementierung.

Agile Methoden - Stärken

Die Vorteile oder Stärken der Agile-Methode sind:

  • Frühe und häufige Veröffentlichungen.
  • Anpassung an sich ändernde Anforderungen.
  • Tägliche Kommunikation zwischen Kunden und Entwicklern.
  • Projekte rund um motivierte Menschen.
  • Selbstorganisierende Teams.
  • Einfachheit, Konzentration auf das, was sofort benötigt wird.
  • Kein Gebäude für die Zukunft oder Überlastung des Codes.
  • Regelmäßige Reflexion zur Anpassung des Verhaltens zur Verbesserung der Wirksamkeit.

Agile Methoden - Schwächen

Die Nachteile oder Schwächen der Spiral-Methode sind -

  • Kundenverfügbarkeit ist möglicherweise nicht möglich.

  • Teams sollten erfahren sein, die Regeln der Methode zu befolgen.

  • Eine angemessene Planung ist erforderlich, um schnell zu entscheiden, welche Funktionen in einer Iteration bereitgestellt werden müssen.

  • Das Team muss über Schätzungs- und Verhandlungsfähigkeiten verfügen.

  • Das Team sollte über effektive Kommunikationsfähigkeiten verfügen.

  • Neue Teams können sich möglicherweise nicht selbst organisieren.

  • Benötigt Disziplin, um sich in zeitlich begrenzten Iterationen zu entwickeln und umzusetzen.

  • Design muss einfach und wartbar gehalten werden, was effektive Designfähigkeiten erfordert.

Wann sollte man agile Methoden anwenden?

Die Agile-Methoden können verwendet werden, wenn:

  • Die Bewerbung ist zeitkritisch.

  • Der Anwendungsbereich ist begrenzt und weniger formal (eine Skalierung der agilen Methoden auf größere Projekte ist in Arbeit, wobei einige der agilen Methoden erweitert wurden).

  • Organisation setzt disziplinierte Methoden ein.

Adaptive Softwareentwicklung - Evolution

Die früheren SDLC-Modelle orientieren sich eher an den Praktiken von Stabilität, Vorhersehbarkeit und sinkenden Renditen. Die Branche, wie beispielsweise die Internetplattformen, ist bestrebt, die Renditeumgebungen zu verbessern und unvorhersehbare, nichtlineare und schnelle Ansätze zu entwickeln.

Adaptive Software Development (ASD) wurde entwickelt, um diese Probleme anzugehen. Es konzentriert sich auf das Hervortreten als den wichtigsten Faktor aus Sicht des Managements, um die Fähigkeit zu verbessern, die Produktentwicklung zu steuern.

In Jim Highsmiths Worten: „Das Adaptive Software Development Framework basiert auf jahrelanger Erfahrung mit traditionellen Software Development-Methoden, Beratung, Einüben und Schreiben über Rapid Application Development (RAD) -Techniken und der Zusammenarbeit mit High-Tech-Softwareunternehmen bei der Verwaltung ihrer Produktentwicklung Praktiken Methoden Ausübungen".

Es wurde festgestellt, dass das Wasserfallmodell durch Linearität und Vorhersagbarkeit mit magerem Feedback gekennzeichnet ist. Es kann als Folge von Plan → Erstellen → Implementieren angezeigt werden.

Wasserfall-Modell

Die evolutionären Lebenszyklusmodelle wie das Spiralmodell haben den deterministischen Ansatz auf den adaptiven mit Plan → Erstellen → Zyklen überarbeiten verschoben .

Evolutionärer Lebenszyklus

Die Denkweise der Praktizierenden blieb jedoch deterministisch, mit langfristiger Vorhersagbarkeit, die sich in kurzfristige Vorhersagbarkeit verwandelte. Die Praktiken von Evolutionary Lifecycle-Modellen wie RAD sind weniger deterministisch.

Der adaptive Lebenszyklus

Das adaptive Modell wird aus einem anderen Blickwinkel erstellt. Obwohl zyklisch wie das Evolutionsmodell, spiegeln die Namen der Phase die Unvorhersehbarkeit immer komplexerer Systeme wider.

Adaptive Entwicklung geht in zweierlei Hinsicht über das evolutionäre Erbe hinaus:

  • Es ersetzt ausdrücklich den Determinismus durch die Entstehung.

  • Es geht über eine Veränderung des Lebenszyklus hinaus zu einer tiefgreifenden Veränderung des Führungsstils.

Adaptiver S / W-Entwicklungslebenszyklus

Die drei Phasen des Adaptive Software Development Lifecycle sind:

  • Spekulieren - Spekulieren ersetzt die deterministische Wortplanung, die Planung von Produktspezifikationen oder die Planung von Projektmanagementaufgaben.

  • Kollaborieren - Kollaborieren steht für eine Balance zwischen

    • Management im traditionellen Projektmanagementsinn und

    • Schaffung und Pflege der für die Entstehung erforderlichen kollaborativen Umgebung.

  • Durch gemeinsame Aktivitäten werden Produkte erstellt, die das Tempo der Änderungen in der Umgebung berücksichtigen.

  • Lernen - Lernen zielt darauf ab, sowohl die Entwickler als auch die Kunden, die Ergebnisse jedes Entwicklungszyklus zu nutzen, um die Richtung des nächsten zu lernen.

Adaptive Softwareentwicklung - Konzepte

In diesem Kapitel werden die verschiedenen Konzepte der adaptiven Softwareentwicklung erläutert.

Komplexe Adaptive Systeme (CAS) Theorie

Brian Arthur und seine Kollegen vom Santa Fe Institute haben die Theorie der Komplexen Adaptiven Systeme (CAS) verwendet, um das Verständnis von Physik, Biologie, Evolution und Ökonomie zu revolutionieren.

Brian Arthur gipfelte in seinem mehr als zwei Jahrzehnte dauernden Versuch, etablierte Ökonomen davon zu überzeugen, dass ihre Sichtweise, die von den fundamentalen Annahmen sinkender Renditen, des Gleichgewichts und der deterministischen Dynamik dominiert wird, nicht mehr ausreicht, um die Realität zu verstehen. Die neue Welt ist geprägt von zunehmender Rendite, Instabilität und Unfähigkeit, Ursache und Wirkung zu bestimmen.

Die beiden Welten unterscheiden sich in Verhalten, Stil und Kultur. Sie fordern -

  • Unterschiedliche Managementtechniken
  • Unterschiedliche Strategien
  • Unterschiedliches Verständnis

Komplexe Softwareentwicklung

Mit der Explosion des Umfangs der Softwareanwendungen stoßen auch die Softwareentwicklungsorganisationen auf ähnliche Widersprüche wie oben erwähnt.

  • One World wird durch die deterministische Entwicklung repräsentiert, die sich aus Managementpraktiken ableitet, die auf den Grundlagen der Stabilität und Berechenbarkeit basieren (was in Arthurs Ausdrücken bedeutet, dass die Renditen sinken).

  • Second World wird durch die Branchen repräsentiert, die von abnehmenden zu wachsenden Renditeumgebungen wechseln, die unvorhersehbar, nichtlinear und schnell sind.

Um die Probleme dieser zweiten Welt anzugehen, bot Jig Highsmith das Framework Adaptive Software Development an, das sich von der deterministischen Softwareentwicklung unterscheidet.

Die Adaptive Software-Entwicklung konzentriert sich auf die Adressierung der komplexen Systeme -

  • Adaptive Softwareentwicklung für den Entwicklungslebenszyklus.

  • Adaptive Management-Techniken, die eine andere Denkweise erfordern als herkömmliche Projektmanagement-Praktiken.

In diesem Lernprogramm können Sie beide Implementierungen verstehen.

Adaptive Software Development (ASD) basiert auf zwei Perspektiven -

  • Konzeptionelle Perspektive basierend auf der Theorie der komplexen adaptiven Systeme (CAS), wie im ersten Abschnitt dieses Kapitels angegeben.

  • Praktische Perspektive basiert auf

    • Langjährige Erfahrung mit deterministischen Softwareentwicklungsmethoden.

    • Beratung, Übung und Schreiben über Rapid Application Development (RAD) -Techniken; und Zusammenarbeit mit High-Tech-Software-Unternehmen bei der Verwaltung ihrer Produktentwicklung.

In diesem Kapitel werden Sie die konzeptionelle Perspektive der adaptiven Softwareentwicklung verstehen.

Komplexe adaptive Systeme (CAS) Konzepte

Die Theorie komplexer adaptiver Systeme (CAS) hat viele Konzepte. Die adaptive Softwareentwicklung basiert auf zwei dieser Konzepte:

  • Entstehung
  • Komplexität

Entstehung

In komplexen Softwareproduktentwicklungsprojekten sind die Ergebnisse von Natur aus unvorhersehbar. In solchen Umgebungen entstehen jedoch immer wieder erfolgreiche Produkte.

Dies kann durch Emergenz geschehen, wie in der Theorie der komplexen adaptiven Systeme (CAS) dargestellt. Es kann anhand eines einfachen Beispiels das Flockverhalten von Vögeln verstanden werden.

Wenn Sie einen Vogelschwarm beobachten, bemerken Sie, dass -

  • Jeder Vogel versucht es

    • Halten Sie einen Mindestabstand zu anderen Objekten in der Umgebung ein, einschließlich anderer Vögel.

    • Passen Sie die Geschwindigkeiten an die Vögel in der Nachbarschaft an.

    • Bewegen Sie sich in Richtung des wahrgenommenen Massenzentrums der Vögel in seiner Nachbarschaft.

  • Es gibt keine Verhaltensregeln für die Gruppe. Die einzigen Regeln betreffen das Verhalten einzelner Vögel.

  • Es gibt jedoch ein aufstrebendes Verhalten, das Herden von Vögeln. Wenn irrtümliche Vögel aufholen, spaltet sich die Herde um Hindernisse und Reformen auf der anderen Seite.

Dies zeigt die Notwendigkeit der schwierigsten mentalen Modelländerungen in der adaptiven Entwicklung - von der Art und Weise, wie diese individuelle Freiheit verwaltet und organisiert wird, bis zu der Vorstellung, dass eine kreative neue Ordnung unvorhersehbar durch spontane Selbstorganisation entsteht.

Emergenz ist neben der Entwicklung auch aus Managementsicht das wichtigste Konzept.

Komplexität

Im Kontext der Softwareentwicklung geht es bei der Komplexität um:

  • Die Einzelpersonen eines Teams wie Entwickler, Kunden, Lieferanten, Wettbewerber und Aktionäre, ihre Anzahl und ihre Geschwindigkeit.

  • Größe und technologische Komplexität.

Praktiken der adaptiven Softwareentwicklung

Die adaptive Softwareentwicklung bietet eine andere Perspektive auf Software-Management-Praktiken. In den folgenden Abschnitten werden die beiden wichtigen Vorgehensweisen - Qualität und RAD - erläutert, die sich auf das Sammeln von Anforderungen auswirken.

Einzelheiten zu allen Vorgehensweisen finden Sie im Kapitel Adaptive Software Development Practices in diesem Lernprogramm.

Qualität

In einer komplexen Umgebung funktioniert die uralte Praxis von "Beim ersten Mal richtig machen" nicht, da Sie nicht vorhersagen können, was am Anfang richtig ist. Sie müssen ein Ziel haben, um den richtigen Wert zu erzielen. In einer komplexen Umgebung sind die Kombinationen und Permutationen von Wertkomponenten wie Umfang (Funktionen, Leistung, Fehlerstufen), Zeitplan und Ressourcen jedoch so groß, dass es niemals einen optimalen Wert geben kann. Daher liegt der Schwerpunkt auf einer Verlagerung, um den besten Wert auf dem Wettbewerbsmarkt zu erzielen.

RAD-Verfahren

RAD-Praktiken umfassen im Allgemeinen eine Kombination der folgenden:

  • Evolutionärer Lebenszyklus
  • Kundenfokusgruppen, JAD-Sitzungen, technische Überprüfungen
  • Zeitgesteuertes Projektmanagement
  • Kontinuierliche Softwareentwicklung
  • Engagierte Teams mit Kriegsräumen

Die RAD-Projekte haben einen inhärenten adaptiven, aufstrebenden Charakter. Viele IT-Organisationen sind gegen RAD. Microsoft und andere haben jedoch unglaublich große und komplexe Software mit Techniken erstellt, die mit RAD vergleichbar sind, da sie Fragen zu ihrer grundlegenden Weltanschauung aufwirft.

RAD-Verfahren und Microsoft-Prozesse sind Beispiele für die aktive adaptive Entwicklung. Indem Sie ihnen ein Label geben (dh Adaptive Entwicklung) und erkennen, dass es immer mehr wissenschaftliche Erkenntnisse gibt (dh CAS-Theorie), erklären Sie, warum sie funktionieren. Dies sollte eine Grundlage für eine umfassendere Anwendung dieser Praktiken bilden.

Adaptive Softwareentwicklung - Lebenszyklus

Die adaptive Softwareentwicklung hat sich aus den RAD-Praktiken entwickelt. Die Teamaspekte wurden ebenfalls zu diesen Praktiken hinzugefügt. Unternehmen von Neuseeland bis Kanada haben für eine Vielzahl von Projekt- und Produkttypen die adaptive Softwareentwicklung eingesetzt.

Jim Highsmith veröffentlichte 2000 Adaptive Software Development.

Praktiken der adaptiven Softwareentwicklung ermöglichen die Anpassung an Veränderungen und sind in turbulenten Umgebungen anpassbar, da sich Produkte mit geringem Planungs- und Lernaufwand weiterentwickeln.

Phasen des ASD-Lebenszyklus

Die adaptive Softwareentwicklung ist wie das Evolutionsmodell zyklisch, wobei die Phasennamen die Unvorhersehbarkeit in den komplexen Systemen widerspiegeln. Die Phasen im adaptiven Entwicklungslebenszyklus sind:

  • Spekulieren
  • Zusammenarbeiten
  • Lernen

Diese drei Phasen spiegeln die Dynamik der adaptiven Softwareentwicklung wider. Die adaptive Entwicklung ersetzt den Determinismus ausdrücklich durch die Entstehung. Es geht über eine bloße Veränderung des Lebenszyklus hinaus zu einer tiefgreifenden Veränderung des Managementstils. Die adaptive Softwareentwicklung hat einen dynamischen Spekulations-Kollaborations-Lern-Lebenszyklus.

Der Adaptive Software Development Lifecycle konzentriert sich auf Ergebnisse, nicht auf Aufgaben, und die Ergebnisse werden als Anwendungsmerkmale identifiziert.

Adaptiver Softwareentwicklungs-Lebenszyklus

Spekulieren

Der Begriff Plan ist zu deterministisch und weist auf einigermaßen sicheres Ergebnis hin. Das implizite und explizite Ziel der Planübereinstimmung schränkt die Fähigkeit des Managers ein, das Projekt in innovative Richtungen zu lenken.

In der adaptiven Softwareentwicklung wird der Begriff Plan durch den Begriff Spekulieren ersetzt. Während des Spekulierens gibt das Team die Planung nicht auf, erkennt jedoch die Realität der Unsicherheit bei komplexen Problemen an. Spekulieren regt zum Erforschen und Experimentieren an. Iterationen mit kurzen Zyklen werden empfohlen.

Zusammenarbeiten

Komplexe Anwendungen entstehen nicht, sie entstehen. Bei komplexen Anwendungen muss eine große Menge an Informationen gesammelt, analysiert und auf das Problem angewendet werden. In turbulenten Umgebungen ist der Informationsfluss hoch. Komplexe Anwendungen erfordern daher, dass eine große Menge an Informationen gesammelt, analysiert und auf das Problem angewendet wird. Daraus ergeben sich unterschiedliche Wissensanforderungen, die nur durch Teamzusammenarbeit bewältigt werden können.

Kollaborieren erfordert die Fähigkeit, gemeinsam Ergebnisse zu erzielen, Wissen auszutauschen oder Entscheidungen zu treffen.

Im Kontext des Projektmanagements stellt Collaboration ein Gleichgewicht zwischen der Verwaltung mit traditionellen Managementtechniken und der Schaffung und Aufrechterhaltung der für die Entstehung erforderlichen kollaborativen Umgebung her.

Lernen

Der Lernteil des Lebenszyklus ist entscheidend für den Erfolg des Projekts. Das Team muss sein Wissen ständig verbessern, indem es Praktiken anwendet wie:

  • Technische Bewertungen
  • Projektrückblicke
  • Kundenfokusgruppen

Überprüfungen sollten nach jeder Iteration durchgeführt werden. Sowohl die Entwickler als auch die Kunden überprüfen ihre Annahmen und verwenden die Ergebnisse jedes Entwicklungszyklus, um die Richtung des nächsten zu ermitteln. Das Team lernt -

  • Über Produktänderungen

  • Grundlegendere Änderungen der zugrunde liegenden Annahmen zur Entwicklung der Produkte

Die Iterationen müssen kurz sein, damit das Team aus kleinen und nicht aus großen Fehlern lernen kann.

Spekulieren - Zusammenarbeiten - Zyklus als Ganzes lernen

Wie Sie aus dem oben angegebenen Zyklus Spekulieren - Zusammenarbeiten - Lernen ersehen können, sind die drei Phasen offensichtlich nichtlinear und überlappen sich.

Wir beobachten das Folgende aus einem adaptiven Rahmen.

  • Es ist schwierig, zusammenzuarbeiten, ohne zu lernen, oder zu lernen, ohne zusammenzuarbeiten.

  • Es ist schwierig zu spekulieren, ohne zu lernen oder zu lernen, ohne zu spekulieren.

  • Es ist schwierig zu spekulieren, ohne zusammenzuarbeiten, oder zusammenzuarbeiten, ohne zu spekulieren.

Lebenszyklus-Eigenschaften

Adaptive Software Development Lifecycle weist sechs grundlegende Merkmale auf:

  • Mission konzentriert
  • Funktionsbasiert
  • Iterativ
  • Time-Boxed
  • Risiko getrieben
  • Toleranz ändern

In diesem Kapitel werden Sie diese sechs Merkmale der adaptiven Softwareentwicklung verstehen.

Mission konzentriert

Bei vielen Projekten ist die Gesamtaufgabe, die das Team leitet, gut formuliert, obwohl die Anforderungen zu Beginn des Projekts möglicherweise ungewiss sind. Leitbilder sind Leitfäden, die zu Beginn der Erforschung anregen, aber im Verlauf eines Projekts einen engen Fokus haben. Eine Mission bietet eher Grenzen als ein festes Ziel. Mission Statements und die Diskussionen, die zu diesen Statements führen, liefern Anweisungen und Kriterien für kritische Projektkompromissentscheidungen.

Ohne eine klare Mission und eine konstante Missionsverfeinerungspraxis werden iterative Lebenszyklen zu oszillierenden Lebenszyklen, die ohne Fortschritt in der Entwicklung hin und her schwingen.

Funktionsbasiert

Der Adaptive Software Development Lifecycle basiert auf Anwendungsfunktionen und nicht auf Aufgaben. Features sind die Funktionen, die während einer Iteration basierend auf den Prioritäten des Kunden entwickelt werden.

Features können sich über mehrere Iterationen entwickeln, wenn die Kunden Feedback geben.

Die Anwendungsfunktionen, die dem Kunden nach der Implementierung direkte Ergebnisse liefern, sind primär. Ein kundenorientiertes Dokument wie ein Benutzerhandbuch wird ebenfalls als Merkmal betrachtet. Die anderen Dokumente wie das Datenmodell, auch wenn sie als Liefergegenstände definiert sind, sind immer zweitrangig.

Iterativ

Der Adaptive Software Development Lifecycle ist iterativ und konzentriert sich auf häufige Veröffentlichungen, um Feedback zu erhalten, das resultierende Lernen zu verarbeiten und die richtige Richtung für die weitere Entwicklung festzulegen.

Time-Boxed

Im Adaptive Software Development Lifecycle sind die Iterationen zeitlich begrenzt. Man sollte jedoch bedenken, dass es beim Time-Boxing in der adaptiven Softwareentwicklung nicht um Fristen geht. Es sollte nicht verwendet werden, um das Team stundenlang dazu zu bringen, eine kollaborative Umgebung in Frage zu stellen oder Kompromisse bei der Qualität der zu erbringenden Leistungen einzugehen.

In der adaptiven Softwareentwicklung wird das Time-Boxing als eine Richtung betrachtet, um schwierige Kompromissentscheidungen nach Bedarf zu fokussieren und zu forcieren. In einer unsicheren Umgebung, in der die Änderungsraten hoch sind, muss es eine periodische Forcierungsfunktion geben, z. B. eine Timebox, um die Arbeit abzuschließen.

Risikogetrieben

In der adaptiven Softwareentwicklung werden die Iterationen durch die Identifizierung und Bewertung der kritischen Risiken gesteuert.

Änderungstolerant

Die adaptive Softwareentwicklung ist änderungstolerant und betrachtet Änderungen als die Fähigkeit, Wettbewerbsvorteile zu nutzen, jedoch nicht als Entwicklungsproblem.

Adaptive Softwareentwicklung - Praktiken

Die Praktiken der adaptiven Softwareentwicklung basieren auf der Überzeugung einer kontinuierlichen Anpassung, wobei der Lebenszyklus so ausgelegt ist, dass kontinuierliche Änderungen als Norm akzeptiert werden.

Adaptive Software Development Lifecycle widmet sich:

  • Fortlaufendes Lernen
  • Ändern Sie die Ausrichtung
  • Neubewertung
  • Ein Blick in eine ungewisse Zukunft
  • Intensive Zusammenarbeit zwischen Entwicklern, Management und Kunden

Adaptive SDLC

Die adaptive Softwareentwicklung kombiniert RAD mit Best Practices für das Software-Engineering, wie z.

  • Projektinitiierung.
  • Adaptive Zyklusplanung.
  • Concurrent Component Engineering.
  • Qualitätsüberprüfung.
  • Endgültige Qualitätssicherung und Freigabe.

Die Praktiken der adaptiven Softwareentwicklung können wie folgt dargestellt werden:

Praktische Lernschleife

Wie oben dargestellt, sind die Praktiken der adaptiven Softwareentwicklung wie folgt auf die drei Phasen verteilt:

  • Spekulieren - Initiierung und Planung

    • Projektinitiierung

    • Zeitrahmen für das gesamte Projekt festlegen

    • Legen Sie die Anzahl der Iterationen fest und weisen Sie jedem eine Zeitbox zu

    • Entwickeln Sie für jede der Iterationen ein Thema oder Ziel

    • Weisen Sie jeder Iteration Features zu

  • Zusammenarbeiten - Gleichzeitige Entwicklung von Funktionen

    • Zusammenarbeit für verteilte Teams

    • Zusammenarbeit für kleinere Projekte

    • Zusammenarbeit für größere Projekte

  • Lernen - Qualitätsprüfung

    • Ergebnisqualität aus Kundensicht

    • Ergebnisqualität aus technischer Sicht

    • Die Funktionsweise des Lieferteams und der Mitglieder des Praxisteams wird genutzt

    • Der Projektstatus

Spekulieren - Initiierung und Planung

In der adaptiven Softwareentwicklung umfasst die Spekulationsphase zwei Aktivitäten:

  • Initiation
  • Planung

Speculate verfügt über fünf Methoden, die während der Initiierungs- und Planungsphase wiederholt ausgeführt werden können. Sie sind -

  • Projektinitiierung
  • Zeitrahmen für das gesamte Projekt festlegen
  • Legen Sie die Anzahl der Iterationen fest und weisen Sie jedem eine Zeitbox zu
  • Entwickeln Sie für jede der Iterationen ein Thema oder Ziel
  • Weisen Sie jeder Iteration Features zu

Projektinitiierung

Projektinitiierung beinhaltet -

  • Festlegung der Mission und Ziele des Projekts
  • Einschränkungen verstehen
  • Aufbau der Projektorganisation
  • Anforderungen identifizieren und umreißen
  • Erste Schätzungen zu Größe und Umfang
  • Identifizierung der wichtigsten Projektrisiken

Die Projektinitiierungsdaten sollten in einer vorläufigen JAD-Sitzung gesammelt werden, wobei Geschwindigkeit als Hauptaspekt betrachtet wird. Die Einführung kann in konzentrierten zwei bis fünf Tagen für kleine bis mittlere Projekte oder in zwei bis drei Wochen für größere Projekte abgeschlossen werden.

Während der JAD-Sitzungen werden die Anforderungen detailliert genug erfasst, um Merkmale zu identifizieren und einen Überblick über das Objekt, die Daten oder andere Architekturmodelle zu erhalten.

Zeitfenster für das gesamte Projekt einrichten

Der Zeitrahmen für das gesamte Projekt sollte auf der Grundlage des Umfangs, der Featureanforderungen, der Schätzungen und der Ressourcenverfügbarkeit festgelegt werden, die sich aus der Projektinitiierungsarbeit ergeben.

Wie Sie wissen, gibt das Spekulieren das Schätzen nicht auf, sondern bedeutet nur, zu akzeptieren, dass Schätzungen falsch sein können.

Iterationen und Time-Box

Legen Sie die Anzahl der Iterationen und die einzelnen Iterationslängen fest, basierend auf dem Gesamtprojektumfang und dem Grad der Unsicherheit.

Für eine kleine bis mittlere Anwendung -

  • Iterationen variieren normalerweise zwischen vier und acht Wochen.
  • Einige Projekte funktionieren am besten mit zweiwöchigen Iterationen.
  • Einige Projekte benötigen möglicherweise mehr als acht Wochen.

Wählen Sie die Zeit, basierend darauf, was für Sie funktioniert. Wenn Sie die Anzahl der Iterationen und die Länge der einzelnen Iterationen festgelegt haben, weisen Sie jeder Iteration einen Zeitplan zu.

Entwickeln Sie ein Thema oder ein Ziel

Die Teammitglieder sollten für jede Iteration ein Thema oder ein Ziel entwickeln. Dies ähnelt dem Sprintziel in Scrum. Jede Iteration sollte eine Reihe von Funktionen bereitstellen, die die Produktfunktionalität demonstrieren und das Produkt für den Kunden sichtbar machen, um eine Überprüfung und ein Feedback zu ermöglichen.

Innerhalb der Iterationen sollten die Builds möglichst täglich Arbeitsfunktionen bereitstellen, die den Integrationsprozess ermöglichen und das Produkt für das Entwicklungsteam sichtbar machen. Das Testen sollte ein fester Bestandteil der Funktionsentwicklung sein. Es sollte nicht bis zum Ende des Projekts verschoben werden.

Features zuweisen

Entwickler und Kunden sollten jeder Iteration gemeinsam Features zuweisen. Das wichtigste Kriterium für diese Funktionszuweisung ist, dass jede Iteration dem Kunden einen sichtbaren Satz von Funktionen mit beträchtlicher Funktionalität liefern muss.

Während der Zuweisung von Features zu den Iterationen -

  • Das Entwicklungsteam sollte die Feature-Schätzungen, Risiken und Abhängigkeiten ausarbeiten und diese dem Kunden zur Verfügung stellen.

  • Kunden sollten anhand der vom Entwicklungsteam bereitgestellten Informationen über die Priorisierung von Funktionen entscheiden.

Die Iterationsplanung erfolgt daher funktionsbasiert im Team mit Entwicklern und Kunden. Die Erfahrung hat gezeigt, dass diese Art der Planung das Projekt besser versteht als eine aufgabenbasierte Planung durch den Projektmanager. Darüber hinaus spiegelt die merkmalsbasierte Planung die Einzigartigkeit jedes Projekts wider.

Zusammenarbeiten ─ Gleichzeitige Entwicklung von Funktionen

In der Collaborate-Phase liegt der Fokus auf der Entwicklung. Die Kollaborationsphase umfasst zwei Aktivitäten:

  • Das Entwicklungsteam arbeitet zusammen und liefert funktionierende Software.

  • Die Projektmanager erleichtern die Zusammenarbeit und die gleichzeitige Entwicklung von Aktivitäten.

Zusammenarbeit ist ein gemeinsamer Schöpfungsakt, der das Entwicklungsteam, die Kunden und die Manager umfasst. Geteilte Schöpfung wird durch Vertrauen und Respekt gefördert.

Teams sollten zusammenarbeiten an -

  • Technische Probleme
  • Geschäftsanforderungen
  • Schnelle Entscheidungsfindung

Im Folgenden sind die für die Phase der Zusammenarbeit in der adaptiven Softwareentwicklung relevanten Vorgehensweisen aufgeführt:

  • Zusammenarbeit für verteilte Teams
  • Zusammenarbeit für kleinere Projekte
  • Zusammenarbeit für größere Projekte

Zusammenarbeit für verteilte Teams

Bei Projekten mit verteilten Teams sollte Folgendes berücksichtigt werden:

  • Unterschiedliche Allianzpartner
  • Breites Wissen
  • Die Art und Weise, wie Menschen miteinander umgehen
  • Wie sie mit Abhängigkeiten umgehen

Zusammenarbeit für kleinere Projekte

In den kleineren Projekten sollte die Zusammenarbeit mit informellen Flurchats und Whiteboards gefördert werden, wenn die Teammitglieder in physischer Nähe arbeiten, da dies als effektiv erachtet wird.

Zusammenarbeit für größere Projekte

Größere Projekte erfordern zusätzliche Vorgehensweisen, Tools für die Zusammenarbeit und die Interaktion mit Projektmanagern und sollten kontextbezogen angeordnet werden.

Lernen - Qualitätsprüfung

Die adaptive Softwareentwicklung fördert das Konzept des Experimentierens und Lernens.

Um aus den Fehlern und Experimenten zu lernen, müssen die Teammitglieder teilweise vervollständigten Code und Artefakte frühzeitig freigeben, um

  • Finde Fehler
  • Lerne von ihnen
  • Reduzieren Sie Nacharbeiten, indem Sie kleine Probleme finden, bevor sie zu großen werden

Am Ende jeder Entwicklungsiteration gibt es vier allgemeine Kategorien von Dingen, die gelernt werden müssen:

  • Ergebnisqualität aus Kundensicht
  • Ergebnisqualität aus technischer Sicht
  • Die Arbeitsweise des Zustellteams und des Praxisteams
  • Der Projektstatus

Ergebnisqualität aus Kundensicht

In den Adaptive Software Development-Projekten hat das Einholen von Kundenfeedback oberste Priorität. Die empfohlene Vorgehensweise hierfür ist eine Kundenfokusgruppe. Diese Sitzungen dienen dazu, ein Arbeitsmodell der Anwendung zu untersuchen und Änderungsanforderungen von Kunden aufzuzeichnen.

Kundenfokusgruppensitzungen sind vereinfachte Sitzungen, ähnlich wie JAD-Sitzungen, aber anstatt Anforderungen zu generieren oder Projektpläne zu definieren, dienen sie dazu, die Anwendung selbst zu überprüfen. Die Kunden geben Feedback zur funktionierenden Software, die sich aus einer Iteration ergibt.

Ergebnisqualität aus technischer Sicht

In den Projekten zur adaptiven Softwareentwicklung sollte eine regelmäßige Überprüfung der technischen Artefakte wichtig sein. Code Reviews sollten kontinuierlich durchgeführt werden. Überprüfungen anderer technischer Artefakte, z. B. der technischen Architektur, können wöchentlich oder am Ende einer Iteration durchgeführt werden.

In Projekten zur adaptiven Softwareentwicklung sollte das Team seine eigene Leistung regelmäßig überwachen. Rückblicke ermutigen die Teams, sich und ihre Arbeit im Team kennenzulernen.

Retrospektiven am Ende der Wiederholung erleichtern die regelmäßige Selbstüberprüfung der Teamleistung, z.

  • Stellen Sie fest, was nicht funktioniert.
  • Was das Team braucht, um mehr zu tun.
  • Was das Team weniger tun muss.

Der Projektstatus

Die Projektstatusüberprüfung hilft bei der Planung weiterer Arbeiten. In adaptiven Softwareentwicklungsprojekten erfolgt die Ermittlung des Projektstatus nach einem funktionsbasierten Ansatz, wobei das Ende jeder Iteration durch abgeschlossene Funktionen gekennzeichnet ist und zu einer funktionierenden Software führt.

Die Überprüfung des Projektstatus sollte Folgendes umfassen:

  • Wo ist das Projekt?
  • Wo ist das Projekt im Vergleich zu den Plänen?
  • Wo soll das Projekt sein?

Da die Pläne in den Adaptive Software Development-Projekten spekulativ sind, ist Frage 3 wichtiger als die oben gestellte Frage 2. Das heißt, das Projektteam und die Kunden müssen sich ständig fragen: "Was haben wir bisher gelernt und ändert sich dadurch unsere Perspektive, wohin wir gehen müssen?"

Adaptive S / W-Entwicklung - Management

Ein Flussdiagramm der traditionellen Softwareverwaltung ist unten dargestellt.

Neubewertung

Traditionelles Software-Management wird als Befehlssteuerung bezeichnet.

Viele Unternehmen haben eine Tradition der Optimierung, Effizienz, Vorhersehbarkeit, Kontrolle, Genauigkeit und Prozessverbesserung. Die sich abzeichnende Wirtschaft des Informationszeitalters erfordert jedoch Anpassungsfähigkeit, Geschwindigkeit, Zusammenarbeit, Improvisation, Flexibilität, Innovation und Geschmeidigkeit.

Harvard Business Review und Management Books haben Begriffe wie Empowerment, Partizipatives Management, Lernende Organisation, Human-Centered Management usw. formuliert, aber keine davon wird in die Verwaltung moderner Organisationen einbezogen.

Im Kontext der adaptiven Softwareentwicklung sieht die Lücke viel größer aus, und es besteht die Notwendigkeit, die Techniken des adaptiven Managements zu berücksichtigen, die sich in anderen Bereichen als erfolgreich erwiesen haben.

Adaptives Management

Adaptives Management hat sich in Umgebungen bewährt, in denen die Ressourcenmanager mit Interessengruppen und Wissenschaftlern als Team zusammengearbeitet haben, mit folgenden Zielen:

  • Erfahren Sie, wie verwaltete Systeme auf menschliche Eingriffe reagieren.

  • Zukünftige Verbesserung der Ressourcenrichtlinien und -praktiken.

Das Prinzip hinter adaptivem Management ist, dass viele Ressourcenmanagementaktivitäten Experimente sind, da ihre Ergebnisse nicht zuverlässig vorhergesagt werden können. Diese Experimente werden dann als Lernmöglichkeiten für zukünftige Verbesserungen genutzt.

Das adaptive Management soll die Fähigkeit verbessern, rechtzeitig auf neue Informationen und unter Berücksichtigung unterschiedlicher Ziele und Präferenzen der Stakeholder zu reagieren. Sie ermutigt die Interessengruppen, Streitigkeiten zu binden und sie in geordneter Weise zu erörtern, während die Umweltunsicherheiten untersucht und besser verstanden werden.

Das adaptive Management hilft den Stakeholdern, Managern und anderen Entscheidungsträgern, die Grenzen des Wissens und die Notwendigkeit zu erkennen, auf unvollständige Informationen zu reagieren.

Das adaptive Management hilft, die getroffenen Entscheidungen zu ändern, indem es klarstellt, dass

  • Die Entscheidungen sind vorläufig.
  • Die Entscheidung eines Managements muss nicht immer richtig sein.
  • Änderungen werden erwartet.

Es gibt zwei Arten von adaptiven Managementansätzen:

  • Passives adaptives Management.
  • Aktives adaptives Management.

Passives adaptives Management

Das adaptive Management zielt darauf ab, die wissenschaftlichen Kenntnisse zu verbessern und dadurch Unsicherheiten zu verringern.

Passiv Adaptiv

Innerhalb des passiven adaptiven Managements wird eine einzelne bevorzugte Vorgehensweise ausgewählt, die auf vorhandenen Informationen und Kenntnissen basiert. Die Ergebnisse von Managementmaßnahmen werden überwacht und nachfolgende Entscheidungen werden basierend auf den Ergebnissen angepasst.

Dieser Ansatz trägt zum Lernen und effektiven Management bei. Es ist jedoch nur eingeschränkt in der Lage, wissenschaftliche und Managementfähigkeiten für Bedingungen zu verbessern, die über die gewählte Vorgehensweise hinausgehen.

Aktives adaptives Management

Ein Active Adaptive Management-Ansatz überprüft die Informationen, bevor Verwaltungsmaßnahmen ergriffen werden.

Aktiv adaptiv

Anstelle eines einzelnen Modells wird dann eine Reihe von konkurrierenden alternativen Systemmodellen des Ökosystems und der damit verbundenen Reaktionen (z. B. demografische Veränderungen; Freizeitnutzung) entwickelt. Die Managementoptionen werden basierend auf den Bewertungen dieser alternativen Modelle ausgewählt.

Leadership-Collaboration-Management

Das adaptive Management eignet sich am besten für die adaptive Softwareentwicklung. Der Ansatz erfordert Ressourcenmanager, dh Manager, die mit Menschen arbeiten, menschliche Eingriffe zulassen und ein freundschaftliches Umfeld schaffen können.

In der Softwareentwicklung nehmen die Führungskräfte diese Aufgaben häufig wahr. Wir brauchen mehr Führer als Kommandeure. Die Führungskräfte sind Mitarbeiter und arbeiten mit dem Team zusammen. Collaborative-Leadership ist die gefragteste Übung in der adaptiven Entwicklung.

Die Führer haben die folgenden Eigenschaften -

  • Fassen Sie und geben Sie die Richtung vor.

  • Beeinflussen Sie die Beteiligten und geben Sie Orientierung.

  • Arbeiten Sie zusammen, erleichtern Sie und verwalten Sie das Team auf Makroebene.

  • Die Richtung angeben.

  • Schaffen Sie Umgebungen, in denen talentierte Mitarbeiter innovativ und kreativ sein und effektive Entscheidungen treffen können.

  • Verstehe, dass sie gelegentlich befehlen müssen, aber das ist nicht ihr vorherrschender Stil.