Kategorie: Realisierung

Projektsteckbrief

Veröffentlicht in Angebotsphase, Konzeption, RealisierungKommentar hinterlassen

Oft wird man gefragt, ob man nicht mal schnell dies oder das übernehmen kann. Oder – im Falle eines Managers – ob man nicht jemanden für dies oder jenes parat hat. Ruck-Zuck entsteht ein Hin- und hergeschreibe, bei dem die Details geklärt werden und es geht schnell mal eine halbe Stunde oder mehr ins Land, bevor überhaupt das wesentliche geklärt ist. Klar, man könnte einfach den Höhrer in die Hand nehmen und anrufen. Aber in der Regel wird geschrieben.

Damit solche Eskapaden reduziert werden, habe ich ein Tool übernommen, was mein alter Chef gerne eingesetzt hat. Wobei Tool schon zuviel gesagt ist. Ein kleiner Steckbrief für Projekte, damit man schnell eine Übersicht bekommt.

Der Steckbrief

Projektname: (Gib dem Kind einen Namen. Im Idealfall ist die Projektablage auch unter dem Namen zu finden)

Projektbeschreibung: (Beschreibe das Thema und mit 2-3 Sätzen.)

Projektleiter: (Wer ist bei uns Hauptverantwortlicher?)

Kunde: (Wer will dieses Projekt. Im Idealfall Kunde und Abteilung)

Ansprechpartner: (Wer ist beim Kunden verantwortlich)

Aufwand: (Wie groß wird das Ganze voraussichtlich. Eine Range reicht auch aus [z.B. 50-100 PT])

Benötigte Rollen: (Entwicklung, Testmanagement, Architektur, Infrastruktur, Suche, UI, UX …)

Technologien und Fähigkeien: (SharePoint 2007, O365, Clientside Development, Serverside Development, AnguarJS, Taxonomy Termstores, Projektmanagement etc…)

Diese Fragen sind aus meiner Sicht schnell beantwortet und geben einen guten ersten Eindruck von einem Projekt. Außerdem können Sie für ein Projektstammblatt verwendet werden und machen Themen vergleichbar.

Projekte in der Krise VI

Veröffentlicht in Realisierung, WartungKommentar hinterlassen

Die Übernahme von internen Fremdprojekten

Nachdem wir uns im letzten Beitrag damit beschäftigt haben, was alles bei externen Fremdprojekten schiefgehen kann, kommen wir nun zu den internen. Wo der Unterschied ist? Nun, zum einen sind die Kollegen meist noch greifbar. Zum anderen spielt hier aber auch ein gutes Stück Politik mit hinein und die Gefahr einem Kollegen auf die Füße zu treten.

Das Szenario

Gehen wir von folgendem Szenario aus. Eine Abteilung innerhalb des Unternehmens hat seit einigen Jahren bereits einen SharePoint im Einsatz. Es gibt jemanden, der sich recht gut damit auskennt. Das meiste hat er sich autodidaktisch beigebracht und auch für viele Probleme seiner Kollegen eine schnelle Lösung gefunden. Nicht immer ganz sauber, aber immer so, dass es weitergeholfen hat. Nun ist er jedoch an einem Punkt angelangt, indem die weitere Pflege dieser Plattform sich zeitlich nicht mehr mit seinen anderen Aufgaben vereinbaren lässt. Also soll die Site Collection (sprich die Webseite, auf der die Lösung betrieben wird) nun in die Obhut der internen IT übergeben werden. Wir als externe Consultants werden genau von dieser IT-Abteilung als Ratgeber mit dazu gezogen.

Die Herausforderung

Nun beginnt die eigentliche Aufgabe. Denn oft sind solche Projekte nur sehr schwer zu administrieren und zu erweitern. Wieso? Nunja, derjenige, der bisher den SharePoint erweitert und die Änderungen vorgenommen hat war kein IT-Spezialist, sondern ist in diese Rolle hineingewachsen. Für unser Beispiel war es ein Mitarbeiter der Buchhaltung und hat kleinere Tools und Lösungen für ebenjene Abteilung erstellt. Das Problem dabei ist jedoch, dass ihm damit auch das Handwerkszeug eines IT-Spezialisten fehlt. Das bedeutet, dass in der Regel alle Änderungen „mal schnell“ durchgeführt wurden und damit nichts dokumentiert wurde. Es gibt also keine Architekturübersicht, Anforderungsdokumente, Änderungshistorie oder dergleichen. Alles, was man vermutlich hat sind ein paar Änderungswünsche oder Fehlerbeschreibungen von der Abteilung.

Gut, immerhin ist der Kollege, der das Tool erstellt hat, noch verfügbar. Doch er hat diese Anwendung über Jahre erstellt und weiß selbst nicht mehr genau, wo er was nun gemacht hat. Das war ja schließlich auch der Grund wieso er es letztlich abgegeben hat. Denn all dies wird ihm zu viel und es würde die Abteilung inzwischen billiger kommen, wenn es durch den IT-Support betreut wird, als wenn man einen weiteren Kollegen ausschließlich für diese Seite beschäftigen würde. Das Problem des Beraters und der IT-Abteilung hier ist offensichtlich. Man muss versuchen möglichst viel Informationen abzugreifen und durch möglichst gezielte Fragen der Erinnerung des Abteilungskollegen auf die Sprünge helfen. Doch man sollte unter allen Umständen vermeiden den Kollegen zu sehr vor den Kopf zu stoßen oder seine Arbeit zu hart zu kritisieren. Das würde für Verdruss auf beiden Seiten sorgen und im Notfall zieht der Kollege die Reißleine und beschränkt seine Zusammenarbeit nur noch auf das Nötigste

Die Herangehensweise

Tatsächlich weiß der Kollege in der Regel selbst, dass er hier nicht das Gelbe vom Ei produziert hat. Schließlich kommt er selbst nicht mehr damit zurecht. Daher sollte man versuchen eine positive Art zu dem Kollegen zu finden. Ja, das Projekt ist nicht gut, aber die Aufgabe ist nun einmal gestellt und nun gilt es erst einmal eine Bestandsaufnahme zu machen. Anschließend muss man dann entscheiden wie es weitergeht. Wichtig ist vor allem, dass man hier nicht in schlechte Stimmung verfällt. Nur allzu leicht kann dies passieren, wenn man das Projekt zu nah an sich heran lässt oder es mit dem gewohnten Maßstab vergleicht. Entscheidend ist tatsächlich hier, dass man sich klar macht, dass es ein Hobbyprojekt war und der Kollege es gut gemeint hat. Nur mit dieser Einstellung kann man ein solches Projekt stemmen ohne sich selbst zu verschleißen.

Okay, wir gehen also positiv an die Sache heran (Tschakka!). Also machen wir als erstes mal eine Bestandsaufnahme um herauszufinden was überhaupt möglich ist. Welche Version ist im Einsatz, welche Features sind aktiviert, welche Third-Party-Tools finden Verwendung und wo hatte der Kollege welche Rechte. Mit diesen Fragen lässt sich das Tätigkeitsfeld erst einmal einschränken. Anschließend schauen wir uns die Probleme an, die mit der Anwendung gemeldet wurden. All diese Informationen erfassen wir jetzt natürlich sauber in unsere ALM Tool (z.B. dem TFS oder VSTS), damit die Erkenntnisse künftig sauber dokumentiert an einem Ort abgelegt sind.

