Software-Entwicklung mit und nach SCRUM, Teil 2: SCRUM kurz und knapp

Dieser Blog-Eintrag ist eine Fortsetzung des ersten Teils über SCRUM.

Die Umsetzung der Prinzipien Transparenz, Überprüfung und Anpassung wird in SCRUM durch folgende Elemente abgebildet:

Rollen:

  • Der Product Owner gibt die fachliche und strategische Ausrichtung des Produkts vor.
  • Das Entwicklungs-Team setzt die Vorgaben des Product Owners um.
  • Der SCRUM-Master ist für das Gelingen des SCRUM-Prozesses verantwortlich. Er arbeitet mit dem Product Owner und dem Entwicklungsteam zusammen, gehört aber nicht dazu. Er beseitigt Probleme, die den Fortschritt des Projekts verhindern und achtet darauf, dass alle Projektteilnehmer nach den Regeln spielen.

Artefakte:

  • Im Product Backlog hält der Product Owner in Form von User Stories, also Beschreibungen aus Benutzersicht, Anforderungen an sein Produkt fest.
  • Im Sprint Backlog ist, für jedes Team-Mitglied ersichtlich, der aktuelle Projektstatus festgehalten. Das Sprint Backlog beinhaltet unter anderem abgeschlossene und offene Aufgaben sowie den Fortschritt in Form eines Burndown-Charts.
  • In der Impediment-Liste werden Probleme festgehalten, die das Team bei der Arbeit behindern. Es ist Aufgabe des SCRUM-Masters diese Probleme zu beseitigen.

Der Ablauf von SCRUM ist durch seine Zeremonien definiert:

  • Ein Sprint beschreibt einen festen Zeitraum von mindestens zwei, maximal vier Wochen, in denen ein Produkt entwickelt wird. Ziel eines Sprints ist immer ein „potentially shippable Product“, also ein Produkt, das soweit gereift ist, dass es theoretisch mit der neuen Funktionalität an Kunden herausgegeben werden kann und einen Mehrwert bietet.
  • Im Sprint Planning wird durch den Product Owner und das Entwicklungs-Team zunächst festgelegt, welche User-Stories im kommenden Sprint umgesetzt werden. Der Product Owner stellt die von ihm hoch priorisierten Stories vor. Dabei schätzt das Team die Größe der User-Stories und wie viel in einem Sprint umgesetzt werden kann. Im zweiten Teil des Meetings, das nun ohne den Product Owner stattfindet, legt das Team anschließend fest, wie die gewählten Stories umzusetzen sind. Die einzelnen Stories werden in Tasks aufgebrochen und im Sprint umgesetzt.
  • Das Daily Scrum findet jeden Morgen während des gesamten Sprints statt und dauert nicht länger als 15 Minuten. Während des Daily Scrums erklärt jedes Mitglied des Entwicklungs-Teams, was es am Vortag getan hat, was es plant am aktuellen Tag zu tun und ob es Hindernisse bei der täglichen Arbeit gibt, die vom Scrum-Master beseitigt werden müssen. Das Sprint Backlog und die Impediment-Liste werden entsprechend aktualisiert.
  • Das Sprint Review findet am Ende eines Sprints statt. Das Entwicklungs-Team präsentiert dem Product Owner, ggf. auch einem Benutzer oder Auftraggeber, die Ergebnisse des vergangenen Sprints. Der Product Owner bewertet und beurteilt die Ergebnisse. Es wird überprüft, ob die im Sprint Planning gesteckten Ziele im Sprint erreicht worden sind. Bei der Bewertung werden keine Kompromisse eingegangen. Eine User-Story aus dem Product Backlog gilt erst dann als abgeschlossen, wenn sie die „Definition Of Done“, einer vor Umsetzung festgelegten Menge von Anforderungen, entspricht. Sollten User-Stories nicht vollständig abgeschlossen sein oder Änderungsbedarf bestehen, so kann der Product Owner sie zurück ins Product Backlog aufnehmen und neu bewerten.
  • Im Sprint Retrospective, welches zwischen Sprint Review und Sprint Planning stattfindet, reflektiert das Team gute und schlechte Erfahrungen, die während des letzten Sprints gemacht worden sind. Das Sprint Retrospective soll dem Entwicklungs-Team die Möglichkeit geben, aus diesen Erfahrungen zu lernen.

Alle Zeremonien in SCRUM sind „time-boxed“, das bedeutet, dass sie für einen fest angegebenen Zeitrahmen angesetzt sind, der nicht überschritten werden darf. Es ist Aufgabe des Scrum-Masters auf die Einhaltung des Time-Boxing zu achten. Dadurch sollen endlose Diskussionen und Verstrickungen in Details vermieden werden.

Lesen Sie im folgenden dritten Teil, wie SCRUM bei Ferber-Software zum Einsatz kommt und was wir bisher für Erfahrungen damit gemacht haben.

Ausblick auf das neue IKAROS-Fibu: Buchungsperioden

Die Redesign-Projekte in IKAROS machen gute Fortschritte. Aktuell werden die Zusatzmodule IKAROS-Import und IKAROS-Fibu auf die neue Architektur umgestellt.

