Master-Thesis. Zur Erlangung des Grades. Master of Science (MSc.) PROF. DR. DR. HERBERT NEUNTEUFEL

Transkript

1 Aspekte eines unternehmensübergreifenden agilen Softwareentwicklungsprozesses für unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung Master-Thesis Zur Erlangung des Grades Master of Science (MSc.) EINGEREICHT BEI: PROF. DR. DR. HERBERT NEUNTEUFEL PROF. DR. ERHARD ALDE EINGEREICHT AM: EINGEREICHT VON: SEBASTIAN B. MEIER GEB. AM IN HAMBURG MATRIKELNUMMER: INSTITUTION: HOCHSCHULE WISMAR FAKULTÄT DER WIRTSCHAFTSWISSENSCHAFTEN WIRTSCHAFTSINFORMATIK, MASTER

2

3 ABSTRACT Die agile Softwareentwicklung hat im letzten Jahrzehnt in vielen IT-Projekten Einzug gehalten. Als eines der verbreitetesten Modelle hat sich Scrum etabliert und wird zunehmend für die Entwicklung kritischer Systeme eingesetzt. In der konventionellen Softwareentwicklung ist das Einbeziehen einer externen Qualitätssicherung in solchen Fällen verbreitet. In der agilen Softwareentwicklung ist dieses Vorgehen noch nicht üblich. In der vorliegenden Master- Thesis wurde untersucht, wie externe Qualitätssicherung in die agile Softwareentwicklung eingeführt werden kann, um Systeme mit hohen Qualitätsanforderungen zu entwickeln. Scrum hat sich als geeignetes Referenzmodell herausgestellt. Erweitert um Kanban ermöglicht es entfernten Teams zusammenzuarbeiten. Internetbasierte Kollaborationswerkzeuge können eine enge Kooperation ermöglichen. Im Testprozess durchläuft jede User Story ein abgewandeltes V-Modell. Nicht die komplette Software wird am Ende des Sprints getestet, sondern jede User Story direkt nach ihrer Implementierung. Automatisierte Regressionstest sichern die Qualität der kompletten Software. Durch die Ermittlung von Kennzahlen über das Kanbansystem sowie über Softwaremetriken kann ein kontinuierlicher Verbesserungsprozess etabliert werden. Als Ausgangspunkt dient die Sprint Retrospective, in der alle Projektbeteiligten nach jeder Iteration gemeinsam die Optimierung des Entwicklungsprozess hinsichtlich Prozess- und Produktqualität anstreben. Die Ergänzung agiler Vorgehen um eine externe Qualitätssicherung ist möglich. Sie trägt zur Produktqualität bei und schafft Vertrauen in die entwickelte Software. Scrum wurde in seinem Kern wenig verändert, die getroffenen Maßnahmen können mit geringem Aufwand eingeführt werden. A lot of projects implemented agile software development over the last decade. Scrum is one of the most widespread models. It's increasingly used for the development of critical systems. In such a case it is not uncommon to use external quality assurance in heavyweight methods. Agile methods are not supporting external quality assurance yet. This master thesis evaluates the integration of external quality assurance into agile software development to allow the production of company critical software systems. Scrum has shown to be the best reference model. It was extended with the Kanban method to allow remote teams to cooperate. Teamwork is enhanced through the supplement of internetbased collaboration tools. The test process is derived from the V-Model. Not the complete software will be tested on the end of the sprint. But, every user story is tested after its implementation. Automated regression tests ensure the quality of the whole software on the end of the sprint. Key figures are raised through the Kanban system and software metrics are measured during development. They are used to establish a continual improvement process. All stakeholders meet to improve and optimize the process and product quality of the development process in sprint retrospective after each iteration. It is possible to extend agile development methods with external quality assurance. The product quality is improved and trust is created for the developed software. Scrum stayed mostly unchanged in its core. The undertaken measures can be implemented with little effort. ABSTRACT

4

5 INHALTSVERZEICHNIS INHALT ABKÜRZUNGEN ABBILDUNGEN TABELLEN III IV V 1 Einführung Motivation und Hintergrund der Arbeit Aufgabenstellung und Abgrenzung Einführung in die agile Softwareentwicklung und Scrum Einführung in Vorgehensmodelle Entstehung und Prinzipien agiler Modelle Scrum Grundgedanken und Begrifflichkeiten Prozessverlauf Zusammenfassung Analyse des Qualitätsmanagements zur Verwendung mit agilen Modellen Einführung in das Qualitätsmanagement Prozessqualität in der agilen Softwareentwicklung Zusammenfassung Software-Qualitätssicherung im agilen Umfeld Relevanz und Einordnung Konventionelles Testen Qualitätssicherung in der agilen Softwareentwicklung Zusammenfassung Teilung des Softwareentwicklungsprozesses auf die beteiligten Unternehmen Festlegung der Aufgaben der beteiligten Unternehmen Zusammenspiel und Schnittstellen Zusammenfassung Unterstützung des Softwareentwicklungsprozesses Einbindung von Qualitätsmanagementelementen Kanban und Scrum Einsatz zur Einbindung der externen Software-Qualitätssicherung I

6 INHALTSVERZEICHNIS 6.2 Werkzeuge Kommunikationswerkzeuge Taskmanagement Qualitätsmanagementwerkzeuge Entwicklungs- und Testwerkzeuge Zusammenfassung Gestaltung des Softwareentwicklungsprozesses Prozessmodellierung Prozess und Prozessmodell Ausnahmen und informelle Kommunikation Zusammenfassung Fallbeispiel Darstellung und Analyse des Beispielprojekts Anwendung des ausgearbeiteten Prozesses auf das Fallbeispiel Zusammenfassung Schlussbetrachtungen Zusammenfassung Fazit Ausblick LITERATUR VI SONSTIGE QUELLEN UND VERWEISE GLOSSAR ANHANG 1 XI XIV II

7 ABKÜRZUNGSVERZEICHNIS ABKÜRZUNGEN BPMN BTS CMMI EPK FDD FIT PDCA QMS QS TDD TOC TPS TQM UML WIP XP Business Process Modelling Notation Bug-Tracking-System Capability Maturity Model Integration Ereignisgesteuerte Prozesskette Feature Driven Development Framework for Integrated Test Plan Do Check Act Qualitätsmanagementsystem Qualitätssicherung Test Driven Development Theory of Constraints Toyota Production System Total Quality Management Unified Modelling Language Work in Progress extreme Programming III

8 ABBILDUNGSVERZEICHNIS ABBILDUNGEN Abbildung 2.1: Das V-Modell Abbildung 2.2: Die grafische Darstellung von Scrum Abbildung 4.1: Dokumente nach Standard IEEE 829 [entnommen aus IEEE829] Abbildung 5.1: Verteilung der Aufgaben Abbildung 5.2: Schnittstellen zwischen den Rollen und Systemen Abbildung 6.1: Beispiel für ein Kanbanboard [entnommen aus Kanbanboard] Abbildung 6.2: An die Gegebenheiten angepasstes Kanbanboard Abbildung 6.3: Vergleich von Kommunikationswerkzeugen [aus HR01] Abbildung 6.4: Beispiel eines virtuellen Kanbanboards [smartq] Abbildung 7.1: Popularität von Prozessnotationen [entnommen aus FR12, S. XIII].. 88 Abbildung 7.2: Basiselemente der BPMN Abbildung 7.3: Darstellung des gesamten Entwicklungsprozesses Abbildung 7.4: Darstellung der Pflege des Product Backlogs Abbildung 7.5: Darstellung des Sprint Planning Abbildung 7.6: Darstellung des Sprints Teil Abbildung 7.7: Darstellung des Sprints Teil Abbildung 7.8: Darstellung des Sprint Review und der Sprint Retrospective IV

9 TABELLENVERZEICHNIS TABELLEN Tabelle 2.1: Anzahl und Stärke von Beschränkungen von Vorgehensmodellen [aus BT08, S. 167] V

10

11 1 EINFÜHRUNG Die Entwicklung von Softwareprodukten mit hoher Qualität und im festgelegten Zeitrahmen ist schon seit Beginn des Software Engineering mit Schwierigkeiten verbunden. Als Begriff für diese Problematik manifestierte sich die Softwarekrise. Der Begriff der Softwarekrise ist erstmals 1968 verwendet worden. Auf einer Konferenz des NATO Science Comittees über Software Engineering in Garmisch, Deutschland, wurde eine zunehmende Abweichung zwischen den gewünschten Anforderungen an Softwaresystemen und deren Erreichung diskutiert. Unterschiede zwischen der versprochenen und implementierten Funktionalität, Überschreitung der Budgets und Überziehung des Zeitrahmens in fast allen Softwareentwicklungsprojekten wurden festgestellt griff Edsger Dijkstra den Begriff erneut auf und verhalf ihm zu einer gewissen Popularität [Dij72]. Er beschrieb, wie die Softwareentwicklung der schnell steigenden Leistung der Hardwaresysteme sowie den wachsenden Anforderungen der Benutzer nicht mehr gerecht werden konnte. In einem zusammenfassenden Report der Konferenz [NR68] tauchte ein interessantes Zitat von Kenneth W. Kolence auf. Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved. Kenneth W. Kolence Mit der Thematik von Softwareentwicklungsmodellen wurde sich seitdem eingehend beschäftigt. Verschiedene Vorgehensmodelle sind entwickelt und verbessert worden, einige wenige haben sich als Standardmodelle etabliert. Meist wurde versucht, die Probleme mit möglichst standardisierten Prozessen, viel Dokumentation und festen Meilensteinen zu überwinden. Nach einer Erhebung von 2009 schlossen etwa ein Drittel aller Projekte die Entwicklung im Zeit- und Kostenrahmen mit vollem Funktionsumfang ab. [standish] Das bedeutet jedoch, dass in zwei Dritteln aller Softwareentwicklungsprojekte noch Verbesserungsbedarf vorhanden ist. Obwohl viel Zeit seit der Feststellung einer Softwarekrise vergangen ist, scheinen die Probleme noch nicht behoben zu sein. Ein volles Verständnis für den Softwareerstellungsprozess hat sich bisher nicht eingestellt. Die etablierten, starren Entwicklungsmodelle scheinen nicht genug zur Eingrenzung der Softwarekrise beigetragen zu haben. Durch die zunehmende Schnelllebigkeit und 7

12 KAPITEL 1: EINFÜHRUNG Komplexität der Programme ist es umso wichtiger geworden, ein Entwicklungsmodell zu etablieren, das auf alle Anforderungen eines Entwicklungsprozesses eingeht. Lange, starre Entwicklungszeiten können heutzutage nicht mehr gerechtfertigt werden. Die Software läuft Gefahr, an den Anforderungen des Kunden vorbei entwickelt zu werden und bei Fertigstellung schon veraltet zu sein. Deshalb wurde die agile Softwareentwicklung auf Basis des agilen Manifests begründet. Sie verspricht schnelle Auslieferungen bei einer kundenorientierten Sichtweise, so dass schon früh von der in Auftrag gegebenen Software profitiert werden kann. Ein großer Teil der Dokumentation entfällt dadurch, das gesamte System wird nicht von Anfang an spezifiziert, sondern stetig erweitert. Die konventionelle Qualitätssicherung hängt stark von diesen Dokumenten ab. Sie dienen als Grundlage für die Testfallerstellung, die zeitgleich mit dem Entwicklungsprozess beginnt. Änderungen an den Anforderungen verursachen weitreichende Nacharbeiten an den Testfällen. Um mit agilen Modellen Software für kritische Aufgaben zu entwickeln, wird jedoch für jede Auslieferung eine entsprechend hohe Qualität erwartet, für deren Sicherstellung eine umfassende Qualitätssicherung nötig ist. Bei linearen Vorgehensmodellen wurde ein umfassender Test vor der Auslieferung vorgenommen. Nun gibt es während der Entwicklung nach jedem Iterationsschritt eine Auslieferung. Dementsprechend oft wird ein kompletter Softwaretest benötigt. Hinzu kommt, dass unternehmenskritische Software von einer von der Entwicklung unabhängigen Institution überprüft werden sollte, um möglichst viel Vertrauen in das Produkt zu schaffen und einen objektiven Eindruck von der Qualität zu bekommen. Es treffen zwei gegensätzliche Anforderungen aufeinander. Auf der einen Seite schnelle, kundenorientierte Entwicklung mit möglichst vielen Auslieferungen und wenig Dokumentation, auf der anderen Seite eine aufwändige, externe Qualitätssicherung mit einem hohen Dokumentationsbedarf, die in bisherigen Modellen einmalig bei Projektende vorgenommen wurde. Zwischen diesen beiden Aspekten soll eine Schnittmenge gefunden werden, um den agilen Entwicklungsprozess mit einer tiefgehenden Qualitätssicherung in Einklang zu bringen. Als Ergebnis der folgenden Arbeit wird ein Vorgehensmodell erstellt, das den benötigen Prozess und seine einzelnen Aspekte beschreibt. Vielleicht birgt diese Betrachtung ein tieferes Verständnis für einen idealen Entwicklungsprozess. 8

13 1.1 MOTIVATION UND HINTERGRUND DER ARBEIT 1.1 MOTIVATION UND HINTERGRUND DER ARBEIT Die Thesis entsteht in Zusammenarbeit mit dem Büro für praktische Informatik BFPI GmbH (im folgenden BFPI genannt). Die BFPI ist bestrebt, externe Qualitätssicherung als Dienstleistung für ihre Kunden anzubieten. Durch langjährige Zusammenarbeit in Softwareentwicklungsprojekten für ihre Kunden aus dem Maschinen- und Anlagenbau ist sie dafür prädestiniert, Qualitätssicherungsmaßnahmen für Applikationen durchzuführen, die von diesen an andere Auftragnehmer vergeben wurden. Die Kunden lassen ihre Software häufig mit dem agilen Entwicklungsmodell Scrum (vgl. Kap. 2.3) erstellen. Mangelnde Kapazitäten, fehlendes Wissen über das Testen von Software und die Kritikalität des Produkts auf Seiten der Auftraggeber führten dazu, dass eine unabhängige Qualitätssicherung gewünscht wurde. Diese Rolle fällt dem BFPI zu. Es stellte sich die Frage, wie die externe Qualitätssicherung mit dem agilen Vorgehensmodell in Einklang gebracht werden kann, um einen möglichst hohen Mehrwert zu schaffen und den Entwicklungsprozess nicht zu behindern. Als Verantwortlicher für den Bereich der externen Qualitätssicherung bei der BFPI hat der Autor umfassende Kenntnisse zu den Bedürfnissen der beteiligten Unternehmen und den Anforderungen an das erweiterte Entwicklungsmodell erworben. 1.2 AUFGABENSTELLUNG UND ABGRENZUNG Es ist ein Konzept zu erarbeiten, das die Integration von Qualitätssicherung in einem Softwareentwicklungsprozess über drei Unternehmen (Auftraggeber, Auftragnehmer der Entwicklung sowie Auftragnehmer der QS) beschreibt. Die Standorte der Unternehmen sind dabei voneinander getrennt, die Zusammenarbeit ist über die räumliche Ferne zu koordinieren. Das Ausleihen von Mitarbeitern für die Projektdauer ist nicht möglich. Dabei stehen die Erhöhung der Produktqualität und die Orientierung an der agilen Methodik Scrum im Vordergrund. Es werden die Aufgabenteilung, der Methoden- und der Werkzeugeinsatz sowie die unternehmensübergreifenden Abläufe dargestellt. Das Konzept wird in einem Prozessmodell zusammengefasst, das geeignete Qualitätsmanagementmethoden zur langfristigen Erhöhung von Prozess- und Produktqualität integriert. 9

14 KAPITEL 1: EINFÜHRUNG Zur Evaluierung des Konzepts findet eine abschließende Anwendung auf ein Fallbeispiel statt. Es wird sich nur mit den Themen tiefer befasst, die zur Lösung beitragen. Grundlagen werden kurz umrissen, um die benötigte Theorie zu vermitteln. Der Fokus der Arbeit liegt auf unternehmensübergreifender Ebene. Die Aufgaben der einzelnen Beteiligten werden dargestellt und zugewiesen, eingesetzte Methoden und Werkzeuge erklärt. Die genaue Umsetzung innerhalb der Unternehmen wird nicht betrachtet, da hierfür bereits allgemein anerkannte Modelle existieren. Stattdessen stehen die Schnittstellen und Abläufe zwischen den beteiligten Unternehmen im Vordergrund. Eine genaue Beschreibung der einzelnen Aufgabendefinitionen, des Informationsbedarfes und Identifikationsmöglichkeiten möglicher Schwierigkeiten bei Entwicklung und im Prozess werden vorgenommen. Als weitere Einschränkung ist die Begrenzung auf drei beteiligte Unternehmen zu nennen. Eine Erweiterung auf mehrere Auftragnehmer ist nicht vorgesehen. Die Fallstudie dient zur Verdeutlichung des Konzepts anhand eines bereits durchgeführten Projekts. Auch hier steht die Beziehung zwischen den Unternehmen im Vordergrund, die Arbeitsweise innerhalb der einzelnen Firmen wird nicht betrachtet. 10

15 2 EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICK- LUNG UND SCRUM Um externe Qualitätssicherung in ein agiles Vorgehen zu integrieren, ist es erforderlich, die Problematik der Softwareentwicklung zu verstehen und bestehende Lösungsansätze zu betrachten. Dabei stehen die Unterschiede zwischen konventionellen und agilen Vorgehen im Vordergrund. Aufgrund der Vielfalt von agilen Methoden muss eine speziell für die Integration externer Qualitätssicherung ausgewählt und näher erläutert werden. 2.1 EINFÜHRUNG IN VORGEHENSMODELLE Die Entwicklung von Software ist ein hoch komplexes Fachgebiet. Viele verschiedene Aufgaben, Personalbedarfe und Abläufe müssen geplant, organisiert und koordiniert werden. Zwischen dem ersten Gedanken und dem fertigen Produkt liegen oft mehrere Monate bis Jahre Entwicklungszeit. Das zu entwickelnde Produkt ist hochkomplex. Eine hohe Anzahl an Abhängigkeiten, Schnittstellen, intransparenten Anforderungen sowie komplizierte Programmiersprachen bergen zusätzlich ein hohes Fehlerpotenzial. Ein entsprechend klares Vorgehensmodell wird benötigt, um den Überblick zu behalten und ein funktionierendes Produkt gemäß den Anforderungen liefern zu können. Seit Beginn der Software-Technik wurden Ingenieure mit diesem Problem konfrontiert und mussten sich aktiv mit der Gestaltung der Softwareentwicklung beschäftigen, da diese ohne klare Methoden und Strukturen nicht bewältigt werden konnten. Auch das für komplexe Arbeiten benötigte Projektmanagement war zur damaligen Zeit noch nicht ausgereift. Es wurde fast zeitgleich beim Manhattan Projekt und dem sogenannten Wettlauf ins All entwickelt und erstmals angewandt. [vgl. Lit07, S. 23f] Aus diesem Grund wurde schon früh damit begonnen verschiedene Methoden und Abläufe speziell für die Softwareentwicklung in sogenannten Vorgehensmodellen zusammenzufassen. Ein Vorgehensmodell ist eine Ablaufbeschreibung, mit der ein bestimmtes Ergebnis erreicht werden soll. Es ist meist in einzelne, zeitlich getrennte Abschnitte geteilt, sogenannte Phasen, die konsekutiv zu durchlaufen sind. Dies führt zu einer Verringerung der Gesamtkomplexität. Aufgabenbereiche sind zeitlich und inhaltlich unabhängig voneinander und können einzeln angegangen werden. [vgl. Hof08, S. 491] 11

16 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM Im Laufe der Zeit wurde eine Vielzahl an Vorgehensmodellen entwickelt wurde das erste sequentielle Vorgehensmodell für die Softwareentwicklung von Herbert D. Benington beschrieben, das sogenannte Stagewise Modell. [vgl. Ben56] Es beschreibt ein phasenorientiertes Vorgehen, das schon viele Elemente moderner Vorgehensmodelle enthält. So sind bereits Phasen für die Programm- und Quellcodespezifikation vorhanden, für das Schreiben des Quellcodes und das Testen. Mehr als ein Jahrzehnt später, 1970, erweiterte Winston Royce das Stagewise Modell. Er fügt zu den einzelnen Phasen Rückkopplungen hinzu. Damit in jeder Phase der Entwurf detaillierter werden kann, kommt es oft zu Iterationen mit der vorherigen Phase. Jedoch nicht mit weiter entfernten Phasen, da dies den Prozess unnötig verkomplizieren würde. Eine effektive Absicherung wurde geschaffen, um auf Unstimmigkeiten früh zu reagieren. Dieses grobe Konzept wurde von Royce in seinem eigenen Paper kritisiert und weiter verbessert. [Roy70] Bei der Erstellung des Militärstandards, dem DoD-STD-2167, wurde jedoch nur der erste Teil aufgenommen und Royce Bedenken sowie weitere Verbesserungen nicht mit einbezogen. [vgl. Lar04] Das Modell gewann schnell an großer Popularität und wurde seitdem viel verwendet. Seinen heutigen Namen, Wasserfallmodell, bekam es jedoch erst 1981 durch Barry Boehm. [Boe81] Wasserfallmodell Das Wasserfallmodell unterliegt bestimmten Kriterien. [vgl. Bal08, S. 520] Die Aktivitäten müssen in der vorgegebenen Reihenfolge vollständig durchlaufen werden. Jede Phase muss abgeschlossen werden, bevor die Nächste beginnt. Für den Abschluss einer Phase ist jeweils ein bestimmtes Dokument zu erstellen. Die Einbindung der Nutzer geschieht nur in den Definitionsphasen zu Beginn der Entwicklung. Das Modell hat heutzutage jedoch keine praktische Relevanz mehr. Zwei ausschlaggebende Nachteile sind dazu besonders hervorzuheben. Dem Wasserfallmodell fehlt es an Flexibilität. Es ist völlig statisch, die Anforderungen werden zu Beginn aufgenommen und Phase um Phase strikt abgearbeitet. Das die Anforderungen zu Beginn der Projekte häufig unklar sind und sich zudem mit der Zeit ändern können, wird nicht in Betracht gezogen. Somit sind die Projekte häufig zum Scheitern verurteilt, da das Produkt nicht den Bedürfnissen des Anforderers genügt. 12

17 2.1 EINFÜHRUNG IN VORGEHENSMODELLE Ein weiterer großer Nachteil ist die einmalige Testphase am Ende des Projekts. Sie findet unabhängig von der Implementierung statt. Fehler werden so erst sehr spät erkannt und sind dementsprechend teuer bei der Behebung. Sollte der Bedarf nach grundlegenden Änderungen festgestellt werden, kann eine komplette Neuplanung des Projektes nötig sein. [vgl. Hof08, S. 495f] Um diesen Nachteilen entgegenzuwirken, wurde das Wasserfallmodell erweitert. Es entstand das sogenannte V-Modell. V-Modell Das V-Modell erweitert die Phasen des Wasserfallmodells um Qualitätssicherung. Zu jeder Phase werden simultan passende Testfälle erstellt. So wird bei der Anforderungsanalyse der Abnahmetest geplant und bei dem Systementwurf der Systemtest. Nachdem die Implementierung abgeschlossen wurde, werden die Tests von unten nach oben ausgeführt. Bei grafischer Gegenüberstellung der Entwicklungs- und der Testphasen entsteht ein V, welches die Namensgebung erklärt. ABBILDUNG 2.1: DAS V-MODELL Zusätzlich trennt das V-Modell die Validierung und die Verifizierung voneinander. In den niedrigeren Teststufen wird die Software darauf geprüft, ob sie sich gemäß der Spezifikationen verhält. In den höheren Teststufen hingegen, steht die Eignung der Software für den Kunden im Vordergrund. Das Vorgehen ähnelt sonst dem Wasserfallmodell. Die Phasen werden konsekutiv durchlaufen, es gibt jeweils Rückkopplungen mit der vorherigen Phase. [vgl. Hof08, S. 496f] Der Test 13

18 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM wird schon früh definiert, findet jedoch immer noch am Ende der Entwicklung statt. Der Kunde wird weiterhin nur zu Beginn mit in den Entwicklungsprozess einbezogen. Das V-Modell erfreute sich besonders im deutschsprachigen Raum großer Beliebtheit und war lange Zeit Standard für IT-Projekte von Bund und Ländern bis es durch eine Erweiterung, das V-Modell XT, abgelöst wurde. V-Modell XT Das V-Modell XT [vgl. HH08] ist kein Vorgehensmodell, sondern vielmehr ein Leitfaden zur Entwicklung eines projektspezifischen Vorgehensmodells. XT steht für extreme tailoring und soll verdeutlichen, dass es auf verschiedene Projekttypen zugeschnitten werden kann. Um mit dem V-Modell XT ein Vorgehensmodell zu erstellen, ist zuerst der Projekttyp auszuwählen. Die Auswahl beschränkt sich auf drei verschiedene Möglichkeiten. Systementwicklungsprojekt eines Auftraggebers Systementwicklungsprojekt eines Auftragnehmers Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Zu jedem Projekttyp gibt es verschiedene verpflichtende und optionale Vorgehensbausteine, die beschreiben, welche Aktivitäten durchgeführt und welche Produkte erreicht werden müssen. Ein Produkt ist in dem Zusammenhang nicht nur das Endprodukt, sondern auch die Zwischenergebnisse. Dies können unter anderem Dokumente und Quellcode sein. Da die Vorgehensbausteine in keiner Reihenfolge zueinander stehen, muss zusätzlich eine Projektdurchführungsstrategie ausgewählt werden. Sie beschreibt die Reihenfolge der einzelnen Arbeitsschritte. Es gibt verschiedene Projektdurchführungsstrategien. Demgemäß kann unter anderem die inkrementelle, die komponentenbasierte oder die agile Entwicklung gewählt werden. Das Vorgehensmodell ist jedoch immer noch stark dokumentenlastig. Es müssen zum Abschluss vieler Vorgehensbausteine Dokumente erstellt werden, um in den nächsten Schritt überzugehen. Somit entfällt ein hoher Aufwand auf die Dokumentation. Spiralmodell Die vorhergehenden Modelle sind alle stark dokumentengetrieben. Das V-Modell und das Wasserfallmodell sind strikt linear. 14

19 2.2 ENTSTEHUNG UND PRINZIPIEN AGILER MODELLE Eine andere Herangehensweise wurde von Barry Boehm [Boe88] beschrieben. Im Gegensatz zu den sequentiellen Modellen beschreibt er ein evolutionäres Vorgehen. Es ist ein Metamodell, in dem 4 Schritte immer wieder von neuem durchlaufen werden. In jeder Phase kann das geeignete Vorgehensmodell gewählt werden, um die Ziele zu erreichen. Da die Anforderungen zu Projektbeginn meistens unklar sind, wird darauf gesetzt schon sehr früh eine laufende Software zu entwickeln, den sogenannten Prototyp. Dieser wird zusammen mit dem Nutzer evaluiert und mit jedem Durchlauf weiter verfeinert. Jeder Durchlauf wird mit einem Prototyp abgeschlossen. Dies wird solange wiederholt, bis der Prototyp zum Endprodukt gereift ist. Eine zusätzliche wichtige Erweiterung ist das Hinzufügen von Risikoanalysen. So können Risiken frühzeitig entdeckt und Gegenmaßnahmen rechtzeitig geplant und umgesetzt werden. Dadurch ist das Modell risikogetrieben, das Risiko ist möglichst zu minimieren. Das Spiralmodell konnte sich jedoch nicht gegen die sequentiellen Pendants durchsetzen, auch wenn es in der Theorie viel Anerkennung fand. [vgl. OW08] 2.2 ENTSTEHUNG UND PRINZIPIEN AGILER MODELLE Ende der 90er Jahre entwickelte sich mit der agilen Softwareentwicklung eine Gegenströmung zu den zunehmend monumentalen Modellen. Diese beruhten vor allem auf einem iterativen Vorgehen, ähnlich dem Spiralmodell. Der lang verfolgte Ansatz, der Softwareentwicklung durch starke Standardisierung ihre Komplexität zu nehmen, führte zu einer hohen Bürokratisierung. Die Entfaltung der Mitglieder wurde gehemmt und eigenverantwortliches Handeln verhindert. Teams mit hohem Potential erfuhren eine Standardisierung auf das Mittelmaß. Hinzu kommt, dass die Entwicklung zu einem Selbstzweck wurde. Das Produkt stand nicht mehr im Vordergrund, der Praxisbezug ging verloren, es wurden die einzelnen Phasen abgearbeitet, ohne dass eine Validierung erfolgte. [vgl. OW08, S. 14] Die agile Bewegung setzt sich zum Ziel, den Fokus von den Vorgehensmodellen zurück auf das Produkt und den Kunden zu lenken. Dabei sollen die Vorteile und Errungenschaften der bisherigen Entwicklungsformen erhalten bleiben, die starken Begrenzungen jedoch aufgelöst werden. [vgl. OW08, S. 12f] Im Jahr 2000 wurde das agile Manifest von führenden Personen der agilen Softwareentwicklung niedergeschrieben, um verbindliche Grundsätze festzuhalten. 15

20 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. 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 Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. [agile_manifesto] Es wird deutlich, dass der Fokus auf die Erstellung funktionierender Software gelegt wird, bei einer möglichst hohen Befriedigung der Kundenbedürfnisse. Die Werte der rechten Seite sind immer noch willkommen und sollten nach Möglichkeit eingehalten werden, sie dürfen jedoch nicht die Werte auf der linken Seite einschränken. Bei monumentalen Modellen war dies der Fall. Prozesse, Werkzeuge, Dokumentation, Vertragsverhandlung und Pläne fallen jedoch nicht völlig weg, sie nehmen nur einen geringeren Stellenwert ein. Eine Entwicklung agil zu nennen, nur auf Grund fehlender Dokumentation, ist falsch. Ein weiteres Manifest wurde durch eine Gruppe um David Anderson verfasst, die Declaration of Interdependence. Sie begründet agile Grundlagen für das Management agiler Projekte [pmdoi]. Agile and adaptive approaches for linking people, projects and value We are a community of project leaders that are highly successful at delivering results. To achieve these results: We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. 16

21 2.2 ENTSTEHUNG UND PRINZIPIEN AGILER MODELLE We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situationally specific strategies, processes and practices. Mit interdependence wird sowohl die Wechselbeziehung zwischen den einzelnen Teammitgliedern bezeichnet, als auch die Zusammenhänge zwischen dem Team, den Kunden und den Interesseneignern. Der Schwerpunkt liegt hier auf dem Projektmanagement und lässt die erhofften Mehrwerte durch agile Methoden erkennen sowie die Mittel, durch die sie erreicht werden sollen. Es ist ersichtlich, wodurch die agilen Methoden ihren Namen bekommen haben. Statt eines streng regulierten Prozesses gibt es einen Rahmen, in dem die Teammitglieder eigenverantwortlich arbeiten. Die Entwicklung einer funktionierenden Software steht im Vordergrund; Dokumentation erfolgt nur dort, wo es notwendig ist. Teammitglieder sollen sich mit dem Projekt identifizieren und selbst für die Ergebnisse einstehen, bessere Leistung durch erhöhte Motivation wird erhofft. Mehr Freiheiten bedeuten eine steigende Innovationsfähigkeit, die bessere Ergebnisse hervorbringen kann. Zu Beginn der Entwicklung wird nicht davon ausgegangen, dass alle Anforderungen schon existieren und dokumentiert werden können. Die Bedürfnisse der Nutzer sollen sich während der Entwicklung herauskristallisieren. Dafür ist eine enge Zusammenarbeit mit den späteren Nutzern notwendig. Meist wird den Entwicklern eine konkrete Ansprechperson zugewiesen, auf die während des Entwicklungsprozesses immer zurückgegriffen werden kann. Eine kurzfristige Reaktion auf Änderungen ist notwendig, eine flexible Anpassung auf sich ändernde Ausgangsbedingungen gewollt. [vgl. OSW, S. 17f] Die Entwicklungszyklen sind möglichst kurz gehalten, in der Regel 4-6 Wochen. Alle drei Entwicklungszyklen ist eine neue Produktversion fertigzustellen, die an den Kunden übergeben werden kann. Es wird so früh wie möglich ein brauchbares Produkt produziert, so dass sich für den Auftraggeber unmittelbar ein Mehrwert ergibt. Die Ergebnisse des Projekts erfahren eine frühe Evaluierung, über die der weitere Verlauf der Entwicklung gegebenenfalls anpassbar ist. [vgl. HRS09, S.8f] Die agile Methode setzt ein gut eingespieltes Team voraus. Kommunikation ist notwendig, alle Teammitglieder müssen zusammenarbeiten. Die Größe eines agilen Teams beträgt in der 17

22 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM Regel weniger als Mitglieder. Mit wachsender Teamgröße wird es zunehmend schwerer, ein agiles Vorgehen umzusetzen. Es gibt jedoch Ansätze, um ein agiles Vorgehen auch in größeren Projekten mit über 300 Projektmitarbeitern zu verwirklichen. [vgl. HRS09, S. 92] Für die Umsetzung der agilen Methode gibt es unterschiedliche Modelle. Das erste agile Vorgehensmodell war XP (extreme Programming). Es wurde von Kent Beck 1999 während eines Projekts für Chrysler entwickelt und kurz darauf publiziert. Einige dabei eingesetzte Praktiken sind bezeichnend für agile Modelle und werden auch in anderen Modellen eingesetzt. [Bec99] On-site customer Der Kunde ist während der Entwicklung vor Ort. Es wird zu Beginn keine umfassende Anforderungsspezifikation geschrieben. Stattdessen steht der Kunde selbst stets zur Verfügung, um fachliche Unterstützung zu geben und darauf zu achten, dass seine Wünsche richtig verstanden werden. Er führt am Ende den Akzeptanztest durch, um die Software zu validieren. Planning game Mit planning game wird die Planung des nächsten Entwicklungszyklus bezeichnet. Der Kunde nennt und priorisiert seine Anforderungen. Die Entwickler schätzen den benötigten Aufwand. Short releases Die Entwicklungszyklen sind kurz. Es wird dem Kunden oft eine neue Version der Software übergeben. Die Erfahrungen der Anwender mit dem Produkt werden bei der Weiterentwicklung berücksichtigt. Es wird möglichst früh ein return-on-investment erzielt. Metaphor Eine Metapher beschreibt auf einfache Weise das System und seine Architektur. Sie dient dazu, schnell und einfach die Software zu erklären, ohne dass ein technischer Hintergrund zwingend erforderlich ist. Collective ownership Es gibt nur eine Codebasis, für die alle Entwickler gemeinsam verantwortlich sind. Jeder Entwickler des Teams darf den Code von jedem anderen Entwickler ändern. 18

23 2.2 ENTSTEHUNG UND PRINZIPIEN AGILER MODELLE Continuous integration Der geschriebene Quellcode wird kontinuierlich in das gesamte Produkt integriert, um späteren Kompatibilitätsproblemen vorzubeugen. Die Software kann schon frühzeitig als Gesamtsystem getestet werden. Coding standards Das Team einigt sich schon früh auf Richtlinien für die Codeerstellung. Der Quellcode soll einheitlich gestaltet und gut lesbar sein. 40 hour week Es wird ein einheitliches Entwicklungstempo eingehalten. Die Entwickler sollen auf dem Niveau ihrer höchsten Leistungsfähigkeit arbeiten. Dies aber nicht mehr als notwendig und nicht länger als 40 Stunden die Woche. Sollten Überstunden zur Regel werden, deutet dies auf ein Managementproblem hin, nicht auf Schwächen in der Entwicklung. Testing Die Programmierer schreiben automatisch ausführbare Tests für die Software, nach Möglichkeit vor Implementierung der Funktion in Form von Test Driven Development (TDD). Die Kunden schreiben Funktionstest in Form von Anwendungsfällen. Der finale Akzeptanztest findet im laufenden Betrieb statt. Simple design Das Programmdesign soll so einfach wie möglich gehalten werden. Ein gutes Verständnis und leichte Änderbarkeit des Quellcodes stehen im Vordergrund. Refactoring Der Quellcode soll wann immer möglich umstrukturiert werden, wenn sich damit ein einfacheres Ergebnisse erzielen lässt. Bei der Änderung oder Implementierung einer Funktion soll immer die Lösung gewählt werden, die zum einfachsten Design führt, auch wenn dies Mehraufwand zur Folge hat. Pair programming Eine der umstrittensten Vorschläge Becks ist die paarweise Programmierung. Zwei Personen sitzen an einem Computer. Während einer die Anforderung implementiert, denkt der zweite mehr strategisch über das Vorgehen nach. Er soll mögliche Probleme frühzeitig erkennen und 19

24 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM auf einfachere Lösungen hinweisen. Durch ein regelmäßiges Wechseln der Partner wird ein Gruppenverständnis über den kompletten Code gefördert. Diese 12 Faktoren sind für XP verbindlich. Mehrere agile Vorgehensmodelle wurden von diesen Praktiken inspiriert und setzen sie zumindest zum Teil um. Neben XP haben sich weitere agile Modelle herausgebildet. Zu den populäreren Modellen neben XP gehören Crystal, FDD und Scrum. [vgl. Bal08, S. 651ff] Einen Vergleich zwischen verschiedenen Vorgehensmodellen, agilen wie auch konservativen, haben Boehm und Turner vorgenommen. [vgl. BT08, S.165ff] Sie haben die Modelle nach Bezug auf kritische Bereiche, Life Cycle Aktivitäten und Beschränkungen analysiert. Tabelle 2.1 zeigt verschiedene Vorgehensmodelle nach einem Agilitäts-Ranking, aufsteigend nach der Anzahl der Beschränkungen. Ist für ein Vorgehensmodell eine unterschiedliche Anzahl an Beschränkungen ausgewählt, ist dies als von-bis anzusehen. Agility Methode Rank 1 Scrum 2 Adaptive Software Development (ASD) 3 Lean Development (LD) 4 Crystal 5 extreme Programming (XP) 6 Dynamic Systems Development Method (DSDM) 7 Rational Unified Process (RUP) 8 Team Software Process (TSP) 9 Feature-Driven Development (FDD) 10 Capability Maturity Model Integration (CMMI) 11 Capability Maturity Model for Software (SW-CMM) 12 Personal Software Process (PSP) 13 Cleanroom Sehr Niedrig Niedrig Mittel Hoch Sehr Hoch TABELLE 2.1: ANZAHL UND STÄRKE VON BESCHRÄNKUNGEN VON VORGEHENSMODELLEN [AUS BT08, S. 167] 20

25 2.3 SCRUM Es ist gut ersichtlich, dass Scrum die leichtgewichtigste Methodik ist. Sie gibt kaum mehr als einen Prozessrahmen vor, in dem das Team selbstbestimmt arbeitet. Nach unten nehmen die Beschränkungen für den Prozess zu. Dies führt über XP mit der expliziten Einhaltung der Praktiken bis zu Cleanroom, mit einer strikten, auf fehlerfreien Code ausgelegten Methodik. Scrum bringt für Einbindung von externer Qualitätssicherung in die agile Softwareentwicklung verschiedene Vorteile mit. Durch die wenigen Beschränkungen lässt sich das Modell anpassen, ohne von seinen Vorgaben abzuweichen. Je restriktiver ein Modell gestaltet ist, desto schwerer wird es, sinnvolle Anpassungen zu bewirken. Des Weiteren ist Scrum in seinem Kern sehr agil. Die Gefahr den agilen Prinzipien zu widersprechen, dementsprechend geringer. Hinzu kommt, dass Scrum eines der beliebtesten agilen Vorgehensmodelle ist und dementsprechend viele repräsentative Studien zu seinem Einsatz vorliegen. Zusätzlich ergib sich Scrum durch die Aufgabenstellung als Ausgangsmodell. Aus diesen Gründen wurde Scrum im Kontext dieser Arbeit als agiles Modell ausgewählt und um externe Qualitätssicherung erweitert. Da weiterhin die agilen Richtlinien beachtet werden, sollte das Ergebnis mit kleinen Änderungen auch auf andere agile Modelle anwendbar sein. 2.3 SCRUM Nach der Auswahl von Scrum als Referenzmodell ist eine Aufarbeitung der Grundlagen des Vorgehensmodells notwendig. Basierend auf dem ursprünglichen Prozess kann eine Erweiterung um die externe Qualitätssicherung stattfinden GRUNDGEDANKEN UND BEGRIFFLICHKEITEN Ursprünglich wurde Scrum nicht direkt für die Softwareentwicklung entwickelt. Es stammt aus einer Zeit, in der von agilen Modellen noch nicht die Rede war. Takeuchi und Nonaka beschrieben 1986 eine inkrementelle-iterative Projektmanagementmethodik. [TN86] Es wird von einem sich selbst verwaltenden Team ausgegangen, eine subtil geführte, lernende Organisation. Das Vorgehen wird immer wieder mit dem Scrum aus dem Sport Rugby verglichen, bei dem alle Teammitglieder zusammenarbeiten und gemeinsam auf das ständig wechselnde Spielgeschehen reagieren, um den Sieg zu erringen. Zu seinem heutigen Bekanntheitsgrad verhalfen Jeff Sutherland und Ken Schwaber durch ihre Präsentation zu Scrum 1995 auf der OOPSLA 95 in Austin, Texas. 21

26 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM Scrum ist ein Rahmenwerk, in dem die Entwicklung eines Softwareprodukts stattfindet. Das Vorgehen ist iterativ. Die Entwicklung findet in so genannten Sprints statt. Ein Sprint ist timeboxed, er hat eine zuvor genau festgelegte Länge, in der Regel vier Wochen. In diesen vier Wochen werden zuvor festgelegte Anforderungen umgesetzt. Die Anforderungen wurden zuvor priorisiert. So kann mit den wichtigsten Anforderungen begonnen und sich zu den zweitrangigen vorgearbeitet werden. Sollten am Ende des Sprints noch Anforderungen offen sein, ist dies unproblematisch, da die wichtigen bereits umgesetzt wurden. Am Ende eines Sprints sollte das entwickelte Teilprodukt lauffähig sein. [vgl. Pic08, S. 7f] In Abbildung 2.2 ist das Vorgehen grafisch dargestellt. In Scrum sind mehrere Rollen definiert, der ScrumMaster, der Product Owner, das Scrum- Team sowie Nebenrollen. [vgl. Wir09, S. 36ff] Das ScrumTeam ist für die Entwicklung des Produkts verantwortlich. Es besteht aus allen Personen, die für die Erstellung der Software erforderlich sind. Es ist funktionsübergreifend. So können Softwareentwickler, Dokumentatoren, Analysten, Tester und alle weiteren zur Entwicklung benötigten Kompetenzen Teil des ScrumTeams sein. Zu beachten ist, dass die ideale Größe für ein ScrumTeam zwischen 3 und 9 Personen liegt. Es ist keine Führungsrolle vorgesehen, Hierarchien sind nicht vorhanden. Das ScrumTeam ist selbst organisierend. Das Ziel der Entwicklung ist für das gesamte Team verbindlich, alle sind gemeinsam für die Ergebnisse verantwortlich. ABBILDUNG 2.2: DIE GRAFISCHE DARSTELLUNG VON SCRUM 22

27 2.3 SCRUM Der ScrumMaster ersetzt den Projektmanager. Er hat eine unterstützende Funktion und nur bedingt eine führende. Seine Aufgabe ist es, den Erfolg des Projekts zu sichern. Dies geschieht auf zwei Wegen. Zum einen stellt er sicher, dass die Regeln und Rahmenbedingungen von Scrum eingehalten werden. Zum anderen steht er schützend über dem ScrumTeam, negative Einflüsse auf das Projekt sind abzuwehren und Hindernisse von ihm zu beseitigen. Der ScrumMaster nimmt jedoch keinen Einfluss auf die Entwicklung, eine Intervention ist nur nötig, wenn das ScrumTeam nicht von alleine zur Lösung eines Problems kommt. Der Product Owner ist für das endgültige Produkt und den wirtschaftlichen Erfolg des Projekts verantwortlich. Er stellt die Schnittstelle zum Kunden und Nutzer dar. Seine Aufgabe ist es, sich in die Anwendungsdomäne des Kunden einzuarbeiten und mit ihm zusammen die Anforderungen an das Projekt in sogenannten User Storys niederzuschreiben. Im Laufe des Projekts wird der Product Owner die User Storys regelmäßig aktualisieren und anpassen. Er ist während der Entwicklung der Ansprechpartner für das Team. In den Nebenrollen sind die Stakeholder des Projekts enthalten, also alle mit einem Interesse am Gelingen des Projekts. Zum einen ist dies der Kunde, zum anderen das Management des eigenen Unternehmens. Zu Kunden hält der Product Owner engen Kontakt, zum eigenen Management der ScrumMaster, um den Entwicklungsstand zu kommunizieren und Hindernisse zu beseitigen. Neben der ständigen Kommunikation innerhalb des Teams und zwischen den Rollen gibt es verbindliche Meetings zu festgelegten Zeitpunkten. [vgl. Han10, S. 61ff] Das Sprint Planning Meeting dient als Vorbereitung auf den Sprint. Es kommen Product Owner, ScrumMaster und das ScrumTeam zusammen und gehen gemeinsam das Product Backlog, eine Anforderungsliste, durch. Geeignete User Storys werden gemeinsam ausgewählt und in das Selected Backlog übertragen. Das Selected Backlog wird daraufhin für die Zeit des Sprints nicht mehr verändert, während der Product Owner das Product Backlog ständig verändern kann. Im weiteren Verlauf des Meetings werden die User Storys des Selecteted Backlogs in einzelne Aufgaben zerlegt. Es entsteht ein Sprint Backlog, dem während des Sprints die einzelnen Aufgaben entnommen werden. Anhand des Sprint Backlogs ist der Fortschritt des Projekts erkennbar. Innerhalb des Sprints findet jeden Tag zu einem festen Zeitpunkt ein Meeting statt, das sogenannte Daily Scrum. Der Vortag wird reflektiert und die Aufgaben des laufenden Tages besprochen. Das Meeting ist in der Regel 15 Minuten lang. Aufgetretene Probleme werden 23

28 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM erwähnt, die Lösung der Probleme findet jedoch außerhalb des Meetings statt. Das Daily Scrum hilft dem ScrumMaster dabei, den Fortschritt des Projekts festzustellen und mögliche Hindernisse zu erkennen. Am Ende eines jeden Sprints werden zwei Meetings durchgeführt. Im Sprint-Review werden die Ergebnisse des Sprints den Kunden und Stakeholdern vorgestellt. Es ist eine Präsentation der laufenden Software. Wichtig ist das Feedback der Beteiligten, da das Sprint-Review eine wichtige Funktion für die Bestimmung des weiteren Verlaufs der Entwicklung hat. Die Sprint-Retrospektive ist eine Diskussion der Projektbeteiligten am Ende des Sprints. Sie soll einen kontinuierlichen Lernprozess anstoßen. Positive und negative Aspekte der Zusammenarbeit und des Entwicklungsprozesses werden zusammengetragen und Schlüsse für die nächsten Sprints gezogen. Am Ende soll eine Liste mit konkreten Verbesserungsvorschlägen entstehen, die vom ScrumMaster und Team umgesetzt wird. Neben den Rollen und Meetings sind verschiedene Dokumente vorgesehen. Das Product Backlog enthält alle Anforderungen des Kunden als User Storys. Eine User Story ist die Definition einer Programmfunktion in Form einer Beschreibung, was der Kunde mit ihr verrichten möchte. Der Aufwand der UserStorys ist geschätzt, die Priorität nach Wert für den Kunden defniert. Das Product Backlog wird durch den Product Owner gepflegt und Änderungen sind stets vorbehalten. Im Sprint Backlog werden die im Sprint umzusetzenden Aufgaben festgehalten. Hierzu werden aus dem Product Backlog UserStorys vom Product Owner, ScrumMaster und Scrum- Team ausgewählt und in einzelne Aufgaben zerlegt. Die einzelnen Aufgaben werden im Sprint Backlog dokumentiert. Das Sprint Backlog ist während des Durchlaufs eines Sprints fest. An ihm orientiert sich das Team während der Entwicklung, der Fortschritt wird an der Abarbeitung der Aufgaben gemessen. Zusätzlich gibt Scrum mehrere verbindliche Prinzipien vor. Während sich die meisten aus den Prinzipien der agilen Softwareentwicklung ergeben, gilt es eine besonders hervorzuheben. Die Definition of Done, also die Definition, wann eine User Story als abgeschlossen angesehen werden kann. Sobald eine User Story beendet wurde, soll sie für den Kunden verfügbar sein. Eine User Story, die nur zu 90 % abgeschlossen ist, bietet keinen Mehrwert. Meist handelt es sich dabei um mehrere Kriterien. Eine Definition of Done könnte die erfolgreiche Abnahme durch die Qualitätssicherung sein. [vgl. Wir09, S.32ff] 24

29 2.4 ZUSAMMENFASSUNG PROZESSVERLAUF Der Prozess von Scrum beginnt mit einer Vision, einer Idee für das zu entwickelnde Produkt. [vgl. Wir09, S. 29] Der darauf folgende Ablauf ist grob vorgegeben. [vgl. Pic08, S. 81ff] Der Product Owner setzt sich daraufhin mit dem Kunden zusammen, um seine Anforderungen in Form von User Storys aufzunehmen und in das Product Backlog zu übertragen. In dem Product Backlog werden die Anforderungen priorisiert und der Aufwand geschätzt. Vor Beginn des ersten Sprints setzen sich ScrumMaster, ScrumTeam und Product Owner zusammen, um die User Storys für den ersten Sprint auszuwählen und in Aufgaben zu zerlegen. Das Sprint Backlog wird erstellt. Während des Sprints entnimmt das Team eigenständig die Aufgaben aus dem Sprint Backlog. Hier ist keine Steuerung durch den ScrumMaster erforderlich. Dieser ist damit beschäftigt, alle Hindernisse aus dem Weg zu räumen, so dass das Team ohne Schwierigkeiten arbeiten kann. Der Product Owner hält regelmäßig Rücksprache mit dem Team und lässt sich die neuesten Ergebnisse zeigen. Jeden Tag findet ein kurzes Meeting statt, in dem der Stand und zukünftige Schwierigkeiten besprochen werden. Das Resultat am Ende des Sprints wird im Sprint-Review vorgestellt und kann sofort an den Kunden übergeben werden. In der Sprint Retrospective wird der vergangene Sprint analysiert und Veränderungen für die Zukunft herausgearbeitet. Es ist gut ersichtlich, dass die Mehrheit der 12 von Beck postulierten Regeln für XP auch in Scrum wieder zu finden sind. Auch XP typische Praktiken wie TDD und Pair Programming lassen sich gut in Scrum umsetzen. [vgl. Pic08, S. 85] Scrum ist ein durch und durch agiles Vorgehensmodell, das dennoch klare Richtlinien und einen übergeordneten Prozess liefert, in dem die Rahmenbedingungen klargestellt werden. 2.4 ZUSAMMENFASSUNG Zu Beginn des Kapitels wurde eine Einführung in Vorgehensmodelle gegeben und der Unterschied zwischen konventionellen und agilen Modellen herausgearbeitet. Die konventionellen Modelle mit ihren konsekutiven Phasen wurden vorgestellt. Für die Entwicklung von komplexen Produkten hat sich in Deutschland das V-Modell als Standard durchgesetzt. Auf Grund 25

30 KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM von Inflexibilität, einem geringen Kundenbezug und hohem bürokratischen Aufwand sind mit diesen Modellen entwickelte Projekte oft gescheitert. Zu den zunehmend monumentaleren Modellen hat sich Ende der 90er Jahren eine Gegenströmung entwickelt, die agile Softwareentwicklung. Mit kurzen Iterationen, hoher Kundennähe und selbstständigen Entwicklern wird die Software inkrementell erstellt. Im Gegensatz zum konventionellen Vorgehen, bei der das vollständige Produkt erst am Ende der Entwicklung übergeben wird, entsteht die Software nun Stück für Stück. Der Kunde bekommt schon früh ein Produkt, das in jeder Iteration an Funktionsumfang gewinnt. In der agilen Softwareentwicklung gibt es verschiedene Vorgehensmodelle. Eines der Leichtgewichtigsten ist Scrum. Es wurde als Referenzmodell für die weitere Verwendung in der Arbeit ausgewählt. Scrum definiert drei Rollen: Den Product Owner, den ScrumMaster und das ScrumTeam. Der Product Owner übernimmt die Kommunikation mit dem Kunden und stellt die Anforderungen bereit, der ScrumMaster schützt das ScrumTeam vor Unterbrechungen und beseitigt Hindernisse. Das ScrumTeam entwirft, implementiert und testet die Software. Die Entwicklung findet in einem Zeitrahmen von 2 bis 6 Wochen statt, wobei dem jeden Tag ein kurzes Meeting stattfindet. Scrum ermöglicht es dem Team, völlig frei zu arbeiten und bietet viel Platz für den Einsatz einer externen Qualitätssicherung. Mit der Aufarbeitung der verschiedenen Vorgehensmodelle wurde die Grundlage für die Gestaltung des Entwicklungsprozesses vermittelt. Konventionelle und agile Modelle wurden beschrieben und voneinander abgegrenzt. Scrum ist als passendes Referenzmodell identifiziert worden und wird in der vorliegenden Arbeit als Vorgehensmodell genutzt. 26

31 3 ANALYSE DES QUALITÄTSMANAGEMENTS ZUR VERWENDUNG MIT AGILEN MODELLEN Während Vorgehensmodelle den projektspezifischen Ablauf beschreiben, zielt das Qualitätsmanagement auf organisatorische Optimierung zur Verbesserung der Produktqualität. Um die Prozess- und die Produktqualität langfristig zu erhöhen, sollen Qualitätsmanagementelemente in den Entwicklungsprozess eingearbeitet werden. Während es Qualitätsmanagementkonzepte für schwergewichtige Modelle gibt, muss dies für die agile Softwareentwicklung im Einzelnen erarbeitet werden. 3.1 EINFÜHRUNG IN DAS QUALITÄTSMANAGEMENT Zur Vertiefung in diesem Gebiet ist eine klare Definition von dem Begriff Qualität notwendig. In der ISO 9001: , der gültigen Norm für Qualitätsmanagement, wird Qualität wie folgt definiert: Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt. Qualität gibt also das Ausmaß an, in dem zuvor festgelegte Anforderungen an das Produkt umgesetzt wurden. Zu beachten ist, dass die beschriebenen Anforderungen selbst eine gewisse Qualitätsdefinition mitbringen. Werden in den Anforderungen Toleranzgrenzen gesetzt, kann das Produkt trotz eines hundertprozentigen Qualitätsgrades fehleranfällig sein, da diese Toleranzen zuvor, meist aus Kostengründen, mit einkalkuliert wurden. Dies wird in der Definition von R. A. Broh aus Managing Quailty for Higher Profits von 1982 [Bro82] deutlich. Quality is the degree of excellence at an acceptable price and the control of variability at an acceptable cost Es wird das Kosten-Nutzen-Verhältnis in den Vordergrund gestellt. Die Kosten für die Qualitätserreichung sollten nicht über den Kosten liegen, die durch mangelhafte Produkte entstehen. 27

32 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN Die Ausrichtung der Qualität im Unternehmen sollte am Kunden und im Vergleich zu den Mitbewerbern geschehen. Ein Wettbewerbsvorteil ist anzustreben, um die Kunden zu einer Kaufentscheidung für das eigene Produkt zu bewegen. [vgl. BW08, S. 3] Unter Qualitätsmanagement werden laut ISO9000 alle Aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität verstanden. Ziel ist die Sicherung eines langfristigen Unternehmenserfolges durch die Erhöhung der Kundenzufriedenheit und Reduzierung von Kosten und Mängeln. Die Produktqualität ist stark von der Prozessqualität abhängig. Ein reibungsloser Prozess hat eine hohe Produktqualität zur Folge, da alle Arbeitsschritte überprüfbar und standardisiert ablaufen. Die Prüfung eines Produktes nur nach seiner Fertigstellung hat sich als zu teuer und langwierig erwiesen. Die Korrekturkosten für Fehler steigen mit jeder durchlaufenen Entwicklungsphase nahezu exponentiell an. [vgl. Lig09, S. 32] Aufgabe des Qualitätsmanagements ist es, die Entstehung der Fehler zu vermeiden oder für eine frühestmögliche Aufdeckung zu sorgen. Schon während der Entwicklung des Produkts müssen Maßnahmen ergriffen werden, um eine hohe Qualität zu gewährleisten. Als Prozess definiert die ISO 9000:2000 (2000)... einen Satz von in Wechselwirkung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt. Ein Prozess hat folglich einen Input, der über eine aufeinanderfolge Durchführung verschiedener Aktivitäten in einen bestimmten Output umgewandelt wird. Als Geschäftsprozess werden die Prozesse mit direktem Kundennutzen bezeichnet. In einem Softwareentwicklungsprozess wird das Produkt hergestellt und Mehrwert für den Kunden generiert. Dementsprechend ist er ein Geschäftsprozess. In dieser Arbeit wird Prozess und Geschäftsprozess als synonym verwendet. Die Gestaltung, Steuerung und Kontrolle der Geschäftsprozesse geschieht durch das Prozessmanagement. Siehe hierzu Kapitel 7.1. Das Qualitätsmanagement besteht aus fünf Komponenten. Die Qualitätspolitik, Qualitätsplanung, Qualitätssicherung, Qualitätslenkung und Qualitätsverbesserung. [vgl. Wal11, S. 40f u. KW08, S. 38] Unter Qualitätspolitik wird die Ausrichtung des Unternehmens auf Qualität bezeichnet. Sie ist Aufgabe des obersten Managements, wird schriftlich festgelegt und dient als Basis zur Ableitung von Qualitätszielen für die Geschäftsebene. 28

33 3.1 EINFÜHRUNG IN DAS QUALITÄTSMANAGEMENT Die Qualitätsplanung legt die Qualitätsziele fest. Qualitätsziele sind die Ergebnisse, die durch das Qualitätsmanagement zu erreichen sind. Des Weiteren werden die zur Umsetzung benötigten Ressourcen und Prozesse geplant und eingeführt. In der Softwareentwicklung werden hier insbesondere genaue Spezifikationen der Anforderungen gefordert, um daraus die Qualitätsziele abzuleiten. Qualitätssicherung ist der vertrauensbildende Teil des Qualitätsmanagements. Der Nachweis über die Einhaltung der Qualitätsanforderungen wird erbracht und die eingesetzten Maßnahmen des Qualitätsmanagements überprüft. Zudem ist Qualitätssicherung für die Dokumentation der eingesetzten Methoden verantwortlich. Die Qualitätssicherung geht fließend in die Qualitätslenkung über. Die Qualitätslenkung dient der Aufdeckung und Vermeidung von Fehlern im Prozess und beim Produkt. Dies kann zum einen konstruktiv, also durch Maßnahmen zur Verhinderung von Fehlern, geschehen. Andererseits sind analytische Maßnahmen durch die Prüfung der End- und Zwischenprodukte möglich. Die Qualitätsverbesserung steigert die Fähigkeit des Unternehmens, Qualitätsanforderungen zu erreichen. Dies geschieht durch kontinuierliche Prozessverbesserung oder die Steigerung der Reifegrade der Prozesse. Die Umsetzung des Qualitätsmanagement geschieht in einem Qualitätsmanagementsystem (QMS). In der ISO 9000:2000 ist es als ein System für die Festlegung der Qualitätspolitik und von Qualitätszielen sowie zum Erreichen dieser Ziele definiert. Kern des Qualitätsmanagementsystems ist die Aufbau- und Ablauforganisation. Die Organisation wird durchgängig transparent gestaltet und gut dokumentiert, die Qualität fördernden Maßnahmen direkt in den Ablauf eingebunden und mit messbaren Größen versehen. [vgl. BW08, S.22ff] Zur Umsetzung eines Qualitätsmanagementsystems im Unternehmen gibt es im Wesentlichen zwei verschiedene Ansätze. Auf der einen Seite haben wir kontinuierliche Ansätze mit einer problemorientierten Vorgehensweise, auf der anderen Seite stehen die modellbasierten Ansätze mit einem lösungsorientierten Vorgehen. [vgl. Lig09, S. 11] Kontinuierliche Ansätze Die kontinuierlichen Ansätze bestehen aus fortlaufender Verbesserung gezielter Problemfelder der Organisation. Das Hauptaugenmerk liegt auf der Verbesserung der Prozesse. Kontinuierlichen Ansätzen liegt in der Regel der PDCA-Zyklus (bzw. Deming-Zyklus) zu Grunde. 29

34 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN PDCA steht für Plan-Do-Check-Act und wurde in den 1950ger Jahren von W. Edwards Deming entwickelt. PDCA ist in vier Phasen unterteilt, mit denen Prozesse und deren Aktivitäten verbessert werden sollen. [vgl. Koc11, S. 118f] Planen (plan) Zu Beginn wird eine Ist-Analyse vorgenommen. Aufgrund der gewonnen Erkenntnisse wird ein Verbesserungsplan erstellt und Ziele für die weiteren Schritte festgelegt. Umsetzen (do) Einleiten der nötigen Maßnahmen und Ausrollen des Verbesserungsplans im Unternehmen. Überprüfen (check) Die eingeführten Veränderungen werden durch erneute Aufnahme und Analyse von Qualitätsindikatoren überprüft. Verbessern (act) Bestehen Abweichungen zwischen Soll und Ist, sind die Phasen Planen und Umsetzen erneut anzustoßen und solange zu durchlaufen, bis die Prozesse die gesetzten Ziele erreichen. Bei Zielerreichung müssen Maßnahmen für die weitere Optimierung und Einhaltung des Prozesses geplant und ergriffen werden. Dieses Vorgehen erlaubt Verbesserungen gezielt zu priorisieren und kritische Probleme direkt zu beheben. Das Qualitätsmanagementsystem wird direkt auf das Unternehmen zugeschnitten und hilft die individuellen Stärken weiter auszubauen. Es ist jedoch ein schwieriger und langwieriger Prozess, bis das gewünschte Maß an Optimierung eingetreten ist. Modellbasierte Ansätze Modellbasierte Ansätze basieren auf standardisierten Vorgaben. Die im Unternehmen vorhandenen Prozesse und Praktiken werden gegen ein Referenzmodell geprüft, in dem Referenzprozesse und Best Practices festgehalten sind. Auf diese Weise ist der Stand des Qualitätsmanagements mit anderen Unternehmen vergleichbar. Weiter ist es möglich, die Modelle auf das eigene Unternehmen anzuwenden und ein Qualitätsmanagementsystem gemäß erprobter Praktiken aufzubauen. Die Anforderungen an die 30

35 3.1 EINFÜHRUNG IN DAS QUALITÄTSMANAGEMENT Prozesse und zu erreichenden Ziele werden beschrieben, wie genau der Prozess eingeführt und umgesetzt wird, ist in den Modellen nicht enthalten. Oft bieten die Modelle mehrere Reifegrade ( Maturity Models ). Somit kann das Unternehmen selbst festlegen, bis zu welcher Stufe dem Modell gefolgt werden soll. Zu den meisten Referenzmodellen gibt es Zertifizierungsmöglichkeiten, um seinen Prozessstandard auch zu Marketingzwecken einzusetzen. [vgl. Hof08 S514ff] Kontinuierliche und modellbasierte Vorgehen müssen sich nicht ausschließen. Ab einem gewissen Grad verlangen modellbasierte Vorgehen die Einführung kontinuierlicher Methoden zur weiteren Optimierung der eingeführten Prozesse. Kontinuierliche Vorgehen können darüber hinaus gut zur Problemidentifikation eingesetzt werden, um mit standardisierten Prozessen und Best Practices aus einem Referenzmodell schneller zu Ergebnissen zu kommen. [vgl. Lig09, S. 13] Qualitätsmanagement wird in der Softwareentwicklung meist zusammen mit konventionellen Vorgehensmodellen benutzt. Die dokumentengetriebene Entwicklung mit ihren klaren Prozessen unterstützt die Vorgaben des Qualitätsmanagement gut und integriert sich problemlos in ein Qualitätsmanagementsystem. Der agilen Softwareentwicklung hingegen fehlen diese Eigenschaften. Sie verzichtet bewusst auf fest definierte Prozesse und reichhaltige Dokumentation. Dies führt zu Konflikten mit den Vorgaben der Qualitätsmanagementmodelle. Agile Softwareentwicklung lässt sich jedoch in den Organisationsrahmen einbetten und bringt eigene Praktiken zur Umsetzung von Qualitätsanforderungen mit. Das Qualitätsmanagement beschreibt nicht nur die organisationsweiten Abläufe, sondern definiert zusätzlich die Anforderungen zur Umsetzung eines Projekts. So beschreibt der zweite Reifegrad des CMMI-Modells als ersten Schritt zur Einführung eines unternehmensweiten Qualitätsmanagementsystems die Sicherstellung der Projektprozesse und ihrer Ergebnisse, sowie das Überwachen, Überdenken und Verbessern der Vorgehensweisen. [CMMI] Ziel ist die Definition eines standardisierten Projektablaufs um alle Projekte erfolgreich auf gleiche Art und Weise durchzuführen. Erst in den darauf folgenden Reifegraden werden organisationsweite Verbesserungsprozesse implementiert. Es lässt sich eine Sicht des Projektverantwortlichen und eine organisationsweite Sicht im Qualitätsmanagement feststellen. 31

36 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN Die organisationsweite Sicht beschäftigt sich mit dem Aufbau einer Qualitätsmanagementorganisation, einer Supportorganisation für Prozesse und Qualität. Das projektbezogene Qualitätsmanagement beschäftigt sich mit der Qualität der Projektprozesse, der End- und Zwischenprodukte sowie der eingesetzten Ressourcen. Des weiteren werden vor- und nachgelagerte, sowie Übergangsprozesse betrachtet. [vgl. Wal11, S. 151f] Durch diese Unterscheidung ist es möglich, dass Qualitätsmanagement des Projekts unabhängig von der Organisation zu betrachten, in der es umgesetzt wird. Da das organisationsweite Qualitätsmanagement in jedem Unternehmen auf eine andere Weise umgesetzt wird, lässt sich keine allgemeine Aussage über die Einbindung von agilem Projektmanagement in dieses System geben. Die Projektprozesse sind im organisatorischen Qualitätsmanagement definiert, liegen jedoch in der Verantwortung des Projektmanagements. Ebenso wird durch die meisten Referenzmodelle vorgegeben, welche Prozesse im Projekt vorhanden und welche Tätigkeiten durchgeführt werden müssen, jedoch nicht auf welche Weise sie im Projekt umzusetzen sind. Statt durch streng reglementierte Prozesse können die Anforderungen des Qualitätsmanagements an das Projekt auch durch agile Praktiken und Herangehensweisen erbracht werden. Dadurch wird die Vorgehensweise des agilen Teams reifer und lässt sich besser auf größere Teams skalieren, da die explizite Nutzung bestimmter Praktiken und die Ausführung spezifischer Tätigkeiten gefordert wird. Auf der anderen Seite profitiert CMMI von einem Konzept mit sinnvollen Techniken, die bisher noch keinen Eingang in das Modell gefunden haben. Auf diese Weise ist es möglich, Qualitätsmanagementsysteme auch in der agilen Entwicklung umzusetzen. [CMMI_Agile] Im Bezug auf die Einführung externer Qualitätssicherung kann durch projektbezogenes Qualitätsmanagement die Zusammenarbeit der beiden Unternehmen verbessert und dadurch die Softwarequalität erhöht werden. Hierfür ist es erforderlich, die Möglichkeiten von agiler Softwareentwicklung, inklusive Scrum, für die Erweiterung mit Qualitätsmanagementmethoden auszuloten. Die Software-Qualitätssicherung ist eine projektspezifische Aufgabe. Die organisationsweite Sicht ist für diese Aufgabe nicht von Relevanz, sie orientiert sich an den Anforderungen der Unternehmen bezüglich Qualität und benötigt die Kennzahlen des Projekts. Daher wird das unternehmensweite Qualitätsmanagement nicht betrachtet, sondern Schnittstellen zu diesem definiert. Die Qualitätsplanung ist stark von den Anforderungen abhängig. In der agilen Softwareentwicklung werden diese nicht vorher definiert. Die benötigte Qualität des 32

37 3.1 EINFÜHRUNG IN DAS QUALITÄTSMANAGEMENT Produktes kristallisiert sich während der Entwicklung heraus. Die Qualitätszielbestimmung ist daher dem agilen Prozess inhärent, jedoch nicht als eigenständige Funktion. Es ist dennoch erforderlich, die eingesetzten Ressourcen zu planen. Zusätzlich entsteht durch den Einsatz einer externen Qualitätssicherung ein Prozess außerhalb von Scrum. Dieser ist in der Qualitätsplanung zu berücksichtigen und zu definieren. Die Verwendung der Begriffe Qualitätslenkung und Qualitätssicherung sind in der Softwareentwicklung nicht eindeutig zu trennen. Obwohl laut allgemeiner Definition die Qualitätslenkung die prüfende und weisende und die Qualitätssicherung eine nachweisende Funktion innehat, werden in der Literatur zur Software-Qualitätssicherung die produktorientierten Tests der Qualitätssicherung als Funktionen zugeschrieben. [vgl. Hof08/Lig09 u. Wal11, S. 44f] Im Gegensatz zum produzierenden Gewerbe, ist in der Softwareentwicklung eine ständige Produktprüfung notwendig. Es wird nur ein komplexes Produkt entwickelt, nicht eine hohe Anzahl gleicher Produkte. Somit ist die Lenkung der Qualität sowie die Sicherstellung derselben ein kontinuierlicher, entwicklungsbegleitender Prozess auf dem selben Werkstück, um dessen Qualität zu erhöhen, während er in der Industrie stichpunktartiger Natur ist, um unter anderem Ausschuss auszusortieren. Da in dieser Arbeit die Einführung einer externen Software-Qualitätssicherung behandelt wird, sind in diesem Kontext die prüfenden Maßnahmen gegenüber dem Produkt zu verstehen. Diese darf nicht mit der Qualitätssicherung und Qualitätslenkung verwechselt werden, welche im Folgenden für die Qualität des übergeordneten Testprozesses verantwortlich sein wird. Die Produktqualität wird allein durch die Software-Qualitätssicherung sichergestellt. Qualitätsverbesserung stützt sich auf das Prozessmanagement. Das kontinuierliche Verbessern der Prozesse führt zu einer Kostenreduktion und Steigerung der Zuverlässigkeit. [vgl. FB08, S. 20] Da die Entwicklung in einem sich selbst regulierenden Prozess stattfindet, ist es nicht möglich, eine Verbesserung von außen herbeizuführen. Es können jedoch die vor-, sowie nachgelagerten Prozesse, die Kommunikationsprozesse nach außen sowie zur externen Qualitätssicherung definiert und einer kontinuierlichen Verbesserung unterworfen werden. 33

