Agile Integration

SharePoint-Einführung mit Feature-driven Development
Kommentare

Die Einführung von SharePoint läuft längst nicht immer reibungslos ab. Zum Leidwesen der Unternehmen, die das Thema aus guten Gründen vorantreiben wollen, bauen sich in der Belegschaft schon bei Bekanntwerden der Integrationsbemühungen Widerstände auf. Ohne die aktive Mitarbeit und Unterstützung der Mitarbeiter wird die Einführung einer neuen Software – ob nun SharePoint oder eine andere Lösung – schwierig bis unmöglich.

Immer mehr Methoden für die Integration neuer Anwendungen gewinnen aktuell an Bedeutung, die die Mitarbeiter von Anfang an auf die Reise mitnehmen und somit vieles leichter machen. Mittels Feature-driven Development (FDD) etwa, gelang Assecor kürzlich in Zusammenarbeit mit einem Kunden aus der öffentlichen Verwaltung mithilfe einer angepassten agilen Projektmanagementmethode die erfolgreiche SharePoint-Einführung in einem sich verändernden Umfeld.

SharePoint-Einführung verlangt Köpfchen

Die Motivation, SharePoint einzuführen, entsprang weniger dem Anstreben eines vorab definierten Geschäftsnutzens, sondern eher dem Wunsch, das in der eigenen Zuständigkeit befindliche System als führende Lösung der Zusammenarbeit zu etablieren. SharePoint stand daher in direkter Konkurrenz zum selbst entwickelten Intranet. Der Kunde hatte bereits einige Versuche unternommen, den Mitarbeitern die SharePoint-Nutzung „schmackhaft“ zu machen, sah in dem bisher Erreichtem aber noch Potenzial. Das zunächst beauftragte „Konzept für die SharePoint-Einführung“ empfahl, aufbauend auf Microsofts IMPACT-Methode, die Einführung des SharePoint-Angebots über ein angepasstes AIDA-Modell (Abb. 1).

Abb. 1: Projektkommunikation nach dem AIDA-Modell

Abb. 1: Projektkommunikation nach dem AIDA-Modell

Nach Abschluss der Konzeptphase erfolgte die Umsetzung. Gleichzeitig war der Kunde skeptisch, ob die Einführung den gewünschten Erfolg, nämlich eine große Nachfrage seitens der Anwender bringen würde und war folglich vorsichtig, die SharePoint-Einführung im Rahmen eines großen Projekts freizugeben. Stattdessen kam es zu einer Vereinbarung, die die Unterstützung der Kunden-IT bei allen SharePoint-Belangen im Rahmen eines Dienstleistungsvertrags definierte. Neben dem Einsatz bei der Erstellung eines SharePoint-Betriebshandbuchs sollten die Berater der Assecor GmbH bei Informationsveranstaltungen unterstützen und bei Anforderungen aus Reihen des Kunden beratend und gegebenenfalls umsetzend unterstützen.

Obwohl der Kunde damit ein sehr schwer planbares Projektumfeld abgesteckt hatte, waren die Ansprüche an Reporting und Projektmanagement trotzdem vergleichsweise hoch. Insbesondere die Situation, dass Anforderungen von Mitarbeitern auch kurzfristig aufzunehmen und zu beraten sein würden, führte zur Entscheidung der Nutzung einer agilen Projektmanagementmethode. Die Wahl fiel dabei auf die Methode des Feature-driven Development („FDD“).

Kurz vorgestellt: Feature-driven Development (FDD)

Neben Scrum oder auch Extreme Programming (XP) stellt das Feature-driven Development (FDD) eine weniger bekannte und auch etwas schwergewichtigere, aber dennoch agile Einführungsmethodik in der Softwareentwicklung dar. Es vereint eine Reihe von „Best Practices“, basierend auf inkrementellen Planungsphasen und schnellen, iterativen Entwicklungszyklen („Sprints“) und wird vorwiegend bei größeren (Festpreis-)Projekten oder Projekten mit einer großen Anzahl an Entwicklern mit unterschiedlichem Know-how in Tiefe und Breite eingesetzt.

