Adaptive S / W-Entwicklung - Kurzanleitung

Was ist agil?

Literarisch bedeutet das Wort „agil“ jemanden, der sich schnell und einfach bewegen kann, oder jemanden, der schnell und klar denken und handeln kann. In der Wirtschaft wird „agil“ verwendet, um Planungs- und Arbeitsweisen zu beschreiben, wobei es selbstverständlich ist, dass das Vornehmen von Änderungen nach Bedarf ein wichtiger Teil der Arbeit ist. Geschäftsagilität bedeutet, dass ein Unternehmen immer in der Lage ist, die Marktveränderungen zu berücksichtigen.

In der Softwareentwicklung bedeutet der Begriff „agil“ „die Fähigkeit, auf Änderungen zu reagieren - Änderungen aufgrund von Anforderungen, Technologie und Mitarbeitern“.

Agiles Manifest

Das Agile Manifest wurde 2001 von einem Team von Softwareentwicklern veröffentlicht. Es unterstreicht die Bedeutung des Entwicklungsteams, berücksichtigt sich ändernde Anforderungen und die Einbeziehung der Kunden.

Das Agile Manifest ist -

Wir entdecken bessere Möglichkeiten zur Entwicklung von Software, 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 umfassende Dokumentation.
Kundenzusammenarbeit über Vertragsverhandlungen.
Antworten auf Umstellung nach einem Plan.

Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr.

Eigenschaften der Beweglichkeit

Im Folgenden sind die Merkmale der Beweglichkeit aufgeführt:

Agilität in der agilen Softwareentwicklung konzentriert sich auf die Kultur des gesamten Teams mit multidisziplinären, funktionsübergreifenden Teams, die befähigt und selbstorganisierend sind.
Es fördert die gemeinsame Verantwortung und Rechenschaftspflicht.
Ermöglicht effektive Kommunikation und kontinuierliche Zusammenarbeit.
Der Ansatz des gesamten Teams vermeidet Verzögerungen und Wartezeiten.
Häufige und kontinuierliche Lieferungen gewährleisten ein schnelles Feedback, das es dem Team wiederum ermöglicht, sich an den Anforderungen auszurichten.
Durch die Zusammenarbeit können verschiedene Perspektiven zeitnah bei der Implementierung kombiniert, Fehler behoben und Änderungen berücksichtigt werden.
Der Fortschritt ist konstant, nachhaltig und vorhersehbar und betont die Transparenz.

Agile Methoden

Zu den frühen Implementierungen agiler Methoden gehören Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Softwareentwicklung, 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 Software Development.

Was ist adaptive Softwareentwicklung?

Adaptive Softwareentwicklung ist ein Schritt in Richtung adaptiver Praktiken, wobei die deterministischen Praktiken im Kontext komplexer Systeme und komplexer Umgebungen belassen werden. Die adaptive Softwareentwicklung konzentriert sich auf Zusammenarbeit und Lernen als 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 Spekulationen die Planung ersetzten.

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

„Adaptive Softwareentwicklung ist wie das Evolutionsmodell zyklisch, wobei die Phasennamen Spekulieren, zusammenarbeiten, lernen den unvorhersehbaren Bereich immer komplexer werdender Systeme widerspiegeln. Die adaptive Entwicklung geht in zweierlei Hinsicht über ihr evolutionäres Erbe hinaus. Erstens ersetzt es explizit den Determinismus durch die Entstehung. Zweitens geht es über eine Änderung des Lebenszyklus hinaus zu einer tieferen Änderung des Führungsstils. “

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:

Requirements Gathering- Die Anforderungen an eine zu entwickelnde Software werden gesammelt. Diese Anforderungen werden in einer Sprache verfasst, die vom Kunden / Benutzer verstanden wird. Eine domänenspezifische Terminologie wird empfohlen.
Analysis - Die gesammelten Anforderungen werden unter dem Gesichtspunkt der Implementierung analysiert und die Softwarespezifikationen werden so geschrieben, dass sie sowohl die funktionalen als auch die nicht funktionalen Anforderungen abdecken.
Design - In dieser Phase werden die Softwarearchitektur und die Implementierungsspezifikationen basierend auf der für die Entwicklung ausgewählten Technologie ermittelt.
Construction - In dieser Phase wird der Code entwickelt, Unit-getestet, integriert, Integrationstest und der Build erstellt.
Testing- In dieser Phase werden Funktionstests der erstellten Software durchgeführt. Dies beinhaltet auch die Prüfung nicht funktionaler Anforderungen.

Es gibt zwei Ansätze zur Durchführung dieser Aktivitäten:

