Integration von Scrum in das V-Modell XT

Transkript

1 Datum: 12. November 2010 Themendossier für die User Group»Agile Methoden in der Softwareentwicklung«Integration von Scrum in das V-Modell XT Seite 1

2 Einführung in das Thema Einleitung Innerhalb des Software Engineerings gibt es eine Palette an Projektmanagementmethoden oder auch Vorgehensmodellen, die dabei helfen, Projekte erfolgreich von der Formulierung von Anforderungen bis hin zur Auslieferung von Produkten umzusetzen. Dabei unterscheidet man zwischen sequenziellen Vertretern z. B. dem Wasserfallmodell und iterativen Ansätzen wie das Spiralmodell und Scrum. Ein von der öffentlichen Hand bevorzugtes Vorgehen ist das V-Modell XT, das alle Schritte von der Erstellung einer Ausschreibung über den Vertragsschluss bis zum Projektabschluss sehr ausführlich umfasst. Innerhalb des Modells steht eine Vielzahl an Vorgehensbausteinen zur Verfügung, die in unterschiedlichen Kontexten angewendet werden müssen. So wird z.b. zwischen unterschiedlichen Projekttypen unterschieden, da man Projekte sowohl als Auftraggeber (AG), Auftragnehmer (AN) aber auch aus beiden Perspektiven abwickeln kann. Bei der Vergabe von öffentlichen Ausschreibungen hält sich der Auftraggeber an den im V-Modell beschriebenen Prozess und erwartet vom Auftragnehmer den äquivalenten AN- Prozess, um die beiden Projekte über die definierten Schnittstellen zu steuern. Somit ist der Auftragnehmer gezwungen, ebenfalls nach dem V-Modell vorzugehen. Auf Auftragnehmerseite ist hingegen Scrum als Projektmanagementmethode weit verbreitet. Scrum bietet seinen Nutzern die Möglichkeit, sich in kurzen Intervallen an das gewollte Produkt heranzutasten und so Fehlentwicklungen vorzubeugen. Durch häufig stattfindende Meetings, wie das Daily Scrum, wird eine hohe Transparenz innerhalb des Entwicklungsteams geschaffen. Ebenso werden Dokumente wie das Sprintbacklog fortlaufend gepflegt. Anhand dieser kann man den Projektfortschritt auf einer täglichen Basis ablesen. Wie bringt man nun beide Seiten zusammen? Der Auftraggeber fordert das V-Modell, da dieses einen vollständigen Rahmen aller in der Projektentwicklung benötigten Tätigkeiten absteckt. Der Auftragnehmer möchte hingegen seinen gewohnten Prozess weiterführen, da an diesem auch sehr stark der Projekterfolg gekoppelt ist. Für solche Szenarien bietet das V-Modell XT eine Konformitätsprüfung an, in der organisationsspezifische Prozesse auf die Anforderungen des V-Modell XT untersucht werden können. Durch die Zertifizierung wird bestätigt, dass der unternehmenseigene Vorgang anstelle des V-Modells eingesetzt werden kann. Der Auftraggeber erhält dadurch eine Bestätigung, dass eine hohe Qualität für das angestrebte Produkt gewährleistet sein wird. Der Auftragnehmer kann umgekehrt effizienter und somit auch kostengünstiger produzieren. Seite 2

