Adaptive Softwareentwicklung - Praktiken

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

Der Zeitrahmen 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 den Projektinitiierungsarbeiten 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. Geteilte 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 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 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 den 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?"