Prescriptive - Die SDLC-Modelle, mit denen Sie die Aktivitäten auf vorgeschriebene Weise ausführen können, wie im Framework definiert.
Adaptive- Die SDLC-Modelle, die Ihnen Flexibilität bei der Durchführung der Aktivitäten bieten, mit bestimmten Regeln, die befolgt werden müssen. Die agilen Methoden folgen meist diesem Ansatz, wobei jede ihre Regeln hat. Ein adaptiver oder agiler Ansatz bedeutet jedoch nicht, dass die Software ohne 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 ist daher in bestimmten Kontexten geeignet.

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 Prescriptive-Ansatz verwenden. Wenn andererseits die Softwareentwicklung nicht vorhersehbar ist, dh die Anforderungen nicht vollständig bekannt sind oder das Entwicklungsteam zuvor nicht mit der aktuellen Domäne oder Technologie usw. vertraut war, ist der adaptive Ansatz die beste Wahl.

In den folgenden Abschnitten werden Sie die gängigsten SDLC-Modelle kennenlernen, 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 kennen und in welchen Kontexten sie geeignet sind.

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

Im Wasserfallmodell kann jede Lebenszyklusphase erst beginnen, nachdem die frühere Lebenszyklusphase abgeschlossen ist. Somit ist es ein lineares Modell ohne Rückkopplungsschleifen.

Wasserfallmodell - Stärken

Die Stärken des Wasserfallmodells sind -

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

Wasserfallmodell - Schwächen

Die Schwächen oder Nachteile des Wasserfallmodells sind -

Idealisiert - Es passt nicht gut zur Realität.
Unrealistisch - kann zu Beginn des Projekts keine genauen Anforderungen erwarten.
Spiegelt nicht den iterativen Charakter der explorativen Entwicklung wider, der häufiger vorkommt.
Es ist schwierig und teuer, Änderungen vorzunehmen.
Software wird erst am Ende des Projekts geliefert. Aus diesem Grund -
- Verzögert die Entdeckung schwerwiegender Mängel.
- Möglichkeit der Lieferung veralteter Anforderungen.
Erheblicher Verwaltungsaufwand, der für kleine Teams und Projekte kostspielig sein kann.
Benötigt erfahrene Ressourcen in jeder Phase - Analysten, Designer, Entwickler, Tester.
Das Testen beginnt erst, nachdem die Entwicklung abgeschlossen ist und die Tester an keiner der früheren Phasen beteiligt sind.
Das Fachwissen der funktionsübergreifenden Teams wird nicht geteilt, da jede Phase in Silos ausgeführt wird.

Wann soll das Wasserfallmodell verwendet werden?

Sie können das Wasserfallmodell verwenden, wenn -

Anforderungen sind sehr bekannt.
Die Produktdefinition ist stabil.
Technologie ist gut verstanden.
Neue Version eines vorhandenen Produkts.
Portieren eines vorhandenen Produkts auf eine neue Plattform.
Große Organisation mit strukturierten funktionsübergreifenden Teams.
Kommunikationskanäle sind innerhalb der Organisation und 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 Korrekturen am Prototyp oder zusätzliche Funktionen sein. Basierend auf dem Feedback verfeinern die Entwickler den Prototyp weiter.

Somit entwickelt sich das Produkt durch den Prototyp → Feedback → Verfeinerte Prototypzyklen und daher den Namen Evolutionäres 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.

Evolutionäres Prototyping-Modell - Stärken

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

Kunden / Endbenutzer können die Systemanforderungen beim Sammeln des Prototyps visualisieren.
Entwickler lernen von Kunden und daher keine Unklarheiten in Bezug auf Domäne oder Produktionsumgebung.
Ermöglicht flexibles Design und Entwicklung.
Die Interaktion mit dem Prototyp fördert das Bewusstsein für zusätzlich benötigte Funktionen.
Unerwartete Anforderungen und Anforderungsänderungen 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 wie folgt:

Tendenz, die strukturierte Entwicklung in der Code-and-Fix-Entwicklung aufzugeben, obwohl dies nicht das Modell ist.
Dieses Modell erhielt einen schlechten Ruf für die schnellen und schmutzigen Methoden.
Die allgemeine Wartbarkeit kann möglicherweise übersehen werden.
Der Kunde kann möglicherweise die Lieferung des Prototyps als endgültiges Produkt anfordern, ohne den Entwicklern die Möglichkeit zu geben, den letzten Schritt, dh die Standardisierung des Endprodukts, auszuführen.
Das Projekt kann für immer fortgesetzt werden (mit kontinuierlichem Umfangskriechen) und das Management wird es möglicherweise nicht zu schätzen wissen.

Wann sollte das evolutionäre Prototyping-Modell verwendet werden?

Sie können das Evolutionary Prototyping-Modell verwenden -

Wenn Anforderungen instabil sind oder geklärt werden müssen
Als Anforderungsklärungsstufe eines Wasserfallmodells
Benutzeroberflächen entwickeln
Für kurzlebige Demonstrationen
Für neue oder originelle Entwicklung
Zur Implementierung einer neuen Technologie

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

Iteratives inkrementelles Modell - Stärken

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