In diesem Video möchten wir Ihnen heute erste Eindrücke des neuen IKAROS-Fibu-Moduls vermitteln. Das Entwicklungsteam hat sich zum Projektstart mit der Verwaltung der Buchungsperioden beschäftigt.

Um das Video sehen zu können, müssen Sie sich zuerst in unserem Kundenbereich anmelden.

Klicken Sie hier, um das Video zu starten!

Sagen Sie uns Ihre Meinung zum Video und diskutieren Sie mit.

Software-Entwicklung mit und nach SCRUM, Teil 1: Motivation

Das klassische Projektmanagement in der Welt der Software-Entwicklung, z.B. nach dem Wasserfall- oder V-Modell, hat diverse Schwachpunkte. Die Planung eines Projekts beruht auf Schätzungen und Nebenbedingungen (man bezeichnet sie auch als „Unbekannte“), die sich während eines Projekts ändern. Das kann dazu führen, dass kurzfristig Planungen angepasst oder komplett geändert werden müssen. Im schlimmsten Fall wird die komplette Planung obsolet.

Dies ist der Ansatzpunkt und Grundgedanke von SCRUM: Ein Projekt ist aufgrund vieler Unbekannter zu komplex, um es vom Start bis zum Abschluss komplett durchplanen zu können. Wenn sich die Unbekannten – und damit wahrscheinlich auch Anforderungen – ändern, muss kurzfristig darauf reagiert werden können, unabhängig davon, was ein Projektplan vorschreibt. Man bezeichnet SCRUM daher auch als ein Vorgehensmodell zur agilen Softwareentwicklung.

SCRUM versucht, den Schwachpunkten des klassischen Projektmanagements mit drei Prinzipien entgegenzutreten:

  • Transparenz: Wissen bzgl. Projektfortschritt und Hindernissen wird täglich im Team gestreut.
  • Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet.
  • Anpassung: Anforderungen werden nicht festgeschrieben, sondern können nach jeder Lieferung von Projektergebnissen neu angepasst und bewertet werden.

Festgehalten sind diese Prinzipien im Agilen Manifest:

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Lesen Sie im folgenden zweiten Teil, wie sich diese Prinzipien in Form von Rollen, Artefakten und Zeremonien in SCRUM darstellen.

Update des Bankleitzahlenverzeichnisses (2012-06)

Das aktuelle BLZ-Verzeichnis, gültig ab 4. Juni 2012, steht Kunden mit gültigem Wartungsvertrag zum Download unter /kunden/wartung/BLZ/ auf unserem FTP-Server bereit. Informationen zum Einspielen des aktualisierten BLZ-Verzeichnisses entnehmen Sie bitte dem jeweiligen Dokument. Bitte beachten Sie, dass die Kontonummernüberprüfung von IKAROSsql 1.6 oder neuer zu einem späteren Zeitpunkt aktualisiert werden muss. In der Zwischenzeit kann die Fehlermeldung „Für die Kontonummer … existiert kein Prüfziffernberechnungsverfahren“ auftreten, falls neue, noch nicht unterstützte Prüfziffernberechnungsverfahren benötigt werden.

Links:

Für IKAROSsql ab Version 2.4:
BLZUpdate_mit_BIC.blz
BLZ-Verzeichnis-Update.pdf 

Für IKAROSsql ab Version 1.6:
BLZUpdate.blz
BLZ-Verzeichnis-Update.pdf 

Für IKAROSsql vor Version 1.6:
BLZUpdate_ohne_Pruefsumme.blz
BLZ-Verzeichnis-Update.pdf

IKAROS 2.7 und SA 12

Es ist geschafft – die ersten Ramp-ups sind produktiv gegangen!

Eine Reihe von Kunden hat erfolgreich das Update auf IKAROS 2.7 und die Migration auf den neuen Sybase Server SA 12 durchgeführt. Einige technisch versierte Anwender haben die Umstellung in Eigenregie bewältigt, andere haben unsere Dienstleistungsangebote in Anspruch genommen. Als große Hilfe hat sich in jedem Fall das kostenlos bereitgestellte Migrationstool erwiesen, das viele Voraussetzungen prüft und die diversen einzelnen Schritte zur Migration der Datenbank automatisch durchführt und protokolliert.

Ohne Anspruch auf Vollständigkeit und Allgemeingültigkeit weisen wir Sie auf einige Punkte hin, die bei den bisherigen Ramp-ups aufgefallen sind und für Sie ggf. von Interesse sein könnten:

  • Bitte achten Sie darauf, dass sich Ihre Windows-Version auf einem aktuellen Stand befindet (z. B. sollte beim Windows Server 2003 das Servicepack 2 installiert sein).
  • Falls das Migrationstool trotz erfolgreicher Installation des SA 12 diesen als nicht vorhanden meldet, hilft ein Neustart des Rechners weiter.
  • Der SA 12 als „Netzwerkserver“ muss ggf. in der Windows-Firewall freigeschaltet werden.

Haben Sie weitere Beobachtungen gemacht, die für andere Anwender hilfreich sein könnten? Teilen Sie Ihre Erfahrungen mit uns, indem Sie diesen Beitrag kommentieren – wir freuen uns auf einen interessanten Informationsaustausch!