Nachdem wir nun das Gefühl haben, dass wir zumindest die Rahmenparameter kennen und uns auch die Anwendung schon einmal angeschaut haben, reden wir mit dem Kollegen. Welche Probleme hat er mit seiner Anwendung behoben, an welche Änderungen kann er sich noch erinnern, wo sind die Knackpunkte an denen er gescheitert ist. Ich denke, in einem positiven (!) Gespräch kann man etwa 70-80 % der Applikation in Erfahrung bringen und die häufigsten Anwendungsfälle identifizieren. Natürlich schreiben wir auch hier wieder alles mit was wir erfahren und bringen es anschließend in eine geeignete Form, sodass wir auch künftig damit arbeiten können.

Gut, damit sollten wir jetzt zumindest schon einmal die wesentlichen Rahmendaten kennen. Wir wissen über die Technologie, die groben Strukturen der Applikation, die Probleme und auch über den Wissensstand des Kollegen bescheid. Daraus können wir also schon einmal herleiten, was er vermutlich getan hat und wozu er einfach nicht in der Lage war. Wenn wir dieses Wissen nun mit der Applikation und den aufgetretenen Problemen abgleichen können wir vielleicht schon das meiste identifizieren und benennen.

Die Übernahme

Der nächste Punkt ist dann der eigentlich Entscheidende. Ist das Projekt geeignet um die Probleme zu lösen, die es aktuell gibt und ist es möglich das Projekt auch in Zukunft sauber zu warten? Wenn nicht, macht es Sinn das Projekt neu aufzusetzen? Das wäre auch dann sinnvoll, wenn es ausreichend Änderungsvorschläge und Verbesserungspotenzial gibt, damit die Abteilung einen echten Mehrwert von der Weiterentwicklung hat. Gibt es dafür entsprechendes Budget und die Bereitschaft, dann ist dieser Weg zu bevorzugen. In der Regel ist es jedoch so, dass genau dieses Budget eben fehlt. Deshalb hat der Kollege ja angefangen alles in Eigenregie umzusetzen. Also was jetzt?

Die Lösung ist ähnlich wie auch bei externen Projekten. Man muss eine Kostenaufstellung machen. Dazu sollte man sich fragen, welche Laufzeit für das Projekt erwartet werden kann. Sind solche Zahlen nicht lieferbar würde ich von einer geschätzten Laufzeit von 5 Jahren ausgehen. Denn in der Regel wird eine Plattform innerhalb dieser Zeit durch ihren Nachfolger abgelöst und auch ansonsten ist der Zeitraum groß genug um zu zeigen wie groß die Initialen und die Folgekosten sind. Nun stellt man also die Initialen Kosten für die Übernahme bzw. für die Neuerstellung und den Betrieb für die nächsten Jahre gegenüber. Man nennt die Risiken bewertet diese mit Multiplikatoren. Am Ende werden 2 Zahlen herauskommen. Welche Kosten entstehen für die Übernahme bzw. Neuentwicklung des Projektes im vermuteten Zeitraum. Natürlich gibt es dort immer etwas Spielraum und die Zahlen sind nicht final. Dennoch bieten sie einen guten Einblick mit welcher Größenordnung gerechnet werden muss.

Ist diese Zahl weit jenseits der erwarteten und veranschlagten Kosten für das Projekt sollte man auch als IT-Abteilung bereit sein ein Projekt abzulehnen oder zumindest an die nächste Instanz zu eskalieren. Was passiert, wenn es zur Eskalation kommt, darüber werden wir uns in einem anderen Beitrag unterhalten.

Mehr zum Thema?

Projekte in der Krise IV

Veröffentlicht in Allgemein, Qualitätssicherung, Realisierung2 Kommentare

Wie ein Projekt seiner Ausbaustufe das Leben schwer machen kann

Puh. Es war ein harter Weg, doch das Projekt steht endlich. Wir befinden uns in der Abnahmephase. Einige kleinere Findings und Nice-To-Have-Wünsche hat der Kunde noch. Wir haben noch etwas Budget in unserem Projekt und diese letzten Aufgaben werden gerade realisiert. Der Business Consultant hat das Ohr direkt am Kunden und wir erfüllen diese neuen Anforderungen quasi in Realtime. Ein kurzes Meeting mit dem Kunden, eine Mail an den Entwickler und los. Der Kunde testet jede neue Funktionalität direkt am System. Damit das knappe Restbudget für die Extras noch reit, machen wir sie schnell direkt auf dem System, welches bald live gehen soll. Der Code wird dann anschließend gesammelt in das Quellcodeverwaltungssystem eingecheckt. Der letzte Code, der letzte Test, Booya!

Der GoLive verläuft weitgehend problemlos. Die Codes sind JavaScript und andere Frontend-Logik, die wir in das Produktivsystem eingespielt haben. Damit musste die Seite nun nur noch öffentlich bekannt gemacht und die Rechte für die Benutzergruppen gesetzt werden. Alles läuft weitgehend glatt. Kleinere Bugfixes im Livesystem werden ebenfalls zeitnah gefixt. Die Akzeptanz ist hoch, die Stimmung gut.

Die Zeit vergeht. Das System läuft stabil, die Endnutzer arbeiten damit und entwickeln neue Ideen für Verbesserungen und neue Use Cases. Da das System wichtig ist, hat das Steering Board die wichtigsten Vorschläge und neuen Anforderungen gesammelt und ein neues Paket geschnürt. Das Projekt geht in Phase II und aufgrund der guten Leistung sind auch wir wieder als Entwicklungs- und Consultingmannschaft mit dabei.

Leider ist das damalige Entwicklungsteam inzwischen in anderen Projekten eingesetzt und nur sporadisch erreichbar. Daher wird ein neues Team eingesetzt. Der Business Consultant und Projektleiter konnten glücklicherweise aus anderen Projekten abgezogen werden und somit stehen zumindest an der Kundenfront die gleichen Ansprechpartner. Ein mehr oder weniger typisches Setting für eine Folgebeauftragung also.

Die Phase II

Und so beginnt es von Neuem. Doch schon bei Beginn liegt Ärger in der Luft. Die Entwicklermannschaft hat sich in die Dokumente der Anforderungsphase eingearbeitet und auch die INT- und QA-Maschine angesehen. Irgendwie ist es passiert, dass in den Anforderungs- und CR-Dokumenten etwas anderes steht, als im INT-System umgesetzt wurde. Das QA-System scheint sich außerdem ebenfalls in einzelnen Aspekten vom INT-System zu unterscheiden. Zudem geistern immer wieder E-Mails von dem letzten Entwicklerteam durch den Raum, die noch etwas anderes verkünden.

Klar, es war ja etwas hektisch zu Projektende. Aber im Quellcodesystem sind ja die aktuellsten Sources hinterlegt. Dann erneuern wir INT- und QA-System eben. Und schon tauchen die nächsten Fragen auf. Scheinbar wurden die Codes ohne oder unzureichendem Kommentar eingecheckt. Auch lassen sich daraus keine Pakete mehr erkennen weil gleich mehrere Pakete auf einmal eingecheckt wurden. Also lassen sich daraus keine Rückschlüsse auf Änderungen und Bugs schließen und auch der aktuelle Stand lässt sich so nicht eindeutig ermitteln. Na schön. Also installieren wir alles und schauen es uns an.