Sie können zuerst priorisierte Anforderungen entwickeln.
Die anfängliche Produktlieferung ist schneller.
Kunden erhalten frühzeitig wichtige Funktionen.
Senkt die anfänglichen Lieferkosten.
Jede Version ist ein Produktinkrement, sodass der Kunde jederzeit ein funktionierendes Produkt zur Hand hat.
Der Kunde kann zu jedem Produktschritt Feedback geben und so Überraschungen am Ende der Entwicklung vermeiden.
Anforderungsänderungen können leicht berücksichtigt werden.

Iteratives inkrementelles Modell - Schwächen

Die Nachteile des iterativen inkrementellen Modells sind -

Erfordert eine effektive Planung der Iterationen.
Erfordert ein effizientes Design, um die erforderliche Funktionalität einzubeziehen und Änderungen später bereitzustellen.
Erfordert eine 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 der Entwicklung anderer entwickelt werden.
Die Gesamtkosten des Gesamtsystems sind nicht niedriger.

Wann sollte das iterative inkrementelle Modell verwendet werden?

Das iterative inkrementelle Modell kann verwendet werden, wenn -

Die meisten Anforderungen sind im Voraus bekannt, werden sich jedoch voraussichtlich im Laufe der Zeit weiterentwickeln.
Die Anforderungen werden priorisiert.
Die Grundfunktionalität muss schnell bereitgestellt werden.
Ein Projekt hat lange Entwicklungspläne.
Ein Projekt hat neue Technologie.
Die Domain ist neu im Team.

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

Requirements Planning phase - In der Anforderungsplanungsphase muss ein Workshop durchgeführt werden, um Geschäftsprobleme strukturiert zu diskutieren.
User Description phase - In der Phase Benutzerbeschreibung werden automatisierte Tools verwendet, um Informationen von Benutzern zu erfassen.
Construction phase - In der Bauphase werden Produktivitätswerkzeuge wie Codegeneratoren, Bildschirmgeneratoren usw. innerhalb einer Zeitbox mit dem Ansatz „Do till Done“ verwendet.
Cut Over phase - In der Cut-Over-Phase werden die Installation des Systems, Benutzerakzeptanztests und Benutzerschulungen durchgeführt.

Schnelles Anwendungsentwicklungsmodell - Stärken

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

Eine kürzere Zykluszeit und eine verbesserte Produktivität mit weniger Teammitgliedern würden niedrigere Kosten bedeuten.
Die Einbeziehung des Kunden während des gesamten Zyklus minimiert das Risiko, dass Kundenzufriedenheit und Geschäftswert nicht erreicht werden.
Der Fokus bewegt sich in einem WYSIWYG-Modus (WYSIWYG) 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 wie folgt:

Der beschleunigte Entwicklungsprozess muss dem Benutzer schnelle Antworten geben.
Risiko, niemals einen Abschluss zu erreichen.
Schwer zu verwenden mit Legacy-Systemen.
Entwickler und Kunden müssen sich in einem verkürzten Zeitraum zu Schnellfeueraktivitäten verpflichten.

Wann sollte das Rapid Application Development Model verwendet werden?

Das Rapid Application Development-Modell kann verwendet werden, wenn -

Der Benutzer kann während des gesamten Lebenszyklus einbezogen werden.
Das Projekt kann zeitlich festgelegt werden.
Die Funktionalität kann schrittweise geliefert werden.

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

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

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

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

Objectives - Funktionalität, Leistung, Hardware- / Software-Schnittstelle, kritische Erfolgsfaktoren usw.
Alternatives - Bauen, wiederverwenden, kaufen, untervergeben usw.
Constraints - Kosten, Zeitplan, Schnittstelle usw.

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

Studieren Sie Alternativen in Bezug auf die festgelegten Ziele und Einschränkungen.
Identifizieren Sie Risiken wie mangelnde Erfahrung, neue Technologien, enge Zeitpläne usw.
Lösen Sie die identifizierten Risiken, indem Sie deren Auswirkungen auf das Projekt bewerten, die erforderlichen Minderungs- und Notfallpläne ermitteln und umsetzen. Risiken müssen immer überwacht werden.

Quadrant 3 - Entwickeln Sie ein Produkt der nächsten Stufe

Typische Aktivitäten sind -

Erstellen Sie ein Design
Design überprüfen
Code entwickeln
Code überprüfen
Produkt testen

Quadrant 4 - Nächste Phase planen

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 einen frühzeitigen Hinweis auf die Risiken, ohne große Kosten zu verursachen.
Benutzer können das System dank der Rapid Prototyping-Tools frühzeitig anzeigen.
Kritische Hochrisikofunktionen werden zuerst entwickelt.
Das Design muss nicht perfekt sein.
Benutzer können eng in alle Lebenszyklusschritte eingebunden werden.
Frühes und häufiges Feedback von Benutzern.
Kumulierte Kosten werden häufig bewertet.

Spiralmodell - Schwächen

Die Nachteile oder Schwächen der Spiralmethode sind -