3 Verfahren für V-Modell XT-Konformität Die Konformitätsprüfung setzt sich aus fünf Schritten zusammen, die zum Erreichen des Zertifikats nötig sind: Scoping Festlegung der Messlatte Beantwortung der allgemeinen Fragen Beantwortung der generischen Fragen Bewertung Der erste Schritt der Prüfung besteht aus dem Scoping, welches das V-Modell als Referenzmodell zum organisationsspezifischen Prozess einschränkt. Dies ist nötig, da das ursprüngliche V-Modell Projekte aus unterschiedlichen Perspektiven und für verschiedene Projektarten und -typen unterstützt. Das Scope bildet die V-Modell Entsprechung des organisationsspezifischen Prozesses. Im zweiten Schritt wird die Messlatte festgelegt. Dabei werden bestimmte Produkte aus dem V-Modell identifiziert, deren Inhalte nicht zwingend im organisationsspezifischen Prozess vorhanden sein müssen. So können beispielsweise externe Produkte an der AG/ AN-Schnittstelle ausgelassen werden und bestimmte Themen aus dem Projekthandbuch wie z.b. Abweichungen vom V-Modell werden nicht gefordert. Im nächsten Schritt werden allgemeine Fragen bezüglich des organisationsspezifischen Prozesses beantwortet. Dabei werden grundlegende Anforderungen geprüft, die ein Vorgehensmodell besitzen muss. Das sind z.b. das Rollenmodell, die Systemzerlegung und Prozesse für die Anforderungsänderungen. Im vierten Schritt wird anhand der generischen Fragen der organisationsspezifische Prozess auf das Scope geprüft. Die Fragen unterteilen sich dabei in die Kategorien Objekte, Zuordnungen und Abhängigkeiten und Abläufe. Die Fragen des Abschnitts Objekte beschäftigen sich mit der inhaltlichen Übereinstimmung des Scopes mit dem organisationsspezifischen Prozesses. Im Abschnitt Zuordnungen und Abhängigkeiten wird geprüft, ob die Konsistenzbedingungen zwischen den einzelnen Dokumenten gewahrt werden. Schließlich werden im Fragenteil Abläufe untersucht und dabei insbesondere auf eine sinnvolle Ordnung der Erstellung von Dokumenten geachtet. Anhand der beiden Fragebögen wird der organisationsspezifische Prozess bewertet. Bei einem positiven Ergebnis kann sich die Organisation für ihren Prozess zertifizieren lassen, um V-Modell Projekte mit firmeneigenem Prozess umzusetzen. Scrum als organisationsspezifischer Prozess Möchte man Scrum der V-Modell XT-Konformitätsprüfung unterziehen, so wird man feststellen, dass viele Inhalte des V-Modells nicht abgedeckt werden können. Das liegt zum einen daran, dass viele Themen innerhalb von Scrum in den Punkt der Selbstorganisation des Teams fallen und somit nicht explizit ge- Seite 3

4 nannt werden. Zum anderen ist Scrum eine effektive Methode, um Anforderungen umzusetzen und den Entwicklungsfortschritt transparent darzustellen und bedient sich somit weniger effektiver Elemente. Das V-Modell umfasst im Gegensatz dazu viel mehr Eigenschaften, so wird z. B. auf einen Ausschreibungsprozess und den Vertragsschluss eingegangen. Auch auf das Konfigurationsmanagement und eine Qualitätssicherung wird geachtet. Diese Informationen können aus dem ursprünglichen Scrum nicht ermittelt werden, es sei denn, man untersucht auf einer tieferen Ebene, wie einzelne Prozesse innerhalb des Unternehmens abgebildet werden. Scrum kann also nur schwierig als Ersatz des V-Modells eingesetzt werden und gleichzeitig alle Anforderungen des Scopes erfüllen. Es ist jedoch möglich, ein Kombinationsmodell zu entwickeln. Entwicklung eines Kombinationsmodells Um ein konformes und gültiges Kombinationsmodell zu erstellen, sollte zunächst ein äquivalentes V- Modell XT Projekt getailort werden. Dabei muss zunächst ein Projekttyp gewählt werden. Hier stehen die Typen Systementwicklungsprojekt (AG), Systementwicklungsprojekt (AN), Systementwicklungsprojekt (AG/AN) und Einführung und Pflege eines organisationsspezifischen Vorgehensmodells zur Auswahl. Da man von einer Ausschreibung ausgeht, bei der AG und AN zwei voneinander verschiedene Organisationen darstellen, muss der Projekttyp Systementwicklungsprojekt (AN) gewählt werden. Der Scrum-Prozess soll also in ein Auftragnehmer V-Modell Projekt integriert werden. Im zweiten Schritt muss eine Projekttypvariante bestimmt werden. Die Auswahl wurde durch den Projekttyp schon etwas eingeschränkt und so stehen AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration und AN-Projekt mit Wartung und Pflege zur Auswahl. An dieser Stelle wird man in den meisten Fällen die erste Variante wählen, da diese für die meisten Entwicklungsprojekte zutrifft. Abbildung 1: Projektdurchführungsstrategie, V-Modell XT S. 122 Durch die Projekttypvariante wird eine Projektdurchführungsstrategie festgelegt, für die eine passende Entwicklungsstrategie ausgewählt werden muss. Dabei stehen die Strategien Komponentenbasierte Systementwicklung, Unterauftrag, Inkrementelle Systementwicklung und Prototypische Systementwicklung zur Verfügung. Seite 4

5 Abbildung 2: Inkrementelle Entwicklung, V-Modell XT S. 122 Da man sich bei Scrum nicht zwingenderweise an Komponenten halten muss, die man hintereinander fertigstellt, wird man sich in den meisten Fällen für eine Inkrementelle Systementwicklung entscheiden. Im letzten Schritt werden die Projektmerkmale bestimmt. Diese können z.b. die besondere Beachtung von Systemsicherheit (AN) oder der Einsatz von Fertigprodukten. Hat man die einzelnen Schritte durchlaufen, so ergibt sich eine Menge von Vorgehensbausteinen und deren Inhalte (Produkte), welche z.b. Systemelemente oder Dokumente sein können. Desweiteren ergibt sich aber auch eine Reihenfolge von Entscheidungspunkten. Diese geben die Ordnung vor, in der die Produkte fertiggestellt werden müssen. Um die Konformität des V-Modells nicht zu verletzten, muss ein integriertes Modell die geforderten Inhalte beibehalten. Zunächst muss jedoch eine Stelle in dem getailorten Modell definiert werden, an der sich Scrum platzieren lässt. Integration von Scrum auf Entscheidungspunktebene Betrachtet man die Entscheidungspunkte, welche durch den Tailoring-Prozess festgelegt wurden, so fällt auf, dass man innerhalb eines Scrum Sprints vor allem Systemelemente entwirft, verfeinert, herstellt und integriert. Dies geschieht so, dass dem Product Owner ein ausführbares Softwareinkrement am Sprintende vorgeführt werden kann. Eine grundlegende Eigenschaft der Entscheidungspunkte des V-Modells ist, dass am Ende jedes Punkts eine Projektfortschrittsentscheidung getroffen sowie ein Projektstatusbericht erstellt wird. Im V-Modell werden also die einzelnen Phasen in größeren Zeitintervallen (Entscheidungspunkte) durchlaufen, wie das z. B. bei Scrum üblich ist. Seite 5

6 Tabelle 1: Entscheidungspunkte innerhalb eines Sprints Für ein Kombinationsmodell legt man die Entscheidungspunkte System entworfen, Feinentwurf abgeschlossen, Systemelemente realisiert und System integriert zu einem Entscheidungspunkt zusammen und deklariert diesen als Sprint durchgeführt. Die Inhalte, welche in Scrum größtenteils nicht explizit genannt werden, treten nun in den Vordergrund. Dadurch werden die Systemarchitektur erweitert, das System und einzelne Systemelemente spezifiziert, Tests spezifiziert und durchgeführt und schließlich die geschaffenen Segmente/Einheiten in das Gesamtsystem integriert. Dies alles geschieht innerhalb eines Sprints. Zusätzlich sollte geprüft werden, ob die Inhalte der Produkte auch innerhalb der Organisation vorhanden sind. Der Entscheidungspunkt Sprint durchgeführt wird nun so oft wiederholt, bis alle Anforderungen über die geplante Periode umgesetzt wurden. Erst wenn geliefert wird, kann zu dem Entscheidungspunkt Lieferung durchgeführt übergegangen werden. Dadurch ist gewährleistet, dass man nach seiner gewohnten Art und Weise mit Sprints und allen Meetings drum herum entwickeln kann. Die Entscheidungspunkte Projekt genehmigt, Projekt definiert, Angebot abgegeben und Projekt beauftragt gehören zu dem formalen Ausschreibungsprozess des V-Modells. Diese Punkte bleiben unverändert bestehen, da Scrum diese Inhalte nicht liefert. Die Entscheidungspunkte Lieferung durchgeführt, Abnahme erfolgt und Projekt abgeschlossen bleiben ebenfalls unverändert und somit V-Modell konform. Der Entscheidungspunkt Iteration geplant wird mit der Produkt-/Releaseplanung von Scrum vereinigt, da sich diese zeitlich gleich einordnen lassen. Schließlich bleibt noch der Punkt System spezifi- Seite 6