Der Business Consultant drängelt inzwischen etwas, da er für die neuen Anforderungen gerne einige Konzeptpapiere erstellen würde. Doch dazu braucht er Daten aus dem Bestandssystem und auch einige Screenshots.

Und nun wieder das Entwicklerteam, denn es ist leider wurden auch noch einige Konfigurationen nicht aktualisiert und nun funktionieren einige Funktionen nicht. Schließlich muss ein Entwickler der letzten Phase aus einem anderen Projekt losgeeist werden, damit dieser die Konfigurationen einstellen kann.

All das verzögert leider auch unsere Phase II immer weiter und der Anfangs gute Eindruck des Kunden wird leider getrübt. Natürlich kann man die Aufwände durch entsprechende Mehrarbeit wieder hereinholen, doch nun müssen auch die Dokumentationen aus Phase I noch nachbereitet werden. Und da nicht mehr alle Anforderungen vorhanden sind und man sich dem Kunden gegenüber natürlich auch keine Blöße geben will, wird man nie völlig aus dieser Klemme herauskommen und immer wieder gezwungen sein Dinge nach zu dokumentieren und durch Mehraufwände auszugleichen.

Was kann man tun?

Die Lösung ist natürlich offensichtlich und greift die Prinzipien aus dem ersten Teil der Serie auf. Nicht nur ein Projektplan muss sauber erstellt werden, sondern auch alle Änderungen im späteren Prozess müssen nachgetragen und aktualisiert werden. Man sollte bei der Umsetzung eines Projektes immer auch den gesamten Application Lifecycle im Blick haben. Was passiert, wenn eine Phase II kommt, oder ich die Applikation ablösen und auf eine neue Plattform heben will? Wir profitieren selbst davon, dass wir sauber dokumentieren und auch neue Anforderungen nachhalten. Denn wenn man gute Arbeit geleistet hat, ist es sehr wahrscheinlich, dass ein Kunde auch für den Folgeauftrag wieder den gleichen Dienstleister auswählt, anstatt sich der Gefahr auszusetzen mit einem etwas günstigeren Anbieter neues Lehrgeld zahlen zu müssen. Im Idealfall wirkt sich saubere Arbeit also sogar auf den Tagessatz aus, da man einen guten Ruf durchaus auch mal etwas höhere Kosten ausgleichen kann.

Und im Detail?

Soweit die Theorie. Aber was kann man denn nun ganz konkret tun? Nun, ich empfehle das ALM-Tool Visual Studio Online (ehem. Team Foundation Server). Durch geringe Kosten, hohe Verfügbarkeit und gute Skalierbarkeit bietet dieses Tool nahezu für jede Anwendung optimale Voraussetzungen. Außerdem bietet es diverse Werkzeuge für das ALM-Management. Zum Beispiel bei der Erfassung von Requirements, Tasks, Bugs, Issues, Testcases und ähnlichem, oder bei der Planung von Teams, Sprints und Kanban Boards. Aber auch für die Abbildung großer Projekte mit unterschiedlichen Epics, Features und User Stories ist es gut geeignet. Außerdem kann man die erstellen Dokumente oder auch Quellcode direkt zu jedem dieser Elemente direkt referenzieren. Die Vorteile sind so vielseitig, dass es für eine eigene Serie reicht. Deshalb soll dies nur als Anregung gedacht sein, sich selbst zu informieren. Oder natürlich auf ebenjene Serie zu warten. 🙂

Mehr zum Thema?

Projekte in der Krise III

Veröffentlicht in RealisierungKommentar hinterlassen

Die Krux mit der Entwicklungsmaschine

Und wieder kommt ein neuer Stolperstein in das Projekt. Dieses mal handelt es sich gar nicht um die Projektmethodik selbst, sondern um ein viel banaleres und dennoch genauso ärgerliches Thema. Wir haben die Planung sauber durchgeführt, auch das Kick-Off war gut und jeder weiß was zu tun ist. Wir haben Qualitätsprozesse etabliert und sind nun bereit endlich den ersten Code zu schreiben! Wir gehen also zu unserem Entwicklungsteam und sagen, dass sie starten können. Und nun die Ernüchterung. Das Entwicklungsteam, dass wir ab heute voll eingeplant haben, und das ab heute auch unser Budget aufzehrt, kann nicht arbeiten! Wieso? Nun, wir haben für das Team keine Entwicklungsmaschinen.

Ja, aber! Das ist ja wohl Aufgabe des Entwicklers, dass er sein Handwerkszeug mitbringt! Schließlich habe ich ihm als Projektleiter ja auch keinen Laptop oder Tastatur besorgt! Schon, aber so einfach ist das nicht. Natürlich hat der Entwickler bereits für viele Kunden gearbeitet und natürlich hat er sich irgendwann auch mal eine Development-VM aufgesetzt. Doch die ist leider nicht das, was wir für unsere Anforderungen brauchen. Das kann dann sein, wenn wir z.B. mit einer ganz neuen Version von SharePoint arbeiten, für die es schlicht noch nichts gibt. Oder wir benötigen eine K2 oder Nintex Engine. Außerdem wurde diese Entwicklungsmaschine ja schon von 10 Projekten mit 1.000 Einzelanforderungen genutzt. Jede hat die Maschine etwas weiter kaputt konfiguriert und nun ist sie für uns einfach nicht mehr brauchbar.

Diese Problem mag einigen Projektleitern etwas weit hergeholt zu sein. Und tatsächlich tritt es auch nicht so häufig auf. Besonders in Zeiten des Client-Server-Object-Models ist es ehr selten, dass ein Projekt wirklich den ganzen Server kaputt konfiguriert. Doch auf der anderen Seite steht, dass der Schaden beträchtlich sein kann, wenn es wirklich auftritt. Spätestens bei Release-Wechsel der Host-Plattform (z.B. SharePoint) muss definitiv eine neue Maschine her. Im Idealfall haben wir tatsächlich eine Maschine pro Projekt und/oder Kunde, auf der wir den letzten Stand einfach archivieren können und wenn der Kunde eine Weiterentwicklung möchte, reaktivieren wir einfach die Maschine und arbeiten weiter. Meist ist dies aus Platzgründen Wunschdenken. Außerdem möchten die Projekte diese Konfiguration der Entwicklungs-VMs natürlich nicht zahlen. Also, was machen wir nun?

Die eleganteste Lösung bietet aus meiner Sicht die Azure Cloud an. Vor allem, wenn man selbst ein Entwickler mit MSDN-Subscription ist. Denn dann hat man auf der Azure Plattform bereits ein gewisses Cloud-Kontingent gratis dabei. Ja, schön. Aber ist das Problem dann jetzt nicht nur von meiner eigenen VM in eine Cloud-VM verschoben? Die Antwort ist nein. Denn Microsoft bietet inzwischen unzählige Images an, die verschiedenste Anforderungen abdecken. Im Rahmen dieses Artikels habe ich mir den aktuellsten Stand selbst einmal angesehen. Aktuell werden aktuell bereits Visual Studio 2017 RC und die SharePoint 2016 Trail Version als Konfigurationssetting für die eigene VM angeboten.

Ich habe der Vollständigkeit halber auch einmal getestet, wie lange die Installation der beiden Systeme dauert. Für Visual Studio hat es mich vom Einstellen der Parameter bis zur Eingabe der ersten Quellcode-Zeile etwa 30 Minuten gekostet. Das Öffnen von Visual Studio innerhalb der neuen VM hat beinahe genauso lange gedauert wie das Provisionieren der VM durch Azure. Aus meiner Sicht eine wirklich überzeugende Geschwindigkeit.

Für den SharePoint 2016 sah das Ganze ähnlich aus. 20 Minuten vom Konfigurieren bis zum Öffnen des Config Wizards. Insgesamt haben wir also innerhalb von etwa einer Stunde sowohl eine SharePoint 2016er Plattform als auch Visual Studio als Entwicklungsumgebung aufgesetzt und konnten anschließend arbeiten.

Wer übrigens eine vollständige Anleitung zum Installieren einer VM für SharePoint 2016 auf Azure benötigt, wird hier fündig: https://technet.microsoft.com/de-de/library/mt723354(v=office.16).aspx

Nachdem diese Maschinen übrigens einmal aufgesetzt wurden, kann man in den Einstellungen auch so genannte Automatisierungsskripte finden. Diese Skripte erlauben es einem exakt die gleiche Umgebung erneut aufzusetzen, indem man bspw. über PowerShell das Skript erneut ausführt. Das ist also dann interessant, wenn jemand zum Start eine blanke 2016er SharePoint VM mit Visual Studio 2015 R3 benötigt. Ein Skript absetzen und etwas warten. Dann wird in der eigenen Azure Umgebung eine neue Applikation provisioniert und kann anschließend eingesetzt werden.

Aber die Kosten! Ja, die sollte man nicht aus den Augen verlieren. Für eine virtuelle Maschine mit 8 Kernen und 14 GB RAM werden bei 160 Stunden Laufzeit (also 20 Tage * 8 Stunden) ca. 100€ fällig. Nimmt man einen separaten Domain Controller mit 2 Kernen und 4 GB RAM dazu ist man zusammen bei etwa 120€ pro Entwickler und Monat. Ein nicht unerheblicher Betrag. Doch man muss bedenken, dass einem Entwickler mit MSDN Lizenz ohnehin etwa 130 Euro Guthaben pro Monat zur Verfügung stehen. In diesem Fall würde er also nicht einen Euro echten Geldes kosten und hätte eine frische virtuelle Maschine für jedes Projekt, die auch nur dann das Guthaben belastet, wenn sie wirklich eingeschaltet ist.

Einzig die Staging-Maschinen sollten dann von einem Konto betrieben werden, dass nicht direkt den Entwicklern zugeordnet ist, um nicht die Budgetgrenzen zu sprengen. Oder man entscheidet sich dafür, dieses Geld zu investieren.

Und wenn man einen guten Sales Manager hat, dann verkauft dieser die entstehenden Kosten gleich mit. Immer mit dem Argument, dass die Entwicklungsmaschinen anschließend nicht gelöscht werden müssen und damit der letzte Entwicklungsstand sauber archiviert wird. Ein ziemlich guter Vorteil für Unternehmen im agilen Umfeld, wenn ihr mich fragt.

Mehr zum Thema?

Projekte in der Krise II

Veröffentlicht in Qualitätssicherung, RealisierungKommentar hinterlassen

Über Testmanagement und Qualitätsansprüche

Nachdem ich im ersten Teil dieser Serie davon geschrieben habe, wie wichtig gute Projektinitialisierung ist kommen wir im zweiten Teil auf einen Dauerbrenner. Das Testmanagement. Ich möchte diesen Teil relativ früh in der Serie bringen, obwohl die Entscheidung dafür bei den Tests zu sparen oft sehr spät fällt. Wieso? Weil es einer der häufigsten Missstände ist und oft sowohl von den Lieferanten als auch den Kunden als der Punkt angesehen wird, bei dem man schnell mal 20 % Budget einsparen kann. Ein Trugschluss, wie sich oft zeigt.

Aber von Anfang. Das Projekt ist gestartet, die Voraussetzungen gut. Zwar sind die Anforderungen etwas nebulös, aber wir haben im Vertrag einen guten Grundstock gelegt. Konzeption, Realisierung, Test und Abnahme. Alle Phasen vorhanden und als Milestones definiert. Das Zeitfester ist gerade ausreichend. Die Mitarbeiter sind für Ihre Jobs qualifiziert und haben sich auf Ihre Aufgaben committed. Die Konzeption findet direkt mit dem Kunden statt und erstmals definiert der Kunde wirklich, was er sich unter den einzelnen Punkten vorstellt. Der Nebel verschwindet und Klarheit kehrt ein. Langsam wird klar, dass das Projekt an der ein oder anderen Stelle deutlich komplexer ist als angenommen. Zum Teil verstecken sich die entsprechenden Anmerkungen in Nebensätzen der Ausschreibung, zum Teil wurde einfach vergessen die entsprechenden Bereiche abzugrenzen. Der Kunde weigert sich mehr Budget bereitzustellen, da diese Anforderungen aus seiner Sicht Kern-Bestandteil der Anwendung sind. Was nun? Der Projektleiter möchte den Kunden nicht verärgern und dieser hat Jahresziele auf dieser Applikation und möchte bei seinem Vorstand nicht schlecht dastehen, indem er mehr Budget aushandelt. Man geht also gemeinsam durch das Konzept und identifiziert schließlich einen großen Block, der nicht wirklich etwas zum Projekt beiträgt. Das Testmanagement!

Natürlich fordert der Vorstand einen entsprechenden Bericht von dem Projekt. Schließlich ist das ja eine wichtige Vorgabe aus dem V-Modell! Da das Projekt natürlich agil läuft hat sich der Vorstand letzten Ends darauf eingelassen, dass ein einzelner Testbericht erstellt wird. Aber der muss dann umfänglich sein.

Die Projektsteuerung aus Kunde und Lieferant kommt auf eine einfache Lösung. Das Testmanagement in der geplanten, strukturierten Form mit Unit-Tests, Testfällen und eigenem Integrationstest wird gestrichen. Stattdessen sollen die Entwickler ihren Code testen und die Ergebnisse in einem Excel zusammenfassen. Am Ende wird so ein Testbericht entstehen, der alle Bereiche umfasst und somit klar den Anforderungen des Vorstandes entspricht. Ursprünglich waren 20% für Testmanagement eingeplant. Nun konnte es auf 5% reduziert werden. Die Ersparnisse werden ausreichen um das Projekt umzusetzen und sogar noch etwas Puffer überlassen um ein paar Bugs mehr zu beheben, die diesem Vorgehen geschuldet sind.

Das Projekt läuft gut an. Die Kollegen sind zufrieden die lästigen Tests los zu sein und arbeiten schnell und effektiv die Aufgaben ab. Als weiteren Einsparungseffekt hat man auf Sprintplanung und -abschluss verzichtet. Gelegentlich zeigt man dem Projektleiter und dem Kunden einen zwischenstand und diese wirken auch soweit zufrieden. Ab und zu treten Bugs während dieser Vorführung auf. Diese werden jedoch immer bis zur nächsten Vorstellung beseitigt.