38 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN 3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICK- LUNG Grundsätzlich ist es möglich, in Unternehmen aus dem IT-Sektor sowohl kontinuierliche als auch modellbasierte Qualitätsmanagementansätze umzusetzen. Für die Prozessqualität in der agilen Softwareentwicklung, insbesondere für den Zweck der Einführung einer externen Qualitätssicherung, ist der geeignete Ansatz zu identifizieren. Referenzmodelle sind in der Softwarebranche weit verbreitet. Zum einen werden die kontinuierlichen Maßnahmen im Rahmen des Referenzmodells mit eingeführt, zum anderen bieten sie eine gute Vergleichbarkeit zu Wettbewerbern. Große Auftraggeber setzen oft eine bestimmte Prozessreife bei Auftragnehmern voraus. Sie ist eine Bedingung für die Auftragsvergabe. In der Literatur wird deutlich, dass Qualitätsmanagement im Softwareengineering noch nicht den Stellenwert wie in der konventionellen Industrie erreicht hat. Der Schwerpunkt liegt hier auf der Qualitätssicherung, der Rahmen des Qualitätsmanagements spielt eine untergeordnete Rolle. Deutlich wird jedoch, dass weder Qualitätsmanagement, Software-Qualitätssicherung oder Vorgehensmodelle allein zum erfolgreichen Abschluss von IT-Projekten führen. Alle drei sind erforderlich, um Projekte im größeren Umfang abzuwickeln. Es darf jedoch zu Recht angezweifelt werden, ob ein umfassendes Qualitätsmanagement immer angebracht ist. Ziel beim Aufbau eines Qualitätsmanagementsystems sollte nicht die unbedingte Einführung einer Methodik mit allen ihren Konsequenzen sein, sondern die Prozess- und Produktqualität nachhaltig und kontinuierlich zu erhöhen. [vgl. Pet01, S. 203] Die Rolle der Prozessqualität ist nicht zu vernachlässigen, da das Vermeiden von Fehlern und eine Beschleunigung der Zusammenarbeit die Wertschöpfung erhöhen. Es ist zu beachten, dass die Prozesse vor allem für die wichtigsten Aufgaben vorhanden sind und reibungslos ablaufen. Auf Projektebene sind verschiedene Aufgaben im Rahmen des Qualitätsmanagements zu erfüllen, um den Erfolg des Projekts sicherzustellen. [vgl. Wal11, S. 152ff] Dazu zählen das Managen kritischer Entscheidungen, Beschaffungs- und Lieferantenmanagement, Architekturmanagement, Risikomanagement sowie Projekt-, Programm- und Portfoliomanagement. 34

39 3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICKLUNG Die verschiedenen Aufgaben verfolgen das Ziel, das Projekt und die darin erfolgende Entwicklung in ihrer Komplexität zu erfassen und durch verschiedene Maßnahmen zu vereinfachen. Sie sind umfassend in verschiedenen Standards und Reifegradmodellen beschrieben. Wie und in welcher Form diese Aufgaben im Projekt umgesetzt werden, ist projektspezifisch und hängt vor allem von der Größe und Komplexität der entwickelten Software ab. Den klaren Vorgaben an Aufgaben, sowie der damit einhergehenden Dokumentation stehen die agilen Methoden diametral gegenüber. Die Aufgaben mögen durch verschiedene Praktiken, aber auch vollständig gemäß der Beschreibung, in der Entwicklung umgesetzt werden. Die Entscheidung, ob sie umgesetzt werden, obliegt jedoch der Verantwortung des Teams und nicht des Managements. Anderenfalls wäre die Selbstverwaltung des agilen Teams nicht mehr gegeben. Kontinuierliche Qualitätsmanagementansätze hingegen besitzen mehrere Gemeinsamkeiten mit der agilen Softwareentwicklung. So zeigt Poppendieck [Pop01] die Anwendung von Lean Manufacturing und TQM auf die Softwareentwicklung. Lean Manufacturing zielt darauf ab, Verschwendung in den Prozessen zu reduzieren und durch kontinuierliche Verbesserung Potentiale zu nutzen. Ein Konzept, das in das agile Umfeld mit seiner iterativen Vorgehensweise und dem Fokus auf lauffähige Software passt. Während TPS, TQM, Six Sigma und weitere kontinuierliche Qualitätsmanagementmodelle viele verschiedene Methoden zur Verbesserung heranziehen, haben sie die kontinuierliche Prozessverbesserung gemeinsam. [vgl. BW08, S. 259ff] Es soll sich zur Betrachtung des übergeordneten Testprozesses auf eine kontinuierliche Prozessverbesserung bezogen werden. Praktiken wie Do it Right the First Time, Empower Workers und weitere TQM- und Lean- spezifische Methoden sind schon in Scrum umgesetzt. Es fehlt jedoch eine Messung der Wertsteigerung und Performanz, um das Management mit objektiven Daten über das Projekt zu versorgen. [vgl. And04, S. 257] Diese werden benötigt, um den Erfolg des Projekts zu messen und Verbesserungsmaßnahmen zu steuern. Kontinuierliche Prozessverbesserung kann auf zwei Wegen erreicht werden, Bottom Up und Top Down. Zum einen können Verbesserungsideen von den Mitarbeitern ausgehen. Dies ist in Scrum der Fall, am Ende von jedem Sprint setzt sich das ScrumTeam zusammen und beschließt Verbesserungen für die nächste Iteration. Zum anderen kann das Management anhand zuvor definierter Prozesskennzahlen die Leistung der Prozesse beurteilen und Änderungen anstoßen. Bei aktuellen Qualitätsmanagementmodellen werden beide Methoden angewandt. 35

40 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN [vgl. Koc11, S. 42f] Es ist erforderlich das agile Modell, in diesem Falle Scrum, um die Erhebung von Prozesskennzahlen zu erweitern. Scrum verfügt über kein Planungsinstrument, um vorab den Mehrwert zu bestimmen, der während eines Sprints geschaffen wird. Im Sprint Backlog sind User Stories nicht vollständig vorhanden. Stattdessen werden große Stories in Tasks aufgeteilt. Somit steht die Erledigung eines Backlog Items nicht im direkten Verhältnis zum Kundennutzen. Erst wenn alle Tasks einer Story umgesetzt wurden, kann eine Anforderung als erfüllt angesehen werden. Die Schätzung des Aufwandes einer Story und die Aufteilung in Tasks dienen dazu, das Sprint Backlog zu füllen. Es werden jedoch nicht alle Stories im Backlog während einer Iteration umgesetzt. Somit ist es nicht möglich, eine Kosten-Nutzen-Schätzung vor dem Projekt durchzuführen, sondern erst nach Abschluss einer Iteration. Außerdem werden keine Metriken festgehalten. Befindet sich die User Story in der Entwicklung, werden lediglich Mann-Stunden aufgenommen. Diese sind jedoch nicht aussagekräftig für den Prozess, da dadurch Behinderungen des Prozessablaufs nicht aufgedeckt werden. Der genaue Weg der User Story durch das Team wird nicht erfasst. Eine Methode zur Optimierung des Durchsatzes ist die Theory of Constraints. Sie besagt, dass es zu einer Zeit immer nur einen Engpass im Prozess geben kann. Zur Auflösung des Engpasses müssen entweder alle Aktivitäten auf das Niveau des Engpasses herabgesenkt oder der Engpass erweitert werden. Nach Auflösen eines Engpasses, entsteht an anderer Stelle ein neuer. Dadurch entsteht ein Kreislauf, in dem jedes Mal der Engpass gefunden und aufgehoben werden muss. Dies lässt sich auch in der Softwareentwicklung anwenden. [vgl. And04, S. 35] Laufen die User Stories an einer Stelle auf, zum Beispiel vor der Integration, handelt es sich hier um einen Flaschenhals. Es sollten nun Maßnahmen ergriffen werden, um besagte Aufgabe zu beschleunigen. Zur Kontrolle des Prozesses werden im industriellen Prozessmanagement verschiedene Kennzahlen herangezogen. [vgl. FB08, S. 46f] Dies können unter anderem die Anzahl der Prozessinstanzen, die Durchlaufzeit, Pünktlichkeit oder Zuverlässigkeit sein. Für jede Kennzahl sind die Kriterien nachvollziehbar zu definieren, Messpunkte zu etablieren und die Daten zu erheben. Die agile Softwareentwicklung sieht keine Messpunkte zur Datenerhebung vor. 36

41 3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICKLUNG David Anderson [And04] hat verschiedene Punkte aufgezeigt, an denen es möglich ist, Messungen vorzunehmen. Hierfür bezieht er sich auf Feature Driven Development. Die einzelnen Feature dienen als Bezugspunkt. Zu Beginn der Entwicklung werden die einzelnen Features geschätzt. Während die Features die Entwicklung durchlaufen, wird ihr Status regelmäßig aktualisiert. So kann ständig abgelesen werden, welche Aktivität wie viel Zeit in Anspruch genommen hat und wo sich die einzelnen Features im Entwicklungsprozess befinden. Die Entwicklung wird dadurch transparent, Engpässe sind frühzeitig erkennbar. Die Zeiten lassen sich aufschlüsseln und können direkt mit der Schätzung verglichen werden. Es ist ersichtlich, welche Tätigkeit schlecht geschätzt wurde. So liegen Daten vor, auf die zukünftige Schätzungen aufbauen können. In Scrum ließe sich dies ebenso umsetzen. Die Tasks dienen als Referenz, mehrere Tasks zusammen gehören zu einer User Story, also einem Feature. Hierbei ist zu beachten, dass nur Tasks mit Kundennutzen positive Kennzahlen liefern können. Tasks für Bugfixes würden zwar als abgeschlossene Aufgaben gelten und die Organisation effizient aussehen lassen, jedoch keinen zusätzlichen Kundenutzen generieren, da die Fehler nach Möglichkeit gar nicht erst entstehen sollten. Nur Kennzahlen mit einem Fokus auf Wiederholbarkeit und Zuverlässigkeit der Prozesse sollten erfasst werden. Kennzahlen, die der Performanzmessung einzelner Teammitglieder dienen, sind der selbstständigen Arbeit des Teams nicht zuträglich. Vergleichswerte sind hierfür in der Softwareentwicklung kaum zu setzen. Eine traditionelle Metrik ist die Messung von geschriebenen Zeilen Quellcode. Hier steht Quantität Qualität gegenüber, es lässt sich keine Aussage über die Brauchbarkeit des geschriebenen Codes treffen. So lassen sich auch Metriken über Fehler in der agilen Entwicklung schwer erstellen, da viele Fehler nach direktem Feedback sofort behoben werden. Die Dauer zwischen Fertigstellen der Funktion und Test, sowie Auftreten von Fehlern und deren Bugfix, sollte dieser nicht direkt geschehen, lässt sich jedoch bestimmen und gibt Aufschluss über die Integration des Testprozesses. [vgl. CG09, S. 74f] Durch die Aufnahme von Kennzahlen und die kurzen Iterationen ist es möglich, den Entwicklungsprozess ständig zu verbessern. Es ist zu vermeiden, ein Gefühl der Überwachung bei den Teammitgliedern hervorzurufen. Wie bei jeder organisatorischen Veränderung ist Akzeptanz ein wichtiger Faktor. [vgl. FB08, S. 180f] Aus diesem Grund sollte das Team in alle Entscheidungsprozesse eingebunden werden und eigene Ideen einbringen können. Eingriffe in 37

42 KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN die einzelnen Arbeitsabläufe während des Sprints und in die einzelnen Arbeitsweisen der Teammitglieder sind grundsätzlich zu unterlassen. Das Management kann mit den aufgenommenen Informationen grundsätzliche Entscheidungen fällen. Ein Vergleich zwischen der angewandten Methodik und anderen Projekten wird möglich. Zusätzlich kann bestimmt werden, ob die Einbeziehung der externen Qualitätssicherung einen Nutzen erbringt, oder die Entwicklung zu sehr behindert. Eine Kosten-Nutzen- Beurteilung zum Weiterführen oder Stoppen des Projektes muss auf dieser Ebene durchführbar sein. Entscheidungen über den konkreten Projektablauf obliegen jedoch in der Regel nicht dem Management, sondern dem Projektleiter. Diese Rolle ist in Scrum jedoch nicht vorgesehen. Alternativ ist es möglich, ein Gremium aus allen Projektbeteiligten zu gründen, dessen Aufgabe es ist, die Zahlen vom letzten Sprint zu analysieren und Verbesserungen für den Prozess abzuleiten. Eine Erweiterung der Sprint Retrospective bietet sich dafür an. Auf diese Weise ist das Team mit eingebunden und Kunde, Project Owner sowie Scrum Master können ihr Wissen einbringen. Zusätzlich können Spezialisten zu dem Gremium hinzu gezogen werden. Die Verbesserung des Prozesses wird dadurch effektiv gestaltet und eine hohe Akzeptanz beibehalten. Um Qualitätsmanagement in einen agilen Entwicklungsprozess einzuführen ist ein kontinuierlicher Ansatz einem modellbasierten Ansatz vorzuziehen. Um Daten als Grundlage für die Optimierung zu sammeln sind die User Stories ein guter Ansatzpunkt. An ihrem Durchfluss kann die Dauer sowie die Auslastung der einzelnen Arbeitsschritte abgelesen werden. In der Sprint Retrospective können die Verbesserungen von allen Projektbeteiligten für den nächsten Sprint festgelegt werden. 3.3 ZUSAMMENFASSUNG Um eine langfristige Optimierung der Entwicklung zu ermöglichen, wurde die Verwendung von Qualitätsmanagement in agilen Vorgehensmodellen betrachtet. Zunächst ist Qualität als Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt [ISO 9001: ] definiert worden. Die Qualität eines Softwareprodukts erschließt sich folglich aus dem Ausmaß, in dem eine bestimmte Anzahl an Anforderungen umgesetzt wird. Das Qualitätsmanagement beschäftigt sich damit, alle Maßnahmen zum Erreichen der Anforderungen zu planen, zu leiten und zu steuern. Es setzt sich aus den Teilbereichen Qualitätspolitik, Qualitätsplanung, Qualitätssicherung, Qualitätslenkung und Qualitätsverbesserung zusammen. Für die 38

43 3.3 ZUSAMMENFASSUNG Umsetzung von Qualitätsmanagement im Unternehmen gibt es kontinuierliche und modellbasierte Ansätze. Modellbasierte Ansätze basieren auf Referenzmodellen, die vorgeben, durch welche Praktiken die Qualität im Unternehmen sichergestellt werden kann. Kontinuierliche Ansätze setzen hingegen auf einen stetigen Verbesserungsprozess. Eine ständige Optimierung der innerbetrieblichen Abläufe führt das Unternehmen langsam zur gewünschten Reife. Die Betrachtung der beiden Ansätze bezüglich ihrer Eignung zum Einsatz in einem agilen Entwicklungsprojekt ergab ein höheres Potential für kontinuierliche Methoden. Während modellbasierte Ansätze die Selbstverwaltung des Teams einschränken, ist für kontinuierliche Ansätze durch die kurzen Iterationen und die Sprint Retrospective bereits der Grundstein gelegt. Um eine Messbarkeit des Prozesses zu gewährleisten, bietet sich die Betrachtung der User Stories an. Unter anderem geben ihre Bearbeitungs-, Liege- und Durchlaufzeit einen interessanten Einblick in die Auslastung der einzelnen Aktivitäten und Rollen. Es wurde gezeigt, dass sich agile Methoden mit einer abgeschwächten Form des Qualitätsmanagements vereinen lassen. Der Entwicklungsprozess sollte folglich um entsprechende Mechanismen erweitert werden, damit eine hohe Produktqualität ermöglicht wird. 39

44

45 4 SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Herkömmliches Qualitätsmanagement bezieht sich überwiegend auf die Prozessqualität und steuert darüber die Produktqualität. In der Softwareentwicklung nimmt die Produktqualität jedoch eine Sonderrolle ein. Daher muss zusätzlich die Software-Qualitätssicherung im Einzelnen betrachtet werden. Die gängigen Modelle kommen aus der konventionellen Softwareentwicklung, während sich in der agilen Softwareentwicklung eigene Regeln etabliert haben. Die agile und die konventionelle Softwareentwicklung müssen voneinander abgegrenzt werden. Es sind geeignete Software-Qualitätssicherungsmaßnahmen zu identifizieren, die hohe Qualität in agilen Modellen ermöglichen. 4.1 RELEVANZ UND EINORDNUNG In der Softwareentwicklung muss die Qualität des Produktes auf zwei verschiedenen Wegen sichergestellt werden. Sowohl die Gestaltung eines reibungslosen Prozesses, als auch die Prüfung des Produktes sind notwendig. Während der Softwareentwicklung entsteht ein komplexes, einzigartiges Produkt. Im Gegensatz zur Massenproduktion muss hier jedes Ergebnis der Entwicklung eingehend geprüft werden. Somit kann die Sicherstellung eines reibungslosen Prozessablaufs keine eingehende Produktprüfung ersetzen. Die Qualitätssicherung ist ein Teilgebiet des Qualitätsmanagements. Im Qualitätsmanagement liegt der Schwerpunkt klar auf der Prozessoptimierung. Daher beschäftigt sich die Qualitätssicherung hauptsächlich mit der Sicherstellung der Prozessqualität durch die Prüfung der Wirksamkeit des Qualitätsmanagements, Dokumentation, Zertifizierung und dem Einsatz von Verbesserungsprogrammen. [vgl. Wall11, S. 45f] Die Software-Qualitätssicherung nimmt jedoch eine Sonderrolle ein. Durch den stark produktbezogenen Ansatz der Softwareentwicklung ist die Software-Qualitätssicherung nicht schwerpunktmäßig auf die Prozessqualität, sondern zusätzlich auf die Sicherstellung der Produktqualität ausgelegt. Die prozessbezogenen Maßnahmen wurden bereits in Kapitel 3 dargelegt. 41

46 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Die produktbezogenen Maßnahmen der Qualitätssicherung lassen sich in zwei Bereiche aufteilen, die konstruktive und die analytische Qualitätssicherung. Ersteres dient zur Verhinderung von Fehlern während der Entwicklung, Letzteres zum Aufdecken möglicher Fehler in den verschiedenen Artefakten. [vgl. Pet01, S. 42] Als Artefakte werden Dokumente, Quellcode und Programme bezeichnet, die während der Entwicklung entstehen, wobei auch Zwischenergebnisse unter den Begriff fallen. Konstruktive QS Die konstruktive Qualitätssicherung ist darauf ausgerichtet, die Qualitätsanforderungen gleich in das Softwareprodukt hinein zu entwickeln. Petrasch [vgl. Pet01, S.43ff] unterscheidet drei verschiedene konstruktive Qualitätssicherungsmaßnahmen. Er nennt organisatorische Maßnahmen, technische Maßnahmen und personelle Maßnahmen. Unter organisatorischen Maßnahmen wird nicht die Aufbauorganisation des Unternehmens, sondern die Organisation der Softwareentwicklung mit Hilfe von Vorgehensmodellen und Methoden betrachtet. Technische Maßnahmen betreffen vor allem die Unterstützung der Entwicklung durch Werkzeuge. Dies könnten zum einen Computer Aided Software Engineering (CASE) Werkzeuge sein, aber auch Werkzeuge zur Unterstützung des Projektmanagements, der Planung, Dokumentation und Automatisierung. Unter personelle Maßnahmen fällt die Besetzung der im Qualitätsmanagement festgelegten Rollen. Hoffmann [vgl. Hof08, S. 65ff] hingegen sieht in der konstruktiven Qualitätssicherung vor allem Richtlinien und Standards für den Aufbau des Quellcodes sowie der Dokumentation. Der Begriff der konstruktiven Qualitätssicherung ist demnach nicht klar abgegrenzt und wird in der Literatur verschieden weit gefasst. Der Begriff der konstruktiven Qualitätssicherung lässt sich nicht so einfach auf verschiedene Teilbereiche einschränken. Im Folgenden werden alle Maßnahmen die a priori für eine hohe Qualität im Softwareprodukt sorgen als konstruktive Qualitätssicherung verstanden. Dies gilt sowohl für die organisatorischen, technischen und personellen Maßnahmen als auch für Richtlinien und Standards. 42

47 4.1 RELEVANZ UND EINORDNUNG Analytische QS Die analytische Qualitätssicherung beschäftigt sich mit dem Aufdecken von Fehlern innerhalb der einzelnen Artefakte des Softwareentwicklungsprozesses. Als Artefakte werden Dokumente, Quellcode und Programme bezeichnet, die während der Entwicklung entstehen, wobei auch Zwischenergebnisse unter den Begriff fallen. Bei einer vollständigen Qualitätssicherung würde jedes Ergebnis und Zwischenergebnis geprüft werden, welches während des Entwicklungsprozesses entsteht. Dies ist jedoch mit einem sehr hohen Aufwand verbunden. Vor Entwicklungsbeginn werden deshalb bestimmte Artefakte ausgewählt und die Prüfmethoden festgelegt. Für Softwaretests hat sich ein stufenartiges Vorgehen etabliert, jede Testphase wird als Teststufe bezeichnet. Die Teststufen wurden aus dem V-Modell abgeleitet und sind gleichwertig zur Entwicklung. Sie lassen sich auch auf andere Vorgehensmodelle übertragen. [vgl. SL10, S. 41 ff] Es gibt vier Teststufen, der Unittest, der Integrationstest, der Systemtest und der Abnahmetest. Sie folgen in genannter Reihenfolge aufeinander. Jede Teststufe ist eng mit einer Konstruktionsphase verbunden. Die Spezifikation der jeweiligen Phase wird zur Erstellung der Testfälle herangezogen. So werden für jede Konstruktionsphase passende Testfälle geschrieben. Die Erstellung der Tests beginnt so früh wie möglich. Die vier Teststufen unterscheiden sich stark. Für jede Teststufe gibt es unterschiedliche Methoden, Tester und Artefakte. Die Teststufen werden in Kapitel 4.2 näher erläutert. Die Qualitätssicherungsmaßnahmen können im Unternehmen selbst oder über externe Dienstleister erbracht werden. Unter externer Qualitätssicherung wird im Rahmen dieser Arbeit ein unabhängiger Dienstleister verstanden, der Aufgaben zur Qualitätsprüfung wahrnimmt. Aufgrund seiner Position ist es für ein externes Unternehmen nur schwer möglich die Sicherstellung des Prozessablaufs zu gewährleisten oder die Definition konstruktiver Maßnahmen vorzunehmen. Dies ist über punktuelle Beratungsleistungen möglich, sollte auf lange Sicht jedoch im Unternehmen selbst gehandhabt werden. Bei analytischen Maßnahmen ist es möglich, diese dauerhaft an Dritte zu übergeben. Das externe Testteam wird mit den fertiggestellten Artefakten beliefert und führt zuvor festgelegte 43

48 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Tests durch. Die Ergebnisse werden an den Auftraggeber zurück geliefert. Im Fehlerfall werden dort Maßnahmen zur Produktverbesserung eingeleitet. Durch eine unabhängige analytische Qualitätssicherung lassen sich verschiedene Vorteile nutzen. Die Unabhängigkeit der Tester verhindert eine Einflussnahme der Entwicklungsabteilung. Ungeschönte Ergebnisse sind gewährleistet. Fehler am eigenen Produkt zu finden widerstrebt Entwicklern, daher sind unabhängige Tester objektiver. Durch die Trennung von Test und Entwicklung ist es möglich, Interpretationen und Annahmen der Entwickler kritisch zu hinterfragen. Die Einbindung einer unabhängigen Institution zwingt dazu, das Testen schon früh zu planen. Auf Testen spezialisierte Dienstleister verfügen über ein hohes Spezialwissen und die nötigen Werkzeuge. Es können jedoch auch Nachteile entstehen, deren Vermeidung eine gute Organisation erfordert. Bei einem eigenständigen Testteam kann es zu starker Isolation kommen, so dass die Kommunikation zwischen Testern und Entwicklern behindert wird. Durch Fehlplanung kann der unabhängige Test die Entwicklung behindern, da auf Ergebnisse gewartet werden muss. Die Entwickler übernehmen weniger Verantwortung für die Qualität, sondern übertragen diese auf das Testteam [vgl. SL 10, S. 173] Bei einer nach außen vergebenen Entwicklung entsteht ein weiterer Vorteil, da die externe Qualitätssicherung zusätzlich an den Auftraggeber berichten kann. Dadurch ist dieser durch eine unabhängige Stelle über den Stand der Entwicklung informiert und kann bei Problemen dementsprechend steuernd eingreifen. Zu beachten ist, dass die externe Qualitätssicherung von dem Auftragnehmer für die Entwicklung nicht als feindlich gesinnt erachtet werden darf. Dies kann zu einer Erschwerung der Zusammenarbeit bis zu einer vollständigen Verweigerung führen. Eine transparente Gestaltung von Aufgaben und Prozessen ist nötig, eine enge Integration der externen Institution in 44

49 4.2 KONVENTIONELLES TESTEN den Entwicklungsprozess notwendig. Das Schaffen von Akzeptanz sollte gerade zu Beginn der Entwicklung eine hohe Priorität erhalten. Die Einbindung externer Qualitätssicherung in einen Entwicklungsprozess erfordert ein hohes Maß an Planung und sollte beim Aufbau des Qualitätsmanagementsystems mit beachtet werden. In der Regel wird nicht die gesamte Qualitätssicherung ausgelagert. Es werden sogenannte Blended Service Delivery Modelle genutzt, bei denen die Leistungen zum Teil lokal und zum Teil extern erbracht werden. Nur 14 Prozent der in einer Studie von Pierre Auodin Consultants Befragten konnten sich vorstellen mehr als 50 % der Testaktivitäten auszulagern. Es war kein Trend über Anzahl und Art der auszulagernden Testaktivitäten abzulesen, da die getroffenen Maßnahmen sich an den individuellen Gegebenheiten einzelner Unternehmen orientierten. [SQS Market Research 2011] Interne und externe Qualitätssicherungsmaßnahmen sind daher aufeinander abzustimmen. 4.2 KONVENTIONELLES TESTEN Es gibt drei unterschiedliche Prüftechniken, White-Box-Tests, Black-Box-Tests und Grey- Box-Tests. [vgl. Hof08, S. 174ff] Die Software wird im Falle dieser Techniken jeweils als Box betrachtet. Bei einem White-Box-Test ist das Innere der Box sichtbar, zur Erstellung der Tests wird der interne Aufbau des Produkts herangezogen. Daher sind sie auch unter dem Namen strukturorientierte Tests bekannt. Bei Black-Box-Tests ist der Inhalt der Box nicht erkennbar, die Tests werden aus funktionalen Beschreibungen abgeleitet. Diese Art von Tests werden auch funktionale Tests genannt. Der Grey-Box-Test ist ein Hybrid zwischen White- Box- und Black-Box-Test. Er wird häufig in der agilen Softwareentwicklung beim Test-First- Ansatz verwendet. Die Tests werden aus der funktionalen Beschreibung abgeleitet und vor der Unit geschrieben, die Ausführung findet jedoch auf Codeebene statt. [vgl. Wall11, S. 299] Bei den oben aufgeführten Testtechniken handelt es sich um so genannte dynamische Tests, da der Quellcode ausgeführt wird. Eine weitere Prüfmethode sind sogenannte statische Tests. Das Testobjekt wird nicht zur Ausführung gebracht, sondern einer Analyse unterzogen. Die Methode kann auf jedes Dokument angewandt werden, das relevant für die Softwareerstellung ist. Zusätzlich lassen sich Werkzeuge auf Dokumente mit formaler Struktur anwenden. 45

50 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Auf diese Weise lassen sich Metriken aus dem Quelltext gewinnen, um unter anderem die Einhaltung von Programmierkonventionen zu prüfen. [vgl. SL10, S. 81ff] Das konventionelle Testen in einem linearen Vorgehensmodell baut auf die vier Teststufen auf. Jede Teststufe testet andere Merkmale des Produkts und zieht dazu unterschiedliche Spezifikationen heran. Die erste Teststufe ist der Unittest. Als Unit wird die kleinste sinnvolle testbare Einheit der Software bezeichnet. Dies sind in der Regel Prozeduren, Klassen oder Objekte. Die Unit wird aus dem Kontext des Programms heraus gelöst und unabhängig vom Gesamtsystem getestet. Dadurch werden externe Einflüsse ausgeschlossen und die Ursachen sind leichter zu identifizieren. Unittests werden von den Entwicklern durchgeführt. Die Tests werden anhand des Quellcodes erstellt und automatisiert. Folglich handelt es sich um White-Box-Tests. Die Ausführung der Module findet in einem Testrahmen statt. Die aufrufenden und aufgerufenen Komponenten werden durch Treiber und Dummies ersetzt, solange die Originale nicht fertig sind. Durch die Automatisierung ist es möglich, Unittests schnell und oft auszuführen. [vgl. Lig09, S. 371] Ein neuerer Ansatz ist das sogenannte Test-Driven-Development, durch den der Test-First- Ansatz umgesetzt wird. Der Test wird vor Implementierung der Unit geschrieben. Die Unit wird vom Entwickler später erstellt und so lange verfeinert, bis sie alle Tests besteht. Durch Unittests soll zum einen die richtige und fehlerfreie Implementierung der Unit sichergestellt werden, zum anderen wird durch das Ausführen aller Unittests auf ungewollte Seiteneffekte in den restlichen Units geprüft. [vgl. SL10, S. 51] Die zweite Teststufe ist der Integrationstest. Er erfolgt nach dem Unittest während der Integration der einzelnen Module zu einem Gesamtsystem. Die einzelnen Units werden schrittweise zusammengeschlossen und gemeinsam getestet. Es wird sichergestellt, dass die Komponenten auch zusammengeschlossen ein funktionsfähiges System ergeben. [vgl. Hof08, S. 163] Die Tests basieren auf dem Software- und Systemdesign, sie sind somit White-Box-Tests. Die Ausführung der Tests erfolgt nach wie vor automatisch, der Testrahmen wird nach Möglichkeit von den Unittests wieder verwendet. Zum Zusammenfügen der Units können verschiedene Integrationsstrategien verfolgt werden. Die Ansätze reichen von Bottom-Up, dem schrittweise Integrieren von der untersten Schicht 46

51 4.2 KONVENTIONELLES TESTEN an, bis zum gleichzeitigen Aneinanderfügen aller Units, genannt Big-Bang Integration. [vgl. SL10, S. 54ff] Die dritte Teststufe ist der Systemtest. Während die vorherigen Teststufen auf Grundlage der technischen Spezifikation stattfanden, zieht der Systemtest die Anforderungen als Referenz heran. Da nun die Funktionen der Software im Vordergrund stehen, sind Systemtests Black- Box-Tests. Das Testobjekt wird aus Sicht der Anwender betrachtet. Spätestens ab dieser Phase sollten die Tests nicht mehr von Entwicklern durchgeführt werden, sondern von unabhängigen Testern. Bisher wurde die Software nur verifiziert. Dies bedeutet, sie wurde auf Konformität zur Spezifikation geprüft. [vgl. SL10, S. 60f, 173f] Nun wird die Software auch validiert, es erfolgt nicht nur eine Prüfung, ob das System richtig reagiert, sondern auch, ob die Bedürfnisse des Kunden richtig verstanden und umgesetzt wurden. [vgl. Wall11, S. 252] Der Systemtest umfasst mehrere Tätigkeiten, um die verschiedenen Aspekte der Software zu testen. Um sicherzustellen, dass die Funktionalität der Software richtig umgesetzt wurde, werden sogenannte Funktionstests durchgeführt. Das Verhalten des Systems unter Last wird durch Lasttest beurteilt. Für Überlastung über die Leistungsgrenzen hinaus und die Simulation von teilweisen Systemausfällen, sind Stresstests zuständig. Ein weiterer wichtiger Test ist der sogenannte Regressionstest, der besonders bei einer inkrementellen Entwicklung nicht zu vernachlässigen ist. Hierbei handelt es sich um wiederholbare, meist automatisierte Testfälle. Sie werden nach Fertigstellung einer neuen Version ausgeführt, um Seiteneffekte von neuen oder veränderten Funktionen auszuschließen. Um das System unter möglichst produktivnahen Bedingungen zu testen, werden Betatests durchgeführt. Da Betatests häufig zusammen mit dem Kunden durchgeführt werden, gehen diese in die nächste Testphase über. [vgl. Lig09, S. 377] Der Abnahmetest ist die letzte Teststufe und findet kurz vor der Inbetriebnahme der Software statt. Der Test wird selbstständig oder mit Unterstützung durch Tester vom Kunden durchgeführt. Sein Hauptzweck ist die Validierung der Software vor der Abnahme. Der Kunde soll durch den Test feststellen, ob die Software seinen Anforderungen genügt. Hierbei sind drei verschiedene Perspektiven zu beachten. Die zukünftigen Nutzer sind für die Prüfung der Software auf ihre Eignung zur Verrichtung der vorgesehenen Aufgaben im geplanten Einsatzgebiet verantwortlich. Weiter müssen die vertraglichen Aspekte beachtet werden. Es ist festzustellen, ob alle zuvor geforderten Leistungen erbracht wurden. Schlussendlich ist das 47

52 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD neue System in die Systemlandschaft einzufügen, um die Integration in das bestehende Gesamtsystem zu überprüfen. Technische Fehler sollten in dieser Testphase weitestgehend eliminiert worden sein. Eine besondere Aufmerksamkeit sollten die Schnittstellen zu anderen Systemen im Unternehmen bekommen. [vgl. SL10, S. 63ff] ABBILDUNG 4.1: DOKUMENTE NACH STANDARD IEEE 829 [ENTNOMMEN AUS IEEE829] Neben dem Durchführen der Tests kommt der Software-Qualitätssicherung auch die Aufgabe zu, die Planung, die Testfälle sowie die Ergebnisse zu dokumentieren. Die Dokumentation des Testprozesses ist in dem Standard IEEE 829 geregelt. Er fordert insgesamt acht verschiedene Dokumente. In Abbildung 4.1 ist der Zusammenhang der Dokumente zu erkennen. Zwei Kategorien von Dokumenten lassen sich unterscheiden: die für die Planung und die für die Durchführung. In den Planungsdokumenten wird der Test vorbereitet. Es wird ein Plan für den Test erstellt und die Testfälle spezifiziert. Die Reihenfolge zur Abarbeitung der Testfälle wird in einem weiteren Dokument festgelegt. Während der Durchführung steht die Protokollierung und das Erstellen von Berichten im Vordergrund. 48