Neben der Definition eines Prozess- und Rollenmodells stellt FDD den „Feature“-Begriff in den Mittelpunkt der Softwareentwicklung. Features sind kleine, klar definierte und für jeden Projektbeteiligten verständliche Funktionalitäten des geplanten Systems und stellen jeweils einen Kundenmehrwert dar. Alle Anforderungen an das System werden in einzelne Features zerlegt und diese wiederum hierarchisch gruppiert. Durch diese Verknüpfung von Anforderungen zu mindestens einem Feature ist FDD stark „anforderungsgetrieben“. Ein Feature ohne verknüpfte Anforderung(en) kann nicht existieren, und es werden somit auch nur vom Kunden geforderte Funktionalitäten umgesetzt. FDD beschreibt einen Prozess mit fünf Kernaktivitäten:

  • Entwickle Gesamtmodell
  • Erstelle Featureliste
  • Plane je Feature
  • Entwerfe je Feature
  • Konstruiere je Feature

Entwicklung des Gesamtmodells

Zur Entwicklung des Gesamtmodells wird zusammen mit dem Kunden und den Fachvertretern ein s. g. „Domain Walkthrough“ durchgeführt. Diese Vorgehensweise dient einerseits dazu, einen Überblick über die Anforderungen und den Systemkontext zu erhalten und damit ein gemeinsames Verständnis des Projektziels und des Scopes sowie über den Umfang des geplanten Systems zu erhalten. Darüber hinaus lässt sich so das Gesamtmodell in Form von Klassendiagrammen ableiten. Dazu werden parallel innerhalb kleiner Teams Teilbereiche betrachtet, jeweils modelliert und nach gegenseitigen Peer-Reviews iterativ zu einem Gesamtmodell vereint. Zur Modellierung empfohlen und in der Praxis häufig eingesetzt ist in diesem Kontext der Ansatz des „Modeling in Color“.

Erstellen der Featureliste

Aus dem Gesamtmodell lässt sich im nächsten Schritt die Featureliste ableiten. Dafür werden die im Gesamtmodell definierten Fachbereiche zusammen mit dem Kunden hierarchisch in Fachgebiete, Geschäftsaktivitäten und Schritte/Features gegliedert und das Gesamtmodell somit weiter detailliert. FDD gibt hierbei eine sehr konkrete und einfache Schablone zur Beschreibung und Dokumentation eines Features vor: <Aktion> <Ergebnis> <Objekt> (z. B. „Berechne das Auftragsvolumen für das Vertriebsgebiet). Die benötigte Zeit für die Umsetzung eines Features sollte zwei Wochen nicht überschreiten. In der Praxis haben sich Featuregrößen von drei bis fünf Tagen bewährt. Dieses doch sehr strikte Schema bietet eine Reihe von Vorteilen. Die in Features aufgegliederten und gruppierten Anforderungen sowie deren Übersetzung in Features in „Befehlsform“ formalisieren die Anforderungen und ermöglichen so für den Kunden einen schnellen, strukturierten und damit verständlichen Überblick über das Gesamtsystem mit seiner Fülle an Einzelanforderungen. Generisch formulierte Anforderungen werden soweit konkretisiert, dass versteckte Komplexitäten der Anforderung nicht erst in der Umsetzung zu Tage treten. Darüber hinaus vereinfacht die Zerlegung der Anforderungen in kleinteiligere Features die Aufwandsschätzung erheblich und liefert damit einhergehend viel belastbarere Aufwandszahlen für die weitere Planung. Alle so definierten Features und deren Aufwände werden mit dem Kunden abgestimmt und priorisiert. Dabei gilt: „Was nicht als Feature definiert ist, wird auch nicht umgesetzt“.

Weitere Prozessschritte

Im Prozessschritt „Plane je Feature“ gilt es, die grobe Reihenfolge der umzusetzenden Features zu planen. Entsprechende Variablen können die Abhängigkeiten der Features untereinander sein, die Ressourcenverfügbarkeit im Team, die Komplexität der Features aber auch die zeitliche Kritikalität der abzubildenden Geschäftsaktivitäten. Hier kann die zuvor vorgenommene Priorisierung der Features als Basis dienen. Ziel ist es, grobe Fertigstellungstermine der Geschäftstätigkeiten zu erhalten und somit eine „Roadmap“ für die Systemeinführung aufzustellen. Schlussendlich werden in dieser Phase die Verantwortlichkeiten festgelegt. Jede Geschäftsaktivität (als Sammlung von gruppierten Features) wird einem verantwortlichen Chefprogrammierer und jedes einzelne Feature einem Entwickler zugewiesen.