Es kann schwierig sein, Ziele zu definieren, überprüfbare Meilensteine, die auf die Bereitschaft hinweisen, mit der nächsten Iteration fortzufahren.
Der Zeitaufwand für die Planung, das Zurücksetzen von Zielen, die Durchführung von Risikoanalysen und das Prototyping kann ein Overhead sein.
Der Zeitaufwand für die Risikobewertung kann für kleine oder risikoarme Projekte zu groß sein.
Das Spiralmodell ist für neue Teammitglieder komplex zu verstehen.
Fachwissen zur Risikobewertung ist erforderlich.
Die Spirale kann auf unbestimmte Zeit fortgesetzt werden.
Entwickler müssen während Aktivitäten außerhalb der Entwicklungsphase neu zugewiesen werden.

Wann wird das Spiralmodell verwendet?

Das Spiralmodell 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.
Produktlinie ist neu.
Während der Exploration werden signifikante Änderungen erwartet.
Langfristiges Projektengagement aufgrund möglicher geschäftlicher Änderungen unklug.

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

Gruppenarbeit.
Kundenzusammenarbeit.
Ständige und kontinuierliche Kommunikation.
Reaktion auf Änderungen.
Bereitschaft eines Arbeitsprodukts.

Es entstanden mehrere agile Methoden, die die iterative und inkrementelle Entwicklung mit Iterationen im Zeitrahmen fördern. 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 agilen 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, die sich auf das konzentriert, 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 Spiralmethode sind -

Kundenverfügbarkeit ist möglicherweise nicht möglich.
Die Teams sollten Erfahrung darin haben, die Regeln der Methode zu befolgen.
Eine angemessene Planung ist erforderlich, um schnell zu entscheiden, welche Funktionen in einer Iteration bereitgestellt werden müssen.
Es wird erwartet, dass das Team über Schätz- und Verhandlungsfähigkeiten verfügt.
Das Team sollte über effektive Kommunikationsfähigkeiten verfügen.
Neue Teams können sich möglicherweise nicht selbst organisieren.
Erfordert Disziplin, um Iterationen in Zeitrahmen zu entwickeln und bereitzustellen.
Das Design muss einfach und wartbar gehalten werden und erfordert daher effektive Designfähigkeiten.

Wann sollten agile Methoden angewendet werden?

Die agilen Methoden können verwendet werden, wenn -

Die Anwendung ist zeitkritisch.
Der Umfang ist begrenzt und weniger formal (die Skalierung agiler Methoden auf größere Projekte ist im Gange, mit bestimmten Erweiterungen einiger agiler Methoden).
Die Organisation setzt disziplinierte Methoden ein.

Die früheren SDLC-Modelle orientieren sich eher an den Praktiken der Stabilität, Vorhersagbarkeit und sinkenden Renditen. Die Branche wie die Internetplattformen hat sich bemüht, die Renditeumgebungen, unvorhersehbare, nichtlineare und schnelle Ansätze zu verbessern.

Die adaptive Softwareentwicklung (ASD) wurde entwickelt, um diese Probleme anzugehen. Der Schwerpunkt liegt auf der Entstehung als wichtigster Faktor aus Sicht des Managements, um die Fähigkeit zur Verwaltung der Produktentwicklung zu verbessern.

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

Das Wasserfallmodell zeichnet sich durch Linearität und Vorhersagbarkeit mit geringem Feedback aus. Es kann als eine Folge von angesehen werdenPlan → Build → Implement.

Die evolutionären Lebenszyklusmodelle wie das Spiralmodell haben den deterministischen Ansatz auf den adaptiven mit verschoben Plan → Build → Revise Cycles.

Die Denkweise der Praktizierenden blieb jedoch deterministisch, und die langfristige Vorhersagbarkeit wandelte sich der kurzfristigen Vorhersagbarkeit zu. Die Praktiken von evolutionären Lebenszyklusmodellen wie RAD sind weniger deterministisch.

Der adaptive Lebenszyklus

Das adaptive Modell ist aus einem anderen Blickwinkel aufgebaut. Obwohl zyklisch wie das Evolutionsmodell, spiegeln die Namen der Phase die Unvorhersehbarkeit zunehmend komplexer Systeme wider.

Die adaptive Entwicklung geht in zweierlei Hinsicht weiter als ihr evolutionäres Erbe -

Es ersetzt explizit den Determinismus durch Emergenz.
Es geht über eine Änderung des Lebenszyklus hinaus zu einer tieferen Änderung des Führungsstils.

Die drei Phasen des adaptiven Softwareentwicklungslebenszyklus sind:

Speculate - Spekulieren ersetzt die deterministische Wortplanung, Planung von Produktspezifikationen oder Planung von Projektmanagementaufgaben.
Collaborate - Zusammenarbeiten bedeutet, ein Gleichgewicht zwischen zu ziehen
- Management im traditionellen Sinne des Projektmanagements und
- Schaffung und Pflege der für die Entstehung erforderlichen kollaborativen Umgebung.

Kollaborative Aktivitäten bauen Produkte auf und halten das Tempo der Veränderungen in der Umgebung aufrecht.