53 4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENTWICKLUNG 4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENT- WICKLUNG Das Konzept des starren phasenorientierten und dokumentengetriebenen Testens steht den agilen Prinzipien diametral gegenüber. Flexible Prozesse, kurze Entwicklungszyklen und knappe Anforderungsbeschreibungen lassen keinen Platz für einen eigenständigen, umfassenden Testprozess mit Fokus auf den Spezifikationen. Dennoch haben sich die Praktiken bewährt und wurden zu Recht als Standard etabliert. Daher ist das Vorgehen nicht von vornherein abzulehnen. Vielmehr ist es nötig, die konventionelle Qualitätssicherung zu verschlanken und auf die geforderten Eigenschaften agiler Methoden anzupassen. Agile Softwareentwicklung baut stark auf konstruktive Qualitätssicherungsmaßnahmen auf. Dies beginnt schon mit kurzen Releasezyklen und einer engen Zusammenarbeit mit dem Kunden, wodurch die Software regelmäßig validiert wird. Durch die kontinuierliche 40- Stundenwoche wird Überlastung der Mitarbeiter vermieden und damit Flüchtigkeitsfehlern vorgebeugt. Beim Pair Programming existiert ein kontinuierliches Code-Review, weil jedes Stück Quelltext von zwei Entwicklern gleichzeitig betrachtet wird. Aus diesen und ähnlichen Praktiken ist zu erkennen, dass Fehlervermeidung höchste Priorität hat. Als analytische Qualitätssicherungsmaßnahme werden in der Regel nur der Unit- und Integrationstest thematisiert. Hier hat sich der Test-First-Ansatz durchgesetzt, des Weiteren sollte keine Unit ohne zugehörige Tests existieren. Im Idealfall sollte die Software die Entwicklung schon fehlerfrei verlassen. Die Hauptaufgabe der Tester ist somit nicht mehr das Aufdecken von Fehlern, sondern das Validieren der Software. [vgl. Eck04, S. 153f] Hinzu kommen Qualitätsprüfungen, die durch Unittests nicht abgedeckt werden können. Dies wären unter anderem Lasttest, Stresstests oder Tests auf der Oberfläche. Problematisch ist der Wegfall von Dokumentation für die Qualitätsprüfung. Basierten die System- und Akzeptanztests zuvor auf umfangreichen Anforderungsbeschreibungen, ist dieses Vorgehen nun nicht mehr möglich. Als Lösung dieses Problems werden die Tester zum Teil des agilen Teams. Sie werden volle Mitglieder des Teams und an allen Aktivitäten beteiligt. [vgl. CG09, S.59ff] Es gibt keine unabhängige Qualitätssicherung außerhalb der Entwicklung. Die Tester arbeiten eng mit Kunden und Entwicklern zusammen, das Verständnis für die Funktionsweise der Software gewinnen sie aus den User Stories und Meetings mit dem Kunden. Hierzu unterstützen sie den Kunden beim Erstellen der User Stories. Zu jeder User Story werden nach Möglichkeit gleichzeitig Akzeptanzkriterien erstellt. Der Tester kann 49

54 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD daraufhin gegen diese Akzeptanzkriterien prüfen und das Produkt validieren. Zusätzlich gelten die Akzeptanzkriterien den Entwicklern als Orientierungshilfe. Die Tests erfolgen zeitnah. [vgl. CG09, S. 37ff] Eine Einbindung des traditionellen Ablaufes des V-Modells in jedes Inkrement klingt verlockend. Hierbei würden die Tests während des Inkrements erstellt und am Ende ausgeführt. In jedem Inkrement entstünden weitere Tests, die zum Bestand hinzugefügt werden. [vgl. SL10, S. 71] In agiler Softwareentwicklung ist dieses Vorgehen jedoch nicht optimal. Der Test am Ende eines Entwicklungszyklus wird eine unbekannte Anzahl an Fehlern aufdecken. Diese Fehler müssen behoben und erneut getestet werden. Die hierfür benötigte Zeit lässt sich nicht einschätzen. Bei unpassender Zeitplanung verlässt das Produkt die Iterationen mit Fehlern, der Einsatz in der Produktion verschiebt sich nach hinten. Beim sogenannten Pipelining [vgl. Pic08, S. 147f] findet der Test deshalb erst im nächsten Zyklus statt und die Fehler werden während der Entwicklung behoben. Die Software wird erst in sogenannten Releasesprints ausgeliefert, die hauptsächlich aus Test und Fehlerbehebung bestehen. Dieses Vorgehen sollte jedoch nach Möglichkeit vermieden werden, da keine ungetesteten oder fehlerhaften Funktionen den Sprint verlassen sollten und sich die Auslieferung der Software verzögert. Ist dies nicht möglich, sind sehr kurze Zykluszeiten zu wählen, um die Auslieferung der Software nicht zu sehr zu verzögern. Die Software sollte sich nach jeder Iteration in einem Zustand befinden, der eine Auslieferung an den Kunden ermöglicht. Dies kann weder mit einem Mini-Wasserfall bzw. Mini-V-Modell noch mit Pipelining gewährleistet werden. Idealerweise finden die Tests zeitgleich mit der Entwicklung statt, um Fehler frühestmöglich aufzudecken. Aus diesem Grund muss die Abnahme der Tests zur Definition of Done gehören. Eine Funktion ist erst fertig, nachdem sie getestet worden ist. Auf diese Weise wird ein irreführender Projektfortschritt vermieden. [vgl. ECK09, S.89] Dies ist im Zusammenhang mit der Praktik Continous Integration möglich, also die kontinuierliche Codeintegration. Sobald eine Funktion implementiert und mit Unittests überprüft worden ist, wird sie in das Produkt integriert. Ziel dieser Praktik ist es, zu jeder Zeit ein lauffähiges Programm mit allen bisher umgesetzten Funktionen zu besitzen. Der Tester kann nun anhand dieses Artefakts die Tests durchführen. Die Ergebnisse werden direkt mit dem Entwickler besprochen und die Fehlerbehebung erfolgt so früh wie möglich. Erst wenn die User Story durch die Qualitätssicherung abgenommen wurde, gilt sie als erledigt. Dadurch wird 50

55 4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENTWICKLUNG sichergestellt, dass nur getestete Backlog Items zum Fortschritt des Entwicklungszyklus beitragen. Die agile Softwareentwicklung legt einen Schwerpunkt auf die Testautomatisierung. Dies gilt nicht nur für Unit- und Integrationstest, sondern auch für Systemtests und teileweise für den Akzeptanztest. Hierfür werden Regressionstests mit Werkzeugen wie FIT, Selenium oder Watir automatisiert. So ist es möglich, die Software am Ende eines Tages einem kompletten Test zu unterziehen. [vgl. CG09 255ff] Seiteneffekte durch Änderungen sind so praktisch auszuschließen. Durch die durchgängigen Unit- und Integrationstests, sowie die parallelen System- und Akzeptanztests befinden sich am Ende des Zyklus nur wenig Fehler im Produkt, die direkt behoben werden müssen. Ein automatisierter Systemtest kann regelmäßig die gesamte Software prüfen und ermöglicht einen schnellen Test am Zyklusende. Es ist möglich, die Tests schon zu Beginn zu schreiben und zu implementieren, als eine Art Anforderungsspezifikation. [vgl. ECK09, S. 172f] Die agile Qualitätssicherung mit Scrum umzusetzen bedeutet zunächst, auf eine Qualitätssicherung außerhalb des Projekts zu verzichten. Es empfiehlt sich, möglichst viele Praktiken der agilen Softwareentwicklung anzuwenden. Durch diese konstruktiven Maßnahmen wird die Produktqualität von Anfang an erhöht. Die Praktiken müssen jedoch vom Team selbst aufgegriffen werden, da Scrum steuernde Eingriffe dieser Art verbietet. Es ist jedoch von vornherein klarzustellen, dass das gesamte Team für die Qualität verantwortlich ist. Die Tester im Team sind wie alle Mitglieder an den Meetings beteiligt. Der genaue Umfang der Testarbeiten ist vom Team abhängig. Ob Code Reviews durchgeführt werden oder die Tester sich nur auf Akzeptanztests beschränken, kann variieren. Die Tester sollen auf alle Fälle den Product Owner beim Erstellen der User Story und ihrer Akzeptanzkriterien unterstützen. Bevor die ersten User Storys umgesetzt wurden, beginnen die Tester bereits mit der Automatisierung von Testfällen. Direkt nach der Umsetzung sollten die Akzeptanztests zusammen mit dem Product Owner durchgeführt werden, um aufwendige Systemtests auf unpassende Funktionalität zu vermeiden. Hier wird nur betrachtet, ob die Funktion den Vorstellungen des Kunden entspricht. Da dabei noch nicht tiefgreifend nach Fehlern gesucht wurde, sind die Systemtests im Anschluss durchzuführen. Am Ende des Sprints sind nur die User Stories als abgeschlossen anzusehen, welche von der Qualitätssicherung abgenommen wurden. Gegen die komplette Software sollten die automatisierten Tests ausgeführt werden. [vgl. CG09, S. 97ff] 51

56 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Die Software hat somit ein verändertes V-Modell durchlaufen. Der Unterschied ist, dass jede User Story ein eigenes V-Modell besitzt. Eine User Story wird zuerst mit Unittests verifiziert und in das Gesamtsystem integriert. Während der Integration findet ein Integrationstest statt. Nun folgen System- und Akzeptanztest durch Tester und Product Owner, wobei es sich anbietet den Akzeptanztest vor dem Systemtest durchzuführen. Auf diese Weise wird sichergestellt, dass jede Anforderung ihre eigenen automatisierten Unittests, Integrationstests und nach Möglichkeit auch Systemtests besitzt. Trotz des kontinuierlichen Testens fallen vor Auslieferung des Produkts weitere Testaktivitäten an. Die Zeit kurz vor der Auslieferung wird End Game genannt. [vgl. CG09, S. 456ff] Der Aufwand für das End Game kann stark in Abhängigkeit von den nötigen Tests variieren. Gibt es aufwendige Tests, die erst am Ende der Iteration durchgeführt werden können, ist entsprechend mehr Zeit einzuplanen. In der Regel fallen verschiedene Tätigkeiten in jedem Projekt an. Zum einen ist ein Test auf dem sogenannten Staging environment nötig, eine Umgebung, die das Produktivsystem nachbildet. Die Umgebung für die kontinuierliche Integration ist meist eine Testumgebung, das Verhalten in der Produktivumgebung kann davon abweichen. In diesem System ist zudem die Integration in alle benötigten Systeme zu testen und auf kundenspezifische Besonderheiten zu achten. Zudem ist es erforderlich die Installation des gesamten Produkts zu testen, da während der Entwicklung inkrementelle Updates zum Aktualisieren des Systems ausgeführt werden und keine komplette Installation durchgeführt wird. Um Vertrauen in die Software zu gewinnen, sind zusätzlich alle automatisierten Regressionstest auszuführen und manuelle Szenarien über die komplette Software durchzuführen. Funktionale Fehler sollten in dieser Phase nicht mehr auftreten, im Vordergrund steht das Sicherstellen der Lauffähigkeit in der neuen Umgebung. Ein weiterer Faktor ist das Testen der nichtfunktionalen Anforderungen. Obwohl nicht-funktionale Tests schon während der Entwicklung durchgeführt wurden, ist zu prüfen, ob die Software unter der neuen Hardware dieselben Eigenschaften aufweist. Für die Prüfung am Ende des Sprints ist das gesamte Team verantwortlich. In dieser Zeit werden keine neuen Funktionen realisiert. Dies bedeutet, dass dementsprechend weniger Zeit für die Entwicklung bleibt und bei der Planung entsprechend berücksichtigt werden muss. [vgl. Wir09, S. 167f] 52

57 4.4 ZUSAMMENFASSUNG Die Rolle des Testers ist in der agilen Softwareentwicklung variabel ausgelegt. Stauen sich am Ende der Iteration die Testaufgaben, können Entwickler beim Testen oder Automatisieren der Regressionstests helfen, während Tester am Anfang der Iteration Aufgaben in der Entwicklung wahrnehmen können. 4.4 ZUSAMMENFASSUNG Die Software-Qualitätssicherung ist von der allgemeinen Qualitätssicherung abgegrenzt worden. Während sich die Qualitätssicherung mit der Prüfung der Wirksamkeit des Qualitätsmanagements beschäftigt, steht in der Software-Qualitätssicherung die Produktqualität im Vordergrund. Die Software-Qualitätssicherung teilt sich in zwei Bereiche, die konstruktive Qualitätssicherung und die analytische Qualitätssicherung. Unter die konstruktive Qualitätssicherung fallen Maßnahmen, um die Qualität in die Software hinein zu entwickeln. Die analytische Qualitätssicherung ist für die Prüfung der Artefakte des Produktes verantwortlich. Dies geschieht in der Regel in vier Teststufen, Unittest, Integrationstests, Systemtest und Akzeptanztest. Während die konstruktiven Qualitätssicherungsmaßnahmen durch eine externe Qualitätssicherung schwer einzuführen sind, da diese während der Planung des Projekts vor Ort definiert werden müssen, können analytische Maßnahmen problemlos nach außen vergeben werden. Durch die Unabhängigkeit und das Fachwissen der externen Tester lassen sich daraus Potentiale aktivieren. Das Testen in der konventionellen Softwareentwicklung unterscheidet sich stark von der agilen Softwareentwicklung. Nach dem V-Modell werden die Tests phasenweise durchgeführt. Dies bedeutet, erst nachdem alle Anforderungen umgesetzt wurden, wird getestet. Dies ist in der agilen Softwareentwicklung nicht durchführbar, da die Iterationsziele auf diese Weise nicht erreichbar sind. Stattdessen wird jede Funktion direkt nach ihrer Umsetzung getestet. Dies erfordert eine erhöhte Zusammenarbeit zwischen Entwicklern und Testern. Des Weiteren ist der Einsatz von automatisierten Tests in der agilen Softwareentwicklung von größerer Bedeutung, da in jeder Iteration die komplette Software getestet werden muss. In der konventionellen Softwareentwicklung geschieht dies hingegen nur ein einziges Mal am Ende der Entwicklung. 53

58 KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD Die Unterschiede in der Qualitätssicherung von konventioneller und agiler Softwareentwicklung wurden verdeutlicht. Da sich die einzelnen Teststufen der konventionellen Softwareentwicklung bereits bewährt haben, wurden Ansätze aufgezeigt, sie in die agile Softwareentwicklung einzubinden, um die Produktion qualitativ hochwertiger Software zu gewährleisten. Zusätzlich sind automatisierte Tests zu verwenden, wie sie im Umfeld der agilen Softwareentwicklung propagiert werden. Folglich kann die agile Softwareentwicklung mit einer effektiven Software- Qualitätssicherung ausgestattet werden, um das benötigte Vertrauen für die Entwicklung von unternehmenskritischen Systemen zu schaffen. 54

59 5 TEILUNG DES SOFTWAREENTWICKLUNGSPRO- ZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Nach dem die Grundlagen zu Vorgehensmodellen, Qualitätsmanagement und Qualitätssicherung erläutert wurden, müssen diese nun auf die besondere Situation angepasst werden. Die agile Softwareentwicklung mit Scrum über drei beteiligte Unternehmen - Auftraggeber, Auftragnehmer für die Entwicklung (Auftragnehmer SE) und Auftragnehmer für die Qualitätssicherung (Auftragnehmer QS) - an verschiedenen Standorten - lässt sich nicht mit der einfachen Vergabe von Testaufgaben nach außen lösen. Durch die oberflächliche Spezifikation in agilen Entwicklungsprojekten ist ein entkoppelter Test der Software nicht sinnvoll. Die Tester benötigen das Kontextwissen, um ihren Tätigkeiten nachzukommen. Darüber hinaus findet die Kommunikation über größere räumliche Entfernungen über Dokumente statt, insbesondere bei der konventionellen Qualitätssicherung. Diese Dokumente werden von einem agilen Prozess nicht ausreichend unterstützt. Es existieren zwei verschiedene Möglichkeiten, den Testern das Wissen über die Anforderungen der Applikation zukommen zu lassen. Auf der einen Seite besteht die Möglichkeit, den Prozess von Scrum soweit zu verändern, dass die benötigten Informationen niedergeschrieben und weitergeleitet werden. Der Auftragnehmer QS testet die vollständige Software nach Sprintende gegen die Spezifikation und liefert die Ergebnisse zurück. Die Fehlerbehebung findet im Laufe des nächsten Sprints statt. Dies würde jedoch den agilen Prinzipien widersprechen und einige Probleme der dokumentengesteuerten Vorgehensmodelle mit sich bringen. Die Flexibilität wird gesenkt und ein zusätzlicher Zeitaufwand für die Dokumentation kommt hinzu. Ein weiterer Faktor ist die Verschiebung der Auslieferung um mindestens einen Sprint. Diese Lösung ist aber in ihrer Umsetzung einfach und erfordert vor allem von der Qualitätssicherung nur einen kleinen Anpassungsaufwand. Eine andere Lösung ist die Integration der externen Qualitätssicherung in die Prozesse von Scrum. Obwohl die Qualitätssicherung nicht vor Ort untergebracht ist, wird sie in alle Entscheidungsprozesse einbezogen. Dies geschieht durch die Unterstützung bei der Erstellung der Backlog Items, Teilnahme an den Hauptsitzungen wie Sprint Planning, Sprint Review und Sprint Retrospective. Über Kollaborationswerkzeuge findet eine transparente Zusammenarbeit zwischen Entwicklungsteam und Qualitätssicherung während des Sprints statt. 55

60 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Übergeordnete Prozesse steuern die Zusammenarbeit, schränken die flexible Kommunikation jedoch nicht ein. Auf einem zentralen Testsystem werden die Funktionen im Gesamtsystem direkt nach Fertigstellung getestet. Der Zugriff erfolgt per Fernzugriff. Die Ergebnisse des Sprints können wie beim agilen Vorgehen direkt nach Sprintende als fertig angesehen und ausgeliefert werden. Diese Lösung erfordert ein hohes Maß an Bereitschaft zum Umdenken in der Qualitätssicherung und viel Akzeptanz bei den Entwicklern, die die Qualitätssicherung nicht als hindernd betrachten dürfen. Während die erste Lösung eine einfache Umsetzung verspricht, verlässt sie doch das agile Feld. So weit möglich, sollten die agilen Prinzipien beibehalten werden, um schnelle Auslieferungen und eine hohe Flexibilität beizubehalten. Aus diesem Grund wird im weiteren Verlauf die zweite Lösung verfolgt. 5.1 FESTLEGUNG DER AUFGABEN DER BETEILIGTEN UNTER- NEHMEN Scrum definiert verschiedene Rollen, den Product Owner, den ScrumMaster, das ScrumTeam sowie die Stakeholder, bestehend aus Kunden, Management und sonstigen Interessenvertretern. Product Owner, ScrumMaster und ScrumTeam dürfen nicht getrennt werden. Sie sind in den Räumlichkeiten des Auftragnehmer SE untergebracht. An ihren Aufgaben ändert sich nichts Grundsätzliches, die Entwicklung der Software läuft nach demselben Schema ab wie zuvor. Das Team wird um ein externes Mitglied mit der Funktion zur Qualitätssicherung ergänzt. Sollte das alte ScrumTeam keinen dedizierten Tester besessen haben, ändert sich an der Teamstruktur nichts. Anderenfalls muss das Zusammenspiel zwischen externen und internen Testern abgestimmt werden. Die Aufgabe der Qualitätssicherung in agilen Softwareprojekten ist die Unterstützung des Product Owners bei der Erstellung von User Stories und Akzeptanztests, Testen und Testautomatisierung während des Sprints sowie verifizieren und validieren der Software am Sprintende. Durch eine gute Integration ist es für die externe Qualitätssicherung möglich, alle diese Aufgaben zu übernehmen. Die Abstimmungen zwischen Product Owner und Kunde zur Erstellung des Product Backlogs finden in der Regel nicht kontinuierlich, sondern punktuell statt. So wird es der 56

61 5.1 FESTLEGUNG DER AUFGABEN DER BETEILIGTEN UNTERNEHMEN Qualitätssicherung ermöglicht, an dem Treffen teilzunehmen. Bei kurzfristigen, außerplanmäßigen Treffen kann die Qualitätssicherung per Telefon o.ä. hinzu gezogen werden. Zum Durchführen der Tests ist vorab die Testart zu bestimmen. Je näher am Code gearbeitet werden muss, desto größer wird der Abstimmungsaufwand mit den Entwicklern. Für einen Test auf der Oberfläche ist keine weitere Erklärung erforderlich, während der Tester für Unittests in die Programmstruktur eingeführt werden muss. Aus diesem Grund ist genau zu planen, auf welchen Schichten sich der Tester bewegen soll. In der agilen Softwareentwicklung sind Tester sehr flexibel und übernehmen auch Aufgaben der Entwickler. Für die externe Qualitätssicherung empfiehlt es sich jedoch, an den traditionellen Prinzipien festzuhalten, um den Kommunikationsbedarf gering zu halten. Die White-Box-Tests sind Aufgabe der Entwickler, die Black-Box-Tests werden von der Qualitätssicherung durchgeführt. Jede Funktion wird von den Entwicklern während des Sprints einmal Unit- und Integrationstests unterzogen und danach gibt es von den Testern System- und Akzeptanztests. Dabei sind beide Tests soweit wie möglich zu automatisieren. Der Test am Ende des Sprints ist Aufgabe des gesamten Teams. Je nach Länge des Sprints sind mehrere Tage einzuplanen, in denen alle automatisierten Tests ausgeführt werden. Die Qualitätssicherung sollte sich hier auf Validierung der nichtfunktionalen Anforderungen konzentrieren, da jede Funktion einzeln während des Sprints getestet wurde und nach Möglichkeit automatisiert geprüft werden kann. Wurde die externe Qualitätssicherung vom Kunden selbst hinzugezogen, besteht die Möglichkeit, unabhängige Statusberichte abzufragen. Die Aufgabe besteht darin, den Kunden über die Qualität der Software zu informieren. Aufgrund der Aussage kann der Kunde entscheiden, ob eine Qualität erreicht wurde, die das Ausrollen des Releases im Unternehmen erlaubt. Durch ein hohes Fachwissen im Bereich Softwarequalität sind spezialisierte externe Dienstleister für eine derartige Einschätzung besonders qualifiziert. Aufgrund der Qualitätseinschätzung kann der Auftraggeber auch weitere Maßnahmen zur Qualitätserhöhung anstoßen, sollten die Ergebnisse nicht positiv ausfallen. Im Falle der konstruktiven Qualitätssicherungsmaßnahmen fällt dem Auftragnehmer QS eine beratende Funktion zu. Sie hat keine Weisungsbefugnis, um die Entwickler zum Nutzen bestimmter agiler Praktiken zu bewegen. Er sollte Vorschläge möglichst früh zur Sprache bringen und auf deren Einhaltung dringen. Durch die räumliche Trennung wird diese Aufgabe 57

62 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN zusätzlich erschwert. In Scrum ist das komplette Team für die Qualität verantwortlich, Entwickler, Analysten, Tester und die Inhaber weiterer Funktionen. Es darf nicht der Eindruck entstehen, dass mit einer zusätzlichen Rolle für die Qualitätssicherung den Entwicklern Verantwortung für die Qualität der Software abgenommen wird. Um den Sprint mit auslieferbarer Software abzuschließen, ist der Bedarf von Nachbesserungen zum Ende möglichst gering zu halten. Der Scrum Master ist dafür zuständig, alle Hindernisse, die das Team in seiner Arbeit einschränken können, zu beseitigen. Durch die Integration der externen Qualitätssicherung muss er auf die Einbindung der neuen Mitglieder achten. Dies wird durch die räumliche Entfernung erschwert, da die Qualitätssicherung nicht am Daily Scrum teilnehmen kann. Seine Aufgabe ist nicht, eine Zusammenarbeit zu erzwingen, sondern die nötigen Mittel und Kompetenzen bereitzustellen, um sie zu ermöglichen. Unternehmensübergreifende Kommunikation kann zu unterschiedlichen Problemen führen. Sie kann einerseits schnell zu Misstrauen führen, andererseits kann die Qualitätssicherung als Überwachungsfunktion angesehen werden oder ein Mangel an Werkzeugen die Zusammenarbeit verhindern. Um dem Vorzubeugen muss sich der ScrumMaster nicht nur im eigenen Unternehmen und mit dem Auftraggeber in Verbindung setzen, sondern auch mit dem Auftragnehmer QS auseinander setzen. Es ist wichtig, dass der ScrumMaster sich zur externen Qualitätssicherung bekennt, da er eine treibende Kraft für den Erfolg der Integration darstellen kann. Der Product Owner ist nach wie vor für die Zusammenstellung und Auswahl der User Stories verantwortlich. Die User Stories werden jedoch von Anfang an um Akzeptanzkriterien erweitert. Zur Erstellung von Akzeptanzkriterien und dem Ableiten von Akzeptanztests wird er von der Qualitätssicherung unterstützt. Das frühzeitige Definieren von Akzeptanzkriterien hilft zusätzlich den Entwicklern dabei, die Anforderungen zu verstehen. Auch während der Akzeptanztests kann die Qualitätssicherung mit Wissen zur Seite stehen und den Product Owner unterstützen. Bei Tests der Qualitätssicherung müssen bei Unklarheiten regelmäßige Rücksprachen mit dem Product Owner getroffen werden, um Missverständnissen vorzubeugen. Bei der Umsetzung von Veränderungen ist das Management immer eine treibende Kraft. Nur mit seiner Unterstützung kann ein unternehmensübergreifendes Projekt funktionieren. Die Entscheidung zur Einbindung externer Qualitätssicherung wird vom Management getroffen. Dies kann mit oder ohne Anreiz vom Kunden geschehen. Das Management muss alle Beteiligten von der Einführung externer Qualitätssicherung überzeugen und die benötigten Mittel 58

63 5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN und Werkzeuge dafür bereitstellen. Eine enge Zusammenarbeit mit dem ScrumMaster ist aufgrund seines Wissens über die Arbeitsweise des Teams dringend erforderlich. Der ScrumMaster benötigt aktive Hilfe zur Beseitigung von Hindernissen. Durch einen direkten Zugang zu Entscheidungsträgern in allen beteiligten Unternehmen können Schwierigkeiten des Scrum- Teams schnell aus dem Weg geräumt werden. Geht die Entscheidung zur Einbeziehung einer externen Qualitätssicherung vom Kunden aus, muss dieser klarstellen, welche Vorteile er sich davon erhofft. Je nach Geschäftsverhältnis kann der Kunde Einfluss auf die Auftragnehmer ausüben. Dadurch kann er den Erfolg des Projekts maßgeblich beeinflussen. Es liegt an ihm, das Management des Auftraggeber SE von der Sinnhaftigkeit dieses Vorgehens zu überzeugen. Fühlt sich der Auftraggeber SE kontrolliert, ist mit starken Widerständen zu rechnen. Des Weiteren obliegt es ihm, zu definieren, welche Leistungen von der externen Qualitätssicherung verlangt werden sollen. Eine kurze Abnahme der Software nach Sprintende zur Evaluierung der Qualität bis zur kompletten Einbindung der externen Qualitätssicherung ist möglich. Außerdem kann er großen Einfluss auf die Einbindung der externen Qualitätssicherung bei der Anforderungsdefinition nehmen. Sollte der externe Dienstleister nicht vom Auftraggeber hinzugezogen worden sein, entfallen keine zusätzlichen Aufgaben auf den Kunden. 5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN In Scrum verwaltet sich das Team selbstständig. Die Qualitätssicherung ist Teil des Teams und unterliegt somit keiner Weisung durch einen Projektleiter. Bei einer externen Qualitätssicherung, die nicht am selben Ort wie das Team operiert, könnte sich dieses Vorgehen anfangs aus zwei Gründen als problematisch erweisen. Zum einen muss die Kommunikation zwischen internen und externen Teammitgliedern angestoßen werden. Ohne geeignete Kanäle und technische Unterstützung besteht die Gefahr, dass der externe Part des Teams nicht als zugehörig angesehen wird, die Kommunikation nicht beginnt oder frühzeitig zum Erliegen kommt. Zum anderen sind bei einer unternehmensübergreifenden Zusammenarbeit die geschäftlichen Aspekte nicht zu vernachlässigen. Je nachdem, von wem die externe Qualitätssicherung hinzugezogen wurde, muss die erbrachte Arbeit gegenüber dem Auftraggeber transparent sein. Je nach Vergütungsgrundlage ist es erforderlich, die Leistungen zu erfassen und gegenüber den internen Mitgliedern abzugrenzen. Dafür ist es erforderlich festzustellen, wo die Arbeit der 59

64 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN externen Teammitglieder beginnt und endet. Da sich das Team auf ihre Aufgaben bezüglich der Softwareentwicklung konzentrieren soll, kann nicht davon ausgegangen werden, dass es derartige Mechanismen von sich aus entwickelt. Folglich sind vorab Kommunikationskanäle zwischen internen und externen Teammitgliedern zu definieren und zu schaffen, sowie Schnittstellen und Leistungserfassungsmechanismen herauszuarbeiten. Durch überschneidungsfreie Aufgaben und Kompetenzverteilung ist es möglich, den Kommunikationsaufwand gering zu halten und eine Leistungsunterscheidung zu treffen. Zur Vereinfachung werden die Unternehmen für die Implementierung und für die Qualitätssicherung als zwei getrennte Systeme betrachtet, deren Kommunikation über klar definierte Schnittstellen abläuft. Anschließend ist es möglich, die Schnittstellen aufzuweichen, um der agilen Methodik entgegen zu kommen. ABBILDUNG 5.1: VERTEILUNG DER AUFGABEN Wie in Bild 5.1 zu sehen, ist eine überschneidungsfreie Aufteilung der Aufgaben von Scrum- Team und Qualitätssicherung möglich. Das dominierende Artefakt der Entwicklung ist die User Story. Sie wird zu Beginn der Entwicklung definiert und dient als Vorlage für alle weiteren Aufgaben. Die Erstellung der User Story findet spätestens vor dem nächsten Scrum Zyklus statt. Der Kunde, Product Owner und die externe Qualitätssicherung erstellen die User Stories gemeinsam. Jeder der drei Beteiligten bringt sein Wissen ein. Der Kunde kennt als einziger seine Anforderungen an das Produkt, der Product Owner gibt ihm Hilfestellung, die Anforderungen zu konkretisieren und zu formulieren, während die Qualitätssicherung bei der Erstellung von Akzeptanzkriterien unterstützt. Diese Tätigkeit wird in der Regel nur einmal vor jedem Sprint durchgeführt. Ein Zusammenkommen der Parteien sollte daher möglich sein. 60

65 5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN Der Aufbau und die Pflege des Product Backlogs erfolgt nach wie vor einzig durch den Product Owner. Das Sprint Planning Meeting spielt eine zentrale Rolle bei der Vorbereitung des Teams auf den kommenden Sprint. Es ist die einzige Besprechung bis zum Ende der Iteration, in dem das Team inklusive der Qualitätssicherung vollständig zusammenkommt. Bei der Auswahl der User Stories für das Product Backlog während des Sprint Planning Meetings ist die Anwesenheit aller Projektbeteiligten nötig, auch der Qualitätssicherung [vgl. CG09, S. 333f]. Zu diesem Zeitpunkt erfolgt die Aufwandsschätzung der User Stories, die ins Sprint Backlog übertragen werden. In der Regel sind die Mitglieder der Qualitätssicherung als einzige in der Lage, den Aufwand für die Tests richtig einzuschätzen. Die übergeordneten Prozesse, Qualitätskennzahlen und Werkzeuge müssen dem Team vorgestellt werden. Es dürfen keine Unklarheiten bestehen bleiben. Alle wichtigen Aspekte bezüglich der Zusammenarbeit sind hier zu besprechen und festzulegen. Dem ScrumMaster kommt die Aufgabe zu, alle Spannungspunkte zwischen den einzelnen Teammitgliedern anzusprechen und aufzulösen. Die Besprechung ist erst dann beendet, wenn sich das Team auf eine gemeinsame Vorgehensweise bezüglich der Qualitätssicherung geeinigt hat. Sollte es sich um das erste Meeting vor dem Sprint mit externer Qualitätssicherung handeln, ist eine Einbeziehung des Managements zur Akzeptanzschaffung wünschenswert. Die Intentionen hinter diesen Maßnahmen müssen offen gelegt werden. Bei mangelnder Transparenz kann es zu Misstrauen gegenüber der externen Qualitätssicherung kommen, die Entwickler könnten sich gegen eine Zusammenarbeit sperren oder nur spärlich Informationen weiter geben. Nach dem Sprint Planning Meeting beginnt der Sprint. Die Kommunikation findet von nun an über entfernte Kommunikationskanäle und Kollaborationsplattformen statt. Die Zielsetzung besteht darin, die Zusammenarbeit möglichst reibungslos zu gestalten. Dazu müssen geeignete Werkzeuge und Systeme bereitgestellt werden, zu denen beide Seiten Zugriff bekommen. Es muss für beide ersichtlich sein, welches Mitglied zurzeit an welcher Story arbeitet, beziehungsweise gearbeitet hat. Dies bezieht Design, Implementierung und Test mit ein. Nachdem die ausgewählten Stories in das Sprint Backlog übertragen wurden, sind sie in ein geeignetes Werkzeug zu übertragen. 61

66 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Bei Scrum werden die Tasks auf einem Taskboard festgehalten. Das Board ist in verschiedene Spalten geteilt, die den jeweiligen Status des Tasks darstellen. Im Laufe der Entwicklung wandert der Task über das Board, bis er in der letzten Spalte done angekommen ist. Die einzelnen Teammitglieder suchen sich selbstständig Aufgaben vom Board aus und sortieren sie nach Beendigung ihrer Aufgabe im zugehörigen Status wieder ein. [vgl. Pic08, S. 102f] Hierfür ist eine Lösung zu finden, die verteiltes Arbeiten zulässt und in der alle Mitglieder gleichermaßen auf die Tasks und deren Status zugreifen können. Eine internetbasierte Applikation, die verteilten Zugriff erlaubt, bietet sich an. Alle wichtigen Informationen zur Story können dem Werkzeug entnommen werden. Kommen während der Entwicklung weitere wichtige Ergänzungen durch Absprache mit dem Product Owner zustande, sind diese nachträglich einzupflegen. Hierbei ist zu beachten, dass diese Ergänzungen nur Erklärungen und Konkretisierungen zu bestehenden User Stories sein dürfen, da während des Sprints keine neuen Anforderungen hinzukommen dürfen. Bei Beginn der Arbeit an einer Story wird im System das betreffende Mitglied eingetragen. Der Status wird auf die entsprechende Tätigkeit gesetzt. So ist für jeden ersichtlich, von wem die Story bearbeitet wird und welche Arbeitsschritte er ausführt. Nach Ende der Implementierung werden die Funktionen in das Testsystem integriert und der Status der Story erneut verändert. Der Tester erkennt daran, dass die Story für den Test bereit ist. Er kann nun von sich aus die Story aufgreifen und mit dem Testen beginnen. Für Rückfragen stehen die Entwickler zur Verfügung und sind über verschiedene Kommunikationskanäle erreichbar. Auf diese Weise wird erreicht, dass die Qualitätssicherung ihrer Arbeit unabhängig von der Entwicklung nachgehen kann, jedoch auf beiden Seiten der gleiche Informationsstand herrscht. Da die Qualitätssicherung schon während der Erstellung der Story involviert ist, hat sie gutes Verständnis über die Bedürfnisse der Kunden. Kommen weitere Informationen während der Entwicklung hinzu, wird entweder die Story erweitert oder in einem Gespräch vor dem Test abgeklärt. Die Übermittlung der Testergebnisse ist kritisch. In der Regel werden von der Qualitätssicherung Testberichte verfasst und an die Entwickler weitergereicht. Dies ermöglicht eine unkomplizierte Kommunikation, der Entwickler kann den Berichten die Fehler entnehmen und im Quellcode beheben. Dabei werden jedoch nicht die Notwendigkeit der Fehlerpriorisierung, der Abstimmung bei Unklarheiten sowie die Besonderheiten agiler Prozesse berücksichtigt. 62