Schließlich erreicht das Projekt einen Stand, in dem die ersten Testbenutzer des Kunden auf das System kommen. Und schnell stellt sich die Ernüchterung ein. Zwar funktionieren alle Module so, wie sie vom Entwickler entwickelt wurden, doch einige gingen einfach komplett an der Anforderung vorbei. Andere erfüllen zwar ihre Aufgabe, doch bei der ersten Fehleingabe entstehen völlig unnütze Daten oder das System katapultiert sich in einen undefinierten Zustand. Auch fachliche Defizite werden schnell wieder offenkundig, da der Projektleiter des Kunden zwar weiß worum es in der Anwendung ging, er selbst jedoch nicht aus der Fachabteilung kommt, sondern Teil der IT ist. Schnell werden Fragen laut. Warum wurde die Fachseite in die Erstellung der Tests nicht involviert? Wie wurde denn dies oder jenes überhaupt getestet? Natürlich wurde das neue Testvorgehen nicht schriftlich fixiert, da es ja unter dem Radar laufen sollte und nun passiert das, was zu erwarten war. Der Projektverantwortliche auf Kundenseite zieht seinen Kopf aus der Schlinge und beruft sich auf das Angebot. Dort steht ja ganz klar etwas von der Erstellung von Testfällen für die einzelnen Testschritte der Testphase.

Das Ganze eskaliert. Der Projektverantwortliche des Kunden wird abgezogen und ein Projektteam übernimmt die Fertigstellung. Es stellt sich heraus, dass das Projekt einige schwerwiegende Punkte falsch oder unzureichend implementiert hat. Die Fehlerrate ist überdurchschnittlich hoch und Testergebnisse sind nicht nachvollziehbar. Der Lieferant bangt um Folgeaufträge, da es sich um einen wichtigen Kunden handelt und verspricht die Missstände zu beseitigen. Es wird sich darauf verständigt die fehlenden Tests nicht mehr nachzuholen und die Bugs im Eskalationsmodus zu beheben. Ein Testteam des Kunden wird aus der Fachabteilung zusammengestellt und die Fehler gefunden und behoben. Das Budget war bereits vorher stark strapaziert und für Bugfixing bleiben lediglich 5 % über, die nun deutlich überschritten werden. Insgesamt belaufen sich die Mehraufwände auf weitere 15 % und das Projekt hat damit die Grenze der Wirtschaftlichkeit erreicht. Beide Parteien bringen das Projekt zu Ende. Die fertiggestellte Applikation ist lauffähig. Leider nicht so performant wie erhofft, denn dafür hat unter dem Strich die Zeit gefehlt. Änderungen sind teuer, da man sich immer durch den Code der Eskalationsphase quälen muss, welcher natürlich mit der heißen Nadel gestricht wurde. Durch das fehlen von Unit-Tests sind auch nachfolgende Änderungen nicht ohne Risiko und Fehler schleichen sich immer wieder ein, die auch die Wirtschaftlichkeit der Änderungen immer wieder gefährdet. Unter dem Strich kann dieses Projekt zwar als Erfolg, jedoch nicht als Glanztat gewertet werden und jeder Entwickler stöhnt leise auf, wenn wieder eine Änderung daran stattfinden soll oder ein Bug aus alter Zeit doch noch aufgrund von Gewährleistungsansprüchen gelöst werden muss.

Hätte all das verhindert werden können? Meiner Meinung nach ja. Und auch wenn in diesem Beispiel mehr Faktoren als nur das Testmanagement eine Rolle gespielt haben, ist es doch dieser Punkt auf den ich mich konzentrieren möchte. Weitere Faktoren waren sicherlich bereits im Angebot mit fehlenden Abgrenzungen und unzureichenden Fachkenntnissen, oder auch das knappe Budget der Kundenseite. Beides lässt sich nicht so einfach abstellen aber ich werde diese Themen in einem späteren Beitrag sicherlich noch einmal ausführlich behandeln.

Warum sollten wir Testmanagement betreiben? Ich denke, es wurde deutlich. Testmanagement umfasst viele verschiedene Aspekte mit dem gleichen Ziel. Die Anforderungen des Kunden möglichst scharf zu zeichnen, diese durch den Kunden abnehmen zu lassen und anschließend genau gegen diese Anforderungen zu entwickeln und das Ergebnis anhand dieser Anforderungen zu verifizieren. Wie kann das funktionieren? Nun, als erstes haben wir einen Wunsch von einem Kunden. Im Agilen Prozess nennen wir das einmal Feature. Jedes Feature besteht aus einer Anzahl an Anforderungen oder Use-Cases oder User-Stories, welche alle umgesetzt werden müssen, damit der Kunde das Feature benutzten kann. Beispielsweise könnte das Feature eine Kontaktverwaltung sein. Die einzelnen Use-Cases sind dann Anlegen, Löschen, Bearbeiten, Anzeigen, Exportieren etc. Jeder Use-Case hat dann noch Vorgaben. So genannte Abnahmekriterien. Abnahmekriterien für die Anlage können Pflichtfelder, Validierungen, Designvorgaben oder Ansprechzeiten sein.

481cd1a2-bf0c-4c03-a9e8-87d81bf15e91tests%20pro%20artefakt

Und genau dieser Struktur stellen wir nun unsere Tests gegenüber. Beispielsweise werden für die Akzeptanzkriterien entsprechende Unit-Tests erstellt. Für die Anlage der Pflichtfelder prüfen wir wie sich das Feld verhält, wenn es ausgefüllt wurde, wenn es nicht ausgefüllt wurde und wenn in ein Zahlenfeld Text eingetragen wird. Entsprechen alle Testergebnisse unseren Erwartungen, können wir davon ausgehen, dass das Akzeptanzkriterium damit erfüllt ist.

Nun schreiben wir noch einen Oberflächen-Test für den Endnutzer. Dort sollten wir die Akzeptanzkriterien berücksichtigen. Also etwa lege einen Eintrag an. Prüfe dabei ob die Pflichtfelder richtig dargestellt werden. Prüfe ob die Validierungen greifen, prüfe ob die Designvorgaben stimmen. Prüfe ob die Reaktionszeit im gewünschten Bereich liegt. All das kann in einem oder in mehreren Testfällen geschrieben werden. Da dieses Beispiel tatsächlich alles die Anlage behandelt würde ich alles zusammen in einen Test schreiben. Würde es Anlegen und Löschen behandeln wären es 2, usw.

Als letztes machen wir unseren Integrationstest und prüfen damit, ob unser neu erstelltes Feature auch zu den restlichen Komponenten passt. Das kann bspw. dann interessant werden, wenn der Kontakt als Referenz zu einem Kunden dient oder für Veranstaltungen. Wir führen also alle Tests unserer Use Cases nun gemeinsam auf der Integrationsumgebung aus.

All diese Arbeit erfüllt 4 Ziele. Erstens, durch die Untergliederung der Features bis hinunter zu Akzeptanzkriterien haben wir eine Anforderungsebene erreicht, auf der sich auch der Entwickler wohl fühlt und genau weiß was er machen muss, damit das Feature umgesetzt werden kann.

Zweitens, der Kunde versteht bei dieser Untergliederung den Zusammenhang zwischen seinem Feature und den Akzeptanzkriterien des Entwicklers und kann anhand dieser Abstufung verstehen was er da genau vor sich stehen hat und auch was er von der fertigen Anwendung erwarten kann.

Drittens, durch dieses Verständnis kann der Kunde die Akzeptanzkriterien freigeben, bevor die eigentliche Entwicklung startet. Damit haben wir die Sicherheit, dass wir die Anforderung richtig verstanden haben und wir haben eine konkrete Liste bei der wir sagen „Lieber Kunde, das waren die konkreten Anforderungen, die wir umgesetzt haben. Nichts links, nichts rechts davon. Wenn jetzt etwas fehlt ist das ein Change.“ Das gibt uns Planungssicherheit.

