Skript 2

• Projekt nicht planbar, weil keine Vorstellung vom Zielsystem

• Arbeiten können nicht verteilt werden

• Anforderungen werden nicht erhoben, also auch nicht erfüllt

• Allen Prüfungen fehlen die Soll-Vorgaben

• Programme sind schlecht strukturiert

• Korrekturaufwand ist unangemessen hoch, da Mängel erst im Betrieb entdeckt werden

• Konzepte und Entscheidungen nicht dokumentiert

• Starr, wenig flexibel

• Fehler werden oft erst spät erkannt

• Je komplexer das projekt, desto schwieriger ist es vorab einen detaillierten Plan aufzustellen

• Wenn Anforderungen nicht bis ins letzte Detail klar, können Fehldeutungen entstehen, die erst spät im Projekt ans Licht kommen

• Mock-Ups/ Attrappen

• Realisieren meist nur sehr rudimentäre Funktionalität

• Zeigen oft nur Oberfläche des (vermuteten) Zielsystems

• Prototyping: Vorgehensweise der Software-Entwicklung, bei der Attrappen („Prototypen“) entworfen, konstruiert, bewertet und revidiert werden

• Software wird in mehreren geplanten und kontrolliert durchgeführten Iterationsschritten entwickelt

• Ziel dabei ist, dass in jedem Iterationsschritt – beginnend bei der zweiten Iteration – das vorhandene System auf der Basis der im Einsatz erkannten Mängel korrigiert und verbessert wird

• Bei jedem Iterationsschritt werden die charakteristischen Tätigkeiten Analysieren, Entwerfen, Codieren und Testen durchgeführt

• System wird in definierten Ausbaustufen realisiert und ausgeliefert

• erste Stufe ist das Kernsystem, jede weitere Ausbaustufe erweitert das vorhandene System um Leistungen und Merkmale, die überwiegend bereits zu Beginn des Gesamtprojekts geplant worden sind

• geeignet, den Widerspruch zwischen kurzfristiger Lieferung (Time-to-Market) und Komplexität des Produkts zu entschärfen

• Ersatz für Wasserfallmodell

• kein konkretes, sondern generisches Vorgehensmodell, das eine Anleitung zur konkreten Ausprägung eines Vorgehensmodells liefert

• Ziel: Risiko erkennen und möglichst früh im Projekt bekämpfen

• Das Projekt beginnt im Zentrum.

• Die Quadranten mit den Nummern 1 und 4 tragen nicht viel zur Aussage bei.

• Wesentlich sind die Quadranten 2 und 3

• Die Planung erstreckt sich aber nur jeweils über einen Zyklus.

• Regelung der Softwarebearbeitung der Bundeswehr, des Bundes und der Länder

• Fokus auf Verhältnis von Auftragnehmer und Auftraggeber (starker akademischer Einfluss bei Entwicklung

• Projektdurchführungsstrategie definiert Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen nutzt Entscheidungspunkte (go, no go)

• Produkte stehen im Mittelpunkt, sie sind DIE Projektergebnisse

• Projektdurchführungsstrategien und Entscheidungspunkte geben Reihenfolge der Produktfertigstellung und somit grundlegende Struktur des Projektverlaufs vor

• detaillierte Projektplanung und -steuerung wird auf Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt

• Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person

• Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten

Inception (Konzeption):

-          Ermittlung zentraler Anforderungen

-          Projektumfang definieren

-          erste Entwurfs- und Implementierungsansätze

-          Identifikation der Projektrisiken und Aufwände

Elaboration (Ausarbeitung):

-          stabile, möglichst vollständige Anforderungen

-          Entwurfsspezifikation

-          detaillierter Projektplan mit aktivem Risikomanagement

Construction (Konstruktion):

-          Implementierung

-          Integration

-          auslieferbare Version

Transition (Inbetriebnahme):

-          Beta-Test

-          Endabnahme

-          Inbetriebnahme

-          Endlieferung

Kernaktivitäten mit spezifischen Rollen, Aktivitäten, Artefakten und Workflows

-          Geschäftsprozessmodell

-          Anforderungsanalyse

-          Design

-          Implementierung

-          Test

-          Installation

-          Projektmanagement

• viele Dokumente erzeugt und gepflegt werden

• Eigene Wissenschaft, Modelle wie V-Modelle und RUP zu verstehen und zurecht zu schneidern

• Prozessbeschreibungen hemmen Kreativität

• Anpassung an neue Randbedingungen, z. B. neue Technologien (Web-Services) in Prozessen und benutzten Werkzeugen ist extrem aufwändig

• Alternativer Ansatz: „Menschen machen Projekte erfolgreich, traue den Menschen“

→ Agile Prozesse (vorheriger Name: leichtgewichtige Prozesse)

Wir zeigen bessere Wege zur Softwareentwicklung auf... [und] bevorzugen:

• Menschen und Zusammenarbeit vor Prozessen und Werkzeugen

• Funktionierende Software vor umfassender Dokumentation

• Kundenzusammenarbeit vor Vertragsverhandlungen

• Reaktion auf Veränderung vor Planeinhaltung

[...] während die Punkte auf der Rechten wertvoll sind, wertschätzen wir die Punkte auf der Linken mehr.

• Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenstellen

• Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden

• Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen (wenige Wochen oder Monate)

• Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projekts

• Bereitstellung eines Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird

• Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht

• Als Fortschrittsmaß gilt nur funktionsfähige Software

• Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung

• Ständiges Augenmerk auf technische Exzellenz und gutes Design: Nur hochwertige Produkte können weiterentwickelt werden

• Einfachheit ist essenziell (KISS-Prinzip)

• Selbstorganisation der Teams bei Planung und Umsetzung

• Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung

• Hat die Produktvision

• Trägt die wirtschaftliche Verantwortung für das Projekt

• Legt die Ziele der Entwicklung fest

• Definiert und priorisiert die Product Features

• Nimmt die Entwicklung des Produkts vor

• Ist selbstorganisierend

ist eine geordnete Liste u.a. der geplanten Produkt-Feature

• beinhaltet die für den Sprint ausgewählten Product Backlog-Einträge

• beinhaltet die gesamte Arbeit, die notwendig ist, um das Sprint-Ziel zu erreichen

• Ergebnis aller in einem Sprint fertiggestellten Product

• Backlog-Einträge und dem Resultat aller früheren Sprints

• Frühere Bezeichnung: Potentially Shippable Product Increment

Bedingungen, unter denen ein Entwicklungsteam eine Aufgabe als fertiggestellt bezeichnen darf

• Zeitfenster (Time Box), innerhalb derer ein fertiges („Done"), nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt werden soll

• Planung des kommenden Sprints

• Meeting von 15 Minuten, innerhalb derer das Entwicklungsteam seine Aktivitäten

• synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet

• Veranstaltung am Ende des Sprints, um das [Produkt-]Inkrement zu überprüfen

• Überprüfung der eigenen Arbeit des Scrum Teams und Planung von Verbesserungen

• Kontinuierliche Überarbeitung des Product Backlog

• Lean-Methode zur Reduzierung der Verschwendung in einem Produktionsprozess

• Anwendung eines Pull-Systems ermöglicht neue Arbeit beginnen, wenn beim Kunden Bedarf dafür besteht

  -> Betriebskosten reduzieren und die Lagerkosten optimieren.

• Work in progress

• Ist so gering wie möglich zu halten

- Arbeitsfluss visualisieren

- WIP begrenzen

- Flow managen

- Prozess-Regeln (Policys) explizit machen

- Feedback-Schleifen einbauen

- Gemeinsam an Verbesserungen arbeiten

• Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung beschreibt

• Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität

• Erstellung des Quellcodes arbeiten jeweils zwei Programmierer gleichzeitig an einem Arbeitsplatz

• Einer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, sofort anspricht

• Diese können dann sofort im Gespräch gelöst werden

• beide Programmierer sollten sich in den beiden Rollen abwechseln

• Zusammensetzung der Paare sollte sich häufig ändern

• manuelle oder automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens

• Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit soll verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken

• Vertreter der Stakeholder als On-Site-Customer beim Entwicklungsteam vor Ort

• ständige Verfügbarkeit hilft den Beteiligten, die Anforderungen und Fragen kurzfristig zu klären

• Stakeholder kann außerdem durch seine Anwesenheit Zwischenstände oder Inkremente des Systems sofort testen und potenzielle Fehler und Missverständnisse klären

• Ist Stakeholder ständig präsent, können feine Details der Anforderungen an das System ermittelt werden

• Verantwortung eines Entwicklers oder eines Entwicklungsteams für die Qualität, Korrektheit und Wartbarkeit einer Codebasis.

• Sammelbegriff für alle Kombinationen von agilen und klassischen Ansätzen

• Integrieren in der Regel selektiv bestimmte Konzepte agiler Methoden in ein „traditionelles“ Umfeld, z. B.Retrospektiven, Stand-Up-Meeting