67 5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN Fraglich ist, wer den Zeitpunkt der Fehlerbehebung bestimmt. In der konservativen Softwareentwicklung wurde eine Behebung aller Fehler vor Auslieferung der Software angestrebt. In der agilen Softwareentwicklung bleibt mehr Spielraum. Unkritische Fehler können in späteren Iterationen behoben werden, bei schwerwiegenden Fehlern muss die Fehlerbehebung schnellstmöglich erfolgen, damit ein erneutes Testen vor Iterationsende möglich ist. Hinzu kommt, dass nur getestete Funktionen nach der Iteration ausgeliefert werden dürfen, diese jedoch noch nicht völlig fehlerfrei sein müssen. Es ist zu bestimmen, ob eine Funktion den Auslieferungskriterien gerecht geworden ist. Ein weiterer Faktor ist die Abstimmung bei Unklarheiten. User Stories geben keine konkrete Vorgabe für die Umsetzung der geforderten Funktion. Da die Qualitätssicherung eine validierende Instanz ist, kann die Implementierung der Entwickler hinterfragt werden. Ist die Qualitätssicherung anderer Meinung als die Entwicklung, entsteht Diskussionsbedarf, der nicht über Dokumente austragbar ist. Des Weiteren erfordern agile Prozesse kurze Kommunikationswege. Der Aufwand, um einen umfassenden Testbericht zu erstellen, ist in einer wenige Wochen umfassenden Iterationsphase nicht gegeben. Die Kommunikation muss zeitnah erfolgen, um die User Story schnellstmöglich abzuschließen. Die Tester können die direkte Kommunikation zu den Entwicklern suchen. Auf diese Weise müssen nicht alle Fehler festgehalten werden. Die Behebung kleiner Fehler ist mit wenig Aufwand verbunden. Eine schnelle Behebung des Fehlers und ein gleich darauf folgender Nachtest ist möglich. [vgl. CG09, S. 420f] Findet sich kein Entwickler oder ist der Fehler nicht trivialer Natur, ist er festzuhalten. Eine Einspeisung der Fehler in die laufende Iteration ist erforderlich. Da nicht alle Fehler direkt behoben werden müssen, obliegt es dem Product Owner zu entscheiden, welche Fehler für die Fertigstellung der Story zu beheben sind. Da das Team während der Tests mit der Arbeit an einer neuen Story begonnen hat, ist es sinnvoll, die Fehlerbehebung als Teil der aktuellen Story zu vollziehen. Dies bedeutet, dass die aktuelle Story erst abgeschlossen ist, wenn alle freigegebenen Fehler aus der vorherigen Phase behoben worden sind. [vgl. Wir09, S. 157] Der Product Owner kann zusätzlich Unstimmigkeiten mit den Anforderungen bei der Umsetzung von Funktionen direkt überprüfen und gegebenenfalls die Story konkretisieren. Wichtig ist, dass die Zusammenarbeit mit dem Product Owner augenblicklich funktioniert, so dass wenig Zeit zwischen Aufdeckung des Fehlers und der Eintaktung der Fehlerbehebung entsteht. 63

68 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Zusätzlich sollten die Fehler in einem offenen System festgehalten werden, einem sogenannten Bug-Tracking-System. Die Entwickler bekommen so direkten Zugriff auf alle Fehler und können diese in Phasen geringer Auslastung abarbeiten. Nach dem Beheben eines Fehlers ist der Status im Bug-Tracking-System zu ändern und die Änderung in das Testsystem zu integrieren. Der Tester kann daraufhin sofort mit dem Nachtest beginnen. Um dieses Vorgehen umzusetzen, wird kein Testbericht für eine komplette Story erstellt, sondern eine knappe Beschreibung für jeden Fehler. Die Fehlerbeschreibung wird einer Funktion zugeordnet. Auf diese Weise können die Fehler einer Funktion schnell identifiziert werden, und eine voneinander unabhängige Behandlung der Fehler wird ermöglicht. Durch die Trennung von Story und Fehler ist es möglich, einen Überblick über alle Fehler im System zu bekommen und nicht nur über fehlerhafte Stories. Durch den verbesserten Überblick wird die Qualität des Systems transparenter. ABBILDUNG 5.2: SCHNITTSTELLEN ZWISCHEN DEN ROLLEN UND SYSTEMEN 64

69 5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN In Bild 5.2 sind die Schnittstellen zwischen den einzelnen Rollen und Systemen visualisiert. Zu beachten ist, dass in der agilen Entwicklung die Interaktion zwischen Menschen einen höheren Stellenwert einnimmt als die Einhaltung von Prozessen und das Benutzen von Werkzeugen. Es entstehen Synergieeffekte durch die direkte Kommunikation. Unter anderem erfolgt ein Wissenstransfer, der dem Entwickler hilft, seinen Code besser zu testen und dem Tester Verständnis für Probleme der Implementierung zu vermitteln. Lösungsmöglichkeiten können durch die unterschiedlichen Sichtweisen schneller gefunden und Kompromisse ausgearbeitet werden. Zusätzlich erfolgt die Fehlerbehebung übergangslos. Wird der Fehler nur in einem Bug-Tracking-System aufgenommen, besteht keine Garantie auf zeitnahe Behandlung. Somit ist die direkte Kommunikation zwischen Team und Qualitätssicherung möglichst auszureizen. [vgl. CG09, S. 412f] Da Situationen entstehen können, in denen kein Entwickler zur Verfügung steht, wird die Möglichkeit geschaffen, Testergebnisse zentral festzuhalten. Für schwerwiegende Fehler, für die möglicherweise neue User Stories verfasst oder Tasks angelegt werden müssen, sowie bei Unstimmigkeiten gegenüber den Anforderungen, ist der Weg über den Product Owner unumgänglich. Der ScrumMaster ist nicht aufgeführt, da er keine Rolle im Entwicklungsprozess selbst übernimmt. Er muss jedoch die Kommunikation zwischen den Rollen und die Nutzung der Werkzeuge betrachten, um gegebenenfalls gegenzusteuern. Eine wichtige Funktion ist dabei der Schutz des Sprint Backlogs. Der Product Owner darf hier nur Informationen zur Klärung der Anforderungen nachtragen und nicht den Aufwand von User Stories erhöhen, beziehungsweise neue User Stories einpflegen. Während der Entwicklung kann es nun zu verschiedenen ad hoc Kommunikationssituationen kommen, bei denen Informationen zwischen zwei Parteien ausgetauscht werden, ohne dass die dritte Partei ohne übergeordneten Prozess davon erfahren würde. Die dort ausgetauschten Informationen könnten kritischer Natur sein und dringend benötigt werden. In einem herkömmlichen Vorgehensmodell trat diese Situation in der Regel nicht auf, da alle Anforderungen und Zeitpläne zuvor genau festgelegt wurden. In einem agilen Umfeld sind kurzfristige Planänderungen und Absprachen bezüglich der Anforderungen gewollt und müssen daher genau betrachtet werden. Es sind Mechanismen zu planen und zu implementieren, über die Informationen mit allen Teammitgliedern geteilt werden können. 65

70 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Es gibt drei Konstellationen, in denen eine dritte Partei nicht in die direkte Kommunikation eingebunden ist. Dies sind: Kunde Entwicklung, Kunde QS und Entwicklung - QS. Die Entwicklung und der Kunde kommunizieren meistens über den Product Owner. Je nachdem von welcher Seite die Kommunikation initiiert worden ist, geht es entweder darum, zusätzliche Informationen zu einer Aufgabe zu erhalten oder zusätzliche Wünsche zu äußern. Zweites ist für Aufgaben in der laufenden Iteration nicht möglich, da das Sprint Backlog in der jeweiligen Iteration gesperrt ist. Zusätzliche Wünsche gehören ins Product Backlog. Zusätzliche Informationen zu einer Aufgabe oder einer User Story sind auch für die Qualitätssicherung von Bedeutung, da diese Auswirkung auf die Tests haben können. Deshalb sollten sie als Ergänzung im Sprint Backlog dokumentiert werden. Ähnliche Informationen können zwischen Qualitätssicherung und Kunde ausgetauscht werden. Diese müssen über das Sprint Backlog, wie oben beschrieben, an die Entwickler weitergeleitet werden, um das Verständnis für Fehler zu verbessern. Absprachen zwischen Entwicklung und Qualitätssicherung können für den Kunden sowie weitere Stakeholder interessant sein, wenn diese Planänderungen oder Prozessänderungen vorsehen. All diese Informationen und das Wissen werden im herkömmlichen agilen Vorgehen direkt zwischen den Teammitgliedern geteilt. Dies ist aufgrund der Nähe der Teammitglieder zueinander und der begrenzten Teamgröße möglich. In der verteilten Entwicklung sind dafür technische Hilfsmittel in Form von Kollaborationswerkzeugen nötig. Hierfür sind unter anderem Wiki-Webs und Listen geeignet. [vgl. Eck04, S.59] Außerdem können Möglichkeiten geschaffen werden, User Stories um eine Änderungsliste zu erweitern. So sind zusätzliche Informationen direkt dort untergebracht, wo sie benötigt werden. Das Dokumentieren von Änderungen und zusätzlichen Informationen ist in einem agilen Prozess jedoch nicht selbstverständlich. Es müssen Anreize geschaffen werden, um dies zu fördern. Jutta Eckstein schlägt den Einsatz eines Kommunikationsteams vor. Dies können eine oder mehrere Personen sein, die in regelmäßigen Abständen alle Teammitglieder nach neuen Informationen befragen. Diese Person muss als Vertrauensperson und nicht als Kontrolleur wahrgenommen werden. [vgl. Eck04, S. 60f] Dieser Aufgabe könnte unter anderem der ScrumMaster nachkommen. 66

71 5.3 ZUSAMMENFASSUNG 5.3 ZUSAMMENFASSUNG Durch das Einbinden einer externen Qualitätssicherung in den agilen Entwicklungsprozess müssen die Aufgaben der verschiedenen Beteiligten genau definiert werden, um Kompetenzstreitigkeiten zu vermeiden sowie die Beschreibung von klaren Schnittstellen zwischen den Unternehmen zu ermöglichen. Die Rollen des Product Owners, ScrumMasters und des ScrumTeams beim Auftragnehmer der Entwicklung bleiben erhalten. Die Rolle der externen Qualitätssicherung musste hingegen in Scrum eingefügt werden. Der Product Owner ist weiterhin die Schnittstelle zum Kunden und für die Auswahl der umzusetzenden User Stories verantwortlich. Zusätzlich wird er bei der Aufnahme und Erstellung der Akzeptanzkriterien von der Qualitätssicherung unterstützt. Dadurch wird diese detailliert über die Anforderungen informiert. Der Scrum Master dient zusätzlich als Schnittstelle zum externen Team und muss alle Hindernisse beseitigen, die der Zusammenarbeit hinderlich sind. Das Management muss dem Projekt seine volle Unterstützung zusichern und eine Infrastruktur bereitstellen, in der ein verteiltes Arbeiten möglich ist. Die Teststufen werden auf die beteiligten Unternehmen aufgeteilt. Die Entwickler sind für die Unit- und Integrationstest zuständig, da sie detaillierte Einblicke in den Quellcode und die technische Umsetzung besitzen. Die externe Qualitätssicherung ist für die Systemtests und soweit machbar, für die Akzeptanztests zuständig. Um das Zusammenspiel zwischen den Beteiligten zu optimieren, sind an den großen Meetings alle Teammitglieder aus Entwicklung und Qualitätssicherung beteiligt. So herrscht bei Entwicklungsbeginn ein Informationsgleichstand. Kommen während der Entwicklung weitere Informationen zu den User Stories hinzu, muss der Informationsgleichstand wieder hergestellt werden. Dies geschieht über eine Erweiterung der User Stories um die neuen Informationen. Zu diesem Zweck müssen die User Stories in einem zentralen, für beide Unternehmen zugänglichen System festgehalten werden. Die Fehlerbehebung erfolgt so früh wie möglich: Entweder über eine direkte Kommunikation mit dem Tester oder spätestens während der Entwicklung der nächsten User Story. Dazu werden etwaige Fehler zu Tasks der aktuellen User Story in der Entwicklung. 67

72 KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN Um die Zusammenarbeit weiter zu verbessern, sollten Kollaborationswerkzeuge eingesetzt werden. Die verschiedenen Aufgaben der Rollen im erweiterten Scrumprozess, ihre Schnittstellen und ihr Zusammenwirken wurden beschrieben. Sie dienen als weitere Grundlage der Prozessbeschreibung. 68

73 6 UNTERSTÜTZUNG DES SOFTWAREENTWICK- LUNGSPROZESSES Die Gestaltung eines Softwareentwicklungsprozesses erfordert Berücksichtigung aller Anforderungen. Wir haben auf der einen Seite ein agiles Vorgehen, dem die aus einem starren Entwicklungsmodell stammende Qualitätssicherung entgegen steht. Hinzu kommt die Anwendbarkeit für die Entwicklung unternehmenskritischer Systeme, die oft sehr hohen Qualitätsanforderungen entsprechen müssen und aus diesem Grund unterer starker Kontrolle in einem konservativen Kontext hergestellt wurden. Boehm und Turner haben agile und plangetriebene Entwicklungsmodelle untersucht, um die jeweiligen Anwendungsgebiete festzustellen. Hierbei hat sich herausgestellt, dass keines der beiden eine allgemeingültige Lösung liefert, sondern eine Mischung aus beiden die größte Aussicht auf Erfolg hat. Zudem scheint das größte Potential nicht bei den eingesetzten Methoden, sondern bei den Menschen, Werten, Kommunikation und dem Erwartungsmanagement zu liegen. [vgl. BT08, S. 147ff] Sie haben gezeigt, dass viele verschiedene Randbedingungen die Eignung eines Projekts für agile oder plangetriebene Vorgehensmodelle, bzw. den Grad der Mischung von Beidem beeinflussen. Aus diesem Grund ist es nicht möglich, ein allgemeingültiges Modell unter Berücksichtigung aller möglichen Randbedingungen aufzustellen. Daher wird im Weiteren mit Scrum gearbeitet, dessen Skalierung unter anderen Randbedingungen in einschlägiger Literatur festgehalten wurde. [u.a. in Eck04, Eck09] Die Sicherstellung der hohen Qualitätsanforderungen geschieht allein durch die umfassende analytische und konstruktive Softwarequalitätssicherung sowie hohe Prozessqualität. Während der Beschreibung der Schnittstellen begann der Entwicklungsprozess sich herauszubilden. Die Entwicklung mit Scrum konnte unverändert bleiben, da es möglich ist, die Rolle der externen Qualitätssicherung zusätzlich einzuführen. Sie befindet sich jedoch in einem eigenen System außerhalb des implementierenden Unternehmens. Je nachdem, wie sehr der Kunde die externe Qualitätssicherung als unabhängiges Kontrollorgan nutzen möchte, gibt es zwei bis drei verschiedene Systeme, die über Schnittstellen miteinander kommunizieren. Die Beschreibung des unternehmensübergreifenden Prozesses ist erforderlich. Aufgrund des agilen Vorgehens ist dieser jedoch nicht verbindlich für alle Mitglieder festzulegen, sondern dient als Leitfaden. Sollte sich der Prozess als nicht optimal herausstellen, können 69

74 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES Änderungen eingearbeitet werden. Wie in Scrum üblich, sollte dies in der Sprint Retrospective geschehen. Um die Einbindung der externen Qualitätssicherung für Management und Kunde transparenter zu gestalten, sollte der Prozess durch Qualitätsmanagementmaßnahmen begleitet werden. Auf diese Weise können alle Beteiligten zur Qualitätssteigerung beitragen. Das Vorgehen während der Entwicklung orientiert sich an den User Stories und den daraus resultierenden Tasks. Die User Story bildet ein geschlossenes Werk, welches während der Entwicklung bearbeitet wird. Alle User Stories abzuschließen und zusammenzufügen, ist das Ziel der Entwicklung. Die dabei entstandene Software das Produkt. Wird die Qualität zur Entwicklung der einzelnen User Stories hoch angesetzt, kann daraus geschlossen werden, dass das Gesamtsystem über eine hohe Qualität verfügen wird. Somit liegt der Fokus des Prozesses auf der Umsetzung einzelner User Stories und nicht auf der aufeinander folgenden Abarbeitung ganzer Phasen, in denen jeweils alle Anforderungen umgesetzt werden. Die Betrachtung einer User Story lässt sich gut als Prozess abbilden und bezieht alle Entwicklungsschritte ein. Die Aufgaben der drei Parteien wurden zuvor festgelegt. Bevor der Prozess vollständig ausgestaltet werden kann, ist zu klären, auf welche Weise Qualitätsmanagement eingesetzt werden kann, um die Grundlage für eine stetige Optimierung zu schaffen. Des Weiteren sind die eingesetzten Informationskanäle und Systeme für eine reibungslose Verzahnung beider Auftragnehmer wichtig. 6.1 EINBINDUNG VON QUALITÄTSMANAGEMENTELEMENTEN Scrum regelt nicht den Fluss der Aufgaben innerhalb des Projektes. Es wurde jedoch gezeigt, dass eine Betrachtung der Arbeitsschritte den Prozessablauf optimieren kann. Um Verschwendung im Projekt zu minimieren und eine Grundlage für die Optimierung der Durchlaufzeiten zu schaffen, sind zur agilen Softwareentwicklung passende Qualitätsmanagementansätze einzubringen. Wie bereits dargelegt, eignen sich modellbasierte Qualitätsmanagementansätze nur bedingt für die agile Softwareentwicklung, kontinuierliche Ansätze sind ihnen vorzuziehen. Bei den kontinuierlichen Ansätzen gibt es viele verschiedene Modelle, wie TQM und Six Sigma. Je nach Projektgröße und Kritikalität kann der geeignete Ansatz umgesetzt werden. Da agile Projekte meist im kleineren Rahmen durchgeführt werden, ist der Aufwand für die Einführung eines großen Modells zu hoch. Aus diesem Grund wird im 70

75 6.1 EINBINDUNG VON QUALITÄTSMANAGEMENTELEMENTEN Folgenden kein konkretes Qualitätsmanagementmodell verwendet, vielmehr stehen eine kontinuierliche Prozessverbersserung und eine Zusammenarbeit von Entwicklern und Management, basierend auf wenigen aussagekräftigen Kennzahlen im Fokus. Dass die Praktiken von Lean Manufacturing gut in das agile Umfeld passen, wurde in Kapitel 3.2 dargestellt. In den letzten Jahren gab es unter der Bezeichnung Lean Development zunehmend Bemühungen, diese Praktiken in der Softwareentwicklung umzusetzen. Es wurde ein Vorgehen nach der TOC als wirkungsvolle Methode identifiziert, um den Durchsatz in der Softwareentwicklung zu optimieren. Folglich ist der Einsatz einer Methodik ideal, die sowohl aus dem Bereich Lean Development kommt als auch TOC unterstützt. Passend dazu eignet sich Kanban, ein Vorgehen aus der industriellen Produktion, welches den Grundstein für Lean Manufacturing legte. Kanban wurde von David J. Anderson als Vorgehensmodell adaptiert und 2007 offiziell vorgestellt. Kanban gehört zum Bereich des Lean Software Development. [vgl. Epp11, S. 34f] Während Scrum einen Managementrahmen bietet, in dem die Entwicklung eigenverantwortlich stattfindet, optimiert Kanban die Zusammenarbeit der Teammitglieder und den Fluss der Aufgaben. Die beiden Methoden ergänzen sich sehr gut. Ansätze, die beide Techniken miteinander verbinden werden ScrumBan genannt. [ScrumBan] KANBAN UND SCRUM Scrum und Kanban besitzen viele Gemeinsamkeiten und lassen sich gut kombinieren. Während Scrum eine Management Methodik ist, die Teams einen Rahmen für selbstständiges Arbeiten bereitstellt, bringt Kanban eine Grundlage zur Optimierung des Prozessdurchsatzes sowie aussagekräftige Kennzahlen mit. [siehe KS10] Kanban begrenzt den Work in Progress (WIP) in einem System. Hierzu wird eine bestimmte Anzahl an Signalkarten in Umlauf gebracht. Jede Karte steht für eine Aufgabe. Erst wenn eine Aufgabe erledigt ist, wird die dazugehörige Karte aus dem System genommen und eine weitere kann hinzugefügt werden. Im Gegensatz zu den üblichen Push-Prozessen, handelt es sich bei Kanban um ein Pull-Prinzip. Die Aufgaben können nicht in das System geschoben werden, da eine Kapazitätsbeschränkung existiert. Die Aufgaben werden in das System gezogen, sobald wieder Kapazität vorhanden ist. [vgl. And10, S. 14/15] 71

76 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES In der Softwareentwicklung findet die Koordination mit Kanban über ein sogenanntes Kanbanboard statt. Es ähnelt dem Scrumboard und ist beispielhaft in Bild 6.1 zu sehen: Die Zahlen neben oder unter den Spaltentiteln zeigen die Kapazitätsgrenzen an. Die Höhe der Kapazitätslimits ist zu Beginn der Entwicklung zu bestimmen, kann vom Team jedoch nach Absprache geändert werden. Die Aufgaben werden auf Karten geschrieben. In "Todo" sind momentan drei von drei Tickets vorhanden, es kann folglich kein weiteres hinzugefügt werden. In der Entwicklung befinden sich drei von vier Tickets. Die Entwickler können also eine Karte von "Todo" in die Entwicklung übernehmen. Nur Teammitglieder, die eine Aufgabe bearbeiten, dürfen deren Status ändern. So darf kein Entwickler eine Karte von "Complete" in "Test" verschieben, dies darf nur der Tester, der die Aufgabe bearbeiten möchte. [vgl. And10, S. 87f] Eine gute Darstellung von Henrik Kniberg ist im Anhang 1 zu finden. ABBILDUNG 6.1: BEISPIEL FÜR EIN KANBANBOARD [ENTNOMMEN AUS KANBANBOARD] Diese Technik lässt sich sehr gut ergänzend zu Scrum einsetzen. Um erste Verbesserungen zu erreichen, genügt schon die Einführung eines WIP-Kapazitätslimits für die einzelnen Arbeitsschritte. Kommt es innerhalb des Prozesses zu einem Stau, wird dies sofort offensichtlich. Das ganze Team muss bestrebt sein, den Stau aufzulösen, da aufgrund der WIP- Begrenzungen nicht mehr weitergearbeitet werden kann. Auf diese Weise wird eine kontinuierliche Verbesserungsmentalität im Team angestrebt. Durch die hohe Transparenz ist sich jeder im Team bewusst, welche Auswirkungen handeln oder untätig bleiben haben können. Die Zusammenarbeit wird verbessert, da Probleme gemeinsam gelöst werden müssen, um weiter arbeiten zu können. Arbeit ohne Rücksicht auf nachgelagerte Arbeitsschritte 72

77 6.1 EINBINDUNG VON QUALITÄTSMANAGEMENTELEMENTEN durchzuführen, ist nicht mehr möglich, da bei Problemen das WIP-Limit erreicht wird. [vgl. And10, S. 57ff] Dieser Effekt ist für die nötige Zusammenarbeit von Entwicklern und externen Testern besonders wünschenswert. Aufgrund der räumlichen Distanz sind Techniken zur Transparenzerzeugung einzuführen. Kommt es während der Entwicklung zu Problemen, ist nun das gesamte Team gezwungen, näher zusammenzuarbeiten, während sich ein Teil des Teams einer Blockade sonst nicht bewusst geworden wäre. Es ist nicht mehr möglich, Probleme zu verschleppen. Dies steigert die Effizienz, da zuerst alles dafür getan werden muss, Aufgaben abzuschließen, bevor neue ins System gezogen werden können. Zusätzlich ist es für den Product Owner möglich, noch während des Sprints Veränderungen an den Prioritäten der Items im Sprint Backlog vorzunehmen. Die Karten werden während der Entwicklung nach Priorität ausgewählt, so dass sehr viel flexibler auf neue Bedingungen eingegangen werden kann. Je länger sich Aufgaben im System befinden, desto höher steigt ihre Priorität. Auf diese Weise ist es nicht möglich Aufgaben zu ignorieren oder zu vergessen. Die Karten von Kanban dienen nicht nur der Visualisierung, sondern lassen sich um viele Informationen erweitern. Neben einer eindeutigen ID der Anforderungen, einer Kurzbeschreibung sowie weiteren Informationen ist es möglich, Änderungen, Bearbeitungszeiten, Durchlaufzeiten und beteiligte Personen während des Prozesses zu erfassen. Diese Daten können am Ende einer Iteration ausgewertet werden und liefern viele Informationen über den Prozessablauf. Dies ermöglicht es dem Management, die Entwicklung zu beurteilen und unterstützt die Teammitglieder dabei, Verbesserungspotentiale zu erkennen und zu nutzen. [vgl. Epp11, S. 79] Des Weiteren sollten weitere Metriken aus dem Bereich der Produktqualität erhoben werden. Hier sollte sich vor allem auf die Anzahl der gefunden Fehler im Code bezogen werden. Es ist zu beachten, dass dies nicht geschieht, um die Qualitätssicherung zu beurteilen, sondern die Qualität des Produktes. Die initiale Qualität des Produktes ist ein wichtiger Faktor, eine hohe Fehleranzahl lässt auf Probleme während der Implementierung schließen. Hier ist auch die Art von Fehlern interessant, fehlgeschlagene Validierungen lassen auf unklare Anforderungen schließen. Metriken von der Testautomatisierung wie Anforderungs- oder Codeüberdeckung geben Aufschluss über die Aussagekraft der eingesetzten Testtechniken. Dabei wird gemessen, wie viele der gesamten Anforderungen oder des gesamten Codes von den Tests 73

78 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES abgedeckt wird. Werden nur 50 % der Anforderungen abgedeckt, sind die Tests nicht aussagekräftig, da die anderen 50 % fehlerhaft sein können. [vgl. CG09, S.73f] Durch die Einführung von Kanban in Scrum wird folglich ein sich selbst regulierender Prozess mit hoher Transparenz und aussagekräftigen Metriken implementiert. Zusätzlich wird das Entstehen einer Kultur der kontinuierlichen Verbesserung gefördert. Ansätze für Verbesserungen sind klar ersichtlich. Die Einführung von Veränderungen ist stark von der Unternehmenskultur abhängig. Agile Softwareentwicklung befürwortet jedoch eigenständiges Handeln der Mitarbeiter. Somit sollte das Team ermächtigt werden, auch während einer Iteration Änderungen am Prozess, am Kanbanboard oder anderen Aspekten der Entwicklung vorzunehmen. Das Management sowie weitere Stakeholder bekommen während der Sprint Retrospektive die Gelegenheit, sich zu äußern und Vorschläge zu unterbreiten. Funktioniert die Arbeit im Team nicht, müssen Eingriffe von außen erfolgen. Durch die Transparenz des Kanban-Boards können sich Außenstehende ständig informieren und notfalls reagieren. Für den ScrumMaster stellt es ein mächtiges Werkzeug zur frühzeitigen Aufdeckung von potentiellen Schwachstellen dar, auf die er im täglichen Stand-up Meeting direkt eingehen kann. Darüber hinaus ist es möglich, Praktiken von Lean Development, wie Eliminate Waste und Amplify Learning, in die Entwicklung einzubeziehen. Dieses Thema würde jedoch den Rahmen sprengen und wird nicht weiter betrachtet EINSATZ ZUR EINBINDUNG DER EXTERNEN SOFTWARE- QUALITÄTSSICHERUNG Um Kanban und Scrum zu vereinen, sind für die praktische Umsetzung einige Besonderheiten zu beachten. Dies bezieht sich vor allem auf die Gestaltung des Kanbanboards, dass auf die Bedürfnisse von Scrum sowie die Teilung der Entwicklung über zwei Unternehmen angepasst werden muss. Um Unterscheidungen auf dem Kanbanboard zwischen einzelnen Aufgaben und User Stories hervorzuheben, können verschiedene Farben und zusätzliche vertikale Zeilen eingesetzt werden. Aus Platzgründen ist die Anzahl der Zeilen so gering wie möglich zu halten. Es ist anzunehmen, dass die Arten unterschiedlicher Aktivitäten, wie Implementierung, Bug Fix, Testvorbereitung, die höchste Anzahl an Unterscheidungen bietet. Diese können nicht alle in Spalten 74

79 6.1 EINBINDUNG VON QUALITÄTSMANAGEMENTELEMENTEN dargestellt werden, dort sind nur die wichtigsten Funktionen zu finden. So kann die Aktivität Implementierung und Bugfix in der Spalte "Entwicklung" umgesetzt werden, ebenso geschieht dort die Testvorbereitung. Für die Art der Aufgabe ist dann die farbliche Unterscheidung zu wählen. Weitere Besonderheiten sind im Detail näher zu betrachten: Kanban wird in der Regel für die Entwicklung kleiner User Stories, wie sie beispielsweise in der Wartung vorkommen, verwendet. Daher stellt in Kanban eine Karte eine User Story dar. In Scrum werden die Feature im Sprint Planning Meeting zuvor in Tasks aufgeteilt, um bei größeren User Stories Aufgaben mit überschaubaren Aufwänden zu bekommen und eine bessere Arbeitsverteilung zu gewährleisten. Eine Aufgabe steht jedoch in keinem unmittelbaren Bezug zu der Anforderung des Kunden. Erst wenn alle Aufgaben zu einer Anforderung, bzw. User Story, umgesetzt wurden, ergibt sich ein Mehrwert aus der Entwicklung. Aus diesem Grund ist sicherzustellen, dass erst alle Tasks einer User Story abgearbeitet werden, bevor mit der nächsten User Story begonnen wird. Befinden sich mehrere User Stories zur selben Zeit in der Entwicklung, müssen diese visuell voneinander unterscheidbar sein. Dies kann durch farbliche Gestaltung der Karten oder durch Einführen von horizontalen Bereichen auf dem Kanbanboard geschehen. Da die farbliche Gestaltung für die Aufgabenart vorgesehen ist, wird im Folgenden eine horizontale Trennung bevorzugt. Ein weiterer Punkt ist die Testentwicklung. Das Erstellen von Testfällen und die Testfallautomatisierung finden gleichzeitig mit der Implementierung des Tasks statt. Hier ist es nötig, Nebenläufigkeit darzustellen. Für diesen Fall stellt Kanban bereits eine Lösung bereit. Wird eine Aufgabe entnommen, wird sie in zwei verschiedene Karten geteilt, eine für die Entwicklung und eine für die Testentwicklung. Die Trennung der Aufgabenbereiche können entweder farblich oder durch die Einführung einer weiteren horizontalen Ebene kenntlich gemacht werden. Nach Erledigung beider Teilaufgaben ist es möglich, die Karte wieder zusammenzuführen und in den nächsten Schritt zu übertragen. [vgl. And10, S. 82f] Auch hier wird eine horizontale Trennung auf Grund der Vorbelegung der Farben durch die Rollen und der benötigten expliziten Unterscheidung zwischen Entwicklung und Qualitätssicherung (zwei getrennte Unternehmen) genutzt. Fraglich ist die Rückführung von Bugfixes in das Kanban-System. Die einfachste Lösung ist, das Bugfixing direkt mit dem Testen zu verbinden. Sobald ein Fehler gefunden wurde, wird dieser behoben. Die Kanbankarte bleibt in diesem Fall für den 75

80 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES Bugfix in der Testspalte. Wenn der Fehler behoben und nachgetestet wurde, wird die Kanbankarte auf "Done" gesetzt. Dieses Vorgehen ist nur bei einfachen Fehlern und einem sehr eng zusammenarbeitenden Team möglich, da Fehler nicht transparent hervorgehoben und den Entwicklern direkt zugewiesen werden. Aus diesem Grund wurden Vorgehen entwickelt, bei denen Fehler wieder in das Kanban-System zurückgeführt werden. Die fehlerhafte User Story wird direkt in die Spalte für die Entwicklung gesetzt und durchläuft den Zyklus erneut. Mittels der Prioritäten ist eine schnelle Durchlaufzeit der Kanbankarten für die Fehlerbehebung gewährleistet. Schwierigkeiten entstehen hier bei der Rückführung der Karten, wenn die WIP- Limits der benötigten Spalten bereits voll sind. In diesem Fall müsste das WIP-Limit entweder gebrochen oder die Karte zurück ins Backlog geführt werden. [Kanbancard] Um dieses Problem zu umgehen, bietet es sich an, die Bugfixes außerhalb des regulären Ablaufs zu halten. Es wird eine weitere vertikale Linie für die Fehlerbehebung eingeführt. Die Karten können hier direkt abgelegt werden. Die Karte durchläuft weiterhin alle Phasen. Karten in der Zeile für die Fehlerbehebung sind mit höchster Priorität zu behandeln. So lange an dieser Stelle Aufgaben existieren, ist es verboten weitere Arbeit ins System zu ziehen. [Leanrework] Durch die weite Entfernung zwischen Qualitätssicherung und Entwicklung sollten Bugs so deutlich wie möglich hervorgehoben werden. Somit birgt die letztgenannte Lösung das größte Potential. Ein dediziertes Bug-Tracking-System, wie in Kapitel 5.2 beschrieben, ist trotzdem weiterhin nötig. Für Fehler, die nicht direkt behandelt, sondern auf einen späteren Sprint verschoben werden, ist die Möglichkeit zur langfristigen Dokumentation notwendig. Dies ist über das Kanbanboard nicht möglich. Für diese Fehler ist der Einsatz eines Bug-Tracking- Systems weiterhin empfehlenswert. In Bild 6.2 ist ein beispielhaftes Kanbanboard zu sehen, dass auf die Bedürfnisse von Scrum und der verteilten Entwicklung angepasst wurde: In den ersten beiden Spalten befinden sich die User Stories mit ihren Tasks in priorisierter Reihenfolge. Nach Auswahl einer User Story zur Bearbeitung wird diese mit all ihren Tasks nach "todo" verschoben, wo jede User Story eine eigene Zeile bekommt. Von "todo" ziehen sich die Bearbeiter ihre Tasks nach "Entwicklung". Die Unterscheidung zwischen Entwicklung der Applikation, in der Spalte "In Arbeit" und der Tests, in Spalte "Testentwicklung", ist gut ersichtlich untereinander angeordnet. Die Spalte "User Story Done" nimmt die User Story auf, nach dem alle Tasks umgesetzt wurden. In "Pre Test" wird der Vortest des Product 76

81 6.2 WERKZEUGE Owners durchgeführt. Er prüft, ob die User Story seiner Vorstellung entspricht. Nach dem "Pre Test" landet die User Story in "Test todo", von wo aus sich die Tester ihre Testaufträge entnehmen und nach "Test" verschieben. Der Bereich für die Bugfixes, die Zeile "Rework", wurde hervorgehoben in die Mitte gesetzt. Da in der Regel nur die Entwickler und Tester an der Fehlerbehebung beteiligt sind, wurden die wichtigsten Felder rot markiert. Dadurch wird verdeutlicht, dass Karten direkt von In Arbeit nach Test todo verschoben werden können. Die einzelnen User Stories sind mittels gestrichelter Linien von einander abgetrennt worden. Die Darstellung dient lediglich als Beispiel, die einzelnen Spalten sowie die WIP-Limits können je nach Projekt angepasst werden. ABBILDUNG 6.2: AN DIE GEGEBENHEITEN ANGEPASSTES KANBANBOARD 6.2 WERKZEUGE Durch das Arbeiten an verschiedenen Standorten nimmt die Gestaltung von Werkzeugen und Systemen einen hohen Stellenwert ein. Verschiedene Teilbereiche sind zu beachten, um die Entwicklung und die Qualitätssicherung zu verzahnen. Zum einen muss eine Auswahl von Werkzeugen für eine reibungslose und enge Kommunikation getroffen werden, zum anderen ist eine Auswahl von Werkzeugen zur Unterstützung der Entwicklung sowie des Entwicklungsprozesses nötig. 77