In der folgenden Projektphase der iterativen Entwicklungszyklen gilt es nun am Anfang eines Sprints (i. d. R. zwei Wochen) zeitlich anstehende Features zu identifizieren und als Pakete an die verantwortlichen Entwickler zu verteilen. Jedes einzelne Feature durchläuft in dieser agilen Phase nun die beiden Schritte „Entwerfe je Feature“ und „Konstruiere je Feature“. Dabei können kleine Entwicklerteams Features parallel („Featureteams“) abarbeiten.

In der Featureentwurfsphase wird jedes anstehende Feature entworfen und feingeplant. Dazu werden das Gesamtmodell und relevante zugehörige Dokumentationen wie Use Cases usw. herangezogen. Im Ergebnis stehen Ablauf-/Sequenzdiagramme, die zur Detaillierung des Objektmodells dienen, als auch zur Ableitung konkreter Entwicklungsarbeitspakete für die sich direkt anschließende Umsetzung der Features.

In dieser Phase der Featurekonstruktion werden die zuvor designten Features durch Abarbeitung der Entwicklungsarbeitspakete schlussendlich umgesetzt. Dabei dienen Codeinspektionen und Unit Tests während beziehungsweise nach der Implementierung der Arbeitspakete sowie Reviews der Featureumsetzung („Wurden alle Anforderungen mit dem Feature umgesetzt?“) als qualitätssichernde Maßnahmen. Im Ergebnis dieses Teilprozesses soll eine für den Kunden mehrwertbietende Funktionalität des Gesamtsystems entstehen und aus Kundensicht einen spürbaren Fortschritt bedeuten.

Übrigens: Die Schritte „Entwerfe je Feature“ und „Konstruiere je Feature“ gilt es, solange zu wiederholen, bis alle Features umgesetzt sind.

Abbildung 2 zeigt zusammengefasst das Prozessmodell, die beteiligten Rollen und deren Haupttätigkeiten sowie grundlegende Outputs je Prozessschritt.

Abb. 1: FDD – Prozess- und Rollenmodell

Abb. 1: FDD – Prozess- und Rollenmodell

FDD ist anspruchsvoll

Erkennbar ist FDD im Vergleich zu anderen agilen Methoden recht anspruchsvoll. Die inkrementelle Vorbereitungs- und Planungsphase und die darauffolgende iterative Umsetzungsphase des FDD bauen allerdings eine wichtige Brücke zwischen klassisch „starren“ und agilen Herangehensweisen und vereinen so die Vorteile beider Ansätze miteinander. Das am Projektanfang zu erstellende Gesamtmodell sowie die Featuredefinition zwingen das gesamte Projektteam, gemeinsam die Anforderungen an das System, den Scope des Projekts, den Projektumfang sowie die gewünschten Systemfunktionalitäten zu bestimmen. Dafür strukturiert FDD stärker vor als andere agile Methoden (wie beispielsweise Scrum) und macht konkrete Vorgaben dazu, wie Anforderungen zu dokumentieren und zu strukturieren sind. Diese klare Featurebeschreibung und somit detailliertere Anforderungsdokumentation beugt Missverständnissen vor, fördert das gemeinsame Verständnis des Funktionsumfanges und „offenbart“ versteckte Komplexität von Anforderungen frühzeitig. Vor allem diese recht strikte Vorbereitungs- und Planungsphase des FDD bindet den Auftraggeber resp. die Fachabteilungen des Kunden stark mit ein und nimmt diesen damit auch in die Verantwortung. Die Zergliederung der Anforderungen in kleinteilige, einheitlich beschriebene und bestenfalls gleichen Umfang und Aufwand aufweisende Features vor der eigentlichen Umsetzung lassen FDD auch für Festpreisprojekte attraktiv erscheinen. Dennoch legt FDD wie alle agilen Methoden u. a. großen Wert auf eine flexible und schnelle Reaktionsfähigkeit auf Veränderungen im Projektumfeld während der Umsetzung.

SharePoint-Einführung mit FDD