7 ziert offen. In diesem wird unter anderem das Pflichtenheft erstellt. Je nachdem, wie viel Zeit und Personen dieses in Anspruch nimmt, kann auch dieser Entscheidungspunkt als Sprint bzw. in Sprints durchgeführt werden. Was hat man nun durch diese Integration auf Entscheidungspunktebene gewonnen? Das Team kann seinen gewohnten Scrum-Arbeitsfluss innerhalb des V-Modells aufnehmen, muss nur ein paar zusätzliche Dinge beachten, die durch die Produkte hinzugekommen sind. Was verliert man dagegen aus der Scrum- Perspektive? Es wird aktiv in die Selbstorganisation des Teams eingegriffen, so dass der ein oder andere Inhalt gepflegt werden muss, der sonst irrelevant geblieben wäre. Integration auf inhaltlicher Ebene Durch die V-Modell Vorgehensbausteine wird eine Reihe an Produkten vorgeschrieben, deren Inhalte gewährleistet werden müssen. Für die Entwicklungsschritte sind dies vor allem die im vorigen Kapitel aufgeführten Produkte der Entscheidungspunkte. Zusätzlich gibt es noch weitere Inhalte, z.b. aus dem Vorgehensbaustein Konfigurationsmanagement. Die Inhalte dieses Vorgehensbausteins sind jedoch von fast jedem modernen Versionsverwaltungswerkzeug sichergestellt. Ein weiterer zu beachtender Vorgehensbaustein ist die Qualitätssicherung. Dabei muss im Wesentlichen darauf geachtet werden, dass spezifiziert werden muss, wie Dokumente und Prozesse auszusehen haben und wie eine Prüfung protokolliert werden muss. Manche Informationen lassen sich auch direkt aus Scrum ableiten. So beinhalten Hindernisbericht und Sprint-/Release-Burndown-Chart Informationen, die im Projektstatusbericht wiederverwendet werden können. Auch das Sprintbacklog dokumentiert, wer in welchem Zeitraum an welchem Schritt gearbeitet hat. Ebenfalls können Anforderungen nach der Produktplanung aus dem Produktbacklog in das Pflichtenheft übertragen werden. Schließlich gibt es aber auch Informationen, die Scrum nicht direkt hergibt. Dazu gehört z.b. der Vorgehensbaustein Vertragsschluss (AN), der den gesamten formalen Prozess der Ausschreibung abdeckt. In diese Themen muss sich das Team unbedingt einarbeiten. Durchführung der Konformitätsprüfung Nachdem ein integriertes Modell entworfen wurde, muss im Anschluss daran die Konformitätsprüfung durchgeführt werden. Da der Ansatz des Kombinationsmodells dem Scope der Prüfung entspricht, ergeben sich die Antworten der meisten Fragen von selbst. Innerhalb der Entwicklungsstrategie stellt lediglich die Zusammenlegung der vier Entscheidungspunkte zu einem einen größeren Eingriff dar. Jedoch ist es innerhalb der Prüfung legitim, mehrere Entscheidungspunkte auf einem abzubilden. Somit können alle Fragen positiv bewertet werden und ein solches Modell wäre in der Lage, sich auch zertifizieren zu lassen. Seite 7

8 Fazit Das Kombinationsmodell würde eine Konformitätsprüfung bestehen und wäre somit für Projekte qualifiziert, die an das V-Modell gebunden sind. Aus Sicht des V-Modells wird dabei nicht zu tief in die Struktur eingegriffen. Für den Scrum- Anwender ändern sich jedoch viele Schritte gravierend, auf die er nun aktiv eingehen muss. Dennoch werden die wesentlichen gewinnbringenden Elemente von Scrum beibehalten und können sich weiterhin positiv auf den Projekterfolg auswirken Wir wünschen Ihnen eine interessante Lektüre! Bei Fragen kommen Sie gern auf uns zu. Ihr Team der Softwareforen Leipzig Seite 8

9 Inhaltsverzeichnis V-Modell XT Das V-Modell XT Das V-Modell XT: Für Projektleiter und QS-Verantwortliche. Kompakt und übersichtlich Scrum Succeeding with Agile: Software Development Using Scrum User Stories Applied: For Agile Software Development Integration Sprinten mit dem V-Modell XT Das V-Modell XT mit Scrum inside V-Modell Konformität V 1.0 Seite 9

10 Das V-Modell XT Das V-Modell XT Quelle: Autor: diverse Datum: Die PDF-Datei definiert das V-Modell XT in seinem vollen Umfang. Es bildet einen Leitfaden, wie man komplexe Softwaresysteme erstellen kann. Das VModell bietet sowohl Auftraggebern, Auftragnehmern aber auch für beide in einer Rolle vereint, das passende Vorgehen an. Von Ausschreibungsprozessen, über die Formulierung von Anforderungen bis hin zum erfolgreichen Abschluss eines Projektes sind alle Schritte vollständig und detailliert beschrieben. Das V-Modell XT: Für Projektleiter und QS-Verantwortliche. Kompakt und übersichtlich Das V-Modell XT: Für Projektleiter und QS-Verantwortliche. Kompakt und übersichtlich Quelle: ISBN: , Springer, 162 Seiten Autor: J. Friedrich, U.Hammerschall, M.Kuhrmann, M. Sihling Datum: 2009 Das Buch führt in das V-Modell XT ein und erläutert die wichtigsten Punkte für Projektleiter und QS-Verantwortliche. Es ist eine kurze und knappe Ergänzung zum Referenzwerk, die durch Bezug zur Praxis überzeugt. Succeeding with Agile: Software Development Using Scrum Succeeding with Agile: Software Development Using Scrum Quelle: ISBN: , Addison-Wesley, 504 Seiten Autor: Mike Cohn Datum: In diesem Buch zeigt Mike Cohn, wie man Scrum in Organisationen mit unterschiedlichen Größen einsetzen kann. Das Buch ist für fortgeschrittene Scrumanwender geeignet, da es viele Grundbe- Seite 10

11 griffe voraussetzt. In jedem Kapitel gibt es einen Teil "Things to try now", in dem über die aktuell besprochen Praktiken reflektiert wird. User Stories Applied: For Agile Software Development User Stories Applied: For Agile Software Development Quelle: ISBN: , Addison-Wesley, 304 Seiten Autor: Mike Cohn Datum: Das Buch erklärt, wie man User Stories als wertvolles Gut erstellen kann. Es bietet eine Vielzahl an positiv und negativ Beispielen. Desweiteren wird erläutert, wie man mit Managern und anderen Interessensvertretern umgeht. Das Ende des Buchs bildet ein Kapitel mit praktischen Fragen und Übungen. Sprinten mit dem V-Modell XT Quelle: Computerwoche, MicroTool GmbH Autor: O. Lewitz, U.Meseberg Datum: In diesem Artikel beschreiben die Autoren, wie man Scrum und das V-Modell XT kombinieren kann. Zunächst werden die beiden Modelle unabhängig voneinander betrachtet. Danach wird ein Ansatz erklärt, bei dem die Schnittstellenprodukte des V-Modells auf Auftragnehmerseite durch Scrum generiert werden. Seite 11

12 Das V-Modell XT mit Scrum inside Das V-Modell XT mit Scrum inside Quelle: Objekt Spektrum 05/2010 Autor: S. Canditt, D. Rauh, M. Wittmann Datum: 9/2010 In diesem Zeitungsartikel beschreiben die beiden Autorinnen, wie man Scrum in das V-Modell XT integrieren kann und trotzdem konform den Bestimmungen des Referenzmodells vorgeht. Im Gegensatz zum Artikel "Sprinten mit dem V-Modell XT" werden hier auch Produkte beachtet, die sich nicht direkt an der AG/ANSchnittstelle befinden. V-Modell Konformität V 1.0 V-Modell Konformität V 1.0 Quelle: Technische Universität Kaiserslautern Autor: diverse Datum: Das Dokument stellt einen Leitfaden dar, mit dem Unternehmen ihre spezifischen Prozesse auf V- Modell XT Konformität prüfen können. Durch die Möglichkeit eigene Vorgehen bei Realisierungsprojekten einsetzen zu können, versprechen die Autoren eine effizientere und kostengünstigere Entwicklung des Auftragnehmers sowie eine höhere Qualität des Produkts für den Auftraggeber. Mit Hilfe des Dokuments kann man eine Zertifizierung anstreben, um an öffentlichen Ausschreibungen teilzunehmen, die an das V-Modell gebunden sind. Seite 12

13 Impressum Autor Johannes Perlet Tel.: +49 (0) Feedback Uns interessiert Ihre Meinung! Haben Sie Fragen, Anregungen oder Anlass zur Kritik? Bitte senden Sie Ihre Kommentare an: Sven Seiffert Telefon: +49 (0) Abmeldung Sie wollen dieses Dokument in Zukunft nicht mehr empfangen? Senden Sie uns einfach eine mit einer kurzen Nachricht an: Zugangsdaten für Sehr gern richten wir für Sie Zugangsdaten für unseren passwortgeschützten Bereich "Wissen" ein (für unsere Partnerunternehmen; für andere Unternehmen sind Probezugänge möglich). Senden Sie uns einfach eine mit einer kurzen Nachricht an Seite 13

14 Seite 14 Softwareforen Leipzig GmbH Querstraße Leipzig T +49 (0)341 / F +49 (0)341 / E info@softwareforen.de I