82 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES Es folgt eine Beschreibung der nötigen Werkzeuge und Systeme, die für einen reibungslosen Ablauf der Entwicklung erforderlich sind. Auf Grund des allgemeinen Charakters eines Entwicklungsmodells werden keine Empfehlungen für bestimmte Produkte abgegeben, da sich diese nach den besonderen Anforderungen des Projekts richten KOMMUNIKATIONSWERKZEUGE Die Bedeutung von Kommunikation für die agile Entwicklung findet sich schon in den Prinzipien des agilen Manifests. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. [agile_principle] In den vorherigen Kapiteln wurde gezeigt, dass für die Einbindung der externen Software- Qualitätssicherung in die agile Entwicklung eine reibungslose, entfernungsunabhängige Kommunikation essentiell ist. Zusätzlich ist Wartezeit ein Kostenfaktor. Die Zeit, in der auf die Antwort einer Person gewartet oder die für die Initialisierung des Gesprächs benötigt wird, ist nicht produktiv. So kann es passieren, dass der Mitarbeiter anfängt, mit Annahmen zuarbeiten, da er den Kommunikationsaufwand scheut. [vgl. Coc02, S.77 f ] In Bild 6.3 sind die verschiedenen Kommunikationswege dargestellt, erweitert um Kollaborationswerkzeuge von Microsoft, die zur Unterstützung eingesetzt werden können. Hering und Rees haben in einer Studie gezeigt, dass Technologie ein hohes Maß an Kommunikation und Zusammenarbeit über verschiedene Standorte hinweg ermöglichen kann. [vgl. HR01] Die Werkzeuge dienten dabei verschieden Zwecken, von einem entfernten Meeting, über verteilte Kommunikation bis zur Teilung der Artefakte zwischen den Teammitgliedern. Für die Auswahl der Werkzeuge sind die Anzahl der gleichzeitigen Nutzer, die Antwortzeit und die Kommunikationsrichtung von Bedeutung. [vgl. Eck09, S. 78] Für jeden benötigten Zweck ist das geeignete Werkzeug auszuwählen. Je nach Entfernung des Teams wird ein Werkzeug zum Abhalten von Meetings benötigt. Sitzen die Teams an weniger weit entfernten Standorten, ist ein persönliches Treffen vorzuziehen, da sich mit persönlicher Kommunikation eine bessere Zusammenarbeit erzielen lässt. 78

83 6.2 WERKZEUGE Bei entfernter Kommunikation ist nicht unbedingt eine visuelle Verbindung nötig, da diese kaum mehr Informationen beisteuert als ein rein auf Audio ausgelegtes Gespräch. Für diesen Zweck gibt es eine Vielzahl von Werkzeugen (Skype, NetMeeting, Adobe Acrobat Connect Professional). Auch die Telefonie kann für diesen Zweck zum Abhalten von Telefonkonferenzen genutzt werden. ABBILDUNG 6.3: VERGLEICH VON KOMMUNIKATIONSWERKZEUGEN [AUS HR01] Auch für die direkte Kommunikation zwischen zwei Teammitglieder bietet sich die Telefonie an. Ein Nachteil von ad hoc Anrufen ist jedoch, dass die Erreichbarkeit des anderen Teammitglieds nicht zuvor erkannt werden kann. Zusätzlich stellt ein Anruf immer eine garantierte Unterbrechung für den anderen dar. Er kann nur durch ignorieren des Anrufs signalisieren, dass er nicht gestört werden möchte. Für den täglichen Arbeitsgebrauch bietet sich daher Instant Messaging an. Zum einen ermöglicht es einen Zustand von presence and awareness. [siehe HR01] Die Verfügbarkeit der anderen Teammitglieder ist sofort ersichtlich und ihre Präsenz wird wahrgenommen. Durch Statusänderungen können sie signalisieren, ob Störungen erwünscht sind oder sie sich in einer intensiven Arbeitsphase befinden. Außerdem bieten Instant Messenger weitere Funktionen für Gruppenchats oder VOIP Gespräche. So lassen sich zusätzliche Informationskanäle öffnen. Instant Messaging unterstützt informelle Kommunikation die face-to-face Gesprächen ähnelt. Die Hemmschwelle zum Beginn einer Konversation wird gesenkt und ein Vertrauensverhältnis zwischen den Teammitgliedern geschaffen. [NWB00] 79

84 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES Die zuvor genannten Kommunikationsmittel laufen synchron ab, die beiden Teilnehmer stehen zeitgleich in Verbindung. Für die asynchrone Kommunikation hat sich der - Verkehr etabliert. Die birgt jedoch mehrere Nachteile. Bei s kommt es schnell zu einer -Flut. Das Medium wird nicht nur zum Versand essentieller Informationen gebraucht, sondern auch für viele unwichtige Informationen. So kann es passieren, dass E- Mails über einen Verteiler verschickt werden, von dem sich nur wenige für den Inhalt interessieren. Dies führt dazu, dass das Interesse an s sinkt und wichtige s nicht mehr gelesen werden. Genauso kann es in s zu interessanten Diskussionen kommen, diese sind später jedoch nur noch schwer nachzuvollziehen und sollten daher in Kollaborationsplattformen geführt werden, auf denen sie für alle Mitglieder zugänglich sind. [vgl. ECK09, S. 82] Für den Verkehr sind klare Richtlinien zu schaffen, um dieses Medium nicht zu überlasten. In agilen Projekten sollte die synchrone Kommunikation vorgezogen und wichtige Informationen in transparenten Kollaborationsplattformen statt in geschlossenen s festgehalten werden. Die bekannteste Kollaborationsplattform ist das Wiki. Eine Wiki ist eine Server-Software die Benutzern erlaubt, eine Webseite zu editieren. Sie unterstützt Links zwischen verschiedenen Seiten. Dadurch können Nutzer Informationen aus dem Wiki entnehmen oder neue hinzufügen. Ein für alle zugänglicher Informationssammelpunkt entsteht. [WIKI] Bei Wikis lässt sich jedoch nicht zeitgleich an einem Artefakt arbeiten. Es gibt Werkzeuge, die das zeitgleiche Arbeiten an einem Artefakt ermöglichen. Verbunden mit Audiounterstützung bietet sich ein sehr mächtiges Werkzeug, das die Zusammenarbeit zwischen zwei Standorten intensivieren kann. Eine Vielzahl von Werkzeugen stellt bereits virtuelle Whiteboards zur Verfügung. Anbieter von Office-Anwendungen bieten diese meist auch mit der Möglichkeit für kollaboratives Arbeiten an. [vgl. Eck08, S. 83/84] Es bietet sich folglich eine große Anzahl von Werkzeugen an, um die Zusammenarbeit über die verschiedenen Standorte zu gestalten. Wichtig ist die Auswahl des geeigneten Werkzeugs für das geplante Einsatzgebiet. Das beste Werkzeug nützt jedoch nichts, wenn es von den Teammitgliedern abgelehnt oder falsch genutzt wird. Es ist nötig, Anreize zur Kommunikation zu setzen. Hier sollte der Scrum Master mit gutem Beispiel vorangehen und die Nutzung der Kommunikationswerkzeuge vorantreiben. 80

85 6.2 WERKZEUGE TASKMANAGEMENT Damit das Kanbansystem funktioniert, ist ein gutes Kanbanboard essentiell. Es gibt verschiedene Ansätze, ein Kanbanboard über verschiedene Standorte hinweg zu nutzen. Hierbei wird insbesondere zwischen einem physischen und einem virtuellen Kanbanboard unterschieden. Bei einem physischen Kanbanboard wird es wie bei einem stationären Team üblich auf einem Whiteboard aufgezeichnet und mit Kanbankarten versehen. Die Karten werden von den Teammitgliedern vor Ort verschoben und mit dem jeweils anderen Kanbanboard am entfernten Standort synchronisiert. So können sie sich das aktuelle Kanbanboard jederzeit ansehen, müssen jedoch darauf achten, es regelmäßig zu aktualisieren. [vgl. And10, S. 97] Diese Variante ist sehr einfach umzusetzen. Sie bietet den entfernten Teams jedoch nur begrenzte Möglichkeiten, mit dem Board zu arbeiten, da der Stand nicht immer aktuell ist. Des Weiteren müssen Kennzahlen für jeden Task manuell erfasst werden. Nähere Informationen zu den Tasks sind noch einmal digital zu speichern, da nicht direkt auf die physischen Karten der anderen Seite zugegriffen werden kann. Transparenz bezüglich Änderungen an den Karten gibt es nicht, da keine Änderungshistorie existiert. [richhewlett] Um diesen Problemen entgegenzusteuern, bieten sich virtuelle Kanbanboards an. Virtuelle Kanbanboards sind meist Webapplikationen, die sich über das Internet von beliebigen Standorten aus aufrufen lassen. Neben den Funktionen eines physischen Kanbanboards können auf einem virtuellen viele zusätzliche Funktionen umgesetzt werden. Der Zugriff erfolgt von jedem Standort in gleicher Weise. Kanbansysteme gibt es in unterschiedlichen Größen. Während für ein kleines Projekt eine einfache Open-Source Anwendung ausreicht, können für komplexe Projekte umfangreiche Systeme mit großem Funktionsumfang benutzt werden. Um das Qualitätsmanagement zu unterstützen und die Mitarbeiter zu entlasten, ist eine automatisierte Erfassung aller Kennzahlen zu den Karten wünschenswert. So sollte festgehalten werden, zu welchem Zeitpunkt einzelne Karten verschoben wurden, wann sie bearbeitet oder aktualisiert wurden und wie lange sie sich im System befanden. Welcher Mitarbeiter explizit für welche Karte zuständig war, ist dabei nicht wichtig, da dies zu einzelnen Schuldzuweisungen führt und die Ergebnisse Spannungen im Team hervorrufen können. Eine höhere Akzeptanz ist bei anonymisierter Datenerhebung zu erwarten. In der agilen Softwareentwicklung sind Aufgaben nicht klar einzelnen Personen zuzuordnen, da die Zusammenarbeit des Teams explizit gefordert wird. 81

86 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES Das gesamte Team ist für das Produkt verantwortlich. Im Fokus der Kennzahlen stehen daher die Identifikation von Engpässen und die Gewährleistung eines reibungslosen Ablaufs. ABBILDUNG 6.4: BEISPIEL EINES VIRTUELLEN KANBANBOARDS [SMARTQ] Eine Reportfunktion sowie eine Schnittstelle zur Anbindung weiterer Systeme sind nötig. Reporte geben dem Management einen guten Überblick über den Stand der Entwicklung. Für tiefgreifende Analysen müssen die erfassten Daten in Analysetools übertragen werden können. Hierfür sollten nach Möglichkeit Schnittstellen bereitstehen, um die Daten möglichst einfach zu übernehmen. Je nach Möglichkeit, die Anforderungen über das Kanbansystem zu verwalten, sollten zusätzliche Anforderungsmanagementsysteme für große Projekte oder eine Ticketverwaltung für kleine Projekte bereitstehen. Wichtig sind hier die Rückverfolgung von Änderungen sowie das Zusammenführen des Wissens aller Beteiligten QUALITÄTSMANAGEMENTWERKZEUGE Als ein Ziel des Qualitätsmanagements im Rahmen der Einbindung externer Qualitätssicherung in Scrum wurde die Sicherstellung der Prozessqualität identifiziert. Hierzu werden in der Regel Prozessmanagementsysteme eingesetzt. Diese dienen zum einen der Dokumentation des Prozesses, zum anderen unterstützen sie die Ausführung der Abläufe. Bei einem strikten Einsatz dieser Systeme bekommen die Prozessbeteiligten ihre Aufgaben über das Prozessmanagementsystem zugeteilt. [vgl. SN11, S. 27f] Dies lässt sich in einem agilen Projekt jedoch 82

87 6.2 WERKZEUGE nicht umsetzen, da sich die Teammitglieder ihre Aufgaben selbstständig aussuchen. Auch wird der Prozess nicht immer in der vorgegebenen Reihenfolge ausgeführt, kurzfristige Änderungen im Ablauf sind an der Tagesordnung. Ein umfassendes Prozessmanagementsystem, dass den Prozessfluss steuert wird daher nicht benötigt. Dennoch existiert ein dokumentierter, übergeordneter Prozess. Auch wenn dieser nicht bindend ist, sollte der Ist-Zustand abgeglichen und seine Abweichungen dokumentiert werden. Hierfür würde sich ein abgespecktes Prozessmanagementsystem eigenen, das nur zur Protokollierung des Ablaufs gedacht ist. Die hierfür erforderlichen Kennzahlen werden durch das Kanbansystem erhoben. Es werden dadurch jedoch nur grobe Prozessschritte, wie Implementierung oder Test, erfasst. Unterprozesse sowie die unternehmensübergreifende Kommunikation sind nicht Bestandteil der Erhebung. Hinzu kommt, dass die Übertragung der Kennzahlen aus dem Kanbansystem in ein Prozessmanagementsystem, zeitgleich mit ihrer Entstehung oder nachträglich inkrementell, speziell angepasste Software benötigt. Die Betrachtung des Prozesses über ein Prozessmanagementsystem ist somit sehr aufwendig in der Einführung und bietet nur einen geringen Mehrwert. Je nach Projekt sollte daher im Einzelnen darüber entschieden werden, ob die Einführung eines solchen Werkzeugs sinnvoll ist. In kleineren Projekten genügt eine regelmäßige Evaluierung des Prozesses mit allen Teammitgliedern. Um frühzeitig Engpässe zu erkennen, ist Kanban ausreichend ENTWICKLUNGS- UND TESTWERKZEUGE Zwei Werkzeuge sind für die Entwicklung von besonderer Bedeutung. Dies ist zum einen eine Versionsverwaltung für die kontinuierliche Codeintegration sowie die Nutzung eines Frameworks für die Testautomation. In einer Versionsverwaltung wird der Code der verschiedenen Entwickler zusammengeführt, so dass eine zentrale Sammelstelle des Quellcodes geschaffen wird. Gleichzeitig werden während der Zusammenführung die Kompatibilität der Stände geprüft und Konflikte gemeldet. Hier gibt es sowohl freie [SVN] als auch proprietäre Werkzeuge [IBM Rational Synergie]. Das benötigte Produkt kann je nach Umfang des Projektes ausgewählt werden. Wichtig ist die regelmäßige Nutzung des Werkzeugs. Umfangreiche Änderungen sind schwerer zu integrieren als viele kleine. Des Weiteren sind die Entwickler und Tester von einem aktuellen Stand abhängig. Sinnvolle Erweiterung der Versionsverwaltung ist eine Funktion zum automatischen Erstellen einer lauffähigen Applikation aus dem Quellcode. Dadurch bekommen Tester 83

88 KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES schnell Zugriff auf die aktuelle Version, ohne von den Entwicklern für den Build Prozess abhängig zu sein. Auch für die Testautomatisierung gibt es Werkzeuge in allen Größenordnungen und für jede Teststufe. Für Unittests ist JUnit [JUnit] ein verbreitetes Werkzeug aus der Java Welt, für die überwiegenden Programmiersprachen gibt es ähnliche Umsetzungen, meist als Open Source. Bei der Automatisierung von Systemtests, insbesondere bei der Oberfläche, gibt es Implementierungen für alle Komplexitätsstufen. Für die Webentwicklung haben sich Selenium [Selenium] als auch Watir [Watir] als freie Werkzeuge etabliert. Im kommerziellen Bereich ist das HP Quality Center [HP Quality Center] stark vertreten, welches Tests auf allen Oberflächen unterstützt. Als Bug-Tracking-Systeme sind sowohl der Mantis Bug Tracker [mantis] als auch Bugzilla [bugzilla] weit verbreitet. Zudem können auch Ticketsysteme wie Trac [trac] zu diesem Zweck genutzt werden. Wichtig ist, dass die Fehler nach Kritikalität priorisiert werden können. Auch hier hängt die Auswahl des Werkzeugs von Umfang und Komplexität des Projektes ab. Zusätzlich sind die Qualifikationen der Mitarbeiter zu beachten. 6.3 ZUSAMMENFASSUNG Zur Unterstützung von Scrum wurde Kanban eingeführt. Zwischen Scrum und Kanban gibt es mehrere Synergieeffekte, da Scrum einen Managementrahmen bereitstellt und Kanban für eine Regulierung des Durchflusses sorgt. Die beiden Methoden lassen sich gut miteinander kombinieren. Durch den Einsatz von Kanban wird eine enge Zusammenarbeit der beteiligten Standorte erzwungen. Es sorgt für eine hohe, standortübergreifende Transparenz und ermöglicht die Ermittlung von Kennzahlen. Das inkrementelle Vorgehen von Scrum bleibt jedoch erhalten und bietet einen Managementrahmen. Um Kanban für Scrum und den Einsatz externer Qualitätssicherung zu optimieren, wurde ein spezielles Kanbanboard entworfen. Die Entwicklung und die Testvorbereitung sind dabei in zwei Zeilen unterteilt worden. Für die Fehlerbehandlung ist eine weitere Zeile eingeführt worden, die einen Schnelldurchlauf der fehlerhaften User Story ermöglicht. Gleichzeitig wurden die Möglichkeiten zur technischen Unterstützung des Entwicklungsprozesses betrachtet. Die benötigten Werkzeuge wurden vorgestellt und ihr Einsatzgebiet erklärt. 84

89 6.3 ZUSAMMENFASSUNG Für die Kommunikationswerkzeuge wurde Instant Messaging als Schwerpunkt identifiziert, welches einen Zustand von presence and awareness erzeugt. Des Weiteren ist die Werkzeugauswahl des Kanbanboards entscheidend für den Entwicklungsprozess, um die Akzeptanz zu erhöhen und Kennzahlen automatisiert erfassen zu können. Weitere Entwicklungsund Testwerkzeuge wurden vorgestellt. Scrum wird dennoch kaum verändert und ein agiles Vorgehen bleibt uneingeschränkt möglich. Die beschriebenen Elemente müssen nun in einen Entwicklungsprozess eingebunden werden. 85

90

91 7 GESTALTUNG DES SOFTWAREENTWICKLUNGS- PROZESSES Nachdem die Aufgaben auf die beteiligten Unternehmen aufgeteilt, die Qualitätsmanagementmethodik ausgewählt und die eingesetzten Werkzeuge und Systeme bestimmt wurden, wird nun der konkrete Entwicklungsprozess beschrieben. Die Darstellung erfolgt mittels einer Prozessnotation, auf der die ausführliche, schriftliche Beschreibung fußt. Abschließend werden die Regelungen bei Aktivitäten außerhalb des Prozesses dargestellt. 7.1 PROZESSMODELLIERUNG Wie in Kapitel 3 verdeutlicht, ist die Betrachtung von Prozessen ein wichtiger Bestandteil des Qualitätsmanagements. Dies geschieht im Prozessmanagement Es besteht aus drei Phasen, der Prozessabgrenzung, der Prozessmodellierung und der Prozessdurchführung. Während der Prozessabgrenzung entsteht der Prozess. Ausgehend von den unternehmerischen Anforderungen werden Prozesse für jedes Geschäftsfeld identifiziert und bewertet. Die zu modellierenden Prozesse werden abschließend ausgewählt. Die Prozessmodellierung bildet die Prozesse ab. Dabei kann eine Optimierung der bestehenden Prozesse oder eine völlige Neugestaltung entstehen. Während der Prozessdurchführung werden die Prozesse ausgeführt und ihr Erfolg an Messgrößen beurteilt. Je nach Ergebnis ist eine erneute Prozessmodellierung zu durchlaufen. [vgl. Gad10, S. 2f] Der zu implementierende Prozess ist bereits ausgewählt worden, ein Softwareentwicklungsprozess mit Scrum unter Berücksichtigung externer Qualitätssicherung. Nun ist die Aufgabe ihn zu modellieren um eine Grundlage für seine Ausführung zu bekommen und anhand von Messgrößen eine langfristige Optimierung zu ermöglichen. Prozessmodellierung ist die grafische Darstellung eines Prozesses unter Zuhilfenahme einer Notation, das Ergebnis ist das Prozessmodell. [vgl. SN11, S. 33] Verschiedene Notationen haben sich etabliert. Als die drei Bekanntesten sind die Ereignisgesteuerte Prozesskette (EPK), die Unified Modelling Language (UML) sowie die Business Process Model and Notation (BPMN) zu nennen. In Abbildung 7.1 sind die drei Notationen im Vergleich nach Interesse und Praxiserfahrung der Nutzer der Website bpm-netzwerk.de 87

92 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES aufgelistet. Im deutschen Raum am weitesten verbreitet ist die EPK. Ihr hauptsächliches Einsatzgebiet ist auf der Geschäftsebene. Durch ihre langjährige Verwendung ist das Interesse an der Sprache jedoch zurückgegangen. Die UML ist eine technikorientierte Sprache und für den Einsatz in der Geschäftsprozessmodellierung nur auf einem hohen Abstraktionsniveau geeignet. Die BPMN ist eine relativ junge Notation. Ihre Verwendung ist noch nicht so weit verbreitet wie bei der EPK, wird in neuen Projekten jedoch vermehrt eingesetzt. Da sie die Möglichkeit bietet, auf Geschäftsebene zu modellieren und trotzdem einen schnellen Einsatz auf der technischen Ebene und Unterstützung von Geschäftsprozessautomatisierung ermöglicht, ist das Interesse entsprechend hoch. Da BPMN in den letzten Jahren viel Potential erkennen ließ, sich zunehmender Beliebtheit erfreut und bei Bedarf in einer Process Engine ausgeführt werden kann, wird sie im Folgenden als Notation genutzt. ABBILDUNG 7.1: POPULARITÄT VON PROZESSNOTATIONEN [ENTNOMMEN AUS FR12, S. XIII] Zum besseren Verständnis des Prozessmodells werden die wichtigsten Elemente von BPMN kurz erläutert. Zur Vertiefung ist der Standard auf der Seite der Object Management Group (OMG) zu finden. [BPMN] Es gibt drei Flussobjekte: Aktivitäten, Gateways und Ereignisse. Ihre grafische Darstellung ist in Abbildung 7.2 enthalten. Die Aktivitäten beschreiben die Tätigkeiten, welche innerhalb des Prozesses durchgeführt werden. Es existieren zwei verschiedene Arten von Aktivitäten. Einfache Aktivitäten beschreiben nur die auszuführende Tätigkeit. Aktivitäten mit einem kleinen Kreuz sind zur 88

93 7.1 PROZESSMODELLIERUNG Übersicht zusammengefasste Unterprozesse. Sie lassen sich in Modellierungswerkzeugen expandieren und zeigen dann einen weiteren Prozess. Kommt es zu einer Verzweigung, bei der aus verschiedenen Tätigkeiten ausgewählt oder mehrere Tätigkeiten zusammengeführt werden, wird dies über Gateways gelöst. Das XOR-Gateway erlaubt nur die Ausführung einer einzigen Folgeaktivität, während beim AND-Gateway alle angeschlossen Aktivitäten ausgeführt werden. Das OR-Gateway lässt die Ausführung beliebiger Aktivitäten zu. ABBILDUNG 7.2: BASISELEMENTE DER BPMN Eine weitere Kategorie der Flussobjekte sind die Ereignisse. Sie sind auslösender oder beendender Natur. Unter anderem gibt es Nachrichten-, Zeit und Fehlerereignisse, mit denen Teile des Prozesses jeweils angestoßen oder beendet werden können. 89

94 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES Die Verbindung zwischen den Flussobjekten wird durch Sequenzflüsse hergestellt. Die Prozessbeteiligten einer Gruppe werden in einem Pool dargestellt. Weitere Gruppen, Abteilungen oder Bereiche können in zusätzlichen Pools dargestellt werden, zwischen denen es Kommunikation über Nachrichtenflüsse gibt. Der Pool wird für jeden Beteiligten in eine Lane unterteilt. Die Aktivitäten befinden sich in der Lane des für sie verantwortlichen Prozessbeteiligten. Zusätzlich kann das Prozessdiagramm um Datenobjekte und Artefakte erweitert werden. Diese sind an die jeweilige Aktivität anzuhängen. Das Prozessmodell für den Testprozess wird im Wesentlichen mit den in Abb. 7.2 gezeigten Elementen modelliert und dokumentiert. 7.2 PROZESS UND PROZESSMODELL In Abbildung 7.3 ist der Prozess in seiner niedrigsten Detailstufe zu sehen. Nachdem die Entscheidung zur Entwicklung gefällt und alle Ressourcen und Systeme zur Verfügung gestellt wurden, beginnt die Entwicklung. Im ursprünglichen Scrum ist die Pflege des Product Backlogs kontinuierlich und kann auch während des Sprints stattfinden. Dies ist möglich da nur der Kunde und der Product Owner daran beteiligt sind. Im neuen Prozess ist die Qualitätssicherung jedoch zusätzlich anwesend. Sie muss die Anforderungen aus erster Hand hören, um die Tests genauer gestalten zu können und ist zusätzlich für die Erstellung der Akzeptanzkriterien verantwortlich. Kontinuierliche Treffen während des Sprints sind für die externe Qualitätssicherung aufgrund der Entfernung und der Arbeitsbelastung im Sprint schwierig. Aus diesem Grund gibt es einen kontinuierlichen Prozess, in dem sich Product Owner und Kunde regelmäßig über die Anforderungen austauschen können. Die Ergebnisse notieren sie sich informell oder in einem separaten Backlog. Im ersten Schritt des Entwicklungsprozesses werden diese Informationen für die Erstellung des Product Backlogs herangezogen. Während laufend Anforderungen für das Product Backlog gesammelt werden können, findet dessen Pflege nun einmal pro Iteration statt. Nachdem das Product Backlog erstellt wurde folgt das Sprint Planning Meeting, in dem die einzelnen User Stories ausgewählt und in einzelne Tasks herunter gebrochen werden. Die ausgewählten Tasks sind die Grundlage für den Sprint, sie werden mit ihren User Stories in einem Sprint Backlog festgehalten. Bis zum Sprintende wird an den Aufgaben 90

95 7.2 PROZESS UND PROZESSMODELL aus dem Sprint Backlog gearbeitet. Nach dem Sprintende findet das Sprint Review zur Produktvorstellung sowie die Sprint Retrospective für die kontinuierliche Verbesserung statt. Ist das Produkt fertiggestellt, wird der Prozess beendet. Anderenfalls beginnt er mit der Pflege des Product Backlogs von neuem. Auf dieser Detailstufe ist kein Unterschied zum regulären Scrum zu erkennen. Die Abfolge der einzelnen Schritte erfolgt wie vorgeschrieben. Die einzelnen Rollen sind erst in den Unterprozessen erkennbar. ABBILDUNG 7.3: DARSTELLUNG DES GESAMTEN ENTWICKLUNGSPROZESSES Der geöffnete Unterprozess der Aktivität Pflegen des Product Backlog ist in Abbildung 7.4 zu sehen. Beteiligt sind hier der Product Owner, der Kunde und die externe Qualitätssicherung. Ziel ist es, das Product Backlog für das Sprint Planning Meeting vorzubereiten. Der Product Owner ist für den Prozess verantwortlich und führt durch die einzelnen Schritte. Der Product Owner beruft das Meeting ein. In dem Diagramm sind die Aktivitäten jeweils in der Lane des Verantwortlichen, die Gruppierung der Elemente signalisiert, dass alle Rollen an ihrer Ausführung beteiligt sind. Der Produktverantwortliche des Auftraggebers wird im folgenden als Kunde referenziert. Er beginnt das Meeting damit, seine Anforderung als User Story zu äußern. Dabei wird er vom Product Owner unterstützt. Ist es eine komplett neue User Story, muss der Kunde sie genau beschreiben. Haben alle die User Story verstanden, wird sie priorisiert. Die Priorisierung gibt wieder, wie dringend die Umsetzung der Anforderung ist. Ein Kriterium für 91

96 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES die Priorität kann der erwartete Mehrwert für den Kunden sein. Nach der Priorisierung identifiziert die Qualitätssicherung die Akzeptanzkriterien des Kunden. Hierdurch wird der Kunde gezwungen, sich noch einmal konkret mit seinen Wünschen auseinander zu setzen. Die Akzeptanzkriterien werden für den späteren Test genau dokumentiert. Abschließend erfasst der Product Owner die User Story und fügt die Akzeptanzkriterien bei. Dies wird solange wiederholt, bis der Kunde alle seine Anforderungen geäußert hat. Möchte der Kunde eine bestehende Anforderung ändern, werden die Korrekturen an User Story und Akzeptanzkriterien direkt eingetragen. Nach der Besprechung erfolgt die Aktualisierung des Product Backlogs durch den Product Owner. Es enthält nun alle aktuellen Anforderungen. ABBILDUNG 7.4: DARSTELLUNG DER PFLEGE DES PRODUCT BACKLOGS Nach dem das Product Backlog vollständig ist, folgt das letzte Meeting vor dem Sprint. In Vorbereitung für das Meeting legt der Product Owner die Sprintziele fest. Das Sprintziel stellt klar, was das erwartete Ergebnis des Sprints ist. Zusätzlich trifft der Product Owner eine Vorauswahl der Anforderungen für das Sprint Backlog. Das Sprint Planning Meeting wird vom Scrum Master moderiert, weitere Teilnehmer sind der Product Owner und das ScrumTeam, nach Möglichkeit vollständig mit externer Qualitätssicherung. Zu Beginn 92

97 7.2 PROZESS UND PROZESSMODELL des Meetings stellt der Product Owner das Sprintziel vor und diskutiert es mit dem Team. Sind alle mit dem Ziel einverstanden, werden die User Stories vorgestellt. Jede User Story wird in Tasks zerlegt und ihr Aufwand geschätzt. Abschließend wird das Kanban System durch das Anlegen der User Stories mit ihren dazugehörigen Tasks vorbereitet. Zu diesem Zeitpunkt werden auch die WIP Limits der einzelnen Spalten vom ScrumTeam gemeinsam mit Product Owner und Scrum Master festgelegt. Eine Veränderung der WIP Limits ist während des Sprints möglich. Um eine bessere Identifikation mit den Limits zu erreichen, sollte die Zahl jedoch möglichst verbindlich vom Team zu Beginn bestimmt werden. ABBILDUNG 7.5: DARSTELLUNG DES SPRINT PLANNING Das Kanbanboard entspricht dem von Abbildung 6.2 in Kapitel Es wird für diesen Prozess davon ausgegangen, dass das Kanbansystem selbstständig alle Metadaten zu dem Prozess sammelt. Dies bedeutet, dass zu einer Kartenbewegung gleichzeitig alle Zeitinformationen sowie die beteiligten Personen erfasst werden. Während des Meetings sind des Weiteren alle Aktivitäten der Software- Qualitätssicherung zu klären. Dies bezieht sich sowohl auf die konstruktiven als auch auf die analytischen Maßnahmen. Für die konstruktive Qualitätssicherung bieten sich regelmäßige Reviews der produzierten Artefakte an. Bei komplexeren Sachverhalten ist Pair Programming empfehlenswert. Für die analytische Qualitätssicherung mit ihren Softwaretests sollten auf jeden Fall Unit Tests durch die Programmierer durchgeführt werden. So wird schon früh eine Grundqualität in der Software sichergestellt. Nach einer Codeintegration lassen sich alle Unit Tests durchführen, um ungewollte Seiteneffekte auszuschließen. Dies ermöglicht der Qualitätssicherung, sich auf die neuen 93

98 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES Funktionalitäten zu konzentrieren. Für die externe Qualitätssicherung ist festzulegen, in wie weit die System- und Akzeptanztests zu automatisieren sind. Die Entscheidung hängt stark von der Größe des Projektes, der Komplexität der Software und der Reife der Anforderungen ab. Ist mit vielen Änderungen an der Software zu rechnen, wird der Bedarf an Nacharbeiten für die automatisierten Testfälle schnell sehr groß. Des Weiteren muss sich auf zu erfassende Metriken geeinigt werden. Die Metriken sollten aussagekräftig sein und aus verschiedenen Bereichen stammen. So geben Fehler pro 1000 Zeilen Code eine gute Auskunft über die konstruktiven Maßnahmen, während Code-Komplexität die Wartbarkeit der Software offen legt. Nach dem Sprint Planning Meeting kann der Sprint beginnen (Darstellung auf Seite 96 und 97). Da der Prozess den Durchlauf einer User Story beschreibt, wird das tägliche Daily Scrum nicht betrachtet. Es dient zum Austausch von Information und zur internen Koordination, bezieht sich jedoch nicht direkt auf die Umsetzung einer User Story. An dem Sprint sind drei Rollen direkt beteiligt. Der Product Owner gibt die zu entwickelnden User Stories vor und nimmt sie ab. Die Entwicklung implementiert die User Stories und behebt die Fehler. Die Qualitätssicherung testet die User Stories im Einzelnen und das Softwareprodukt im Ganzen. Zu Beginn des Sprints wählt der Product Owner eine oder mehrere User Stories aus. Die User Stories werden in der Spalte Sprint Backlog an die oberste Stelle gesetzt. Von dort aus entnehmen sowohl die Entwicklung als auch die Qualitätssicherung ihre Aufträge. Bei jeder Verschiebung einer Karte wird ein Service ausgelöst. Der Status innerhalb des Kanban Werkzeugs wird automatisch verändert und alle Metadaten vervollständigt und gespeichert. Es gibt jeweils Aufgaben für die Implementierung als auch für die Qualitätssicherung während der Entwicklung. Die Aufgaben der Softwareentwickler beschäftigen sich mit dem Design der Softwarearchitektur und der Implementierung der Funktionen. Die Tasks der Qualitätssicherung haben ihren Schwerpunkt auf der Testfallerstellung und Testautomatisierung. Die Entwickler und die Tester stimmen sich auf eine der vom Product Owner ausgewählten User Stories ab. Die zur User Story gehörenden Tasks werden in die Spalte todo gezogen. Von dort können die Teammitglieder ihre Aufgaben entnehmen. Die Entwickler ziehen sich ihre Kanbankarten in die Spalte In Arbeit und beginnen mit ihrer Umsetzung. Das Umsetzen eines Tasks beinhaltet die Implementierung sowie die 94

99 7.2 PROZESS UND PROZESSMODELL Sicherstellung einer ausreichenden Qualität durch zuvor festgelegte Maßnahmen wie Reviews und Unittests. Nach der Erfüllung der Aufgabe wird der Quellcode in das Gesamtsystem integriert. Zur Integration gehört das Ausführen aller Unittests, um Seiteneffekte auszuschließen. Fehler sind sofort zu beheben. Nach einer erfolgreichen Integration wird der Task zu Done verschoben. Dies wird solange wiederholt, bis alle Tasks einer User Story umgesetzt wurden. Ähnlich läuft es bei der Qualitätssicherung ab, mit dem Unterschied, dass hier keine kontinuierliche Integration stattfindet, da nicht am Produkt entwickelt wird. Das Speichern und Zusammenführen der Ergebnisse geschieht während der Umsetzung des Tasks. Durch das Kanbanboard und die Aufteilung in verschiedene Zeilen können die Qualitätssicherung und die Entwicklung parallel an unterschiedlichen Aufgaben einer User Story arbeiten, obwohl sie an unterschiedlichen Orten untergebracht sind. Der Fortschritt der User Story und die offenen Aufgaben für beide Seiten sind transparent und fördern ein Gefühl der Zusammengehörigkeit. Nach dem alle Tasks einer User Story umgesetzt wurden, wird die Software automatisch erstellt, so dass die aktuellste Version für die Tester zugänglich ist. Die Tasks werden gebündelt und unter der User Story zusammengefasst. Die User Story wird in die Spalte User Story Done verschoben. Entwickler und Tester beginnen mit der Arbeit an der nächsten User Story. Die Arbeit an der nächsten User Story wird von den Testern unterbrochen, wenn der Product Owner die vorherige zum Testen freigegeben hat. Selbiges zählt für die Entwickler, sobald Fehler gefunden wurden. Bevor umfangreiche Tests an der User Story vorgenommen werden, obliegt es erst dem Product Owner, alleine oder zusammen mit dem Kunden die fertiggestellte User Story zu überprüfen. Sie Testen nicht auf Fehler, sondern validieren, ob sich die Umsetzung mit den Anforderungen an das Produkt deckt. Sollten trotz Unittest Ausführungsfehler oder Änderungen aufgrund mangelnder Anforderungsumsetzung auftreten, können diese je nach Schwere direkt von den Entwicklern behoben oder als Fehlerkarte in die Zeile Rework des Kanbanboards abgelegt werden. Wird der Fehler direkt behoben oder tritt keiner auf, ist die Kanbankarte nach Test todo zu verschieben. 95

100 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES ABBILDUNG 7.6: DARSTELLUNG DES SPRINTS TEIL 1 96

101 7.2 PROZESS UND PROZESSMODELL ABBILDUNG 7.7 DARSTELLUNG DES SPRINTS TEIL 2 97

102 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES Die Tester müssen eine gute Balance zwischen Testvorbereitungsaktivität und dem Testen von User Stories finden. Bei einem hohen Anteil von automatisierten Testfällen wird mehr Zeit mit der Testvorbereitung verbracht, da die Testfälle während der Entwicklung zu automatisieren sind. Bei einem hohen Anteil an manuellen Tests nimmt die Testvorbereitung entsprechend weniger Zeit ein, dafür dauert die Testdurchführung länger. Die Tester wählen die User Story jeweils nach der höchsten Priorität aus. Meistens ist es die User Story, die am längsten in der Warteschlange steht. Kommt jedoch eine User Story hinzu, deren Priorität kurzfristig geändert wurde, kann diese schnellstmöglich getestet werden. Die User Story wird wie festgelegt getestet. Zwei Arten von Tests sind in der Regel durchzuführen. Auf der einen Seite die Tests der User Story selbst. Hier werden die neu implementierten Funktionen gegen die Anforderungen und Akzeptanzkriterien geprüft. Zusätzlich ist es noch nötig, mittels Regressionstest Seiteneffekte auf andere Module auszuschließen. Tritt ein Fehler auf, wird der Test sofort gestoppt und der Fehler an die Entwickler weitergereicht. Auch hier gibt es dazu zwei Möglichkeiten. Ist der Aufwand für die Fehlerbehebung gering und steht ein Entwickler zur Verfügung, sollte eine direkte Fehlerbehebung initialisiert werden. Mit der neuen Version sind die Tests direkt fortzusetzen. Lässt sich der Fehler nicht sofort beheben, ist eine Kanbankarte für die Spalte Rework zu erstellen, bevor der Test weitergeführt wird. Sind nach Abschluss der Tests offene Fehler in der Zeile Rework zu der User Story vorhanden, wird diese auch dort abgelegt. Sie wandert mit ihren Tasks durch die Spalten bis sie wieder bei den Testern ankommt. Existieren keine offenen Fehler, ist die User Story abgeschlossen und wird in der Spalte User Story Done abgelegt. Bei der Auswahl von Tasks haben die Aufgaben der Spalte Rework höchste Priorität. Sie gewährt einen schnellen Durchlauf für die User Story und ihre Tasks zur Fehlerbehebung. Auf dem Kanbanboard ist sie extra gekennzeichnet, um ihre Wichtigkeit hervorzuheben. Wurde die Story bereits vom Product Owner überprüft, wird dieser Schritt übersprungen und die Story direkt an die Qualitätssicherung weiter gereicht. Desto länger sich eine User Story im System befindet, desto höher wird ihre Priorität. Befinden sich nach mehrmaligem Testen noch Fehler in der User Story, ist ihre Priorität derart angestiegen, das ein sehr schneller Wechsel zwischen Qualitätssicherung und Entwicklung entsteht, 98

103 7.2 PROZESS UND PROZESSMODELL der nur in direkte Kommunikation münden kann, da sonst keine anderen Tätigkeiten mehr möglich sind. Zusätzlich begrenzen die WIP Limits die im Umlauf befindlichen Karten, so dass beide Unternehmen gemeinsam Engpässe beseitigen müssen, um weiter arbeiten zu können. Das Vorhaben, die Fehler einer User Story zu Aufgaben der nächsten User Story zu machen, wird so umgesetzt. Neue Tasks der aktuellen User Story dürfen erst ins System gezogen werden, wenn die Fehler der vorherigen User Story behoben worden sind. Der Prozess lässt die Grenzen zwischen den verschiedenen Aufgabengebieten der Unternehmen deutlich erkennen. Es herrscht trotzdem eine hohe Transparenz und eine enge Verbindung zwischen den Unternehmen, so dass ein Gefühl der Zusammengehörigkeit entstehen kann und die gute Zusammenarbeit gewährleistet wird. Nach dem Sprint findet, wie in Scrum vorgesehen, das Sprint Review statt, bei dem das Team gemeinsam mit ScrumMaster dem Product Owner und dem Kunden die Ergebnisse vorstellt (siehe Abbildung 7.8). Hier findet keine Veränderung vom regulären Vorgehen statt, die Anwesenheit der externen Qualitätssicherung ist nicht unbedingt nötig, würde jedoch zur Teambildung beitragen. ABBILDUNG: 7.8: DARSTELLUNG DES SPRINT REVIEW UND DER SPRINT RETROSPECTIVE Veränderungen werden in der Sprint Retrospective geplant. Ursprünglich dient sie auch der Prozessverbesserung, jedoch nur für ScrumTeam, ScrumMaster und Product Owner. Da der Prozess über mehrere Unternehmen an Komplexität gewonnen hat und für kritische Systeme ein besonderes Interesse an hoher Qualität besteht, fällt der Prozessverbesserung ein höheres Gewicht zu. Aus diesem Grund sind auch der Kunde sowie weitere Stakeholder aus dem Management der beteiligten Unternehmen anwesend. Die durch das Kanbanwerkzeug erfassten Daten und die erhobenen Metriken sind schon zuvor ausgewertet worden und stehen jedem Beteiligten zur Verfügung. Die Daten werden 99

104 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES gemeinsam besprochen. Das Team sowie das Management legen jeweils ihre Sichtweise über den Erfolg des vergangenen Sprints sowie zukünftige Verbesserungspotentiale dar. Dies kann zu völlig unterschiedlichen Ergebnissen aus dem jeweiligen Blickwinkel führen, da das Team seine Erkenntnisse direkt aus der Arbeit erhält, während das Management die Situation aus der Distanz beurteilt. So ist sowohl Praxisnähe als auch eine unabhängige Distanz gewährleistet. Nachdem die Sprint Retrospective abgeschlossen wurde, beginnt der Zyklus erneut mit dem Pflegen des Product Backlogs. 7.3 AUSNAHMEN UND INFORMELLE KOMMUNIKATION Der dargestellte Prozess stellt den idealen Durchlauf einer User Story da. Nicht alle in Kapitel 5.2 identifizierten Schnittstellen zu Kommunikation und Informationsaustausch sind abgedeckt. Insbesondere auf die Kommunikation von Team zu Product Owner und Kunde wurde nicht weiter eingegangen. Es wurde angenommen, dass keine weiteren Informationen von Kunde und Product Owner benötigt werden, da die User Story alle Beteiligten vollständig informiert. Dies ist in der Praxis jedoch meistens nicht der Fall. Aus diesem Grund existieren Konzepte wie On Site Customer. In Scrum wurde hierfür die Rolle eines Product Owner erstellt. Des Weiteren ist der Umgang mit Fehlern nicht immer klar, da nicht immer ein Bugfix im selben Sprint nötig ist. Die Entscheidung, wann eine Story fertig ist, obliegt letztendlich dem Product Owner. Folglich ist der Umgang mit verschiedenen Ausnahmen im Prozess sowie die Verbreitung wichtiger Informationen zu klären. Während des Designs und der Implementierung der Tasks oder der Vorbereitung der Testfälle zu den User Stories beschäftigen sich Entwickler und Tester zum ersten Mal intensiv mit den Anforderungen. Zu diesem Zeitpunkt können unklare Beschreibungen zu einem Informationsmangel führen. Ein Mitglied des Teams wird mit dem Product Owner in Verbindung treten und um Klarstellung bitten. Die aus dem Gespräch gewonnen Informationen können für das gesamte Team von Bedeutung sein. Würden die konkretisierten Anforderungen nicht mit dem Rest des Teams geteilt werden, können andere Teammitglieder zu eigenen, abweichenden Interpretationen der User Story kommen. 100

105 7.3 AUSNAHMEN UND INFORMELLE KOMMUNIKATION Aus diesem Grund sind zwei Aktivitäten durchzuführen. Die User Story und die zugehörigen Tasks sind um die konkretisierten Anforderungen zu erweitern. Dies sollte direkt an den Kanbankarten geschehen, bzw. im System, in dem die Anforderungen festgehalten werden. Um die Verbreitung der zusätzlichen Informationen zu gewährleisten und um die Teammitglieder nicht von ihrer Kernaufgabe abzulenken, sollte der Product Owner persönlich für die Verbreitung der Informationen sorgen. Da der Scrum Master das Team vor Änderungen der Anforderungen während des Sprints schützen muss, hat er jeden Eintrag des Product Owners zu prüfen und festzustellen, ob es sich um Konkretisierungen und nicht um Erweiterungen handelt. Folglich sind Product Owner und ScrumMaster gemeinsam für die Verbreitung der Informationen zuständig, der erstgenannte als Initiator und Dokumentator, der zweite als Kontrollinstanz. Wichtig ist, dass das System, in dem die Anforderungen festgehalten werden, sei es direkt das Kanbanwerkzeug oder eine externe Software, über eine Änderungshistorie verfügt. Es muss ersichtlich sein, welche Änderungen an der Anforderung vorgenommen wurden. Neben der Dokumentation der neuen Informationen sind alle Teammitglieder über die Anpassung der User Story in Kenntnis zu setzen. Dies sollte so früh wie möglich geschehen. Als Kommunikationswerkzeug bietet sich -Verkehr aufgrund seiner Asynchronität an. Der Product Owner muss sich nicht nur seiner Rolle als Vertreter des Kunden bewusst sein, sondern sich auch als Informationsvermittler für das gesamte Team verstehen. Durch die Trennung auf zwei Standorte und der Abwesenheit der Qualitätssicherung während des Daily Scrum ist diese weitere Funktion notwendig. Ein weiterer Zeitpunkt, an dem die Kommunikation mit dem Product Owner benötigt wird, ist die Beurteilung von Fehlern. Im Prozess wurde vereinfacht angenommen, dass jeder Fehler zu beheben ist und die nötigen Änderungen bekannt sind. Neben Fehlern, deren Behandlung einfach ersichtlich ist, existieren unklare Fälle. Den Testern können neben direkten Fehlern auch Unstimmigkeiten auffallen. Durch die Arbeit mit der Software während der Tests können zusätzlich Verbesserungsvorschläge entstehen. Diese müssen zum einen erst vom Product Owner gesichtet werden. Stimmt der Product Owner zu, muss er den Zeitpunkt der Einarbeitung bestimmen. Soll dies gleich 101

106 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES geschehen, sind sie wie Fehler zu behandeln und im Kanbanboard entsprechend einzutragen. Sollen die Fehler in einem späteren Sprint behandelt werden, sind sie in einem Bug-Tracking-System abzulegen. Dieselbe Prozedur muss mit Fehlern geschehen, die keine direkte Auswirkung auf die Funktionsweise der Software haben. Dies könnte zum Beispiel bei langen Antwortzeiten oder der falschen Anordnung von Elementen auf der Oberfläche der Fall sein. Die Akzeptanzkriterien können nicht zu der umgesetzten User Story passen, obwohl sie schon zuvor vom Product Owner abgenommen wurde. Hier ist eine Diskussion mit dem Kunden anzuregen, um zu klären, von wem die User Story falsch verstanden wurde. Die informelle Kommunikation zwischen den beiden Standorten wurde in den Prozess nicht aufgenommen. Zum einen kann diese jederzeit stattfinden, zum anderen ist es den Teammitgliedern überlassen, wie sie diese gestalten. Es ist jedoch wichtig, dass Absprachen, die weitere Mitglieder oder den ganzen Prozess betreffen, verteilt werden. Hier sind dieselben Kommunikationswege wie vom Product Owner zu nutzen. Die Kommunikation wird nicht weiter reguliert da die Teammitglieder, wie in agilen Teams üblich, frei zusammen arbeiten sollen. Neben der Kommunikation ist der Umgang mit Ausnahmefehlern im Bug-Tracking- System zu beschreiben. Die Spalte Rework des Kanbanboard dient als Bug-Tracking- System für Fehler, die unmittelbar zu beheben sind. Ein weiteres System ist für Fehler zu verwenden, deren Behebung nicht unmittelbar im Sprint geschehen muss. Die im Bug- Tracking-System abgelegten Fehler sind für alle ersichtlich. Die Tester können erkennen, ob ein gefundener Fehler schon zuvor gemeldet worden ist. Der Product Owner kann Fehler aus dem Bug-Tracking-System entnehmen und in das Kanbanboard überführen. Die Entwickler können jederzeit Fehler aus dem BTS beheben. Dies bietet sich an, wenn eine Funktion erweitert werden soll, für die zuvor schon Fehler eingetragen wurden. Das BTS ist vom Product Owner regelmäßig zu überprüfen. Dort abgelegte Fehler laufen Gefahr, vergessen zu werden. Ein weiterer Sonderfall ist die Beauftragung der externen Qualitätssicherung durch den Auftraggeber der Entwicklung. Dadurch ist die externe Qualitätssicherung nicht nur für die Prüfung der Software zuständig, sondern informiert den Kunden regelmäßig über den Stand der Entwicklung. Am Ende des Sprints hat die Qualitätssicherung das beste 102

107 7.4 ZUSAMMENFASSUNG Verständnis über die Qualität und Leistung der Software. Besonders bei kritischen Systemen ist die Bewertung der Reife von besonderer Relevanz. Der Einsatz der Software im Produktivsystem hängt davon ab. Der externen Qualitätssicherung kommt somit eine beratende Funktion hinzu. Sie kann vom Einsatz der Software nach einem Sprint abraten und den Kunden auf Probleme hinweisen. Dadurch kann der Kunde direkten Einfluss auf die Software nehmen. Unter anderem könnte er einen Release Sprint initialisieren, um die Software für die Auslieferung vorzubereiten. 7.4 ZUSAMMENFASSUNG Der Entwicklungsprozess wurde mittels BPMN modelliert. Durch die Modellierung ist der Prozess dokumentiert und kann einfach nachgeschlagen werden. Des Weiteren wird die Ausführung durch eine Prozess Engine ermöglicht. Die Dokumentation des Prozesses dient als Grundlage für die Optimierung in den folgenden Sprints. Der ideale Ablauf des Entwicklungsprozesses ist gut ersichtlich. Während in den von Scrum vorgesehenen Vorbereitungs- und Nachbereitungsbesprechungen wenige Veränderungen notwendig waren, ist der Sprint aufgebrochen worden. Es wurde gezeigt, dass trotz räumlicher Entfernung mittels des Einsatzes von Kanban eine enge Zusammenarbeit erzwungen wird. Durch die hohe Transparenz des Kanbanboards und die Beschränkung des WIP sind die beiden Auftragnehmer gezwungen, regelmäßig in Kontakt zu treten. Trotzdem lässt der Prozess unabhängiges Arbeiten zu. Die Schnittstellen der Unternehmen sind klar definiert, die Arbeiten überlappen sich an keiner Stelle. Das Vorgehen ist darauf ausgelegt, User Stories so schnell wie möglich abzuarbeiten. Hierzu wird ein schneller Wechsel zwischen Test und Fehlerbehebung implementiert. Die Bearbeitung weiterer User Stories ist erst durchgehend möglich, wenn die vorherigen um Fehler bereinigt wurden. Die intensive Prüfung durch die Qualitätssicherung, die in agilen Methoden verwendeten konstruktiven Maßnahmen und die Konzentration auf wenige Aufgaben zur gleichen Zeit ermöglichen eine hohe Softwarequalität. Doch nicht alle Aktivitäten wurden vom Standardablauf abgedeckt. Es kann Kommunikation auftreten, die Information mit Dokumentationsbedarf hervorbringt, wie z.b. zum besseren Verständnis von Anforderungen. Da dies meist ad hoc und auf verschiedenen Wegen geschieht, wird es hier nicht prozessual geregelt. Es wird jedoch verdeutlicht, was 103

108 KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES in diesem Fall zu geschehen hat. Auch der Einsatz eines Bug Tracking Systems und das Verhältnis der Qualitätssicherung zum Kunden wurden beschrieben. Mittels des Prozesses und unter Berücksichtigung seiner Ausnahmen ist es möglich, externe Qualitätssicherung in den agilen Softwareentwicklungsprozess, insbesondere Scrum, zu integrieren und Software mit hoher Qualität für den Einsatz in kritischen Bereichen herzustellen. 104

109 8 FALLBEISPIEL Nachdem der Entwicklungsprozess herausgearbeitet und verdeutlicht wurde, wird seine Anwendung in der Praxis gezeigt. Hierfür wird ein reales Projekt herangezogen, das durch den Prozess zu optimieren ist. Zuerst wird die Ist-Situation dargestellt und analysiert. Es werden die Probleme und Schwierigkeiten des aktuellen Vorgehens aufgezeigt. Davon ausgehend wird betrachtet, wie sich der Entwicklungsprozess einführen lässt und welche Verbesserungen zu erwarten sind. 8.1 DARSTELLUNG UND ANALYSE DES BEISPIELPROJEKTS Das Büro für praktische Informatik (BFPI) aus Wismar ist Auftragnehmer eines mittelständischen Unternehmens aus Hamburg, von mir bezeichnet als Wind AG (Name geändert), die im Windkraftbereich tätig ist. Über mehrere Jahre hinweg hat sich eine enge Geschäftsbeziehung entwickelt, durch die ein hohes Wissen über die Bedürfnisse des Kunden entstanden ist. Durch die Bereitstellung qualitativ hochwertiger Software sowie einer stabilen Termintreue hat die Wind AG viel Vertrauen in die Arbeit des BFPI gewonnen. Um die gleichen Resultate mit anderen Auftragnehmern zu erreichen, ist die Wind AG dazu übergegangen, das BFPI als externe Qualitätssicherung in Auftragsproduktionen hinzuzuziehen. Dabei steht insbesondere die Schaffung von Vertrauen in die eingekauften Softwareprodukte im Vordergrund, da diese in unternehmenskritischen Bereichen eingesetzt werden. Zusätzlich wird für interne Richtlinien ein unabhängiger Testbericht vor der Produktivsetzung gefordert. In einem jüngeren Projekt wurde ein Entwicklungsauftrag an einen Softwareentwickler aus Hamburg vergeben, die Entwicklung GmbH (Name geändert). Gefordert war eine Software zu Auswertung und Visualisierung von Betriebsdaten. Diese Daten dienen zum einen zur Verrechnung mit dem Kunden, zum anderen als Referenz bei der Entwicklung neuer Produkte. Sie ist somit kritisch für das Kerngeschäft des Unternehmens. Die Entwicklung GmbH benutzt Scrum zum Herstellen ihrer Softwareprodukte. Auch in diesem Projekt ist eine unabhängige Qualitätssicherung vom Kunden gewünscht worden. Vor Entwicklungsbeginn ist die Einbindung der Qualitätssicherung nicht durchgeplant worden, die entstandene Vorgehensweise hat sich während der Entwicklung herausgebildet. 105

110 KAPITEL 8: FALLBEISPIEL Da zum Entwicklungsbeginn die konkrete Vorgehensweise für die Einbindung der Qualitätssicherung noch nicht feststand, war diese nicht an den Planungsprozessen beteiligt. Die Entwicklung begann gemäß den Vorgaben von Scrum. Der Product Owner traf sich mit dem Kunden, um die Anforderungen aufzunehmen. Bei der Wind AG lag ein internes Dokument vor, indem das gewünschte Softwareprodukt grob beschrieben wurde. Dies ist der Entwicklung GmbH zur Verfügung gestellt worden und diente als Grundlage für die User Stories. Unklare Positionen sind mit dem Kunden abgesprochen worden, so dass manche User Stories von den Vorgaben der internen Spezifikation abwichen. Die erstellten User Stories ließen viel Interpretationsspielraum zu, der Product Owner musste dem Scrum Team regelmäßig Hilfestellung bei deren Umsetzung leisten. So wurde die Software mehrere Iterationen lang entwickelt, bis sie einen Stand erreicht hatte, an dem eine erste Produktivsetzung sinnvoll war. Erst zu diesem Zeitpunkt wurde die externe Qualitätssicherung hinzugezogen. Ihr wurde die interne Spezifikation sowie die Featurelisten mit den User Stories übergeben. Es gab keine nähere Einführung in die Thematik der Software. Aus den vorliegenden Artefakten wurden Testfälle abgeleitet. Die Testfälle sind in ein Open-Source Testmanagement System eingepflegt worden. Auf diese Weise hatte der Kunde direkten Zugriff auf die Testfälle. Sobald die Testfälle aus den vorliegenden Artefakten erstellt wurden, sind sie vom Kunden abgenommen worden. Hierbei sind schon einige Änderungen an den Anforderungen festgestellt worden, die in die User Stories und die Spezifikation noch nicht eingeflossen waren. Die Testfälle mussten mehrmals korrigiert werden. Nachdem die Testfälle abgenommen worden sind, wurde die Software an das BFPI übergeben. Diese installierte die Software in Eigenregie auf ihrem Testserver. Danach wurde mit dem Testen begonnen. Automatisierte Testfälle wurden von der externen Qualitätssicherung nicht erstellt, da dieser Aufwand nicht gerechtfertigt erschien. Während die Testergebnisse in dem Testmanagement System gespeichert wurden, sind parallel Tickets mit Änderungsaufgaben für die Entwickler in einem Ticketsystem der Wind AG angelegt worden. Die Entwickler der Entwicklung GmbH exportierten die Tickets aus diesem Ticketsystem in ihr eigenes Ticketsystem. Der Kunde wünschte einen Testbericht nach jedem Testdurchlauf. Dieser wurde aus dem Testmanagementsystem generiert. Die gefundenen Fehler wurden in den nächsten Sprints behoben. Sowie erneut eine auslieferbare Version erstellt worden ist, wurde geprüft, ob die Fehler korrekt behoben worden sind. 106

111 8.1 DARSTELLUNG UND ANALYSE DES BEISPIELPROJEKTS Zusätzlich mussten aufgrund der Implementierung weiterer User Stories neue Testfälle erstellt und ausgeführt werden. Zum Ende der Entwicklung waren die meisten User Stories umgesetzt und in den Sprints sind größtenteils Bug Fixes vorgenommen worden, bis schließlich nur noch Fehlerbehebung betrieben wurde, um das Produkt ausliefern zu können. Dieses Vorgehen brachte diverse Schwierigkeiten mit sich. Da die externe Qualitätssicherung nicht von Anfang an in die Planungsprozesse einbezogen wurden, ist nie ein konkreter Zeitpunkt zur Erstellung der Testfälle und Durchführung der Tests festgesetzt worden. Die Entwicklung setzte dadurch die für den Sprint geforderten User Stories um, jedoch nie mit der für eine Auslieferung erforderlichen Qualität. Als vom Kunden kurzfristig ein Termin für die erste Auslieferung zum Test gesetzt wurde, war dies sowohl für die Entwicklung als auch für die Tester problematisch. Die Entwicklung hatte bislang nicht auf eine Auslieferung hingearbeitet und musste nun die Software von bekannten Fehlern und offenen User Stories bereinigen. Die Tester hatten dadurch nur wenig Zeit, sich in die Anforderungen einzuarbeiten. Eine detaillierte Erklärung des Einsatzgebietes und der Anforderungen an die Software gab es nicht. Dadurch, dass die interne Spezifikation nicht weiter gepflegt wurde, sind viele Testfälle entstanden, die für die bestehende Software nicht gültig waren. Zudem sind durch die oberflächlichen User Stories auch sehr oberflächliche Testfälle entstanden, die viel Interpretationsspielraum zuließen. Da die externe Qualitätssicherung vom Kunden beauftragt und keine Kommunikation zum Product Owner oder den Entwicklern angeregt wurde sowie ein knapper Zeitrahmen bestand, hat keine tiefgreifende Kooperation zwischen den Auftragnehmern stattgefunden, während der die Anforderungen hätten konkretisiert werden können. Diese Situation erschwerte das Testen der Software. Es war nicht immer klar zu unterscheiden, ob es sich um einen Fehler handelte oder die Anforderungen an dieser Stelle von den Testern fehlinterpretiert wurden. Unnötig erstellte Fehlertickets verschlechterten die Beziehung zwischen Testern und Entwicklern zusehends. Die Entwickler hatten das Gefühl, dass die Tester ihre Arbeit nicht korrekt ausführten, während die Tester durch scheinbar grundlos abgelehnte Testfälle ihre Arbeit nicht gewürdigt sahen. Eine weitere Schwierigkeit entstand dadurch, dass die Installation der Software vom BFPI vorgenommen wurde. Bei der zu testenden Applikation handelte es sich um eine Webapplikation, für die eine aufwendige Konfiguration des Webservers erforderlich war. 107

112 KAPITEL 8: FALLBEISPIEL Durch unzureichende Installationsbeschreibung sowie die komplexen Einstellungen kam es zu Konfigurationsfehlern, die sich auf das Programm auswirkten. So entstanden Fehler, die von den Entwicklern auf ihren Systemen nicht nachvollzogen werden konnten. Die Identifikation der Probleme erforderte von beiden Seiten einen hohen Aufwand. Neben den durch die Anforderungen und die Testumgebung hervorgerufenen Problemen verkomplizierten die eingesetzten Systeme zusätzlich das Vorhaben. Durch die Trennung des Testmanagementsystems für den Kunden und das Ticketsystem für die Entwickler mussten Fehler und Anmerkungen an zwei unterschiedlichen Orten festgehalten werden. Dies erhöhte den Aufwand für die Qualitätssicherung bei der Erstellung der Testergebnisse und Tickets, als auch beim Nachtest, da die Einträge in beiden Systemen gesucht und ergänzt werden mussten. Wurden Informationen nur in einem der beiden Systeme festgehalten, bekamen diese entweder der Kunde oder die Entwickler nicht zu sehen, was jeweils zu einem falschen Eindruck über den Stand der Tests als auch der Qualität geführt hat. Zusätzlich bekamen die Entwickler nur negatives Feedback aus der Qualitätssicherung, da sie nur die Fehlertickets, jedoch nicht die bestandenen Testfälle sahen. Neben den genannten Schwierigkeiten blockierten die Mechanismen zur Fehlerbehebung die inkrementelle Auslieferung der Software zur Produktivsetzung komplett. Durch die zuvor beschriebenen Hindernisse und die Notwendigkeit, die Software komplett am Stück zu testen, dauerte die Testphase sehr lange, etwa die Dauer von 2 Sprints. Erst im dritten Sprint konnten die gefundenen Fehler behoben werden. Dies hatte zum einen zur Folge, dass Fehler bereits nicht mehr aktuell waren, da die Funktion, auf die sie sich bezogen, bereits geändert worden war. Zum anderen konnte die Software nach der Fehlerbehebung nicht produktiv gesetzt werden, da sich bereits neue Funktionalitäten von 3 Sprints in der Software befanden, die zuerst getestet werden mussten. Um auch Seiteneffekte abzudecken, wurden die Tests wieder entsprechend aufwendig, so dass sich die Fehlerbehebung verschob. Entsprechend entstand in keinem Inkrement eine Software, die getestet und von der Qualitätssicherung freigegeben wurde. Erst nachdem alle Anforderungen umgesetzt waren, wurde sich komplett auf die Qualität konzentriert. Dadurch ergab sich trotz der Nutzung eines agilen Vorgehensmodells kein frühzeitiger Return on Investment. Es konnte zwar sichergestellt werden, dass keine fehlerhafte Software in die produktive Umgebung eingespielt wurde, dafür ist eine frühzeitige Nutzung der Software jedoch komplett verhindert worden. Einer der großen Vorteile der agilen Softwareentwicklung 108

113 8.2 ANWENDUNG DES AUSGEARBEITETEN PROZESSES AUF DAS FALLBEISPIEL wurde durch den Einsatz externer Qualitätssicherung ausgeschaltet. Die mangelhafte Integration der Qualitätssicherung, das unzureichende Anforderungsmanagement, die ungenügende Nutzung von Werkzeugen und die nicht vorhandene Eintaktung des Testens in den Zeitplan führten zu erhöhten Aufwänden und einem schlechten Verhältnis zwischen Qualitätssicherung und Entwicklung. Um künftige Projekte mit größerem Erfolg abschließen zu können, muss die externe Qualitätssicherung besser in den Entwicklungsprozess integriert werden. Der zuvor ausgearbeitete Entwicklungsprozess wird daher im Folgenden auf das Projekt angewandt und beschrieben, wie das Projekt mit dem Vorgehen hätte ablaufen können. 8.2 ANWENDUNG DES AUSGEARBEITETEN PROZESSES AUF DAS FALLBEISPIEL Bei der Anwendung des Prozess in einem Projekt mit den genannten Rahmenbedingungen ist der Tatsache, dass die externe Qualitätssicherung durch den Auftraggeber hinzugezogen wurde, besondere Aufmerksamkeit zu schenken. Weder die Entwicklung, noch die Qualitätssicherung ist sich vor Testbeginn einander bewusst gewesen. Die Entwickler bekamen plötzlich das Gefühl, einer Überwachungsinstanz gegenüberzustehen, während die Tester von der Aufgabe, aus einer für ein agiles Vorgehen vorgesehenen Spezifikation Testfälle abzuleiten, frustriert wurden. Diese negative Situation zeigt deutlich, wie wichtig die frühzeitige Integration der externen Qualitätssicherung in die Entwicklung ist. Der Prozess sieht das erste Zusammentreffen mit dem Auftragnehmer während der Aufnahme der User Stories mit dem Product Owner und beim Sprint Planning mit dem Rest des Teams vor. Aufgrund der geringen Entfernung zwischen Hamburg und Wismar ist die regelmäßige Teilnahme an allen größeren Treffen möglich. Ein persönlicher Kontakt kann so früh hergestellt werden. Bei der Aufnahme der User Stories ist die Qualitätssicherung ein wichtiger Faktor. Die im Fallbeispiel aus der Spezifikation abgeleiteten User Stories waren ungenau. Durch die Forderung der externen Qualitätssicherung nach konkreten Akzeptanzkriterien sind die User Stories schon sehr viel genauer zu gestalten. 109

114 KAPITEL 8: FALLBEISPIEL Die Wind AG spezifiziert die benötigen Systeme intern. Die Spezifikation wird benötigt, um Gelder für die Entwicklung beantragen zu können. Solch ein Dokument diente als Grundlage für die User Stories. Dies sollte zwingend vom Product Owner als auch von der Qualitätssicherung vor dem Meeting durchgearbeitet werden. So könnten beide informiert in die Besprechung gehen und Fragen formulieren. Jede einzelne User Story würde besprochen und die Akzeptanzkriterien dabei definiert werden. Entstehen nun Abweichungen von der Dokumentation, ist die Qualitätssicherung direkt darüber informiert. Zusätzlich sollte das interne Dokument weiter gepflegt werden, damit es nicht zu Missverständnissen kommt, falls sich doch jemand an der Spezifikation orientiert. Aus der Perspektive der Qualitätssicherung ist es jedoch nicht mehr notwendig, da die User Stories über eine geeignete Aussagekraft verfügen. Die zweite große Besprechung ist das Sprint Planning Meeting. Hier werden die User Stories vorgestellt, in Tasks unterteilt und der Aufwand geschätzt. Außerdem trifft die externe Qualitätssicherung das erste Mal auf das ursprüngliche ScrumTeam. Da der Kunde die Einbeziehung der externen Qualitätssicherung gewünscht hat, sollte er auf jeden Fall anwesend sein. Des Weiteren wird die Unterstützung des Managements der Entwicklung und des ScrumMaster benötigt, um die Gründe hinter der Einbeziehung der Qualitätssicherung klarzustellen. Hierbei ist darauf zu achten, diese als positive Ergänzung für das Team hervorzuheben. Befürchtungen wegen vermuteter Nachteile für das Team sollten ausgeräumt werden. Vor dem Beginn des Sprints ist zudem das neue Vorgehen vorzustellen. Das Team ist in Kanban und die benutzten Systeme einzuführen. Dies kann während des Sprint Plannings oder in einem separaten Meeting geschehen. Sind noch viele offene Fragen zu klären, ist ein separates Meeting vorzuziehen. So sollte das Team und insbesondere die Qualitätssicherung ein Mitspracherecht bei den eingesetzten konstruktiven und analytischen Qualitätssicherungsmaßnahmen haben. Ein grobes Konzept sollte jedoch schon im Voraus erstellt werden, um eine Diskussionsgrundlage zu bekommen. Im Beispielprojekt sind bislang die kontinuierliche Integration sowie automatisierte Unittests als agile Praktiken benutzt worden. Für kritische Bereiche ist es sinnvoll, zusätzlich Pair Programming zu nutzen, um hier die Qualität gezielt zu erhöhen. Simple Design und Refactoring erhöhen die Wartbarkeit der Software und sind deshalb 110