Learn - Learn zielt sowohl auf die Entwickler als auch auf die Kunden ab, anhand der Ergebnisse jedes Entwicklungszyklus die Richtung des nächsten zu ermitteln.

In diesem Kapitel werden wir die verschiedenen Konzepte der adaptiven Softwareentwicklung verstehen.

Theorie komplexer adaptiver Systeme (CAS)

Brian Arthur und seine Kollegen vom Santa Fe-Institut nutzten die CAS-Theorie (Complex Adaptive Systems), um das Verständnis von Physik, Biologie, Evolution und Wirtschaft zu revolutionieren.

Brian Arthur gipfelte in seinen mehr als zwei Jahrzehnten des Versuchs, Mainstream-Ökonomen davon zu überzeugen, dass ihre Ansicht, die von grundlegenden Annahmen über sinkende Renditen, Gleichgewicht und deterministische Dynamik dominiert wird, nicht mehr ausreicht, um die Realität zu verstehen. Die neue Welt ist geprägt von steigenden Erträgen, Instabilität und Unfähigkeit, Ursache und Wirkung zu bestimmen.

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

Verschiedene Managementtechniken
Verschiedene Strategien
Anderes Verständnis

Komplexe Softwareentwicklung

Da der Umfang der Softwareanwendungen explodiert, stoßen selbst die Softwareentwicklungsorganisationen auf ähnliche Widersprüche wie oben erwähnt.

One World wird durch die deterministische Entwicklung repräsentiert, die aus Managementpraktiken abgeleitet ist, die auf den Grundlagen von Stabilität und Vorhersehbarkeit basieren (was in Arthurs Worten eine Verringerung der Rendite bedeutet).
Second World ist durch die Branchen vertreten, die von rückläufigen zu steigenden Renditeumgebungen übergehen, die unvorhersehbar, nichtlinear und schnell sind.

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

Die adaptive Softwareentwicklung konzentriert sich auf die Adressierung der komplexen Systeme -

Adaptive Softwareentwicklung für den Entwicklungslebenszyklus.
Adaptive Managementtechniken erfordern eine andere Denkweise als herkömmliche Projektmanagementpraktiken.

In diesem Tutorial können Sie beide Implementierungen verstehen.

