View this page in English

Projektorganisation mit Scrum

In komplexen Softwareprojekten arbeitet //SEIBERT/MEDIA mit der Projektmanagment-Methode Scrum. In den folgenden Abschnitten erhalten Sie einen Einblick in diese Projektmanagement-Methode:

Scrum als Projektmanagement-Methode

Scrum ist eine iterative, inkrementelle Methode für das Projektmanagement von agilen Softwareprojekten.

PDCA (Plan-Do-Check-Act) ist ein iterativer, vierstufiger Problemlösungsprozess, der häufig bei der Verbeserung von Geschäftsprozessen angewendet wird. Er ist ein integraler Bestandteil guter Scrum-Methodik.

Die grundlegenden Komponenten von Scrum:

Rollen

• Product Owner
• Scrum Master
• Team

Artefakte

• Product Backlog
• Selected Product Backlog
• Sprint Backlog
• Burndown Chart
• Impediment Backlog

Meetings

• Sprint Planning
  • Schätzen und priorisieren
• Daily Scrum
• Sprint Review
• Retrospektive

Projektkoordination

Die Projektkoordination wird gemeinschaftlich von Mitarbeitern des Auftragnehmers (AN) und des Auftraggebers (AG) geleistet. Der AN stellt die Koordination der Umsetzung sicher. Der AG koordiniert die Ressourcen, die die fachliche Spezifikation, sowie die fachlichen Abnahmetests übernehmen.

Die übergreifende Projektkoordination wird durch den Product Owner des AG und den Product Owner-Proxy des AN gewährleistet. AN und AG planen gemeinsam die erforderlichen Schritte zum reibungslosen Ablauf des Projekts.

Der AN stellt Informationen für den AG bereit, die dem AG ermöglichen ein Projektcontrolling durchzuführen und den Status der Entwicklungsarbeiten zu verfolgen. Zu diesen Informationen gehören im wesentlichen:

• Tägliche automatische Zeitnachweise, die Mitarbeitern des AG per Mail zugesandt werden
• Zugang zum Aufgabenverwaltungssystem des AN. Dort sind Burndown-Charts und alle geplanten Aufgaben, sowie deren Status abrufbar.

Weitere wichtige Planungsdetails werden im gemeinsam genutzten Wikisystem dokumentiert (z.B. Kontaktdaten von Ansprechpartnern, Terminlisten etc.).

Change-Request-Management "Wenn Sie möchten, kann jede Änderung kostenfrei erfolgen. Hierzu ersetzen gewünschte Features bereits bestehende."

Ein Change Request ist ein Feature oder Service, welcher von //SEIBERT/MEDIA bereitgestellt wird. Er ist hierbei kein Bestandteil der oben stehenden Spezifikation und Kalkulation.

Change-Requests müssen vom AG ausreichend spezifiziert an den AN übergeben werden. Der AN schätzt den Aufwand, woraufhin der AG die Funktionalität in den Product-Backlog einordnet (Priorität). Ein CR kann entweder budgetneutral als Ersatz für eine andere noch nicht realisierte Funktionalität, oder über eine Erweiterung des Budgets als zusätzliche Funktion eingeplant werden. Hierfür wird auf Anfrage ein Angebot zur zusätzlichen Beauftragung eingereicht.
Falls nichts anderes vereinbart wurde, ersetzen Change-Requests noch nicht realisierte User-Stories.

Fehlerverfolgung

Als ideal wird ein gemeinsam genutztes System zur Fehlerverfolgung angesehen. Der AN kann dem AG einen Zugang zum Aufgabenverwaltungssystem Jira gewähren. Im System können Fehler erfasst, verwaltet und abgearbeitet werden.

Alternativ kann ein Austausch von Fehlerlisten (z.B. Excel) für die Fehlerverfolgung stattfinden.

Mitwirkungsleistungen und Beistellungen

• Der Kunde liefert die notwendigen fachlichen Anforderungen und steht während der Projektlaufzeit für fachliche Rückfragen zur Verfügung.
• Ein Vertreter des Auftragnehmers nimmt regelmäßig, entweder persönlich oder per Telefon, an Planungsmeetings zu Beginn und zum Abschluss von Sprints teil.
• Der Kunde testet die jeweils umgesetzten Funktionalitäten zeitnah und gibt jeweils Feedback zum Status des Tests (Erfolgsmeldung/ Fehlermeldung).

Die Timeline

Dies ist eine beispielhafte Timeline für das Projekt, die einen Eindruck von unserem Vorgehen vermittelt:

Die Vision in Form von User-Stories: Der Product Backlog

Der Product Backlog enthält alle Features und Anforderungen (sog. User-Stories), die nötig sind, um die Produktvision zu verwirklichen. Der Product Backlog leitet sich aus Ihrer Leistungsbeschreibung ab.

Nicht-funktionale Anforderungen und allgemeine Arbeiten

Die folgenden Elemente sind integrale Bestandteile eines komplexen Web-Projekts. Jedes Element in der Preisübersicht enthält eine oder mehrere der folgenden Leistungen:

Technologische Plattform etablieren

• Grundlagen der Entwicklungsumgebung schaffen und konfigurieren
  • Code Repository SVN konfigurieren
• Continous-Integration Server und Unit Test Suite aufsetzen
• Allgemeine Struktur des Software-Systems
  • Hibernate und DB-Migration konfigurieren (Database Abstraction Stack)
  • Oval Validation Framework installieren (Validierungs-Framework)
  • Delivery von Fehlermeldungen sicherstellen
  • Einsatz auf dem Web-Server vorbereiten
  • Aufteilung und Setup der Test- und Productionskonfigurationen (Staging)
  • Übliche Fehlerseiten (z.B.. 404-Fehlerseiten)
  • Allgemeine Server-Konfiguration und Setup der Test-Stage (Tomcat, Apache, MySQL, SSH)
  • Mail-Dienst aufsetzen
  • Zusätzliche Dienste und Frameworks aufsetzen
  • GUI-Kern implementieren
  • Backend-Kern implementieren

Konzeption, Usability, Koordination und Design

• Funktionsanalyse
• Konkurrenzanalyse
• Usability-Konzept
• Layout
• Software-Architektur und UML-Diagramme
• Datenbank-Design
• Auswahl der Technologie
• Abstimmung mit dem Kunden
• Team-Meetings und Koordination der Arbeiten
• Detail-Spezifikation der Anforderungen

Tool- und Prozessinfrastruktur

• Aufsetzen des Bug-Tracking-Systems
• Aufsetzen des Dokumentations-System

Testen

• Unit-Tests und kontinuierliche Kontrolle des Integrations-Servers
• Funktionstest als Bestandteile von Sprints
• Tests der Browser-Kompatibilität

Wir gewährleisten Qualität - Testen

Immer auf der sicheren Seite - Kontinuierliche Integration

Die Behebung eines Fehlers wird umso günstiger, je früher man ihn entdeckt. Daher beginnt die Durchführung der User Story immer mit einem Unit-Test, einem kurzen Code, der dafür sorgt, dass die komplette Implementierung richtig umgesetzt wird. Bei jeder Akutalisierung des Quellcodes werden die Unit-Tests gestartet. Schlagen Tests fehl, werden die Ursachen ermittelt und beseitigt. Die Sicherstellung der Lauffähigkeit der Unit-Tests liegt im Verantwortungsbereich des Auftragnehmers. Ein Zugang zum Integrationsserver kann für den Auftraggeber nicht gewährleistet werden. Auf Anfrage erteilt der Auftragnehmer Auskunft über den Status des Integrationsservers und zeigt das System in Desktop-Sharing-Sessions live. Die ständige Integration (continous integration) garantiert, dass die Technik funktioniert und stabil läuft.

In der Spur bleiben - Sprintabnahme

Ziel jedes Sprints ist es einen zu Sprintbeginn definierten Funktionsumfang zu realisieren. Jede Funktion ist in der Form einer User-Story beschrieben. Bestandteil einer jeden User-Story sind Akzeptanzkriterien, die in Prosa formuliert sind und festlegen welches Verhalten der Anwendung bzw. der Funktion erwartet wird. Die Akzeptanzkriterien sind Grundlage für die Abnahme einer Funktion durch den AG. Zu Beginn des Projektes sollte eine "Definition of Done" formuliert werden, damit sich alle darüber einig sind, wann eine Aufgabe vollständig und korrekt umgesetzt ist.

Nach einem Sprint stimmen sich ein Repräsentant des Kunden und das Scrum-Team in einem Sprint-Review-Meeting ab. In diesem informellen Meeting präsentiert das Team die umgesetzten User-Stories, der Kunde gibt Feedback.

Alle neuen Funktionalitäten sind auf einem Test-Server lauffähig, der Kunde kann während des folgenden Sprints seine Akzeptanztests durchführen. Findet er Bugs und dokumentiert sie für das Team, wird die Behebung für den nächsten Sprint eingeplant.

Das Review und die Akzeptanzkriterien helfen, das Projekt "in der Spur" zu halten, und ermöglichen frühes Feedback vonseiten des Endnutzers.

Ready for rollout - Systemabnahme

Zur Konsolidierung und Gesamtabname des Systems sind zwei Sprints vorgesehen, die auf den letzten Sprint folgen, in dem neue Funktionalitäten implementiert wurden. Während der Konsolidierungssprints erfolgt ein tägliches Deployment auf dem Testsystem. Die Gesamtheit der realisierten Funktionalitäten wird in diesem Zeitraum durch den AG formal abgenommen. Festgestellte Mängel werden so schnell wie möglich behoben, so dass ein erneuter Test stattfinden kann.
Es wird explizit darauf hingewiesen, dass während der Konsolidierungsphase keine neuen Funktionen und auch keine Änderungen an bestehenden Funktionen mehr umgesetzt werden können, sondern nur Mängel beseitigt werden.