115 8.2 ANWENDUNG DES AUSGEARBEITETEN PROZESSES AUF DAS FALLBEISPIEL wünschenswert. Wichtig ist, dass sich die Entwickler diesen Praktiken verschreiben, da sie keine Wirkung erzielen, wenn sie erzwungen werden. Im Fallbeispiel haben die Entwickler bislang automatisierte Unit- und Integrationstests durchgeführt. Die Aufgabe der Qualitätssicherung kann somit wie vorgesehen mit dem Systemtest beginnen. Bei der zu entwickelnden Software handelt es sich um eine Webapplikation. Die Automatisierung von Tests auf der Oberfläche lässt sich mit Werkzeugen wie Watir oder Selenium gut durchführen. Um die Wiederholbarkeit der Tests zu gewährleisten, sollten auch die Tests für die Oberfläche automatisiert werden. Seiteneffekte sind auf diese Weise einfach auszuschließen. Als Grundlage für die Testfallerstellung dienen die User Stories. Es liegt keine formale oder technische Spezifikation vor, aus der die Testfälle abgeleitet werden können. Die Tests sind daher mit funktionsorientierten Testtechniken zu erstellen und durchzuführen. Diese können von einer einfachen Äquivalenzklassenbildung bis zu Entscheidungstabellen und -bäumen reichen. Da die Testfälle sowohl für einzelne, verschieden komplexe User Stories, als auch übergreifend für das gesamte System zu erstellen sind, kann jeweils die geeignete Testart ausgewählt werden. Der Einsatz dedizierter Tester ermöglicht durch das vorhandene Wissen solch ein Vorgehen. Neben den Qualitätssicherungsmaßnahmen ist die technische Unterstützung des Prozesses zu planen. Hier muss ein Kanbanboard ausgewählt und der Umgang mit den bisherigen Systemen geklärt werden. Die bisher eingesetzten Systeme sind Open-Source. Da Anschaffungskosten nach Möglichkeit vermieden werden sollen, bis sich der Prozess bewährt hat, ist auch weiterhin freie Software zu verwenden. Freie Kanbanboards verfügen nicht über alle benötigten Funktionen. Während das Einfügen verschiedener Zeilen noch möglich ist, bleibt die automatische Erfassung und Auswertung von Zeiten den kostenpflichtigen Varianten vorbehalten. Das bisher verwendete Ticketsystem Trac [trac] verfügt jedoch über diese Funktion und lässt einen Export der erfassten Daten zu. Es lassen sich Status gemäß den Spalten im Kanbansystem definieren. Wird eine Karte im Kanbansystem verschoben, ist der Status des zugehörigen Tickets zu ändern, der Zeitpunkt wird automatisch erfasst. Außerdem verfügt es über eine gute Änderungshistorie und ein Wiki. Wird das Kanbansystem nur verwendet, um auf die User Stories und Tickets in einem gemeinsam verwendeten Trac-System zu verweisen, kann mit einer freien Variante ausgekommen werden, ohne große Einschränkungen hinnehmen zu müssen. 111

116 KAPITEL 8: FALLBEISPIEL An die Benutzung von Trac sind alle Projektbeteiligten bereits gewöhnt. Das Kanbantool dient nur noch der Referenzierung auf die Tickets, der Visualisierung und der Begrenzung des WIP. Um weiterhin die Testfälle zu verwalten, bietet sich fürs Erste die Weiterführung des Testmanagementsystems an. Auf lange Sicht ist es jedoch zu empfehlen, ein kommerzielles Werkzeug zu nutzen, das alle Funktionalitäten vereint und Tickets direkt mit ihren Testfällen verknüpft. Für die Kommunikation mit dem Kunden nutzen bereits die Qualitätssicherung als auch die Entwickler den Microsoft Office Communicator. Dieser bietet u.a. Funktionen für (Video-)Telefonie, Instant Messaging und Dateiaustausch. Es ist jeder Zeit ersichtlich, ob die Ansprechperson momentan am Platz ist und ob sie für ein Gespräch zur Verfügung steht. Als Werkzeug für die kontinuierliche Integration ist Subversion [SVN] in beiden Unternehmen im Einsatz. Es kann zum Speichern des Quellcodes des Softwareprodukts und der automatisierten Tests verwendet werden. Mittels eines Skripts lassen sich die Applikationen erstellen und im Webserver bereitstellen. Das Skript kann sowohl von den Testern als auch von den Entwicklern aufgerufen werden. So ist sichergestellt, dass den Testern immer die neueste Version zur Verfügung steht. Die technische Unterstützung des Entwicklungsprozesses kann somit mit kostengünstigen Mitteln sichergestellt werden. Für die langfristige Optimierung des Prozesses sind Kennzahlen und Metriken auszuwählen. Auch der Auftraggeber ist an einer Auswertung interessiert, die den erhöhten Aufwand durch den Einsatz einer externen Qualitätssicherung rechtfertigt. Durch die erhobenen Daten im Trac kann genau ermittelt werden, wie viele Kanbankarten zu welchem Zeitpunkt im System waren. So können durchschnittliche Liegezeiten in den einzelnen Spalten abgeleitet und Engpässe identifiziert werden. Anhand der Art der Tickets lässt sich erkennen, wie die Kommunikation zwischen Qualitätssicherung und Entwicklung verläuft. Handelt es sich um viele kleine Tickets, die auch auf informelle Weise schnell behoben werden können, besteht kein direkter Kontakt. Entstehen Fehler durch unterschiedliche Interpretationen von User Stories, weist dies auf ein Problem mit der internen Informationsverteilung hin. Die unterschiedlichsten Interpretationen der Daten sind möglich und je nach Bedarf anzuwenden. 112

117 8.3 ZUSAMMENFASSUNG Für den Auftraggeber sind Metriken wichtig, die die Wirksamkeit der Qualitätssicherung belegen. So sollte erfasst werden, wie viele Fehler während der Tests auftreten. Auch über informelle Wege weitergegebene Fehler zählen dazu. Zudem sollten die Fehler in verschiedene Kategorien eingeteilt werden, um zu bewerten, ob diese im Produktivsystem zum Problem geworden wären. Sind nur wenige Fehler im System identifiziert worden, scheint der Auftragnehmer für die Entwicklung ausreichende Qualität abzuliefern und die Einbindung der externen Qualitätssicherung kann in Frage gestellt werden. Befinden sich jedoch sehr viele Fehler im System, ist bei den Entwicklern zu eskalieren und für eine stärkere konstruktive Qualitätssicherung zu sorgen. Die Maßnahmen der analytischen Qualitätssicherung sind gegebenenfalls noch zu erhöhen, um bei Mängeln der Entwicklung konsequent gegensteuern zu können. Da sich alle Bedingungen für den Entwicklungsprozess erfüllen lassen, kann er wie beschrieben eingeführt werden. Dies gibt jedoch keine Garantie, dass der Prozess von allen Beteiligten angenommen wird. Hier ist besonders der ScrumMaster gefragt, die Entwickler und Tester im Auge zu behalten und notfalls einzugreifen. Durch die Transparenz des Kanbanboards können Probleme im Prozess frühzeitig von ihm erkannt werden. Zum Ende eines jeden Sprints sollte nach Einführung der hier beschriebenen Maßnahmen eine lauffähige Software zur Verfügung stehen. Der Auftraggeber kann nach jedem Sprint einen Testbericht verlangen und auf Anraten der Qualitätssicherung darüber entscheiden, ob die momentane Version in eine Produktivumgebung übergeführt werden kann. Alternativ können auch nach mehreren Sprints Releasesprints durchgeführt werden, damit nicht so häufig Testberichte anfallen und sich das Team in den übrigen Sprints mehr auf die Entwicklung konzentrieren kann. Für die Sprint-Retrospektive ist die Anwesenheit der Qualitätssicherung wieder erforderlich. Alle Projektbeteiligten entscheiden zusammen über das weitere Vorgehen. Da sich die Entwickler und die Tester das erste Mal seit dem Sprint Planning wieder begegnen, können sie gemeinsam über den vergangenen Sprint reflektieren. 8.3 ZUSAMMENFASSUNG Die Probleme, die eine mangelhaft integrierte externe Qualitätssicherung in einem agilen Softwareentwicklungsprozess mit sich bringt, wurden anhand eines Fallbeispiels 113

118 KAPITEL 8: FALLBEISPIEL beschrieben. So stieg der Arbeitsaufwand stark an und auf Grund langer Test- und Fehlerbehebungsdauern konnten keine Zwischenprodukte ausgeliefert werden. Die Sprintziele wurden nicht erreicht, die Entwicklung nur mit Mühe abgeschlossen. Durch geeignete Maßnahmen wurde anschaulich gezeigt, auf welche Weise die Rahmenbedingungen für den Entwicklungsprozess geschaffen werden können, so dass eine Einführung des ausgearbeiteten Entwicklungsprozesses möglich ist. Die verwendeten Systeme sind hauptsächlich Open-Source und frei verfügbar. Es wurde dargestellt, dass ohne erheblichen Mehraufwand der hier umgestaltete Entwicklungsprozess effizient und lauffähig in die Praxis umgesetzt werden kann. 114

119 9 SCHLUSSBETRACHTUNGEN 9.1 ZUSAMMENFASSUNG Als Zielsetzung der vorliegenden Master Thesis wurde die Schaffung eines unternehmensübergreifenden agilen Softwareentwicklungsprozesses für unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung gesetzt. Das Thema ist systematisch erschlossen worden. Es wurde in die Theorie eingeführt, um die Grundlagen für die Entwicklung des Prozesses zu schaffen. Aufbauend auf den Grundlagen sind die benötigten Aspekte herausgearbeitet worden. Abschließend wurde der Prozess samt Randbedingungen erstellt und an einem Fallbeispiel angewandt. Konventionelle und agile Vorgehensmodelle wurden betrachtet. Die Unterschiede zwischen den beiden Modellen sowie deren Einsatzschwerpunkte wurden dargestellt. Als agiles Referenzmodel ist Scrum aufgrund seiner geringen Einschränkungen gut geeignet. Das Team verwaltet sich innerhalb eines Managementrahmens selbst, es bestehen noch keine Vorgaben, die die Einbindung einer externen Qualitätssicherung verhindern können. Die Vorgehensweise von Scrum ist erklärt und seine Eigenheiten sind dargestellt worden. Um die Qualität langfristig zu erhöhen, wurde die Einführung von Qualitätsmanagement in agile Vorgehensmodelle betrachtet. Dazu wurden die beiden unterschiedlichen Qualitätsmanagementansätze, modellbasiertes und kontinuierliches Qualitätsmanagement, betrachtet. Bezüglich ihrer Eignung zum Einsatz mit agiler Softwareentwicklung ist ein höheres Potential bei den kontinuierlichen Methoden ausgemacht worden. Während modellbasierte Ansätze die Selbstverwaltung des Teams einschränken, ist für kontinuierliche Ansätze durch die kurzen Iterationen und die Sprint Retrospective bereits ein Grundstein gelegt. Neben den prozessorientierten Maßnahmen des Qualitätsmanagements liegt in der Softwareentwicklung ein Schwerpunkt auf der produktorientierten Software- Qualitätssicherung. Hier wurden die vier Teststufen Unittest, Integrationstests, Systemtest und Akzeptanztest des V-Modells im deutschsprachigen Raum identifiziert. Sie haben sich bei der Erstellung qualitativ hochwertiger Software bewährt. Da in der agilen 115

120 KAPITEL 9: SCHLUSSBETRACHTUNGEN Softwareentwicklung ein phasenweises Vorgehen nicht vorgesehen ist und mehrere Probleme mit sich bringt, wurde sich dafür entschieden das V-Modell in abgewandelter Form für jede User Story einzeln zu durchlaufen. Zusätzlich wurden weitere Eigenheiten der Qualitätssicherung in agilen Prozessen dargestellt. Dies sind unter anderem eine hohe Testautomatisierung und die enge Zusammenarbeit zwischen Testern und Entwicklern. Nach der Präsentation der Grundlagen sowie der Auswahl des Referenzmodells, des Qualitätsmanagementansatzes und des Vorgehens bei der Qualitätssicherung wurde der Entwicklungsprozess entwickelt. Der erste Schritt war die Verteilung der Aufgabenbereiche auf die beteiligten Unternehmen. Die Rollen von Scrum vorgegebenen Rollen behielten ihre grundsätzlichen Aufgabengebiete. Das ScrumTeam ist um die externe Qualitätssicherung erweitert worden. Die Entwickler führen Unit- und Integrationstest durch. Die Verantwortung für die Systemund Akzeptanztest liegt bei der externen Qualitätssicherung. Der ScrumMaster stellt die Schnittstelle zwischen den beiden Unternehmen dar und muss alle Hindernisse beseitigen, die der Zusammenarbeit hinderlich sind. Der ProductOwner wird von der externen Qualitätssicherung bei der Aufnahme der Anforderungen unterstützt. Um das Zusammenspiel der Entwicklung und Qualitätssicherung zu optimieren, müssen beide Seiten über denselben Informationsstand verfügen. Hierfür wurde die User Story als zentrale Informationsquelle beschrieben, die um alle wichtigen Informationen erweitert wird. Des Weiteren hat der Abschluss einer User Story höchste Priorität, so dass die gefundenen Fehler auf dem kürzesten Weg an die Entwickler gemeldet und möglichst schnell behoben werden müssen. Nach der Aufteilung der einzelnen Aufgaben ist die konkrete Umsetzung von Qualitätsmanagementmaßnahmen im Entwicklungsprozess betrachtet worden. Um den Fluss zwischen den Unternehmen zu optimieren, wurde Kanban als Methodik eingeführt. Kanban fügt sich gut in den Rahmen von Scrum ein, reguliert den Durchfluss, liefert Kennzahlen und sorgt für eine hohe Transparenz. Durch die Begrenzung der einzelnen Aufgaben im System werden Tester und Entwickler zur Zusammenarbeit gezwungen. Darüber hinaus wurden die Möglichkeiten zur technischen Unterstützung des Entwicklungsprozesses betrachtet, um die Zusammenarbeit und Kommunikation der Entwickler 116

121 9.1 ZUSAMMENFASSUNG über größere Entfernung hinweg zu verbessern. Es wurden mehrere Werkzeuge identifiziert. Besonders Instant Messaging hat ich durch die Erzeugung eines Gefühls der Präsenz und Aufmerksamkeit in beiden Unternehmen hervorgetan. Das Kanbanboard sollte soweit wie möglich alle Kennzahlen, die von den Kanbankarten ausgehen, erfassen können, um die Entwickler nicht mit zusätzlichen Aufgaben zu belasten. Der Ablauf von Scrum wird durch die hinzugefügten Maßnahmen und Werkzeuge nicht verändert. Die Selbstverwaltung des Teams bleibt weitestgehend erhalten. Aus den herausgearbeiteten Aspekten ist ein Entwicklungsprozess erstellt worden. Dieser wurde mit BPMN modelliert. Die Dokumentation des Prozesses dient sowohl als Grundlage für die weitere Optimierung als auch zur Referenz für alle Projektbeteiligten. Bei den Besprechungen zur Vorbereitung des Sprints sind können Änderungen hinzugekommen, lediglich die Rolle der externen Qualitätssicherung wurde mit ihren Aktivitäten hinzugefügt. Im Sprint ist der Prozess darauf ausgelegt worden, eine möglichst schnelle Durchlaufzeit der User Stories zu ermöglichen. Die Vorbereitung der Tests und die Entwicklung laufen parallel ab. Der Product Owner begutachtet die Software direkt nach Implementierung, um das Testen von falsch interpretierten User Stories zu vermeiden. Vom Product Owner oder der Qualitätssicherung gefundene Fehler werden entweder im direkten Kontakt mit den Entwicklern gelöst oder über das Kanbanboard an diese übergeben. Auf dem Kanbanboard bekommen Fehler die höchste Priorität, müssen folglich behoben werden, bevor eine neue Aufgabe begonnen werden darf. So wird sichergestellt, dass keine User Stories im System hängen bleiben. Der Einsatz einer unabhängigen Software-Qualitätssicherung, zusammen mit konstruktiven Qualitätssicherungsmaßnahmen und den Praktiken der agilen Softwareentwicklung sowie der Beschränkung auf wenige Aufgaben zurzeit sorgten für eine hohe Qualität in der Software. Um die Qualität langfristig verbessern zu können, werden über das Kanbansystem Kennzahlen erhoben sowie Metriken benutzt. Diese Daten sind in der Sprint Retrospective mit allen Projektbeteiligten zu besprechen und Verbesserungsmaßnahmen abzuleiten. Neben dem optimalen Prozess wurden Ausnahmen betrachtet, die vom Prozessablauf abweichen. Der Umgang mit diesen Situationen wurde beschrieben. 117

122 KAPITEL 9: SCHLUSSBETRACHTUNGEN Abschließend wurde die Anwendung des Entwicklungsprozess beispielhaft für ein reales Projekt beschrieben. 9.2 FAZIT Um externe Qualitätssicherung in einen agilen Softwareentwicklungsprozess einzuführen, wurden verschiedene Teilgebiete betrachtet. Während Vorgehensmodelle und die Software-Qualitätssicherung aus dem Gebiet der Softwaretechnik als einem Teilgebiet der Informatik stammen, sind Qualitätsmanagement und Prozessmanagement Teilgebiet der Betriebswirtschaftlehre. Die Verknüpfung der verschiedenen Gebiete führt zu einer Lösung, die Rücksicht auf gängige Praktiken aus der Softwaretechnik nimmt, sie auf agile Modelle abbildet und eine langfristige Optimierung ermöglicht. Das Ziel der Arbeit, einen unternehmensübergreifenden agilen Softwareentwicklungsprozess für unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung zu schaffen, wurde erreicht. Mehrere Herausforderungen waren zu überwinden. Während die konventionellen Entwicklungsmodelle gut dokumentiert und auch im akademischen Umfeld genauer betrachtet worden sind, weisen die agilen Modelle noch Lücken auf. Die Literatur ist oft sehr einseitig und mit wenig wissenschaftlichem Hintergrund verfasst. So gibt es kein allgemeingültiges Vorgehen, das die Rolle der Qualitätssicherung in der agilen Softwareentwicklung beschreibt. Alles was über die idealen Umstände, in denen ein agiles Projekt stattfinden kann, hinaus geht (u.a. hochspezialisierte Entwickler, Kunde vor Ort und die Möglichkeit für automatisierbare Regressionstest) wird nicht betrachtet. Dies ist sehr schade, da es eine ernsthafte Auseinandersetzung mit der agilen Softwareentwicklung erschwert. Trotzdem existieren interessante Ansätze mit ausreichend fundiertem Hintergrund, aus denen sich viele Anregungen für den Entwicklungsprozess entnehmen ließen. Ähnlich sah es mit der Einbindung von Qualitätsmanagementelementen in die agile Softwareentwicklung aus. Zum einen sind die Qualitätsmanagementansätze mit der Zeit sehr umfangreich geworden, so dass sie auf kleine Projekte nicht anwendbar sind. Zum anderen gibt es immer noch wenig Bemühungen, agile Softwareentwicklung in 118

123 9.3 AUSBLICK Qualitätsmanagementsysteme zu integrieren. Folglich musste ein leichtgewichtiger Ansatz gefunden werden. Dies ist mit Kanban und einer Fixierung auf User Stories gelungen. Deutlich wurde, dass nur sehr wenige Autoren sich sowohl mit agilen als auch konventionellen Modellen auseinandergesetzt haben, um einen Vorteil aus der Kombination beider zu erhalten. In gleichem Maße waren soziale und technische Aspekte zu beachten, die in dem neu zu beschreibenden Prozess untergebracht werden mussten. Es ist gelungen, einen Entwicklungsprozess zu erstellen, der allen Anforderungen gerecht geworden ist und sich für den praktischen Einsatz eignet. Die zusammengefasste Problematik verdeutlicht, wie wichtig die Auseinandersetzung mit dem Thema war. Obwohl der Softwareentwicklungsprozess von enormer Wichtigkeit für die Erstellung von Software ist, findet er in Forschung und Lehre noch sehr wenig Anklang. Die am Anfang zitierte Aussage von Kenneth W. Kolence wird noch für einige Zeit Bestand haben. Mit der Einbindung externer Qualitätssicherung in die agile Softwareentwicklung ist ein kleines Gebiet der Softwaretechnik beleuchtet worden, das uns dem Verständnis von Softwareentwicklungsprozessen zumindest einen kleinen Schritt näher gebracht hat. 9.3 AUSBLICK Der beschriebene Entwicklungsprozess ist allgemein gehalten. Die Betrachtung unter spezielleren Randbedingungen kann für weitere Erkenntnisse sorgen. So ist die Skalierung auf mehrere Projektteams möglich, um größere, komplexere Projekte abzuschließen. Hierbei können mehrere ScrumTeams eine zentrale Qualitätssicherung beliefern, um nicht in jedem Team Tester vorhalten zu müssen. Des Weiteren haben neben anderen Aspekten auch steigende oder fallende Qualitätsanforderungen, eingesetzte Technologien und Sprintlängen Einfluss auf den Prozess. Er muss für die im Projekt vorgefundenen Bedarfe jeweils angepasst werden. Es reicht folglich nicht aus nur, den Prozess zu verwenden, sondern es muss sich näher mit der Thematik auseinander gesetzt werden, um zu bestimmen, wie unter bestimmten 119

124 KAPITEL 9: SCHLUSSBETRACHTUNGEN Umständen zu verfahren ist. Eine nähere Betrachtung unter weiteren Randbedingungen stellt eine interessante Ergänzung zur Arbeit dar. Momentan nutzt der Prozess sowohl Scrum als auch Lean Software Development. Die zukünftige Entwicklung von Lean Software Development oder die Verbesserung der Kommunikationswerkzeuge könnte dazu führen, dass nur eines der beiden Modelle verwendet werden muss. Eine nähere Betrachtung von Lean Software Development kann Erkenntnisse hervorbringen, die Scrum obsolet erscheinen lassen. Lean Development ist eine vergleichsweise junge Disziplin mit viel Potential. Mit Kanban ist erst kürzlich ein mächtiges Werkzeug entstanden. In Zukunft dürfte in diesem Bereich noch einiges zu erwarten sein, mit dem das Managementmodell von Scrum ausgetauscht werden könnte. Andererseits wird das Einbinden von entfernten Standorten mit zunehmender Technologisierung zusehends einfacher. Telefonkonferenzen über VoiP ist heutzutage an der Tagesordnung, Videokonferenzen die Regel. Mit einer dauerhaften audiovisuellen Verbindung kann es in Zukunft möglich sein, den Eindruck eines Teams an zwei Standorten zu vermitteln. Dies würde den Einsatz von purem Scrum ermöglichen und einen aufwendigen Prozess überflüssig machen. Eine informelle und enge Zusammenarbeit der Teams wäre ohne die Unterstützung durch Kanban möglich. Ein tieferer Einblick in die Mediennutzung sowie ihre zukünftigen Potentiale kann die Einbindung einer externen Qualitätssicherung weiter verbessern. Agile und konventionelle Softwareentwicklung haben viele Unterschiede, jedoch beide ihre Daseinsberechtigung. Die Vertreter beider Richtungen beharren noch sehr auf ihrer Art der Softwareentwicklung. Es ist schade, dass sich so wenig damit beschäftigt wird, die Vorteile beider Modelle in einem Vorgehen unterzubringen. Während agile Modelle mit ihren kurzen Iterationen für einen frühen Kundennutzen sowie eine hohe Flexibilität sorgen, haben konventionelle Modelle einen gut strukturierten Ablauf, der mit seiner umfangreichen Dokumentation eine umfassende Qualitätssicherung ermöglicht. Sollte ein Modell entstehen, das ein wenig von beidem aufgreift und so die Vorteile vereint, wären wir dem Verständnis eines guten Softwareentwicklungsprozesses ein Stück näher gekommen. 120

125

126 QUELLENVERZEICHNIS LITERATUR [And04] Anderson, David J. (2004) Agile management for software engineering. 1. Aufl., New Jersey, Pearson Education [And11] Anderson, David J. (2011) Kanban Evolutionäres Change Management für IT-Organisationen. (1. Aufl.) Heidelberg, dpunkt-verlag (orig.: Kanban: Successful Evolutionary Change Management, 2010, Blue Hole Press, Sequim WA) [Bal08] Balzert, Helmut. (2008). Lehrbuch der Softwaretechnik: Softwaremanagement. 2. Aufl., Heidelberg, Spektrum Akademischer Verlag. [Bec99] Beck, Kent. (1999) Extreme Programming Explained: Embrace Change. 1. Aufl., Amsterdam, Addison-Wesley Longman [Ben56] Benington, Herbert D. (1956) Production of Large Computer Systems. in: Symposium on Advanced Programming Methods for Digital Computers, Washington [Boe81] Boehm, Barry W. (1981) Software Engineering Economics, Enlglewood Cliffs, Prentice Hall [Boe88] Boehm, Barry W. (1988) A Spiral Model of Software Development and Enhancement. In: IEEE Compunter, May 1988 [Bro82] Broh, R.A. (1982) Managing Quality for Higher Profits: A Guide for Business Executives and Quality Managers. McGraw Hill Higher Education VI

127 QUELLENVERZEICHNIS [BT08] Boehm, B., Turner, R. (2008) Balancing Agility and Discipline A Guide for the Perplexed. 1. Aufl. Boston MA, Addison-Weasley [BW08] Brunner, F., Wagner, K. W. (2008) Taschenbuch Qualitätsmanagement Leitfaden für Studium und Praxis. 2. Aufl., München, Hanser Verlag [CG09] Crispin, L., Gregory, J. (2009) Agile Testing A Practical Guide for Testers and Agile Teams. 1. Aufl., Boston, Pearson Education [Coc02] Cockburn, Alistair (2002) Agile Software Development. 2. Aufl., Boston, Addison-Wesley [Dij72] Dijkstra, Edsger W.(1972) The humble programmer. In: Communications of the ACM 15 [Eck04] Eckstein, Jutta (2004) Agile Softwareentwicklung im Großen.1. Aufl., Heidelberg, dpunkt- Verlag [Eck09] Eckstein, Jutta (2009) Agile Softwareentwicklung mit verteilten Teams. 1. Aufl., Heidelberg, dpunkt-verlag [Epp11] Epping, Thomas (2011) Kanban für die Softwareentwicklung. 1. Aufl., Heidelberg, Springer- Verlag [FB08] Feldbrügge, R., Brecht-Hadrashek, B. (2008) Prozessmanagement leicht gemacht Geschäftsprozesse analysieren und gestalten. (2. Aufl.) München, Redline Wirtschaft, Finanzbuch Verlag GmbH [FR12] Freund, J., Rücker, B. (2012) Praxishandbuch BPMN Aufl. München, Hanser Verlag VII

128 QUELLENVERZEICHNIS [Gad10] Gadatsch, Andreas (2010) Grundkurs für Geschäftsprozess-Management Methoden und Werkzeuge für die IT-Praxis: Einführung für Studenten und Praktiker. 6. Aufl. Wiesbaden, Vieweg+Teubner [Han10] Hanser, Eckhard (2010) Agile Prozesse: Von XP über Scrum bis MA. 1. Aufl. Berlin Heidelberg, Springer-Verlag [HR01] Herring, R., Rees, M., Internet-based Collaborative Software Development Using Microsoft Tools. in Proceedings of the 5th World Multiconference on Systemics, Cybernetics and Informatics (SCI'2001) July, Orlando, Florida, online unter (abgerufen am ) [HH08] Höhn, R., Höppner, S. (2008) Das V-Modell XT Anwendungen, Werkzeuge, Standards. 1. Aufl. Berlin Heidelberg: Springer-Verlag [Hof08] Hoffmann, Dirk W. (2008) Software Qualität. 1. Aufl., München Heidelberg: Springer. [HRS09] Ηruschka, P., Rupp, C., Starke, G. (2009) Agility kompakt Tipps für erfolgreiche Systementwicklung.Heidelberg, Spektrum Akademischer Verlag [Koc11] Koch, Susanne (2011) Einführung in das Management von Geschäftsprozessen. 1. Aufl. Heidelberg, Springer [KS10] Kniberg, H., Skarin, M. (2010) Kanban and Scrum making the most of both. o.o, C4Media INC. (erhältlich unter Zugriff am: ) VIII

129 QUELLENVERZEICHNIS [Lar04] Larman, Craig (2004) The historical accident of waterfall validity?. In: Agile & Iterative Development, Amsterdam, Addison-Wesley Longman [Lig09] Liggesmeyer, Peter. (2009). Software-Qualität: Testen, Analysieren und Verifizieren von Software. 2. Aufl., Heidelberg: Spektrum Akademischer Verlag. [Lit07] Litke, Hans-D. (2007) Projektmanagement Methoden, Techniken, Verhaltensweisen.(5. Aufl.) München, Hanser Verlag [NWB00] Nardi, B., Whittaker, S., Bradner, E., Interaction and Outeraction: Instant Messaging in Action. in Proceedings of the 2000 ACM conference on Computer supported cooperative work. Online unter (abgerufen am ) [NR68] Naur P., Randell B. (1968) Software Engineering: Report of a conference sponsored by the NATO Science Committee. Garmisch, NATO Scientific Affairs Division [OW08] Oestereich, B., Weiss, C. (2008) APM - Agiles Projektmanagement, erfolgreiches Timeboxing für IT-Projekte. 1. Aufl., Heidelberg, dpunkt-verlag [Pet01] Petrasch, Roland (2001) Einführung in das Software-Qualitätsmanagement. 1. Aufl., Berlin, Logos-Verlag [Pic08] Pichler, Roman (2008) Scrum Agiles Projektmanagement erfolgreich einsetzen. 1. Aufl., Heidelberg, dpunkt-verlag [Pop01] Poppendieck, Mary (Mai/Juni 2001) Lean programming, Software Development Magazine IX

130 QUELLENVERZEICHNIS [SN11] Slama, D., Nelius, R. (2011) Enterprise BPM Erfolgsrezepte für unternehmensweites Prozessmanagement. 1. Aufl., Heidelberg, dpunkt-verlag [SL10] Spillner, A., Linz, T. Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester. 4. Aufl., Heidelberg, dpunkt-verlag [Roy70] Royce, Winston W. (1970) Managing the development of large software systems. in: WES- CON, August 1970, pages 1-9. [TN86] Takeuchi, H., Nonaka, I. (1986) The new product development game. Havard Business Review, January-February [Wal11] Wallmüller, Ernest (2011) Software Quality Engineering. 3. Aufl. München, Hanser Verlag [WK08] Wagner, K. W., Käfer, R. (2008) PQM Prozessorientiertes Qualitätsmanagement Leitfaden zur Umsetzung der neuen ISO 9001: Rollen im prozessorientierten Qualitätsmanagement. 4. Aufl., München, Hanser Verlag [Wir09] Wirdemann, Ralf (2009) Scrum mit User Stories.1. Aufl., München, Hanser Verlag X

131 QUELLENVERZEICHNIS SONSTIGE QUELLEN UND VERWEISE [agile_manifesto] Agiles Manifest abgerufen am von [agile_principle] Agile Prinzipien abgerufen am [BPMN] Standard der Business Process Model and Notation 2.0 abgerufen am von [CMMI] Dokumentation des CMMI for Development 1.3 abgerufen am von [CMMI_Agile] CMMI or Agile: Why not Embrace Both! abgerufen am von [HP Quality Center] [IBM Rational Synergy] [IEE829] tamp= abgerufen am [JUnit] [Kanbancard] The Kanban Story: Moving Cards Back abgerufen am von XI

132 QUELLENVERZEICHNIS [Kanbanboard] Bild eines Kanbanbaords abgerufen am [lean_rework] Accounting for bugs and rework abgerufen am von [mantis] [bugzilla] [pmdoi] Declaration of Interdependence abgerufen am von [ScrumBan] Scrum-ban abgerufen am von [Selenium] [smartq] [standish] Standish Chaos Report abgerufen am von 9_pdf [SVN] XII

133 QUELLENVERZEICHNIS [SQS Market Research 2011] Wachstumsmarkt Software-Testing Markttrends, Dienstleister und Erfolgsfaktoren abgerufen am php [trac] [Watir] [WIKI] What is Wiki abgerufen am von [richhewlett] Physical vs Virtual Kanban Boards abgerufen am von XIII

134 GLOSSAR GLOSSAR Amplify Learning: Amplify Learning ist einer der sieben Grundsätze von Lean Software Development. Er besagt, dass die Software in kleinen Inkrementen entwickelt wird. Fertige Artefakte werden ständig im Team und mit dem Kunden geteilt. Durch ständiges Feedback soll voneinander gelernt werden. So lernen z.b. die Entwickler die Anforderungen an das Projekt im Laufe der Entwicklung näher kennen, anstatt diese zuvor im Detail zu spezifizieren. Bugfixes: Als Bugfix wird die Beseitigung einer Fehlerquelle im Quellcode bezeichnet. Computer Aided Software Engineering: Unter Computer Aided Software Engineering wird die technische Unterstützung der Softwareentwicklung bezeichnet. Sie unterstützt bei der Planung, dem Entwurf und der Dokumentation. Deming-Zyklus: siehe PDCA-Zyklus Eliminate Waste: Eliminate Waste ist eine der sieben Grundsätze von Lean Software Development. Er besagt, dass alles was kein Mehrwert für den Kunden liefert, als Verschwendung angesehen werden kann. Diese Verschwendung ist zu eliminieren. Feature Driven Development: Feature Driven Development ist eine iterative und inkrementelle Softwareentwicklungsmethodik. Sie vereint mehrere Best-Practices miteinander. Dabei werden die Praktiken durch Funktionalitäten mit Kundennutzen gesteuert, die Feature. Lean: Siehe Lean Manufacturing Lean Manufacturing: Lean Manufacturing ist eine Produktionsmethode, die sich die Reduzierung von Ressourcen um jeden Preis als Ziel gesetzt hat. Der Einsatz von Ressourcen für jede Aktivität, die keinen Kundennutzen erzielt, wird als Verschwendung angesehen. Flussoptimierung hat hohe Priorität. Lean software development: Lean software development ist die Übertragung der Prinzipien und Praktiken des lean manufacturing auf die Softwareentwicklung. Sie basiert auf sieben Kernpraktiken ähnlich den Prinzipien des lean manufacturing. Maturity Models: siehe Reifegrade PDCA-Zyklus: Der PDCA-Zyklus ist eine iterative, vierstufige Managementmethode. Die Aktivtäten Planen (Plan), Umsetzen (Do), Überprüfen (Check) und Verbessern (act) werden aufeinanderfolgenden durchlaufen. XIV

135 GLOSSAR Prozessmodell: Ein Prozessmodell ist die Beschreibung eines oder mehrerer Prozesse auf gleicher Ebene. Dies geschieht meist über eine grafische Darstellung. Reifegrade: Reifegrade sind verschiedene Ebenen in einem Modell, die beschreiben in wie weit die Praktiken und Prozesse einer Organisation verlässliche und gleichbleibende Ergebnisse liefern können. Return on Investment: Return on Investment ist eine Metrik, die den Gewinn im Verhältnis zum eingesetzten Kapital beschreibt. Six Sigma: Six Sigma versucht die Qualität der Prozessergebnisse durch das Entfernen von Fehlerquellen und der Minimierung von Schwankungen zu verbessern. Dabei werden mehrere Qualitätsmanagementmethoden angewandt, darunter auch statistische. Test-First-Ansatz: Die Tests werden vor der Implementierung einer Methode geschrieben. Die Methode wird danach implementiert und so lange verfeinert, bis alle Tests bestanden sind. Ticketsystem: Ein Ticketsystem ist eine Applikation die eine Liste von Aufgaben führt. Ein Ticket beinhaltet die Aufgabe sowie zusätzliche Informationen die für seine Erledigung benötigt werden. Tickets können innerhalb des Systems von den Benutzern verwaltet werden. Timeboxed: Der Begriff timeboxed bezeichnet, dass für eine bestimmte Aktivität ein festgelegter Zeitrahmen existiert. Total Quality Management: Total Quality Management ist eine Management Philosophie zur ständigen Verbesserung von Produkt- und Prozessqualität. Sie bezieht das komplette Unternehmen mit ein. So sind auch die Mitarbeiter, Zulieferer und Kunden an der Erreichung der Qualitätsanforderungen beteiligt. Work in Progress: Als Work in Progress wird in Kanban die Anzahl an Karten bezeichnet, die sich zu einem bestimmten Zeitpunkt im System befinden. XV

136

137 ANHANGSVERZEICHNIS ANHANG Anhang 1: Beispiel für Kanban... 2 Anhang 2: CD-ROM

138 ANHANG ANHANG 1: BEISPIEL FÜR KANBAN 2

139 ANHANG 1: BEISPIEL FÜR KANBAN Abbildung A.1: Beispielhafte Darstellung von Kanban entnommen aus 3