Und schließlich viertens, durch die Erstellung, Ausführung und Protokollierung der Tests erhalten wir die Sicherheit, dass die Anwendung tut was sie soll und der Kunde erhält die Sicherheit, dass wir auch alle Akzeptanzkriterien und damit schlussendlich das Feature vollständig umgesetzt haben.

Und somit erreichen wir unser eigentliches Ziel. Wir setzen genau das um, was der Kunde fordert und zwar so, wie es besprochen war. Die Missverständlichen Features wurden in einfach verständliche Akzeptanzkriterien heruntergebrochen. Natürlich macht das alles Mehraufwände. Doch wir sparen am Ende die Zeit bei der Fehlerbehebung und der Nacharbeit wegen falschen oder fehlenden Schritten wieder ein. Leider ist Testmanagement immer eine Gefühlssache, da man natürlich nicht messen kann, wie viel Zeit man dadurch gespart oder mehr verbraucht hat. Währen die guten Ergebnisse mit Testmanagement auch ohne erreichbar gewesen? Ich sage, vielleicht. Aber nur dann, wenn es sich um einen stark standardisierten Prozess handelt und jeder beteiligte über großes Fachwissen verfügt. Für einen Dienstleister im Projektgeschäft halte ich es für nicht realistisch und dementsprechend das Testmanagement für unabdingbar.

Mehr zum Thema?

Komponenten-, Integrations-, System- und Abnahmetests

Veröffentlicht in Qualitätssicherung, RealisierungKommentar hinterlassen

Ein kleiner Exkurs. Diesmal zu Testverfahren. Ich war gerade im Gespräch mit einem Kollegen über verschiedene Testverfahren. Dabei kam die Frage auf, wie man verschiedene Testfälle angehen kann. Hier nun also das Resultat.

Komponententest

Klassische Unit-Tests. Im Minimalmodell müssen hier vor allem die Schnittstellen zwischen den Systemen abgetestet werden. Die meisten Qualitätsverfahren gehen davon aus, dass die meisten Fehler genau an den Schnittstellen passieren, da der Entwickler sein eigenes Modul gut kennt und die Fehler ehr durch unerwartete Parameter entstehen können.

Im Fall von O365 ist JavaScript wahrscheinlich die häufigste Oberfläche. Daher würde ich die Unit-Tests auch auf dieser Ebene ansiedeln und jede Kommunikation zwischen der Oberfläche und dem Backend abtesten. So wissen wir, welche Funktionen wir aufrufen und bei welchen Parametern wir welche Ergebnisse erwarten. Genau diese würde ich hier testen. So kann man bei jedem Aufruf einmal den Positivfall und die eingebauten Fehlerfälle abtesten.

Ein Beispiel:
GetYearOfDate(„2007-12-12“) assert „2007“
GetYearOfDate(„2. Feb. 2017“) assert „2017“
GetYearOfDate(„30.02.2002“) assert InvalidDateException

Integrationstest

Integrationstests sind Testfälle die zu Testszenarien verbunden sind. Ich habe das zum Beispiel immer gemacht, indem ich mir eine UserStory/UseCase/Requirement des Kunden geschnappt habe. Das war mein Testszenario. Dann habe ich für jedes von mir identifizierte Akzeptanzkriterium einen Testfall geschrieben um es abzuprüfen.

Diese würde ich üblicherweise im VSO Test Manager schreiben. Der Vorteil ist, dass wir diese Testfälle über unseren SSO-Login und den Web-Client auch bei Kunden in ihrem eigenen System nutzen können. Für ausgeführte Testfälle erhalten wir dann nämlich auch ein sehr detailliertes Testprotokoll.

Idealerweise werden Integrationstests auf einer expliziten Testumgebung (der INT-Stage) ausgeführt. Diese Testfälle sind bei mir immer durch einen Tester auf Entwicklerseite ausgeführt worden. Nicht jedoch durch den Entwickler, der das Modul geschrieben hat. Gerne aber durch einen anderen Entwickler, der daran nicht beteiligt war.

Ein Beispiel:

Anforderung:
Ein Nutzer möchte eine Übersicht aller seiner aktiven Projekte aus der Projektliste auf der Startseite.

Implizite Akzeptanztests (zur Abnahme beim Kunden):

  • Es muss möglich sein, dass auf der Startseite ein Anzeigemodul (z.B. Webpart) platziert wird, dass eine Liste von Projekten anzeigen kann
  • Die Liste auf einen speziellen Nutzer gefiltert werden
  • Projekte anderer Nutzer sollen nicht angezeigt werden
  • Es sollen nur aktive Projekte aus der Liste ermittelt werden.
  • Inaktive oder beendete Projekte sollen nicht angezeigt werden.

In diesem Fall schreiben wir ein Testszenario „Aktuelle Projektübersicht eines Nutzers“ und haben darin 5 Testfälle, die jeweils ein Akzeptanzkriterium enthalten.

Systemtest

Der Systemtest ist die Gesamtheit aller Testszenarien die hier im Zusammenspiel getestet werden. Es sollte also eine Testumgebung geben (normalerweise der QA-Stage), auf der kurz vor der Abnahme einmal alle Komponenten installiert werden. Hier testet ein Test-Team, welches wieder vom Entwicklungsteam gestellt werden kann.

Bei mir war es oft so, dass zu diesem Zeitpunkt bereits einige Key-User auf der Plattform unterwegs waren und über Exploratory Testing – also freies Testen nach Gefühl – unterstützt haben, um somit Fehler zu finden, die mehr Fachwissen benötigen.

Auch gibt es als Output ein Testprotokoll.

Abnahmetest

Dieser kann als einziger Test nicht durch den Zulieferer erfolgen. Er wird auch User Acceptance Test (UAT) genannt und lässt die späteren Nutzer – oder eine Teilmenge davon – auf die Umgebung. Im Idealfall kann dieser Test bereits auf der späteren Produktivumgebung stattfinden, damit sichergestellt ist, dass alles richtig eingerichtet wurde. Sollte dies nicht möglich sein, findet der Test auf der QA-Umgebung statt, welche per Definition identisch mit der Produktivumgebung ist.

Zusammenfassung

Komponententest dienen der Abprüfung der Applikationsschnittstellen über Unit-Tests um die Konsistenz der Applikation zu gewährleisten. Liefergegenstand ist das Protokoll der Unit-Tests.

Die Integrationstests entsprechen dem Schreiben von Testszenarien anhand der Requirements und von Testfällen anhand abgenommener Akzeptanzkriterien. Ausführung erfolgt bei Fertigstellung einzelner Module auf der Integrationsumgebung. Liefergegenstand ist das Testprotokoll der Integrationsumgebung.

Als Systemtest versteht man die Ausführung aller Testszenarien der Integrationstests. Ausführung erfolgt auf der QA-Umgebung bei Abschluss der Implementierungsphase. Liefergegenstand ist das Testprotokoll der QA-Umgebung.

Und der Abnahmetests beschreibt die Ausführung aller Testszenarien oder eigener Tests auf der QA- oder Produktivumgebung durch die Fachabteilung. Wir sind hier lediglich beratend tätig und halten Ressourcen für die Fehlerbehebung bereit.

Projekt Kick-Off

Veröffentlicht in RealisierungKommentar hinterlassen

Was ein Kick-Off Meeting erreichen sollte

Eine Frage aus dem Daily Business. Was muss ein Kick-Off Meeting erreichen? Oder besser gefragt, was kann ein Kick-Off Meeting erreichen? Meine Meinung dazu.

Ich weiß, dass PRINCE2 normalerweise keine Kick-Off Veranstaltung kennt. Dennoch sehe ich es als eine essentielle und notwendige Veranstaltung. Vor allem dann, wenn das Projektteam nicht in der immer gleichen Aufteilung unterwegs ist. Kann man also darauf verzichten, wenn man Beispielsweise ein Scrum-Team hat und dieses Team dann immer wieder in der gleichen Rollenverteilung auf neue Projekte losgelassen wird? Selbst da würde ich ungern darauf verzichten. Denn dieses Meeting bietet allen Projektbeteiligten die Möglichkeit sich gegeneinander kennen zu lernen und einen ersten Eindruck zu gewinnen. Außerdem wird in diesem Meeting das Verständnis der einzelnen Aufgaben, die fachlichen Hintergründe, die Personen und Rollen geschaffen. Sowohl für das Projektteam, als auch den Auftraggeber.

Somit ist aus meiner Sicht das Kick-Off lebensnotwendig für einen Projekterfolg. Und zwar nicht als Monolog des Projektleiters, sondern als kollegialer und positiver Austausch, bei dem der Projektleiter der Moderator ist. Ein Kick-Off sollte meiner Meinung nach folgende Ziele haben:

Das Projektziel sollte klar kommuniziert sein.
„Am Tag X müssen wir Y fertig haben, damit der Kunde damit Z erreicht. Der Milestone A ist dabei von essentieller Wichtigkeit, da er die Kernkomponente darstellt.“ Das Projektziel und die Gründe des Kunden für dieses Ziel schaffen ein Verständnis für das Projekt und jeder Einzelne kann dann beurteilen, an welcher Stelle eventuell etwas zurückgestellt werden kann, um am Tag X die notwendigen Komponenten bereit zu haben. Nacharbeiten sind normal, dürfen aber nicht das Ziel des Kunden behindern. Und im Notfall muss man ein Provisorium einrichten, um dem Kunden das Ziel zu ermöglichen. Wobei hier Vorsicht geboten ist, denn nichts hält länger als ein Provisorium!

Klare Definition der Verantwortlichkeiten der einzelnen Projektmitglieder
Welche Aufgaben hat jemand zu erfüllen und welche nicht? Im Gespräch mit verschiedenen Beteiligten eines bestimmten Projektes ist mir hier ein Paradebeispiel aufgefallen. In diesem Projekt gab es einen Beteiligten. Er wurde vom Projektleiter als Softwarearchitekt gesehen. Dies wurde aber scheinbar nicht offen genug kommuniziert, oder die damit verbundenen Verantwortlichkeiten waren nicht klar. Denn der Betroffene selbst hat sich als technischer Ansprechpartner für den Kunden und Vermittler zu den Entwicklern wahrgenommen. Davon, dass er für die Konzeption der Architektur und deren Überprüfen verantwortlich war, wusste er jedenfalls nichts. Derartige Unklarheiten müssen direkt im Kick-Off beseitigt werden, indem sich jeder Projektmitarbeiter in eigenen Worten auf sein Ziel und seine Aufgaben commited. Dies sollte für spätere Nachvollziehbarkeit oder Projektmitglieder, die später in das Projekt kommen, auch schriftlich fixiert werden.

Konkrete Vermittlung der Milestones, der Aufgaben und der Definition of Done
Wann muss welches Ziel erreicht werden? Welche Aufgaben müssen dafür realisiert werden und wann können sie als erledigt betrachtet werden? Und auch, wer wird wann welche Aufgabe angehen und voraussichtlich abschließen können? Wo ist der kritische Pfad der Applikation und wie können wir ggf. Ausfallsicherheit für einzelne Personen schaffen? Oder haben wir eine Möglichkeit den kritischen Pfad mit einer zusätzlichen Person zu entlasten? Wenn diese Themen klar und transparent sind, ist es dem Team möglich ein Gesamtverständnis zu erhalten und bei Bedarf den Kollegen hilfreich beiseite zu stehen.

Welche Methoden nutzen wir technologisch und organisatorisch. 
Darüber habe ich bereits an anderen Stellen viel gesprochen und möchte hier nicht detailliert auf die Methoden eingehen, da es ansonsten den Rahmen sprengen würde. Als Keywords seien Scrum vs. V-Modell, Unit-Tests & User Acceptance Tests, Azure DevOps und Continues Integration genannt.

Welche Schwierigkeiten gibt es noch?
Commitment auf die Probleme, einen Verantwortlichen und mögliche Lösungsansätze. Alles was zu dem Kick-Off noch nicht klar ist oder Probleme die noch nicht behoben sind, müssen in einer Liste erfasst und mit einem Verantwortlichen versehen werden. Auch ein Termin für die Bearbeitung ist notwendig.

Das sind aus meiner Sicht die wichtigsten Erkenntnisse eines Projekt-Kick-Offs. Das Kick-Off sollte übrigens auch mit dem Kunden stattfinden, sodass er weiß was getan wird und sich abgeholt fühlt. Ich bin ein Freund der offenen Kommunikation mit dem Kunden. Schließlich sitzt auf der anderen Seite auch nur ein Mensch und wir sollten mit ihm arbeiten, statt gegen ihn. Wenn es Probleme gibt, kommunizieren wir sie. Dann hat der Kunde die Möglichkeit darauf zu reagieren. Schlimmer wird es, wenn er davon überrascht wird oder anfangen wird Dinge zu faken. Holt den Kunden mit ins Boot und lasst ihn die Entscheidungen mittragen. Das nimmt den Druck aus der Sache und eventuell hat auch der Kunde noch eine Idee zur Lösung.

Mehr zum Thema?

Was ist Application Lifecycle Management (ALM)?

Veröffentlicht in Allgemein, Angebotsphase, Konzeption, Qualitätssicherung, Realisierung, Release, WartungKommentar hinterlassen

Application Lifecycle Management beschreibt einen ganzheitlichen Ansatz, der eine Anwendung während allen Phasen der Software begleitet. Er definiert Artefakte und Rollen und sorgt dafür, dass die einzelnen Schritte der Realisierung eingehalten und geprüft werden. Der Sinn von ALM liegt in einer Steigerung der Gesamtqualität der Software und der Zusammenarbeit mit dem Kunden, sowie in einer möglichst weitgehenden Standardisierung von Einzelschritten, dass Mitarbeiter der gleichen Rolle in verschiedenen. Der Gesamtprozess untergliedert sich dabei in verschiedene Phasen, die nachfolgend einzeln beschrieben werden.

Analyse- und Anforderungsphase

In diesem Schritt wird der konkrete Bedarf des Kunden ermittelt und in seinem betriebswirtschaftlichen Gesamtkontext bewertet. Ziel ist es die Bedürfnisse des Kunden so konkret wie möglich zu verstehen um in der nächsten Phase einen geeigneten Lösungsansatz dafür auszuwählen.

Typische Artefakte dieser Phase sind das Lasten- und Pflichtenheft, welche mit ersten Mockups und ersten Designentwürfen angereichert werden können. Auch Entwicklungs-, Design- und andere Richtlinien des Kunden sollten zu diesem Zeitpunkt durch den Kunden bekannt gemacht werden.

