In Bereichen, in denen Fehler zu Beeinträch-tigungen von Leben führen können, darf diese Kreativität jedoch nicht ungezügelt wirken. Daher galten Wasserfall- oder V-Modell verbunden mit einem starken Qua-litäts- und Regulatory Affairs Management und einem dementsprechend installierten Meilensteinsystem lange Zeit als sicherste und damit beste Vorgehensweisen bei der Entwicklung von Produkten im regulier-ten Umfeld. Effizienz und Sicherheit stehen insbesondere beim V-Modell in sich ergän-zender Koexistenz. Jedoch kann man das Ganze auch übertreiben. Viele Entwick-ler, beispielsweise von Medizinprodukten, fühlen sich durch die Gruppen, welche die qualitätssichernden Aspekte des V-Modells vertreten, gegängelt, vielleicht sogar in Fes-seln gelegt.

Wenn nun Time to Market an Bedeutung gewinnt, ist die Produktentwicklung in der Pflicht, schneller zu werden. Auf der Su-che nach (vermeintlich) effizienteren Vor-gehensweisen stößt man sehr schnell auf agile Verfahren, wie etwa Scrum. Es geht

bei diesen Modellen darum, alle Beteiligten einzubeziehen, dem gesamten Team Ver-antwortung zu übertragen, dabei mensch-liche Beziehungen und Kommunikation zu berücksichtigen und zu nutzen und wenig wertschöpfende Reibungsverluste und for-male Aspekte auf ein notwendiges Min-destmaß zu reduzieren. Die regulatorischen Vorgaben, die sich aus den Gesetzen zur Vermarktung von Medizinprodukten erge-ben, gelten jedoch trotzdem. Somit gilt es, einen gangbaren und maßgeschneiderten Kompromiss zu finden zwischen der Er-füllung gesetzlicher Vorschriften und mög-lichst hoher Effizienz und Kreativität. Wird versucht, ein agiles Vorgehensmodell in das Meilenstein- und Dokumentations-Kon-zept eines traditionellen Vorgehensmodells zu pressen, sind zwar vielleicht gesetzliche Anforderungen erfüllt, aber es geht vielfach Effizienz verloren. Der angestrebte Gewinn wird vielmehr zum Schaden. Maßgeschnei-derte Lösungen müssen her, die Effizienz und Regulatorik gleichermaßen berück-sichtigen.

Zum einen ist der Begriff des Medizinpro-dukts (medical device) per Gesetz definiert. Weltweit haben die Gesetzgeber Kategorien („Klassen“) für die Medizinprodukte fest-gelegt, abhängig davon, welche Produkte welche medizinische Wirkung haben und welcher potenzielle Schaden bzw. welche potenziellen Gefahren von ihnen mit wel-chen Konsequenzen ausgehen. So fallen beispielsweise Thermometer, Röntgengerä-te und Herzschrittmacher in unterschiedli-che Klassen. In Europa gibt es die Klassen I (s/m), IIa, IIb und III, wobei ein Gerät der Klasse III entsprechend höheres Risikopo-tenzial, längere Dauer der Anwendung oder stärkere Eindringung in den Körper in sich birgt als ein Gerät der Klasse I.

Zum anderen wurde per Gesetz und Ver-ordnungen festgelegt, dass gewisse Voraus-setzungen unabdingbar erfüllt sein müssen, um ein Medizinprodukt überhaupt verkau-fen zu dürfen. Diese Markt-Zulassungs-Voraussetzungen sind länderspezifisch und

abhängig von der Klasse des Medizinpro-dukts geregelt.

Am Beispiel von Deutschland und den USA sind die Markt-Zulassungs-Vor-aussetzungen folgendermaßen reguliert: In Europa wurden die Anforderungen an Medizinprodukte in der Medical De-vice Directive („MDD“) zusammenge-stellt. Sie ist von den EU-Mitgliedstaa-ten in nationales Recht zu überführen: in Deutschland in das Medizinprodukte-gesetz („MPG“). Darin ist geregelt, dass der Hersteller eines Medizinprodukts die Erfüllung sogenannter „grundlegender Anforderungen“ nachweisen muss und danach berechtigt ist, ein CE Zeichen anzubringen… und das Medizinprodukt in Deutschland zu verkaufen. In den USA sind die Anforderungen an die Medizinprodukte u.a. in der Quality System Regulation (QSR, 21 CFR Part 820) festgeschrieben. Die Zulassung für den amerikanischen Markt muss bei der U.S. Food and Drug Administrati-on („FDA“) beantragt werden, wobei je nach Klasse des Medizinprodukts ver-schiedene Antragsformen anzuwenden sind. In den USA verkauft werden darf das Produkt erst nach entsprechender Freigabe durch die Behörde.

… haben sich auch die Gesetzgeber gedacht und verschiedene Kontrollsysteme (wie beispielsweise Audits) eingeführt… So ist ein Audit eine ernst zu nehmende Angele-genheit. Sinn und Zweck dahinter ist die Überprüfung, ob der Hersteller zuverläs-sig in der Lage ist, sichere und wirksame Medizinprodukte zu entwickeln und zu produzieren. Kann der Hersteller das nicht nachweisen, kann ihm die Marktzulassung für das jeweilige Land entzogen werden. Audits liegt i.d.R. ein risiko-basierter An-satz zugrunde: Auditoren betrachten das Medizinprodukt oft besonders genau im Hinblick auf mögliche Gefährdungen für den Menschen und deren Gegenmaßnah-men. Prinzipiell begutachtet werden das Qualitätsmanagementsystem (das interne Qualitäts- & Prozessregelwerk, Verant-wortlichkeiten, etc.) des Herstellers und die Anwendung dessen.

Natürlich gibt es ein paar Knackpunkte da-bei …

Wesentlich in einem Audit ist, dass nur ein schriftlicher Nachweis als Begründung

zählt. Das gesprochene Wort ist gegenüber Auditoren nicht ausreichend belastbar und wird bestenfalls wie ein Gerücht oder eine Sage bewertet. Wichtig ist auch, dass be-stimmte Dokumente über ein Vier- oder Mehr-Augen-Prinzip von unabhängigen und befähigten Personen freigegeben sein müssen, um das Risiko von Fehlern und Missbrauch zu reduzieren. Um die saubere Erfüllung dieser Punkte in einem Projekt zu unterstützen, hat sich die Rolle von unab-hängig in der Organisation aufgestellten (Projekt-) Qualitätsmanagern etabliert, die als Experten auf den Gebieten der Qualität und Regulatorik mit den Entwicklungsex-perten optimalerweise Hand in Hand zu-sammenarbeiten.

Audits in Deutschland und den USA: In Deutschland muss nach MPG die Erfül-lung der grundlegenden Anforderungen nachgewiesen werden. Das bedeutet u.a., dass der Hersteller sich nach den Grundsätzen der „integrierten Sicher-heit“ richten muss, und zwar unter Be-rücksichtung des allgemein anerkannten Standes der Technik, welche man in ein-schlägigen Standards und Normen (z. B. ISO 13485, ISO 14971 und IEC/ISO 62304) findet. Der Hersteller lässt sich die Erfüllung der Normen von einem „Notified Body“ (einer akkreditierten,

benannten Stelle, z. B. dem TÜV) auf Basis von bestandenen regelmäßigen Audits zertifizieren. Wird das Audit nicht bestanden, so kann das Zertifikat und damit die Berechtigung entzogen werden, das Produkt auf dem deutschen Markt zu verkaufen.In den USA ist die FDA u.a. auch für die Kontrolle der Hersteller zustän-dig. Die FDA führt verschiedene Arten von Audits („Inspections“) durch, z.B. Quality System Inspections Level 1 bis 3, For Cause Inspections. Eine nicht be-standene Inspection kann verschiedene Konsequenzen von einem im Internet veröffentlichten „Warning letter“, „Re-call“, bis zur „Market Detention“ nach sich ziehen.

Natürlich muss sich der Hersteller an die Gesetze der jeweiligen Länder, wie z. B. an das deutsche MPG oder an die QSR in den USA, halten.

Ein hervorstechendes Thema ist dabei im-mer wieder die Dokumentenlenkung („Do-cument controls“). In diesem Zusammen-hang ist der Hersteller verpflichtet, Verfahren zur Genehmigung, Verteilung und Änderung von Dokumenten inklusive Unterschriftsre-

Abbildung 1: Regulatorisches Umfeld in der Medizintechnik-Branche

Online-Themenspecial Agility 2009

Online-Themenspecial Agility 2009 fachartikel

gelung, Reviews, etc. festzulegen, zu pflegen und natürlich sich daran zu halten.

Kurz zusammengefasst, hat der Herstel-ler die folgenden Themen genauer zu betrachten: In der QSR sind unter dem Kapitel „Ent-wicklungslenkung“ („Design controls“) Hersteller-Pflichten zur „Entwicklungs- und Entwurfsplanung“, zu den „Entwick-lungsvorgaben“, dem „Entwicklungser-gebnis“, der „Entwicklungsüberprüfung“ („Design review“), „-Verifizierung“, „-Validierung“, dem „Entwicklungstrans-fer“, den „Entwicklungsänderungen“ und der „Entwicklungsentstehungsakte“ („Design history file“) vorgegeben.Überdies muss der Hersteller, je nach na-tionaler Gesetzgebung, bestimmte Stan-dards und Normen erfüllen: Üblicher-weise sind Entwicklung und Fertigung nach dem aktuellen Stand der Technik gesetzlich gefordert. Als relevante Nor-men in der Medizinprodukte-Branche wären hier etwa

die ISO 13485 „Medizinprodukte – Qualitätsmanagementsysteme - Be-sondere Anforderungen für die An-wendung von DIN EN ISO 9001“,

die ISO 14971 „Medizinprodukte – Anwendung des Risikomanage-ments auf Medizinprodukte“,

die IEC/EN 60601 „Normen fürmedizinische elektrische Geräte“ (wie z. B. die -1-6 als ErgänzungsnormGebrauchstauglichkeit (Usability)),und

die IEC/ISO 62304 „Medizingerä-te-Software - Software-Lebenszyk-lus-Prozesse“ zu nennen.

Die IEC/ISO 62304 beschreibt ein all-gemeines Rahmenwerk für die Lebens-zyklusprozesse von Medizinprodukte-Software. Fokusgebiete dieser Norm sind Traceability der Anforderungen, Risiko-analyse, Konfigurations- und Änderungs-management.Je nach Art des Medizinprodukts sind un-terschiedliche gesetzliche und normative Anforderungen anzuwenden: In Deutsch-land werden „In-vitro-Diagnostika“, „ak-tiv implantierbare“ Medizinprodukte und „nicht invasive“, „invasive“ und „aktive“ Produkte der Klasse I, Is/m, IIa, IIb, III unterschieden.Teilweise überschreiten die gesetzlichen Vorgaben (z. B. in den USA) die Anfor-derungen aus Standards und Normen.

Bzgl. eines Entwicklungsprozesses von Me-dizinprodukten schreiben die regulatori-schen Anforderungen jedoch kein bestimm-tes Vorgehensmodell vor, auch nicht das Wasserfall-Modell und auch wenn manche Auditoren noch von diesem Modell geprägt sind.

Agile Verfahren bieten einen Sack voller Vorteile und Chancen – auch im Medizinprodukte- UmfeldMit dem Einsatz agiler Vorgehensweisen verspricht man sich unter Anderem folgen-de Vorteile:

Enge Zusammenarbeit zwischen Be-nutzer/Auftraggeber und Entwickler ermöglicht flexibles Eingehen auf sich verändernde oder unklare Anforderun-gen

Abbau administrativen Overheads Frühes Testen für hohe Qualität Regelmäßige Verfügbarkeit lauffähiger

Systeme Bessere Pflegbarkeit durch hohe Code-

Qualität und breitere Teilung des Wis-sens

Intensivere Kommunikation und Infor-mation im Team und damit Arbeiten mit stärkerem Fokus auf die Software-Entwicklung

Integriertes Vorgehensmodell aus Pro-duktentstehung, Projektmanagement und Qualitätsmanagement

Wenn man einen herkömmlichen Wasserfall-Prozess betrachtet, folgen Phasen wie Vorbe-reitung – Analyse – Design – Implementie-rung – Test – Abschluss nacheinander.

Einen agilen Prozess kann man sich so vorstellen, dass nach der Vorbereitung alle

diese Aktivitäten (Analyse, Design, Imple-mentierung, Test) in jeder Iteration stattfin-den und so lange wiederholt werden, bis das Produkt fertig ist, siehe auch Abbildung 2. Der Abschluss bleibt am Ende wie gehabt.

Bei agilen Methoden werden die Require-ments kontinuierlich gesammelt (in Scrum im sog. Product Backlog) und priorisiert behandelt. Und erst dann, wenn die Requi-rements zur Realisierung anstehen, werden sie ausreichend analysiert und herunterge-brochen, – im Gegensatz zu einer detaillier-ten „up-front“-Spezifikation im Wasserfall-prozess. Ein weiteres agiles Grundelement wäre sodann die Bearbeitung der Require-ments in kurzen Iterationen fester Länge (time-boxes) bis hin zu potenziell ausliefer-baren Produkt-Inkrementen.

Unter Einhaltung gewisser Spielregeln kann solch ein agiles Verfahren durchaus auch im Medizinprodukte-Umfeld mit all seiner Regulatorik angewendet werden. Die einzuhaltenden Spielregeln beziehen sich insbesondere auch auf Dokumentati-on, Dokumentenlenkung, Reviews und ein geplantes, kontrolliertes Vorgehen.

Die ZwickmühleDie bisher üblichen Verfahren sind dadurch gekennzeichnet, dass Meilensteine, deren Inhalte gemäß Wasserfallprozess (siehe Ab-bildung) und den regulatorisch zu erfüllen-den Anforderungen ausgelegt sind, gesetzt und möglichst auch zeitlich und inhaltlich

erreicht werden. In den frühen Phasen des Projekts sind die Meilensteine darauf aus-gerichtet, Analyse zu betreiben und zu-nächst das WAS des Projektinhalts, später das WIE der Umsetzung in Dokumenten zu formulieren. Mittels Reviews werden diese

fachartikel

www.objektspektrum.de3

Abbildung 2: Traditioneller vs. Agiler Entwicklungsprozess

4Online-Themenspecial Agility 2009

Online-Themenspecial Agility 2009 fachartikel

Dokumente auf Richtigkeit und Voll -ständigkeit gepru� ft, auf Risiken hin analy-siert und freigegeben. Jede Anforderungund jede Designentscheidung ist identifi-ziert, weitere Arbeitsschritte können inBezug zu einzelnen Anforderungen gesetztwerden (Traceability). Die erstenMeilensteine sind damit erfu� llt. Die näch-sten Schritte treiben die Umsetzung inQuellcode voran und liefern am EndeCode, der vom Entwickler getestet ist(Unit-Tests). Möglicherweise entstehen indiesem Zuge Testrahmen und Testläufe, dieautomatisiert wiederholt werden können.Damit werden die nächsten Meilensteineerreicht. Erst im weiteren Verlauf werdendie Ergebnisse mehrerer Entwickler inte-griert und zu einem (Teil-)Produktzusammengefu� hrt. Wieder ein Meilenstein.Dann wird noch abgetestet, ob dieKundenanforderungen insgesamt erfu� lltsind (noch ein Meilenstein) und ob derKunde mit dem Produktergebnis etwasanfangen kann (endlich die Freigabe).

Die neueren, agilen Verfahren brechenmit der Meilensteindenkweise. Es gibtIterationen fester Länge (beispielsweise 4Wochen), in denen idealer Weise ein poten-ziell auslieferbares, d.h. möglichst vollstän-dig getestetes und dokumentiertes Produkt-Inkrement entsteht. In test-getriebenerManier arbeitet dann ein Produktverant -wortlicher mit einem Entwickler oderTester zusammen mit den Anforderungenan Testrahmen. Dieser Testrahmen dientsowohl zur Festlegungder Anforderungen als auch der Tests. Diezu leistenden Entwicklungsarbeiten werdennicht mit Hilfe eines Projektplans in zeit-licher und personeller Abfolge aufgelistet,sondern zum Beispiel auf Karten geschrie-ben und in täglichen sehr kurzen Meetingszugeteilt. So wird die zu leistende ArbeitTag fu� r Tag verfolgt. Integrationen sinddabei Arbeiten wie jede andere, die ja imLaufe der Iteration kontinuierlich undautomatisch erledigt werden. Am Endejeder Iteration wird unter Verwendung desanfangs erstellten Testrahmens getestet undRetrospektive gehalten. Nach jederIteration könnte so der Kunde bzw. derEndbenutzer eine Applikation erhalten undden Fortschritt in der Funktionalität u� ber-pru� fen. So können in verhältnismäßig kur-zen Schleifen Ru� ckmeldungen zum Produktwieder Eingang in die Entwicklung finden.Die regulatorischen Anforderungen werdenin der Reinform der agilen Entwicklung,bei der lauffähige Software mehr gilt alsDinge wie Dokumentation und Änderungs-

nachverfolgung, nicht automatisch erfu� llt.Auf den ersten Blick sieht das aus wie eineZwickmuhle, aus der man meint, nicht her-auszukommen. Aber es gibt Lösungendafur.

Betrachten wir …Dokumentationsanforderungen: Oft hörtman die vereinfachende Aussage, dass jedeArt von Dokumentation „waste“ also„Verschwendung“ ist, bzw. es wird das agi-le Manifest so interpretiert, dass jeglicheDokumentation, die keinen unmittelbarenKundennutzen erzeugt, „Verschwendung“ist und möglichst unterlassen werden sollte– also zunächst auch z. B. Review-Protokolle oder Nachweis von Require -ments-Tracing. In der Medizin technik istdas allerdings anders, da die Doku -mentation wie eine immerwährendeProduktanforderung dazu gehört. DieAnforderung wird von dem Markt gestellt,auf dem das Produkt verkauft werden soll.

Risikomanagement: Wenn agil entwi -ckelt wird und an einzeln heruntergebro-chenen Funktionalitäten (Features) gear-beitet wird, könnte leicht in Vergessenheitgeraten, dass im Medizinprodukte-UmfeldSicherheit und Wirksamkeit oberstes Gebotsind. Dies sind nicht-funktionale Re -quirem ents, die bei einer reinen Feature-Orientierung zu kurz kommen könnten,wenn man nicht spezielles Augenmerk dar-auf richtet. Insofern muss jedes Require -ment, Feature und jede entwickelte Unitauf ihr potenzielles Produktrisiko einge-schätzt, entsprechend getestet und ggf. inImpact-Analysen berucksichtigt werden.Ziel von Impact-Analysen ist es, Auswir -kungen von (Software-) Änderungen aufdas System und insbesondere auf sicher-heitsrelevante Einheiten fruhzeitig zuerkennen, zu analysieren, zu bewerten undggf. Gegenmaßnahmen einzuleiten.

Change Management: In jeder Iterationkönnen sich potenziell Veränderungen anDokumenten oder an der Entwicklung(Spezifikationen, etc.) ergeben. Diese Ver -än derungen sind essenziell im agilenVorgehen und so zu regeln, dass sie einer-seits handhabbar sind, und andererseits dieregulatorischen Anforderungen erfullen.Dabei ist sorgfältig zu uberlegen, welcheAktivitäten man in jeder Iteration durch-fuhren muss und welche sinnvoll nur zuBeginn oder zu Ende der Entwicklung oderzu bestimmten Meilensteinen – in Ab -weichung von den puren agilen Prinzipien –durchgefuhrt werden sollten. Wichtig indiesem Zusammenhang ist es, zum Ende

der letzten Iteration einen allumfassendenProduct Backlog in freigegebener Form zuhaben, der die umgesetzten Requirementsdes freigegebenen Produkts dokumentiert,und zum Beginn der ersten Iteration einenzu diesem Zeitpunkt gultigen Stand nach-weisen zu können.

Überall hier ist ein schlanker ChangeManagement Prozess bei der Doku -mentation sehr hilfreich.

Projekt-Qualitätsmanagementplan: EinProjekt wird uber einen Projekt-Quali -tätsmanagementplan ausgesteuert. Er gibtden laufenden Stand der Planung wieder,wobei zu erwarten ist, dass er bei einemagilen Vorgehensmodell öfter angepasstwird als bei einem traditionellen Vorgehen.Im Projekt-Qualitätsmanage ment plan wirddie (geforderte) Entwicklungs- undEntwurfs planung samt Verantwortlich -keiten, Schnittstellen, Planung der erforder-lichen Tätigkeiten festgelegt und gepflegt.Als positiver Nebeneffekt erhöht sich mitder steten Aktualisierung im agilen Prozessauch die Planungs sicherheit.

Bei all diesen Themen besteht dieMöglichkeit, dass sich die Diskussions -partner aus ihren Ecken "Agile Entwick lung'gemäß agilem Manifest'" beziehungsweise"Qualitätsmanagement & Regu la torik 'ge-mäß 1000-prozentiger Gesetzeserfüllung'"wenig heraus- und konstruktiv aufeinanderzu bewegen, so dass sich die konkreteProduktentwicklung in Quasi-Zwickmühlenzu befinden scheint.

Die Lösung aus diesen scheinbarenZwickmuhlen besteht in sorgfältig gestalte-ten und gut diskutierten herstellerinternenProzessbeschreibungen, die sowohl dieregulatorischen Anforderungen erfullen alsauch ein agiles Vorgehen unterstutzen. Einesolche Prozessbeschreibung sieht etwa einiteratives Vorgehensmodell vor, das schritt-weise Inkremente erzeugt, mit stetemTesten verbunden ist und Ergebnisse ent-sprechend dokumentiert.

Idealerweise werden die Prozessbeschrei -bungen in den Retrospektiven nach jederIteration kritisch beleuchtet, mit theoreti-schen Vorgaben und Praxis abgestimmtund sinnvoll angepasst. Wichtig ist dabeiunweigerlich, dass sich die Beschreibungender Prozesse und das Leben in der Praxisdecken. Dazu sind die Prozessbe -schreibungen zu versionieren und z. B. imProjekt-Qualitätsmanagementplan zudokumentieren. Wo möglich, sollten dieProzessbeschreibungen naturlich Freiraumfur die Optimierung einzelner Teams las-sen.

notwendig fur die verschiedenen relevantenMärkte? Wie lassen sich diese unver -ruckbaren Anforderungen sinnvoll undauditfest in das agile Vorgehen einbettenund so effizient erarbeiten?

Die Barrieren haben aber auch damit zutun, dass es meist aus der Historie ein eta-bliertes und auf Audits getrimmtesVorgehensmodell gibt und Änderungen mitRisiken verbunden sein können, beispiels-weise in Bereichen, in denen Gesetzestexteinterpretationsbedurftig sind. Falsch wärees, die regulatorischen Anforderungen ein-fach zu ignorieren. Konsequenz wäre dann,die Medizinprodukte nicht vertreiben zudurfen. Beim richtigen Prozessdesign istneben dem oben genannten Sachverstandauch viel aktives Fördern eines Wandels inder Organisation notwendig. Aus derVision „Wir wollen agil werden“ kann mitSachverstand und uber Einbeziehung allerInteressengruppen und aller Menschen(auch denen des Qualitätsmanagements),Weiterbildung und intensiver Kom muni -kation Realität werden. Die alten Fesselnder Entwicklung werden gelockert, ohnegegen Gesetze zu verstoßen. Die Entwick -lung treibt Innovation, Umsetzung undEffizienz voran. Das Qualitätsmanagementals Partner unterstutzt und berät dabei, ins-besondere bei der Einhaltung gesetzlicherVorschriften, um die Innovation letztend-lich auch wirklich auf den Markt bringenzu durfen. n

Iterationen könnte noch das alte Vor -gehensmodell, z. B. ein Mini-Wasserfalloder ein Mini-V-Modell, angewendet wer-den. In diesem Schritt könnten sich dieEntwickler an ein iteratives Arbeiten miteinem häufigeren Testen gewöhnen, ohnedas Risikos einer „BigBang“-Iteration zuEnde der Entwicklung wie im Wasserfallauf sich nehmen zu mussen oder den siche-ren Rahmen des „alten“ Prozesses kom-plett verlassen zu mussen. Sehr bald solltenallerdings Retrospektiven nach jeder Ite -ration eingefuhrt werden, die auch und ins-besondere Prozessthemen adressieren.Diese Prozessthemen wären dann im Hin -blick auf regulatorische Anforderungen zuprufen und entsprechend zu lösen. Dabeiwäre desgleichen zu diskutieren, wie weitman in Richtung Agilität gehen möchte.

JA, es funktioniertDie regulatorischen Anforderungen an dieEntwicklung von Medizinproduktenschrei ben, wie gesagt, kein bestimmtesVorgehensmodell vor, auch nicht dasWasserfall-Modell. Gewisse prozessabfol-gerelevante Anforderungen gibt es, sie kön-nen aber durchaus in einem agilen Umfeldrealisiert werden.

Einfach ist es nicht immer, einen agilenSoftwareentwicklungsprozess effizient undauditfest zu etablieren. Die Barrieren erfor-dern, das Prozessdesign mit sehr vielSachverstand anzugehen: Was ist wirklich

Die Einhaltung der Prozesse wird nebenAudits durch Externe (z. B. vom TÜV) regel-mäßig in den vom Hersteller selber durchzu-fuhrenden internen Audits begutachtet, dieauch durchaus sinnvolle Verbesserungs -möglichkeiten aufzeigen können.

Aller Anfang …Eine Organisation, die neu mit Software -entwicklung und sofort mit einem agilenVorgehen startet, wäre gut beraten, daraufzu achten, leichtgewichtige Prozesse einzu-fuhren, und diese stets, insbesondere imZuge der Retrospektiven einer Iterationanzupassen und auf Basis der gemachtenErfahrungen zu standardisieren. Es emp-fiehlt sich, bewährte Regeln, z. B. Scrummit Sprints, Daily Scrum, Retrospektiven,etc. (dort wo die Umgebung ein Vorgehennach Scrum zulässt), umzusetzen.

Eine Organisation, die bisher nach einemanderen Vorgehensmodell Software ent-wickelt hat, ist es gewohnt, nach den einge-fuhrten Prozessen mit oft anderen Ände-rungszyklen und Meilensteinen zu arbeiten.Im ‚laufenden Betrieb’ ist ein Re-Design derProzesse sorgfältiger vorzunehmen. Wenneine komplette Einfuhrung einer agilenMethode wie Scrum ein zu großes Risikobedeutet, ist als erster Schritt eine Einfuh -rung von Iterationen in festen Zeitfensternverbunden mit einer dazugehörenden, inden Iterationen stattfindenden Require -ments-Definitions-Phase denkbar. In den

fachartikel

5 www.objektspektrum.de