Die adaptive Softwareentwicklung (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 basierend auf
- Langjährige Erfahrung mit deterministischen Softwareentwicklungsmethoden.
- Beratung, Übung und Schreiben über RAD-Techniken (Rapid Application Development); und Zusammenarbeit mit High-Tech-Softwareunternehmen bei der Verwaltung ihrer Produktentwicklung.

In diesem Kapitel lernen Sie die konzeptionelle Perspektive der adaptiven Softwareentwicklung kennen.

CAS-Konzepte (Complex Adaptive Systems)

Die Theorie der komplexen adaptiven Systeme (CAS) hat viele Konzepte. Die adaptive Softwareentwicklung basiert auf zwei dieser Konzepte:

Emergence
Complexity

Entstehung

In komplexen Projekten zur Entwicklung von Softwareprodukten sind die Ergebnisse von Natur aus unvorhersehbar. Erfolgreiche Produkte entstehen jedoch ständig aus solchen Umgebungen.

Dies kann durch Emergenz geschehen, wie in der CAS-Theorie (Complex Adaptive Systems) 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 Schwerpunkts 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 emergentes Verhalten, das Schwärmen von Vögeln. Wenn fehlerhafte 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 Verwaltung und Organisation dieser individuellen Freiheit bis zur Vorstellung, dass eine kreative neue Ordnung unvorhersehbar aus spontaner Selbstorganisation hervorgeht.

Neben der Entwicklung ist die Entstehung auch aus Managementsicht das wichtigste Konzept.

Komplexität

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

Die Personen eines Teams wie Entwickler, Kunden, Anbieter, Wettbewerber und Aktionäre, ihre Anzahl und ihre Geschwindigkeit.
Größe und technologische Komplexität.

Adaptive Softwareentwicklungspraktiken

Die adaptive Softwareentwicklung bietet eine andere Perspektive auf Softwareverwaltungspraktiken. In den folgenden Abschnitten können Sie die beiden wichtigen Vorgehensweisen - Qualität und RAD - verstehen, die sich beide auf die Erfassung 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 "Mach es gleich beim ersten Mal richtig" nicht, da du nicht vorhersagen kannst, was am Anfang richtig ist. Sie müssen das Ziel haben, 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 umfangreich, dass es niemals einen optimalen Wert geben kann. Daher liegt der Schwerpunkt auf der Verlagerung, um den besten Wert auf dem Wettbewerbsmarkt zu erzielen.

RAD-Praktiken

RAD-Praktiken beinhalten im Allgemeinen eine Kombination der folgenden:

Evolutionslebenszyklus
Kundenfokusgruppen, JAD-Sitzungen, technische Bewertungen
Projektmanagement mit Zeitrahmen
Kontinuierliches Software-Engineering
Engagierte Teams mit Kriegsräumen

Die RAD-Projekte haben einen inhärenten adaptiven, aufstrebenden Geschmack. 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 dies Fragen nach ihrer grundlegenden Weltanschauung aufwirft.

RAD-Praktiken und Microsoft-Prozesse sind Beispiele für die adaptive Entwicklung in Aktion. Wenn Sie ihnen ein Label geben (dh Adaptive Development) 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.

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 Adaptive Software Development im Jahr 2000.

Adaptive Softwareentwicklungspraktiken bieten die Möglichkeit, Änderungen Rechnung zu tragen, und können in turbulenten Umgebungen mit Produkten angepasst werden, die sich mit wenig Planung und Lernen 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 -

Speculate
Collaborate
Learn

Diese drei Phasen spiegeln die Dynamik der adaptiven Softwareentwicklung wider. Die adaptive Entwicklung ersetzt explizit den Determinismus durch die Entstehung. Es geht über eine bloße Änderung des Lebenszyklus hinaus zu einer tieferen Änderung des Führungsstils. Die adaptive Softwareentwicklung hat einen dynamischen Speculate-Collaborate-Learn-Lebenszyklus.

Der Adaptive Software Development Lifecycle konzentriert sich auf Ergebnisse und nicht auf Aufgaben. Die Ergebnisse werden als Anwendungsfunktionen identifiziert.

Spekulieren

Der Begriff Plan ist zu deterministisch und weist auf ein hinreichend hohes Maß an Sicherheit hinsichtlich des gewünschten Ergebnisses hin. Das implizite und explizite Ziel der Konformität mit dem Plan 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 fördert das Erforschen und Experimentieren. Iterationen mit kurzen Zyklen werden empfohlen.

Zusammenarbeiten

Komplexe Anwendungen werden nicht erstellt, sondern weiterentwickelt. Komplexe Anwendungen erfordern, dass eine große Menge an Informationen gesammelt, analysiert und auf das Problem angewendet wird. Turbulente Umgebungen weisen einen hohen Informationsfluss auf. Komplexe Anwendungen erfordern daher, dass ein großes Informationsvolumen gesammelt, analysiert und auf das Problem angewendet wird. Dies führt zu unterschiedlichen Wissensanforderungen, die nur durch Teamzusammenarbeit bewältigt werden können.

Eine Zusammenarbeit würde die Fähigkeit erfordern, gemeinsam zu arbeiten, um Ergebnisse zu erzielen, Wissen auszutauschen oder Entscheidungen zu treffen.

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

Lernen

Der Learn-Teil des Lebenszyklus ist entscheidend für den Erfolg des Projekts. Das Team muss sein Wissen ständig erweitern und dabei Praktiken anwenden 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 erfahren. Das Team lernt -

Über Produktänderungen
Grundlegendere Änderungen der zugrunde liegenden Annahmen darüber, wie die Produkte entwickelt werden

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

Spekulieren - Zusammenarbeiten - Lernzyklus als Ganzes

Wie Sie aus dem oben angegebenen Zyklus "Spekulieren-Zusammenarbeiten-Lernen" ersehen, ist es offensichtlich, dass die drei Phasen nichtlinear sind und sich überlappen.

Wir beobachten Folgendes aus einem adaptiven Rahmen.

Es ist schwierig, ohne Lernen zusammenzuarbeiten oder ohne Zusammenarbeit zu lernen.
Es ist schwierig zu spekulieren ohne zu lernen oder zu lernen ohne zu spekulieren.
Es ist schwierig, ohne Zusammenarbeit zu spekulieren oder ohne Spekulation zusammenzuarbeiten.

Der Lebenszyklus der adaptiven Softwareentwicklung weist sechs grundlegende Merkmale auf:

Mission konzentriert
Funktionsbasiert
Iterative
Time-boxed
Risikogetrieben
Toleranz ändern

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

Missionsorientiert

Bei vielen Projekten ist die Gesamtmission, die das Team leitet, gut formuliert, obwohl die Anforderungen zu Beginn des Projekts möglicherweise ungewiss sind. Leitbilder dienen als Leitfaden, die zu Beginn die Erforschung fördern, sich aber im Verlauf eines Projekts eng konzentrieren. Eine Mission bietet eher Grenzen als ein festes Ziel. Mission Statements und die Diskussionen, die zu diesen Statements führen, geben Anweisungen und Kriterien für kritische Projektkompromissentscheidungen.

Ohne eine klare Mission und eine ständige Verfeinerung der Mission werden iterative Lebenszyklen zu oszillierenden Lebenszyklen, die ohne Fortschritte 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.

Funktionen können sich über mehrere Iterationen hinweg 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 Feature betrachtet. Die anderen Dokumente wie das Datenmodell, auch wenn sie als Ergebnisse definiert sind, sind immer zweitrangig.

Iterativ

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

Zeitbox

In Adaptive Software Development Lifecycle sind die Iterationen zeitlich begrenzt. Man sollte jedoch bedenken, dass es beim Time-Boxing in der adaptiven Softwareentwicklung nicht um Zeitfristen geht. Es sollte nicht verwendet werden, um das Team für lange Stunden in einer kollaborativen Umgebung arbeiten zu lassen oder um die Qualität der Ergebnisse zu beeinträchtigen.

In der adaptiven Softwareentwicklung wird Time-Boxing als eine Richtung betrachtet, um bei Bedarf harte Kompromissentscheidungen zu fokussieren und zu erzwingen. In einer unsicheren Umgebung, in der die Änderungsraten hoch sind, muss eine periodische Forcierungsfunktion wie eine Zeitbox vorhanden sein, um die Arbeit zu erledigen.

Risikogetrieben

In der adaptiven Softwareentwicklung werden die Iterationen durch Identifizieren und Bewerten der kritischen Risiken gesteuert.

Änderungstolerant

Die adaptive Softwareentwicklung ist veränderungstolerant und betrachtet Veränderungen als die Fähigkeit, Wettbewerbsvorteile zu erzielen, jedoch nicht als Problem für die Entwicklung.

Die Praktiken der adaptiven Softwareentwicklung basieren auf dem Glauben an eine kontinuierliche Anpassung, wobei der Lebenszyklus so ausgestattet ist, dass kontinuierliche Änderungen als Norm akzeptiert werden.

Adaptive Software Development Lifecycle widmet sich -

Fortlaufendes Lernen
Orientierung ändern
Re-evaluation
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 veranschaulicht werden:

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 jeder eine Zeitbox zu
- Entwickeln Sie für jede Iteration ein Thema oder Ziel
- Weisen Sie jeder Iteration Features zu
Collaborate - Gleichzeitige Funktionsentwicklung
- Zusammenarbeit für verteilte Teams
- Zusammenarbeit für kleinere Projekte
- Zusammenarbeit für größere Projekte
Learn - 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
Planning

Spekulieren hat fünf Praktiken, 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 jeder eine Zeitbox zu
Entwickeln Sie für jede Iteration ein Thema oder Ziel
Weisen Sie jeder Iteration Features zu

Projektinitiierung

Projektinitiierung beinhaltet -

Festlegen 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 vornehmen
Identifizierung der wichtigsten Projektrisiken

Die Projektinitiierungsdaten sollten in einer vorläufigen JAD-Sitzung gesammelt werden, wobei Geschwindigkeit als Hauptaspekt betrachtet wird. Die Initiierung 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 ausreichend detailliert erfasst, um Merkmale zu identifizieren und einen Überblick über das Objekt, die Daten oder ein anderes Architekturmodell zu erhalten.

Festlegen des Zeitrahmens für das gesamte Projekt

Das Zeitfenster für das gesamte Projekt sollte auf der Grundlage des Umfangs, der Anforderungen an den Funktionsumfang, der Schätzungen und der Ressourcenverfügbarkeit festgelegt werden, die sich aus der Projektinitiierung ergeben.

Wie Sie wissen, gibt das Spekulieren die Schätzung nicht auf, sondern bedeutet nur zu akzeptieren, dass Schätzungen schief gehen können.

Iterationen und Zeitbox

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

Für eine kleine bis mittelgroße Anwendung -

Die 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 auf dem, was für Sie funktioniert. Wenn Sie die Anzahl der Iterationen und die Länge der einzelnen Iterationen festgelegt haben, weisen Sie jeder der Iterationen einen Zeitplan zu.

Entwickeln Sie ein Thema oder Ziel

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

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

Funktionen zuweisen

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

Während der Zuordnung von Features zu den Iterationen -

Das Entwicklungsteam sollte die Funktionsschätzungen, Risiken und Abhängigkeiten erstellen und dem Kunden zur Verfügung stellen.
Kunden sollten anhand der vom Entwicklungsteam bereitgestellten Informationen über die Priorisierung von Funktionen entscheiden.

Daher ist die Iterationsplanung funktionsbasiert und wird im Team mit Entwicklern und Kunden durchgeführt. Die Erfahrung hat gezeigt, dass diese Art der Planung ein besseres Verständnis des Projekts bietet als eine aufgabenbasierte Planung durch den Projektmanager. Darüber hinaus spiegelt die funktionsbasierte Planung die Einzigartigkeit jedes Projekts wider.

Zusammenarbeiten ─ Gleichzeitige Funktionsentwicklung

In der Phase der Zusammenarbeit liegt der Schwerpunkt auf der Entwicklung. Die Phase der Zusammenarbeit umfasst zwei Aktivitäten:

Das Entwicklungsteam arbeitet zusammen und liefert funktionierende Software.
Die Projektmanager erleichtern die Zusammenarbeit und die gleichzeitige Entwicklung.

Zusammenarbeit ist ein Akt der gemeinsamen Erstellung, der das Entwicklungsteam, die Kunden und die Manager umfasst. Gemeinsame Schöpfung wird durch Vertrauen und Respekt gefördert.

Teams sollten zusammenarbeiten an -

Technische Probleme
Geschäftsanforderungen
Schnelle Entscheidungsfindung

Im Folgenden sind die Praktiken aufgeführt, die für die Phase der Zusammenarbeit in der adaptiven Softwareentwicklung relevant sind:

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
Die Art und Weise, wie sie Abhängigkeiten verwalten

Zusammenarbeit für kleinere Projekte

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

Zusammenarbeit für größere Projekte

Größere Projekte erfordern zusätzliche Praktiken, Tools für die Zusammenarbeit und die Interaktion mit dem Projektmanager 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 fertiggestellten Code und Artefakte frühzeitig teilen, 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 Lieferteams und des Praxisteams
Der Projektstatus

Ergebnisqualität aus Kundensicht

In den Projekten zur adaptiven Softwareentwicklung 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 Kundenänderungsanforderungen aufzuzeichnen.

Kundenfokusgruppensitzungen sind erleichterte 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 der regelmäßigen Überprüfung technischer Artefakte Bedeutung beigemessen werden. Codeüberprüfungen sollten kontinuierlich durchgeführt werden. Überprüfungen anderer technischer Artefakte, wie 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, gemeinsam als Team etwas über sich und ihre Arbeit zu lernen.

Iterationsende-Retrospektiven ermöglichen eine regelmäßige Selbstüberprüfung der Teamleistung wie -

Stellen Sie fest, was nicht funktioniert.
Was das Team mehr tun muss.
Was das Team weniger tun muss.

Der Projektstatus

Die Überprüfung des Projektstatus hilft bei der Planung weiterer Arbeiten. In adaptiven Softwareentwicklungsprojekten ist die Bestimmung des Projektstatus ein merkmalsbasierter Ansatz, wobei das Ende jeder Iteration durch abgeschlossene Merkmale gekennzeichnet ist, die zu funktionierender Software führen.

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 Projekten zur adaptiven Softwareentwicklung spekulativ sind, ist Frage 3 wichtiger als 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 Sichtweise, wohin wir gehen müssen?"

Ein Flussdiagramm der traditionellen Softwareverwaltung ist unten dargestellt.

Das traditionelle Software-Management wurde durch den Begriff Befehlssteuerung charakterisiert.

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

In den Harvard Business Review- und Management-Büchern sind Begriffe wie Empowerment, partizipatives Management, lernende Organisation, menschenzentriertes Management usw. enthalten, aber keines 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 adaptiven Managementtechniken zu berücksichtigen, die sich in anderen Bereichen als erfolgreich erwiesen haben.

Adaptives Management

Adaptives Management hat sich in Umgebungen als erfolgreich erwiesen, in denen die Ressourcenmanager mit Stakeholdern und Wissenschaftlern als Team zusammengearbeitet haben, mit folgenden Zielen:

Erfahren Sie, wie verwaltete Systeme auf menschliche Eingriffe reagieren.
Verbesserung der Ressourcenrichtlinien und -praktiken in Zukunft.

Das Prinzip des adaptiven Managements besteht darin, dass viele Ressourcenmanagementaktivitäten Experimente sind, da ihre Ergebnisse nicht im Voraus 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, angesichts neuer Informationen und unter Berücksichtigung unterschiedlicher Ziele und Präferenzen der Stakeholder rechtzeitig zu reagieren. Es ermutigt die Interessengruppen, Streitigkeiten zu binden und sie ordnungsgemäß zu diskutieren, während die Umweltunsicherheiten untersucht und besser verstanden werden.

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

Adaptives Management hilft, die getroffenen Entscheidungen zu ändern, indem klargestellt wird, 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 Erkenntnisse zu verbessern und dadurch Unsicherheiten zu verringern.

Innerhalb des passiven adaptiven Managements wird eine einzelne bevorzugte Vorgehensweise ausgewählt, die auf vorhandenen Informationen und Verständnis 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 begrenzt in der Lage, die wissenschaftlichen 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.

Anschließend wird eine Reihe konkurrierender alternativer Systemmodelle des Ökosystems und der damit verbundenen Reaktionen (z. B. demografischer Wandel; Freizeitnutzung) anstelle eines einzelnen Modells entwickelt. Verwaltungsoptionen 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 übernehmen die Führungskräfte häufig diese Verantwortung. Wir brauchen Führer mehr als die Kommandeure. Die Führungskräfte sind Mitarbeiter und arbeiten mit dem Team zusammen. Collaborative-Leadership ist die gefragteste Praxis in der adaptiven Entwicklung.

Die Führer haben die folgenden Eigenschaften -

Fassen Sie und legen Sie die Richtung fest.
Beeinflussen Sie die Beteiligten und geben Sie Anleitung.
Arbeiten Sie zusammen, erleichtern Sie und verwalten Sie das Team auf Makros.
Die Richtung angeben.
Schaffen Sie Umgebungen, in denen talentierte Menschen innovativ und kreativ sein und effektive Entscheidungen treffen können.
Verstehe, dass sie gelegentlich befehlen müssen, aber das ist nicht ihr vorherrschender Stil.