Beteiligte Personen in dieser Phase sind der Kunde und die Business Consultants. Weitere Personen wie Architekten und Designer können bei Bedarf unterstützen.

 Konzeptionsphase

Die Konzeptionsphase nutzt die Erkenntnisse aus der Anforderungsphase und wählt einen geeigneten Lösungsansatz für die Problemstellung aus. Während der Konzeptionsphase kann es immer wieder zu Rücksprüngen in die Analyse- und Anforderungsphase kommen, wenn Anforderungen nicht präzise genug waren oder neue Gesichtspunkte erneute Fragen aufstellen. Ziel dieser Phase ist es, einen Lösungsansatz zu wählen, der den Bedürfnissen des Kunden entspricht und auch robust genug ist, um künftige Änderungen und Weiterentwicklungen abzubilden.

Typischerweise werden während der Konzeptionsphase ein Grob- und ein Feinkonzept erstellt, welche um weitere Konzepte für Design, Software-Architektur, Release Management und Test Management ergänzt werden sollten.

Beteiligte Personen in der Konzeptionsphase sind Projektleiter, Software-Architekten, Qualitätsmanager und Designer. Business Consultants und ggf. die Kundenseite können bei Bedarf unterstützen.

 Realisierungsphase

Die Realisierungsphase umfasst die eigentliche Umsetzung einer Lösung und geht vom Aufsetzen der Entwicklungs- und Abnahmeumgebungen über die Entwicklung der Software und begleitenden Dokumente bis zur Installation der Lösungen in der Integrationsumgebung. Am Ende dieser Phase müssen die Anforderungen des Kunden durch das Umsetzungsteam vollständig implementiert, dokumentiert und getestet sein.

Artefakte dieser Phase sind die eigentliche Lösung, Deployment-Skripte, das Installations-, Administrations- und Benutzerhandbuch, sowie durch den Entwickler ausgeführte Testszenarien und Unit Tests.

In dieser Phase tragen Entwickler, Designer und Tester die Hauptlast der Arbeit. Ergänzt werden diese durch Projektleiter, Software-Architekten und Qualitätsmanager, welche die Ausführung überwachen und steuern.

 Qualitätssicherungsphase

Die Qualitätssicherungsphase beginnt mit dem Abschluss der Realisierung und dem Beginn des Abnahmeprozesses. Der Abnahmeprozess startet, wenn die Entwicklung der Software abgeschlossen und die Tests durch den Entwickler erfolgreich ausgeführt werden konnten. Der Test durch den Entwickler kann z.B. auf einer Entwicklungs- oder Integrationsumgebung ausgeführt worden sein.

Die Qualitätssicherungsphase selbst umfasst den Review aller erstellten Dokumente und Testfälle, sowie die Prüfung der Software anhand der Testfälle. Außerdem können hier weitere Mittel wie Exploratory Tests genutzt werden, um die Qualität weiter zu steigern. Werden Fehler gefunden, werden diese Dokumentiert und an das Realisierungsteam zurück gespiegelt. Diese haben dann in einer Nachbereitungsphase die Möglichkeit diese Fehler zu beseitigen. Fehler gelten wiederum als behoben, wenn Software, Dokumentation und Testfälle vollständig korrigiert wurden. Ist die Nacharbeit erfolgreich abgeschlossen erfolgt eine neue Prüfungsphase. Nacharbeit- und Prüfungsphase wechseln sich so lange ab, bis keine Fehler an dem Produkt mehr gefunden werden. Das Produkt kann dann an den Kunden zur Abnahme übergeben werden. Wenn dann keine Nacharbeit mehr anfällt, ist diese Phase abgeschlossen.

Ergebnis dieser Phase sind, dass das Produkt auf allen Abnahmeumgebungen (z.B. Integrationsumgebung und QA-Umgebung) erfolgreich getestet werden konnte. Dies wird üblicherweise in einem Abnahmedokument festgehalten. Weitere Artefakte können das Statusprotokoll der ausgeführten Tests oder auch ein Protokoll der Unit Tests sein.

Hauptverantwortlich in dieser Phase sind der Qualitätsmanager und die Tester. Weitere Aufgaben übernehmen der Ressourcen aus der Realisierungsphase. Die Abnahme am Ende der Qualitätssicherungsphase erfolgt durch den Kunden.

 Release- und Deployment-Phase

Die Release und Deployment Phase beschäftigt sich mit der Paketierung und Auslieferung der Software auf die Produktivumgebung. Hierfür sollte über ein Build-Werkzeug, wie zum Beispiel den Team Foundation Server (Visual Studio Online), nach einem standardisierten Vorgehen eine Release-Version des Produktes erzeugt und paketiert werden. Dieses Paket kann anschließend entweder vollautomatisiert oder administrativ über Deployment-Skripte auf dem Produktivsystem installiert werden. Sind beide Optionen nicht gangbar wird ein ausführliches Installationshandbuch benötigt, welches ebenfalls den ALM-Prozess durchlaufen muss.

Ein weiterer wichtiger Punkt dieser Phase ist die Versionierung der Software. Es muss sichergestellt werden, dass jede Version beim Kunden wartbar bleibt und auch zukünftige Bugfixes in eine alter Version übernommen werden können. Die Informationen dafür sollten aus dem Release Management Konzept kommen.

In dieser Phase findet beim Kunden auch die Schulung der künftigen Anwender des Produktes statt, sofern dies erforderlich ist. Die Schulungsunterlagen dafür sind entweder bereits in der Realisierungs- und Qualitätssicherungsphase entstanden, oder können während der Release-Phase erstellt werden. Wichtig ist, dass auch diese einen Review durch das Qualitätsteam erhalten. Die Schulung beim Kunden wird anschließend entweder durch einen Business Consultant oder den Kunden selbst vorgenommen.

Ziel der Release und Deployment Phase ist ein vollständiger Rollout der Installation mit optionaler Schulung der Anwender und Go Live der Anwendung. Ist diese Phase abgeschlossen kann das eigentliche initiale Umsetzungsprojekt als abgeschlossen betrachtet werden und das Produkt wird in den Managed Service überführt.

Hauptverantwortlich für diese Phase ist der Release Manager und das Operation-Team, der entweder vom Zulieferer oder dem Kunden selbst gestellt wird. Zuarbeiten können durch Business Consultants und den Kunden erfolgen.  

Wartungs- und Optimierungsphase

Diese Phase dauert in der Regel am längsten, auch wenn der Zulieferer hiervon meist nur wenig merkt. Das Produkt ist live geschaltet und die Anwender benutzen das Produkt in ihrem Arbeitsalltag. In der Regel betreut ein Support-Team das Produkt und löst die Probleme die nach der Entwicklung im Umgang mit dem Produkt entstehen. Diese können durch Fehlverhalten der Nutzer, eine fehlerhafte Konfiguration des Produktes oder echte Programmierfehler entstanden sein.

Während dieser Phase kann es durchaus vorkommen, dass weitere Versionen des Programms durch den ALM-Zyklus gebracht werden. Ziel in der Wartungs- und Optimierungsphase ist es, solche Änderungen als Updates einzuplanen und den reibungsfreien Betrieb sicherzustellen, sodass es auf den Arbeitsalltag möglichst geringe Auswirkungen hat.

Hauptverantwortlich für diese Phase sind das Operation-Team und gegebenenfalls die Mitglieder des Managed Service für dieses Produkt beim Zulieferer.