Die in der Einleitung beschriebene Situation im Projekt war von sich häufig ändernden Anforderungen gekennzeichnet, was aus dem wachsenden Interesse der Anwender an SharePoint-Lösungen resultierte. Diese – an sich positive – Entwicklung, erschwerte den ursprünglich gewählten, statischen Projektmanagementansatz zunehmend. Gleichzeitig stand der Kunde – eine große Versicherungsverwaltung – dem Einsatz agiler Methoden skeptisch gegenüber. In dieser Situation entschied sich der Projektleiter, den oben beschriebenen FDD-Ansatz auf die Projektgegebenheiten anzupassen und so die agile Anforderungsentwicklung effizient, aber kontrolliert managen zu können – mithilfe des in Tabelle 1 dargestellten Vorgehensmodells.

Tabelle 1: Phasen des angepassten FDD-Modells

Tabelle 1: Phasen des angepassten FDD-Modells

Agil und dennoch strukturiert

Mit diesem Projektmanagementansatz war es möglich, agil auf Anforderungen des Kunden reagieren zu können und ihm trotzdem das Gefühl der Abschätzbarkeit und Planungssicherheit eines Wasserfallmodells zu geben. Dem Sicherheitsbedürfnis des Kunden kam ein elaboriertes Projektreporting sehr entgegen, das sich die Möglichkeiten des Feature-driven Developments zunutze machte. Dessen Methode, den (prozentualen) Bearbeitungsstatus eines Features nachvollziehbar aus der Phase, in der es sich befindet, ableitbar zu machen, führte zu der in Tabelle 2 dargestellten Meilensteinsystematik. Sie fasst die Phasen eines Features zusammen und schätzt – auf das Projekt angepasst – den anteiligen Aufwand zur Erreichung des jeweiligen Meilensteins. Mithilfe dieser Zuordnung kann durch die Summe der bisher erreichten Meilensteine eines Features dessen Status errechnet werden. So wird ein Feature, dessen Umsetzungskonzept vom Projektleiter des Auftragnehmers abgenommen wurde, beispielsweise mit einem Fertigstellungsstatus von 30 Prozent geführt. Nach Entwicklung und Präsentation des dadurch entstandenen Prototypen beim Auftraggeber aus der Fachabteilung erhöht sich der Fertigstellungsstatus auf 85 Prozent.

Tabelle 2: Meilensteinsystematik der Projektmanagementmethode: PL (AG) = Projektleiter Auftraggeber, PL (AN) = Projektleiter Auftragnehmer, MA (AG) = Mitarbeiter Auftraggeber, MA (AN) = Mitarbeiter Auftragnehmer

Tabelle 2: Meilensteinsystematik der Projektmanagementmethode: PL (AG) = Projektleiter Auftraggeber, PL (AN) = Projektleiter Auftragnehmer, MA (AG) = Mitarbeiter Auftraggeber, MA (AN) = Mitarbeiter Auftragnehmer

Während die Meilensteine „Management des Vorhabens“ und „Konzeption der Lösung“ den Phasen „Plan je Feature“ und „Entwerfe je Feature“ entsprechen, unterteilte die Projektleitung die Phase der Lösungsentwicklung in zwei Meilensteine. Dies resultierte aus den Projekterfahrungen in öffentlichen Verwaltungen, die von längeren Abnahmezeiträumen und häufigen, nachgelagerten Zusatzanforderungen geprägt waren. Durch die Aufteilung ließen sich die geschafften Fortschritte dokumentieren – was auch zur positiven Motivation im Gesamtprojekt beitrug.

Zusammenfassung

Die Anpassung der agilen Projektmanagementmethode „Feature-driven Design“ an die Projektbesonderheiten hat zum Projekterfolg in einer unbeständigen Anforderungslandschaft beigetragen, ohne den Kunden durch zu häufige Change Requests und Nachbeauftragungsforderungen unter Druck zu setzen. Der eingesetzte Projektleiter erhielt somit eine Möglichkeit der Planung und Struktur, die ihm und seinem Auftraggeber die Steuerung dieser agilen SharePoint-Einführung ermöglichte.

Insbesondere bei der Einführung von SharePoint warten auf die Projektbeteiligten oft Herausforderungen, die größer nicht sein könnten. Mithilfe praxisbewährter Methoden, wie beispielsweise FDD lassen sich starre Strukturen dynamischer gestalten – ohne dabei den Kunden und die künftigen SharePoint-Nutzer zu überfordern.

Aufmacherbild: Speed Traffic via Shutterstock / Urheberrecht: Taiga

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -