Agiles Projektmanagement in der öffentlichen Verwaltung: Mehr Flexibilität durch iterative Softwareentwicklung

Transkript

1 Agiles Projektmaagemet i der öffetliche Verwaltug: Mehr Flexibilität durch iterative Softwareetwicklug Agiles Projektmaagemet i der öffetliche Verwaltug: Mehr Flexibilität durch iterative Softwareetwicklug Der Vorteil agiler Methode eie schelle, flexible Etwicklug, bei der Kudewüsche jederzeit berücksichtigt werde köe kommt isbesodere bei komplexe Projekte zum Trage. Also bei Projekte, bei dee die fachliche ud techische Aforderuge zu Begi gar icht vollstädig beschriebe werde köe oder bei dee im Projektverlauf Aforderugsäderuge zu erwarte sid. Auch uter de Rahmebediguge öffetlicher Auftraggeber köe agile Methode zur Beschleuigug vo Softwareetwicklugsprojekte beitrage. I diesem Artikel wird erläutert, wie agile Methode wie Scrum mit der eher sequezielle Softwareetwicklug i Behörde kombiiert werde köe. Agile Methode zur Softwareetwicklug komme auch i der öffetliche Verwaltug verstärkt zum Eisatz. So utze eizele Behörde mittlerweile agile Methode beispielsweise bei der itere Etwicklug euer IT-Systeme mit eigee Mitarbeiter. Der Grud: Die Lieferate vo IT-Systeme setze für ihre itere Etwicklugsprozesse zuehmed auf agile Methode ud bide bei Bedarf ebe auch die Auftraggeber i diese mit ei. Öffetliche Auftraggeber stehe damit zuehmed vor der Herausforderug, klassische Etwicklugskozepte zur Spezifikatio ud Etwicklug vo IT-Systeme mit agile Methode zu kombiiere. Mit ihe lasse sich Etwicklugsprozesse flexibler gestalte ud Äderuge der Aforderuge im Projektverlauf leichter umsetze. Wie aber köe uter de Rahmebediguge öffetlicher Auftraggeber agile Methode agewedet werde? Überblick über die agile Softwareetwicklug Die klassische Methode der Softwareetwicklug gehe davo aus, dass die Aforderuge a ei IT-System zu Begi der Etwicklug i eiem Lasteheft vollstädig ud detailliert beschriebe werde. Dieses Lasteheft bildet die Grudlage für die Vergabe eies Auftrags a eie extere oder itere Etwickler sowie für die Abahme des fertige IT-Systems. Diese Vorgehesweise setzt voraus, dass ei och icht existieredes IT-System vor seier Etwicklug hireiched geau beschriebe werde ka, um darauf basiered eie Auftrag a eie Softwareetwickler zu vergebe. Die Erfahrug gerade mit Großprojekte i der öffetliche Verwaltug zeigt jedoch, dass i viele Fälle die Aforderuge a ei System vor der Etwicklug och icht vollstädig ud detailliert bekat sid. Die Abstimmug der Aforderuge ud die Erstellug umfagreicher Lastehefte ehme zudem i der Regel so viel Zeit i Aspruch, dass sich i viele Fälle die Aforderuge scho wieder verädert habe, bevor das IT-System überhaupt fertiggestellt ist. Die Folge sid IT-Systeme, die bei der Eiführug icht die Aforderuge der Aweder erfülle ud die mit viel Aufwad ud Termiverschiebuge achgebessert werde müsse. Agile Methode gehe higege davo aus, dass ei IT-System iterativ etwickelt wird ud dass die Aforderuge erst im Projektverlauf schrittweise detailliert werde. Ausgagspukt der agile Etwicklug ist eie Visio des zuküftige IT-Systems, d. h. eie i der Breite vollstädige Beschreibug vo Eigeschafte des IT-Systems, die jedoch och icht i der Tiefe detailliert ist. Diese Eigeschafte werde im Fall vo Scrum i Form vo User-Storys formuliert ud i Abstimmug mit dem Auftraggeber im Product Backlog ach ihrer Priorität sortiert. Eie User-Story beschreibt eie Aforderug eies Nutzers a das System, zum Beispiel so: Als Sachbearbeiter für Bußgeld-Bescheide möchte ich ach Betroffee suche köe, um eie Liste der offee Fälle zu erzeuge. Zur Überprüfug der korrekte Umsetzug eier User-Story, auch für die Abahme, werde Akzeptazkriterie formuliert, wie zum Beispiel: Vorbedigug: Zu eiem Betroffee existiere mehr als zwei offee Bußgeld- Bescheide. Aktio: Der Nutzer wählt de Betroffee aus. Ergebis: Das System gibt eie Hiweis auf die offee Bußgeld-Bescheide. Die Etwicklug des Systems verläuft i Iteratioe mit zwei bis vier Woche Dauer. Zu Begi jeder Iteratio werde Eigeschafte i der Reihefolge ihrer Priorisierug aus dem Product Backlog für die Umsetzug ausgewählt. Ierhalb der Iteratio werde diese Eigeschafte detailliert aalysiert ud umgesetzt. Für die Umsetzug werde immer ur so viele Eigeschafte ausgewählt, wie i eier Iteratio implemetiert werde köe. Am Ede eier Iteratio steht jeweils eie getestete, ausführbare Softwareversio zur Verfügug, die vom Aweder beutzt werde ka. Nach Abschluss jeder Iteratio ka der Auftraggeber als Grudlage für die ächste Iteratio de Product Backlog veräder ud eu priorisiere. Im Gegesatz zur klassische Vorgehesweise, bei der zuächst i eier lage Phase alle Aforderuge im Detail beschriebe werde ud da erst mit der Umsetzug begoe werde ka (siehe Abbildug 1), ist bei agilem Vorgehe also ur eie kurze Phase für die Erstellug des Product Backlogs erforderlich. Die Detaillierug der Aforderuge erfolgt schrittweise i de spätere Iteratioe. Damit köe im Projektverlauf Veräderuge der Aforderuge ud Erfahruge der Aweder flexibel i die Etwicklug eifließe. Vorteile des agile Vorgehes Ei agiles Vorgehe bietet sich vor allem da a, we fachliche ud techische Aforderuge zu Projektbegi icht vollstädig beschriebe werde köe, bei- 05/

2 Agiles Projektmaagemet i der öffetliche Verwaltug: Mehr Flexibilität durch iterative Softwareetwicklug Abb.1: Typisches Phasemodell bei klassischer Etwicklug. spielsweise aufgrud der Komplexität des Projekts. Dies ist gerade i große Projekte zur Etwicklug euer IT-Systeme oftmals der Fall. Da och keie Erfahruge mit eiem bestehede System vorliege, erfordert die Erstellug eies detaillierte Lastehefts sehr viel Zeit ud Aufwad, bietet gleichzeitig jedoch ur weig Sicherheit bezüglich der Frage, ob die Software ach Abschluss der Etwicklug auch die tatsächliche Aforderuge der Aweder erfüllt. Das agile Vorgehe trägt also erheblich zu eier Reduzierug der Projektrisike bei. Auch we im Projektverlauf Äderuge der Aforderuge zu erwarte sid, bietet ei agiles Vorgehe Vorteile: Sid bei klassischer Etwicklug Äderuge ötig, so muss oftmals ei umfagreiches, detailliertes Lasteheft mit alle Abhägigkeite überarbeitet werde, um Ikosisteze zu vermeide. I eiem agile Projekt wird der Product Backlog i jeder Iteratio überarbeitet. Nur die direkt für die Umsetzug vorgesehee Eigeschafte werde im Detail aalysiert. Dadurch fließe Äderuge direkt i die Etwicklug ei. Es werde also zu Projektbegi keie aufwädige Aalyse durchgeführt, die durch ei kompliziertes Äderugsmaagemet wieder überarbeitet werde müsse. Durch agiles Vorgehe ka der Auftraggeber scho zu eiem frühe Zeitpukt im Projekt lauffähige Versioe der Software überprüfe ud bei fachliche ud techische Fehletwickluge gegesteuer. Damit wird das Risiko reduziert, dass der Auftraggeber ach Abschluss vo Laste- ud Pflichteheft über eie lägere Zeitraum keie prüfbare Etwicklugsergebisse sieht ud erst relativ spät im Projektverlauf wieder eigreife ka. Die Vorteile der agile Softwareetwicklug köe jedoch ur da vollstädig geutzt werde, we Auftraggeber ud -ehmer gleichermaße i de iterative Prozess des Etwicklugsprojekts eigebude sid. Zum Abschluss eier Iteratio erfolgt typischerweise eie Vorführug der Software beim Auftraggeber, im Aschluss wird uter Eibidug vo Auftraggeber ud -ehmer der Product Backlog überarbeitet ud bei Bedarf eu priorisiert, sodass er als Basis für die ächste Iteratio diee ka. Dies setzt voraus, dass der Auftraggeber die Iteratiosergebisse zeitah prüft ud schell Etscheiduge über Äderuge am Product Backlog trifft. Ei vollstädig agiles Vorgehe lässt sich mit de Rahmebediguge des Vergaberechts für Festpreisprojekte ur schwer umsetze, da i diesem Fall ei detailliertes Lasteheft als Leistugsbeschreibug fehlt. Deoch gibt es erste Asätze für agile Festpreisprojekte (vgl. [Ope12]), bei dee ei Product Backlog zur Leistugsbeschreibug verwedet wird. Eie weitere Möglichkeit zur stärkere Nutzug agiler Methode ist der Eisatz aderer Vergabeverfahre, beispielsweise ei Verhadlugsverfahre, das mehr Spielraum für die Abgrezug des Leistugsgegestades lässt. Agile Umsetzug eies Lastehefts Zuehmed wede Softwarehersteller auch i klassische Projekte auf Basis eies vollstädig ausformulierte Lastehefts agile Prizipie für die itere Projektorgaisatio a. Damit bleibt der vertragliche Rahme des Lasteheftes bestehe. Die Umsetzug ka i Form eies Festpreisvertrages oder eies Diestleistugsvertrages mit Obergreze erfolge. Wie wirkt sich ei solches Vorgehe auf die zetrale Prozessbereiche des Projektmaagemets ud auf die Kommuikatio mit dem Auftragehmer aus? Die Rolle des Product Owers Der Product Ower (PO) ist bei agiler Etwicklug für die Produktetwicklug zustädig. Er veratwortet die Kozeptio ud Mitteilug eier klare Produktvisio, die Festlegug ud Priorisierug der jeweils zu etwickelde Produkteigeschafte sowie die Etscheidug darüber, ob die vom Etwicklugsteam am Ede eier Iteratio gelieferte Fuktioalität akzeptabel ist. Der PO hält Rücksprache mit dem Auftraggeber ud versucht, desse Bedürfisse ud Wüsche i die Produktetwicklug eifließe zu lasse. Der PO ist damit die zetrale Schittstelle zwische Auftraggeber ud -ehmer, da er die Priorisierug vo Eigeschafte des IT-Systems mit dem Auftraggeber abstimmt ud dere Umsetzug mit dem Etwicklugsteam vereibart. Bei agiler Umsetzug eies klassische Lasteheftes wird die Rolle des PO i der Regel vom Auftragehmer wahrgeomme. Die Aforderuge des Lasteheftes werde bei diesem Vorgehe zuächst als User- Storys im Product Backlog beschriebe. Zudem priorisiert er regelmäßig i Abstimmug mit dem Auftraggeber die eigetragee User-Storys uter Berücksichtigug ihres wirtschaftliche Nutzes ud ihrer Bedeutug für de Geschäftsprozess. Auswirkuge auf das Phasemodell Bei de meiste öffetliche Auftraggeber werde für IT-Etwickluge sequezielle Phasemodelle etspreched Abbildug 1 verwedet, die im Wesetliche auf der Formulierug eies Lasteheftes, der Spezifikatio eies Pflichteheftes ud der Implemetierug des IT-Systems beruhe. Dieses klassische Phasemodell behält seie Gültigkeit grudsätzlich auch bei agilem Vorgehe des Auftragehmers, da ei iteratives Vorgehe i de meiste Vorgehesmodelle prizipiell scho vorgesehe ist ur ist dieses bei eier agile Etwicklug durch die zwei bis vier Woche dauerde Iteratioe für die Phase Defiitio Pflichte- 66

3 heft ud Desig, Implemetierug ud Test stärker ausgeprägt als bei klassische Asätze. Bei agilem Vorgehe erzeugt der Auftragehmer i jeder Iteratio direkt eie ausführbare Software, die der Auftraggeber i de jeweilige Versioe teste ud bewerte ka (siehe Abbildug 2). Bei eier Iteratiosdauer vo zwei bis vier Woche wird der Auftraggeber oftmals icht jede Iteratio prüfe köe, da für eie fudierte Test meist Mitarbeiter der Fachseite erforderlich sid, die icht kotiuierlich verfügbar sid. Eie Alterative ist es, de Auftraggeber jeweils ach mehrere Iteratioe eizubide, beispielsweise durch eie Demostratio der aktuell lauffähige Software. Eie zetrale Herausforderug bei dieser Vorgehesweise ist die ege Eibidug eies etscheidugsbefugte Gremiums auf Seite des Auftraggebers, damit über Fehler ud Äderugsbedarf schell etschiede wird. Aderfalls besteht die Gefahr, dass die Iteratiosplaug auf Seite des Auftragehmers icht eigehalte werde ka. Der Auftraggeber steht bei dieser Vorgehesweise im kotiuierliche Kotakt mit dem Auftragehmer ud ka de Projektfortschritt so direkt beurteile. Hierfür ist seites des Auftraggebers ei dauerhafter Asprechparter zur Abstimmug mit dem PO des Auftragehmers erforderlich. Auswirkuge auf de Plaugsprozess Aus Sicht des Auftraggebers bleibt die Gesamtplaug mit de Phase ud Etscheidugspukte beim Übergag zwische zwei Phase erhalte. Allerdigs wird der Auftragehmer bei agilem Vorgehe zu Projektbegi keie vollstädige Projektstrukturpla zur Bildug vo Arbeitspakete erstelle ud keie Projektablaufpla zur zeitliche Plaug eizeler Arbeitspakete etwickel. Vielmehr wird zu Begi jeder Iteratio eie begrezte Mege vo Aforderuge für die Umsetzug ausgewählt ur für diese erfolgt da eie detaillierte Umsetzugsplaug für das Pflichteheft ud die Implemetierug. Die Plaug der Phase Defiitio Pflichteheft ud Desig, Implemetierug, Test erfolgt bei agiler Etwicklug iterativ. Für jede Iteratio ist jeweils eie feste Dauer vorgesehe, die Orgaisatio der Arbeit ierhalb eier Iteratio erfolgt i Eigeveratwortug durch das jeweilige Team. Der Auftraggeber muss etscheide, ob er bei jeder dieser Iteratioe ivolviert sei möchte oder ur bei der Fertigstellug größerer Teilbereiche der Software eibezoge werde soll. Wofür er sich auch etscheidet: Es sollte darauf geachtet werde, das Feedback des Auftraggebers stets so früh wie möglich eizuhole, um die Etwicklug isgesamt icht zu verzöger. Auch die gemeisame Plaug der Iteratioe durch de Auftragehmer ud die Eibidug des Auftraggebers sollte möglichst frühzeitig erfolge. Nur so ka der Auftragehmer jeweils Pufferzeite für die Rückmeldug des Auftraggebers ud die Eiarbeitug etwaiger Äderuge i de Product Backlog eiplae. Der Auftraggeber ka higege die ötige Kapazitäte für die Bewertug der verschiedee Iteratioe berücksichtige. Agiles Vorgehe i eier sequezielle Umgebug Das Beispiel i Abbildug 3 ist typisch für die Nutzug agiler Vorgehesweise i Großprojekte, bei dee viele Eizelsysteme zu feste Release-Zeitpukte eigeführt werde müsse. Die Plaug auf der Makroebee erfolgt ahad vo Releases, die jeweils i folgede Phase uterteilt sid: eie Aalysephase eie Umsetzugsphase eie Phase für Test ud Deploymet I der Aalysephase werde die Aforderuge i Form vo User-Storys formuliert. Vor Begi der Umsetzug wird ei verbidlicher Release-Cotaier vereibart, der im Zeitfester des Release umgesetzt werde muss. Die Verbidlichkeit ist hierbei ei sehr wichtiger Aspekt, falls ei Teil der Fuktioalität auch vo adere Systeme geutzt wird. Für die Umsetzugsphase werde Sprits geplat, i dee mehrere Teams parallel die Fuktioalität etwickel. Hierbei hat die Projektleitug die Möglichkeit, die User-Storys flexibel auf Sprits beziehugsweise Teams zu verteile. Falls im Verlauf des Release User-Storys hizukomme, gelöscht oder verädert werde, wird der Product Backlog agepasst ud gegebeefalls eu priorisiert. Die Phase Test ud Deploymet diet dem abschließede Systemtest für de komplette Release ud de Übergag i de Betrieb. Auswirkuge auf das Moitorig des Projektverlaufs Moitorig diet der Ermittlug vo aussagefähige Kezahle für ei Projekt, zum Beispiel bezüglich des Aufwads, der Qualität ud des Fertigstellugsgrades. Das Ziel des Moitorigs besteht dari sicherzustelle, dass die Leistug des Auftragehmers gemäß der vertraglich festgelegte Aforderuge hisichtlich Ihalte ud Prozesse i der vereibarte Qualität ud zum vereibarte Preis/Termi erfolgt. Bei agiler Etwicklug ist jede Iteratio als Timebox mit festem Afag ud Ede defiiert. Ierhalb der Iteratio erfolge die Plaug ud Orgaisatio der Arbeit i Eigeveratwortug durch das jeweilige Team. Moitorig durch de Auftraggeber erfolgt also icht ahad vo Arbeitspakete wie bei eier klassische Etwicklug, soder ahad der Erreichug der Ziele der Iteratioe. Nach Abschluss eier Iteratio werde jeweils die Qualität ud die Mege der umgesetzte Fuktioalität bewertet. Bei agiler Etwicklug lasse sich Kezahle, die auf dem Fertigstellugsgrad vo eizele Arbeitspakete basiere, icht awede. Stattdesse wird der Projektfortschritt ahad der umgesetzte Eigeschafte aus dem Product Backlog bewertet. Für das Moitorig ergibt sich dadurch Abb. 2: Typisches Phasemodell bei agiler Etwicklug beim Auftragehmer. 05/

4 Agiles Projektmaagemet i der öffetliche Verwaltug: Mehr Flexibilität durch iterative Softwareetwicklug Abb. 3: Kombiatio aus Release-Plaug ud agiler Umsetzug. eie adere Graularität der Messug des Projektfortschritts. Ei agiles Projekt wird ebe icht daach evaluiert, wie viele Arbeitspakete fertiggestellt sid, soder daach, wie viel der festgelegte Fuktioalität verfügbar ist. Auch die Qualität der Aufwadsschätzuge wird bei eier agile Etwicklug deutlich verbessert, da sich ach jeder Iteratio überprüfe lässt, ob die geplate Mege a Fuktioalität tatsächlich umgesetzt wurde. Auswirkuge auf das Aforderugsmaagemet Bei klassischem Vorgehe werde bereits bei der Erstellug des Lastehefts alle Aforderuge detailliert beschriebe, bei agiler Etwicklug zu Projektbegi higege ur die wesetliche Eigeschafte des IT-Systems i Form vo User-Storys. Diese User-Storys werde i der Reihefolge ihrer Priorität im Product Backlog zusammegefasst. Die detaillierte Aalyse ud Beschreibug der Aforderuge erfolgt erst ierhalb der Iteratioe. Bei der Kombiatio beider Vorgehesweise ist das Gesamtprojekt klassisch ach Phase strukturiert, die Phase der Umsetzug sid auf Seite des Auftragehmers agil strukturiert. Im Bereich des Aforderugsmaagemets wird dieser Uterschied besoders deutlich, da die Aforderuge im Lasteheft für agiles Vorgehe eigetlich scho zu detailliert beschriebe sid. Auf Seite des Auftraggebers verläuft das Aforderugsmaagemet wie bei jeder klassische Etwicklug. Die Umsetzug des Lastehefts i ei Product Backlog ud die Aufteilug auf Iteratioe erfolgt auf Seite des Auftragehmers (siehe Abbildug 4). I de Iteratioe werde die Aforderuge schrittweise i ei Pflichteheft umgesetzt ud implemetiert. Die Erfahrug zeigt, dass atürlich auch bei dem skizzierte Vorgehe Äderuge im Projektverlauf ötig sei köe. Auch hier muss ei Prozess zum Äderugsmaagemet vertraglich vereibart werde. Äderuge a Aforderuge, die och icht umgesetzt wurde, köe relativ leicht durch Apassuge des Product Backlog vorgeomme werde. Da beim agile Vorgehe das Pflichteheft icht als Gazes vor der Etwicklug fertiggestellt wird, fließe Äderuge i die Weiteretwicklug ei ud verursache weig Mehraufwad. Damit werde Äderuge vo Aforderuge bei eiem agilem Vorgehe eher als Normalfall betrachtet, währed sie bei eiem klassischem Vorgehe de reguläre Projektablauf störe. Auswirkuge auf das Testmaagemet Bei agiler Etwicklug wird i jeder Iteratio eie lauffähige Software erstellt, daher muss auch i jeder Iteratio das komplette System getestet werde. Dies setzt voraus, dass für die i eier Iteratio umgesetzte Fuktioalität auch die ötige Testfälle etwickelt ud ausgeführt werde. Die Abb. 4: Aforderugsmaagemet bei agiler Etwicklug. Testfallerstellug erfolgt also gleichzeitig mit der Etwicklug, die Mege der Testfälle immt mit jeder Iteratio zu. I jeder Iteratio werde die eu etwickelte ud die bisher scho bestehede Fuktioalität getestet, um am Ede jeder Iteratio die Korrektheit des Gesamtsystems zu gewährleiste. Da ach jeder Iteratio ei lauffähiges System vorliegt, ka der Auftraggeber kotiuierlich währed der Etwicklug teste. Die Behebug vo Fehler ud die Umsetzug vo Äderugswüsche fließe i die Plaug der weitere Iteratioe ei. Es hat sich bewährt, vor wichtige Meilesteie, zum Beispiel vor Abahme eies Release, eie spezielle Iteratio zur Behebug der restliche Fehler eizuplae. Durch dieses iterative Teste erhält der Auftraggeber scho frühzeitig eie Eidruck vo der Qualität der Software. Das Risiko, dass gravierede Fehler erst beim Abahmetest gefude werde, ist deutlich geriger. Das iterative Teste setzt allerdigs techisch de Eisatz vo Werkzeuge zur Testautomatisierug voraus, da ur so die Wiederholug der stetig zuehmede Mege a Testfälle möglich ist. Bewertug Beide Vorgehesweise klassisch ud agil habe ihre Stärke: Das klassische, eher sequezielle Vorgehe eiget sich für Projektsituatioe, i dee die Aforderuge klar beschriebe werde köe ud im Projektverlauf weitgehed stabil bleibe. Geau diese Bedigug ist i Projekte der öffetliche Verwaltug jedoch immer weiger gegebe. Kurzfristige politische Etscheiduge ud schwer plabare Ab- 68

5 hägigkeite durch die immer stärkere Veretzug der verschiedee Fachverfahre mache es für Auftraggeber i der öffetliche Verwaltug immer schwerer, i eiem realistische Zeitraum Lastehefte für IT- Systeme zu etwickel, die eierseits vollstädig, aber adererseits auch zumidest mittelfristig stabil sid. Agiles Vorgehe ist immer da sivoll, we die Aforderuge zu Projektbegi icht vollstädig ud hireiched geau beschriebe werde köe. Diese Methode eiget sich deshalb für immer mehr IT-Projekte der öffetliche Verwaltug. Friste für Vergabeverfahre ud ei hoher Zeitdruck bei der Umsetzug zwige häufig dazu, Ausschreibuge zu eiem Zeitpukt durchzuführe, a dem die politische Etscheidugsträger ud i viele Fälle auch die Verwaltug selbst och keie detaillierte Vorstellug vo der agestrebte Fuktioalität habe. Nu ist die Durchführug rei agiler Projekte für öffetliche Auftraggeber durch die Rahmebediguge des Vergabe- ud Haushaltsrechts oftmals schwierig, da ohe Lasteheft die beauftragte Leistug icht hireiched geau beschriebe werde ka. Die öffetliche Verwaltug steht also vor dem Dilemma, dass agile Vorgehesweise i viele Fälle zwar geeiget wäre, aber mit de gegebee Rahmebediguge schwer umsetzbar sid. Adererseits passe die klassische, sequezielle Vorgehesweise icht mehr zu der Literatur [Ope12] A. Opelt et al., Der agile Festpreis, Carl Haser Verlag, 2012 hohe Dyamik, mit der IT-Systeme i der öffetliche Verwaltug heute etwickelt werde müsse. Die hier beschriebee Vorgehesweise vereit die Vorteile aus beide Welte: Der Auftraggeber ka die Beauftragug auf Basis eies Lastehefts vorehme. Der Auftragehmer ka das Lasteheft iterativ umsetze ud muss das Pflichteheft icht vollstädig vor der Implemetierug erstelle. Auftraggeber ud Auftragehmer erhalte frühzeitig im Projekt Feedback über ötige Veräderuge am Lasteheft. Fachliche Äderuge köe im Projektverlauf eifacher eigearbeitet werde, da ur die bis zum Äderugszeitpukt erstellte Dokumete geädert werde müsse. Der Auftraggeber erhält eie bessere Eiblick i de Projektfortschritt, da ach jeder Iteratio ei ausführbares Ergebis vorliegt. Dies ka gerade i Großprojekte der öffetliche Verwaltug die Risike erheblich reduziere. Die Abahme ka gege das Lasteheft erfolge. Durch de kotiuierliche Test i de Iteratioe ist die Qualität der Software bei der Bereitstellug zur Abahme i der Regel scho sehr hoch. Daher ist diese Vorgehesweise ei möglicher Weg zur Nutzug der Vorteile agiler Methode uter de Rahmebediguge öffetlicher Auftraggeber. Der Autor Werer Achtert (werer.achtert@msg-systems.com) ist Leiter der Abteilug IT-Cosultig Public Sector bei der msg systems ag ud verfügt über lagjährige Erfahrug im Maagemet vo agile IT-Projekte ud der Orgaisatio vo IT-Prozesse i der öffetliche Verwaltug. 05/