ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt....

5
ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE ORGANISATORISCHE HINDERNISSE EINE CHANCE SEIN KÖNNEN nen. Der Fachbegriff hierfür ist Barriere- freiheit. Was alles zu beachten ist, können Ihnen weder der Product Owner, noch ein- zelne Anwender sagen. Dazu braucht es Experten. Deshalb haben wir ein Kompe- tenzzentrum für Ergonomie und Usability, das alle Dialogkonzepte nach ergonomi- schen Gesichtspunkten prüft. Ohne dessen „OK“ dürfen Sie Ihr Dialogdesign nicht umsetzen. Darauf achten das Management und der Betriebsrat streng. Hintergrund Wichtige gesetzliche Vorschriften und Normen zu diesem Thema sind: Die Verordnung zur Schaffung barrie- refreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Ver- ordnung, kurz BITV 2.0) ist eine Ergänzung des Behindertengleich- stellungsgesetzes (BGG) vom 27. April 2002 (vgl. [Wik-a]). Die ISO-Norm EN ISO 9241 ist ein internationaler Standard, der Richtlinien der Interaktion zwischen Mensch und Computer beschreibt (vgl. [Wik-c]). In großen Firmen kommt es häufig zu Konflikten zwischen den Governance-Regularien und der Vorgehensweise agiler Teams, die diese Regularien als organisatorische Hindernisse empfin- den. Wir wollen in diesem Artikel einige dieser vermeintlichen Hindernisse ansprechen, Verständnis für die zu Grunde liegenden Regularien wecken und Möglichkeiten aufzeigen, wie konstruktiv damit umgegangen werden kann. 20 21 CSM macht sich nun daran, die Leitplanken abzuklären. Dabei ergeben sich die folgenden Gespräche. Hindernis 1: Ergonomie und Usability: Gespräch CSM trifft Uwe Ehrmann (UE), den Usability-Experten der Firma. CSM: Gestern haben wir mit dem Product Owner und zwei Anwendern das Dialog- konzept für unsere neue Anwendung fest- gelegt. Das wird echt cool: mit Touchpad- Bedienung und komplett in den Farben unserer Corporate Identity, also rot und grün. UE: Sie bauen Software für Arbeitnehmer unserer Firma. Dabei müssen Vorgaben des Gesetzgebers und der Berufsgenossen- schaften eingehalten werden, z. B. bezüg- lich der Schriftgrößen und der Farb- kontraste, aber auch der Bedienbarkeit. Dadurch soll sowohl gewährleistet werden, dass durch die Bedienung der Software kei- ne gesundheitlichen Beeinträchtigungen entstehen, als auch, dass Menschen mit körperlichen Einschränkungen die Software uneingeschränkt bedienen kön- Szenario Christian Sebastian Müller (CSM) hat als frisch gebackener Certified ScrumMaster eine Stelle bei der Securitas Versicherung angetreten. Er hat dort mit großem En- thusiasmus das erste Scrum-Team aufge- baut. Nach dem ersten Release wurde eine Release-Retrospektive abgehalten und dabei wurden mehrere Hindernisse in der Organisation der Securitas identifiziert: Das Team darf die Benutzungsschnitt- stelle nicht selbstständig entwickeln, son- dern muss die Dialoggestaltung vom Kompetenzzentrum für Software-Ergo- nomie und Usability genehmigen lassen. Die entwickelte Software muss von einem Information Security Officer (ISO) des Unternehmens geprüft und genehmigt werden Die Architektur kann nicht vom Team allein bestimmt werden, sondern wird von einem übergreifenden Architektur- stab im Wesentlichen vorgegeben. Das Team darf sich seine Tools nicht selbst aussuchen, sondern muss im Unternehmen vorgegebene Standard- werkzeuge einsetzen. Das Team muss sich an das Vor- gehensmodell zur Anwendungsent- wicklung halten, das für alle Teams das Vorgehen festlegt. Das Team muss im Rahmen eines inter- nen Kontrollsystems (IKS) Dokumenta- tionsanforderungen erfüllen, die als bürokratisch und agilen Prinzipien widersprechend empfunden werden. Da die Securitas den CMMI-Level 3 anstrebt, muss das Team einige als überflüssig empfundene Regularien ein- halten. schwerpunkt Michael Schäfer ([email protected]) beschäftigt sich bei der Allianz seit vielen Jahren mit klassischer Verfahrenstechnik und ist seit 2008 als agiler Coach tätig. Er kennt also beide Welten und versucht diese, miteinander zu ver- binden. Christoph Weiß ([email protected]) hat in verschiedenen Firmen praktische Erfahrungen in der Softwareentwicklung gesam- melt. In seiner Doppelrolle als agiler Coach und Koordinator für Internal Control over Financial Reporting (ICOFR) sieht er sich als Brückenbauer. die autoren

Transcript of ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt....

Page 1: ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farben unserer Corporate

ÜBER SIEBEN BRÜCKEN

MUSST DU GEHEN:

WIE ORGANISATORISCHE

HINDERNISSE EINE CHANCE

SEIN KÖNNEN

nen. Der Fachbegriff hierfür ist Barriere -freiheit. Was alles zu beachten ist, könnenIhnen weder der Product Owner, noch ein-zelne Anwender sagen. Dazu braucht esExperten. Deshalb haben wir ein Kompe -tenzzentrum für Ergonomie und Usability,das alle Dialogkonzepte nach ergonomi-schen Gesichtspunkten prüft. Ohne dessen„OK“ dürfen Sie Ihr Dialogdesign nichtumsetzen. Darauf achten das Managementund der Betriebsrat streng.

HintergrundWichtige gesetzliche Vorschriften undNormen zu diesem Thema sind:

■ Die Verordnung zur Schaffung barrie-refreier Informationstechnik nach demBehindertengleichstel lungsgesetz(Barrierefreie-Informationstechnik-Ver -ordnung, kurz BITV 2.0) ist eineErgänzung des Behindertengleich -stellungsgesetzes (BGG) vom 27. April2002 (vgl. [Wik-a]).

■ Die ISO-Norm EN ISO 9241 ist eininternationaler Standard, der Richt liniender Interaktion zwischen Mensch undComputer beschreibt (vgl. [Wik-c]).

In großen Firmen kommt es häufig zu Konflikten zwischen den Governance-Regularien und derVorgehensweise agiler Teams, die diese Regularien als organisatorische Hindernisse empfin-den. Wir wollen in diesem Artikel einige dieser vermeintlichen Hindernisse ansprechen,Verständnis für die zu Grunde liegenden Regularien wecken und Möglichkeiten aufzeigen, wiekonstruktiv damit umgegangen werden kann.

20 21

CSM macht sich nun daran, dieLeitplanken abzuklären. Dabei ergebensich die folgenden Gespräche.

Hindernis 1:Ergonomie und Usability:

GesprächCSM trifft Uwe Ehrmann (UE), denUsability-Experten der Firma.

CSM: Gestern haben wir mit dem ProductOwner und zwei Anwendern das Dialog -konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farbenunserer Corporate Identity, also rot undgrün.

UE: Sie bauen Software für Arbeitnehmerunserer Firma. Dabei müssen Vorgaben desGesetzgebers und der Berufsgenossen -schaften eingehalten werden, z. B. bezüg-lich der Schriftgrößen und der Farb -kontraste, aber auch der Bedienbarkeit.Dadurch soll sowohl gewährleistet werden,dass durch die Bedienung der Software kei-ne gesundheitlichen Beeinträchtigungenentstehen, als auch, dass Menschen mitkörperlichen Einschränkungen dieSoftware uneingeschränkt bedienen kön-

SzenarioChristian Sebastian Müller (CSM) hat alsfrisch gebackener Certified ScrumMastereine Stelle bei der Securitas Versicherungangetreten. Er hat dort mit großem En -thusiasmus das erste Scrum-Team aufge-baut. Nach dem ersten Release wurde eineRelease-Retrospektive abgehalten unddabei wurden mehrere Hindernisse in derOrganisation der Securitas identifiziert:

■ Das Team darf die Benutzungs schnitt -stelle nicht selbstständig entwickeln, son-dern muss die Dialoggestaltung vomKompetenzzentrum für Software-Ergo -nomie und Usability genehmigen lassen.

■ Die entwickelte Software muss voneinem Information Security Officer(ISO) des Unternehmens geprüft undgenehmigt werden

■ Die Architektur kann nicht vom Teamallein bestimmt werden, sondern wirdvon einem übergreifenden Architektur -stab im Wesentlichen vorgegeben.

■ Das Team darf sich seine Tools nichtselbst aussuchen, sondern muss imUnternehmen vorgegebene Standard -werk zeuge einsetzen.

■ Das Team muss sich an das Vor -gehensmodell zur Anwendungsent -wicklung halten, das für alle Teams dasVorgehen festlegt.

■ Das Team muss im Rahmen eines inter-nen Kontrollsystems (IKS) Dokumenta -tionsanforderungen erfüllen, die alsbürokratisch und agilen Prinzipienwidersprechend empfunden werden.

■ Da die Securitas den CMMI-Level 3anstrebt, muss das Team einige alsüberflüssig empfundene Regularien ein-halten.

schwerpunk t

Michael Schäfer

([email protected])

beschäftigt sich bei der Allianz seit vielen Jahren

mit klassischer Verfahrenstechnik und ist seit

2008 als agiler Coach tätig. Er kennt also beide

Welten und versucht diese, miteinander zu ver-

binden.

Christoph Weiß

([email protected])

hat in verschiedenen Firmen praktische

Erfahrungen in der Softwareentwicklung gesam-

melt. In seiner Doppelrolle als agiler Coach und

Koordinator für Internal Control over Financial

Reporting (ICOFR) sieht er sich als Brückenbauer.

d i e au toren

Page 2: ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farben unserer Corporate

2/2013

LösungsvorschlagDie gesetzlichen Vorschriften müssen na -türlich eingehalten werden. Das Team solltedeshalb bei der Entwicklung desDialogkonzepts von Anfang an einenUsability-Experten hinzuziehen, der durchseine Expertise die Einhaltung der Regulariengewährleistet. Dann wird die Genehmigungdes Dialogkonzepts zur reinen Formsache.

Hindernis 2: IT-Security

GesprächCSM trifft Ingmar Schwarz-Olson (ISO),den Information Security Officer derFirma.

CSM: Guten Tag Herr Schwarz-Olson, sowie es aussieht, ist unsere Software sicher-heitsrelevant. Das hat zur Folge, dass wir siesicherheitstechnisch abnehmen lassen müs-sen. Das ist für uns schwierig, da wir in deneinzelnen Sprints nichts abschließen können,weil noch die Abnahme im Raum steht.

ISO: Ihre Software verarbeitet kundenspezifi-sche Daten und diese sind grundsätzlich sehrsensibel. Daher ist sie zweifelsohne sicher-heitsrelevant und Sie werden um die Ab -nahme nicht herumkommen. Wir sollten be -sprechen, welche sicherheitstechnischenMaß nahmen in Ihrem Fall sinnvoll sind,damit Sie wissen, was das für Sie konkretbedeutet.

HintergrundFür die Informationssicherheit gibt es alsNorm die ISO/IEC 27002. Diese beinhaltetEmpfehlungen für diverse Kontroll -mechanismen für die Informations -sicherheit (vgl. [Wik-b]). Zudem sind indiesem Kontext auch das Bundesdaten -schutzgesetz (BDSG) und das Straf gesetz -buch (insbesondere §203 StGB, Verletzungvon Privatgeheimnissen) zu beachten.

LösungsvorschlagWie im ersten Fallbeispiel ist es auch hiereine gute Lösung, den zuständigen ISO

möglichst früh einzubinden und mit diesemdie notwendigen sicherheitstechnischenMaßnahmen und vor allen Dingen auch dieTests dazu festzulegen. Das Team kanndann in den Sprints die zuvor mit dem ISOvereinbarten Tests durchführen und dies alssicherheitstechnische Abnahme betrachten.Die finale Abnahme sollte dann eine reineFormsache sein.

Hindernis 3:Vorgegebene Architektur

GesprächCSM trifft Anna Engel (AE), die Archi -tektur-Expertin der Firma.

CSM: Hallo Frau Engel, ich müsste Sie malwegen der Architektur unseres neuenProdukts sprechen. Sie wissen doch sicher,dass wir in unserem Projekt agil vorgehen,wir halten uns also an die agilen Prinzipien.Und eines davon lautet: „Die bestenArchitekturen entstehen durch selbst orga-nisierende Teams!“ Gemäß diesem Prinzipentwickeln wir unsere Architektur selbstund lassen uns hier nicht dreinreden.

AE: Es ist meine Aufgabe, in unseremUnternehmen für eine tragfähige, einheitli-che Architektur zu sorgen. Das heißt, ichhabe die Architektur-Governance und alleArchi tekturen, die in unserem Hauseimplementiert werden, müssen mit mirabgestimmt und von mir genehmigt wer-den. Auch als agiles Team müssen Sie sichan die Governance-Regeln des Unterneh -mens halten.

Aber davon abgesehen, halte ich auchden Anspruch, Ihr Team könne allein undohne Abstimmung mit den Experten unse-res Hauses eine Architektur festlegen, fürfalsch. Das Produkt, das Sie entwickeln,steht nicht für sich allein, sondern muss aufden IT-Plattformen unseres Unternehmensmit vielen andern Anwendungen zusam-men funktionieren. Zudem müssen einemöglichst hohe Wiederverwendbarkeit und

die langfristige Wartbarkeit gewährleistetsein. Ohne eine übergreifende Architekturgeht es hier einfach nicht. Und diese kannnur von jemandem verantwortet werden,der nicht nur eine einzelne, sondern allerelevanten Anwendungen kennt.

HintergrundGroße Unternehmen sehen in der Fest -legung und Einhaltung der Software -architektur eine Governance-Aufgabe, fürdie eigene Experten eingesetzt werden.Deren Aufgabe ist es, die Qualität undEinhaltung der Architektur sicherzustellen.Hier ergibt sich unter Umständen einKonflikt mit agilen Teams, die Wert darauflegen, gemäß den agilen Prinzipien ihreArchitektur selbst festzulegen.

LösungsvorschlagTeams sollten die Tatsache, dass in derFirma Architekturexperten arbeiten, alsChance und nicht als Einschränkung ihrerFreiheit begreifen. Es gilt, das Experten -wissen zu nutzen, gerade um dem Teamarchitektonische Irrwege zu ersparen.

Andererseits muss die Architektur-Governance auch so organisiert werden, dassdie Teams ihre Wünsche, Erfahrungen undErkenntnisse in die Weiterentwicklung derArchitektur einbringen können. Hier bietetes sich an, das Thema Architektur in einer„Community of Practise“ mit den Architek -turexperten einerseits und den Vertretern deragilen Teams andererseits zu behandeln.

Hindernis 4:Standardisierte Tools

GesprächCSM trifft Tanja Voll (TV), die Testtool-Verantwortliche der Firma:

CSM: Guten Tag Frau Voll. Mein Team hatsich in der Retrospektive für ein neuesTestwerkzeug entschieden, das unsereArbeit besser unterstützt. Der Antrag, die-ses Tool zu kaufen, wurde von Ihnen abge-lehnt. Warum?

schwerpunk t

Page 3: ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farben unserer Corporate

Scrum erhebt also keinen Anspruch aufVollständigkeit. Diese zu erreichen, istAufgabe der Verfahrenstechnik, die ver-schiedene Methoden zu einem Vor -gehensmodell kombiniert.

LösungsvorschlagOb die agile Entwicklung ins Vorgehens -modell der Securitas aufgenommen wirdoder nicht, wurde in unserem Beispielbereits mit „Ja“ beantwortet, da im agilenZweig des PMI nichts anderes steckt. Eineweiterführende Frage ist nun, in welcher„Geschmacksrichtung“ dies geschieht, alsodurch den agilen Zweig des PMI oderdurch Scrum eines anderen Anbieters. Beider Entscheidung, welche agile „Ge -schmacksrichtung“ man bevorzugt, kön-nen verschiedene Argumente eine Rollespielen:

■ Unterschiedliche Schwerpunkte in denjeweiligen Ausbildungs- und Zerti -fizierungsprogrammen.

■ Ansehen der unterschiedlichen Zertifi -zierungen im Unternehmen.

■ Vertrauen in und bisherige Erfahrungenmit dem jeweiligen Anbieter.

■ Einschätzungen zur Qualität und Zu -kunftssicherheit der Programme.

■ Anfallende Kosten, sowohl einmalig alsauch laufend.

Bei der Aufnahme von agilen Methoden insVorgehensmodell sollte man bedenken,dass die agile Vorgehensweise die gesamteEntwicklung betrifft – von der Anfor -derungserhebung bis hin zur Produktiv -setzung. Daher muss das gesamte Vor -gehensmodell daran angepasst werden.

Hindernis 6:Internes Kontrollsystem

GesprächCSM trifft Richard Emil Völler (REV), denzuständigen Kollegen der Revision derFirma.

22 23

len wir aber ein standardisiertes Vor -gehensmodell des Unternehmens einsetzen.Daher möchten wir, dass Scrum in denKanon der im Unternehmen zulässigenVorgehensmodelle aufgenommen wird.

VT: Scrum ist kein vollständiges Vor -gehensmodell, sondern lediglich einProjektmanagement-Verfahren. Es müsstedaher neben den klassischen PM-VerfahrenPMI und PRINCE2 betrachtet werden. Beiuns ist PMI das eingeführte PM-Verfahren.PMI bietet inzwischen einen eigenen agilenZweig an. Wir sollten besser diesen agilenZweig einsetzen, anstatt uns mit Scrum einzusätzliches Verfahren ins Haus zu holen.Sie sollten auch bedenken, dass es mit derreinen Aufnahme von Scrum in den Pro -jektmanagement-Kanon nicht getan wäre.Scrum beinhaltet Rollen, die in das unter-nehmensweite Rollen- und Karrieremodellintegriert werden müssen. Das spielt für dieAkzeptanz eine sehr wichtige Rolle.

HintergrundTrotz teilweise unterschiedlicher Defini -tionen des Begriffs „Vorgehensmodell“herrscht Konsens darüber, dass in einemVorgehensmodell festgelegt ist, welcheErgebnisse im Verlauf einer Entwicklunganfallen müssen. Scrum gibt zwarErgebnisse wie das Product Backlog vor,aber es tut dies nicht in hinreichendemMaße für die gesamte Softwareent wicklung(vgl. dazu auch das folgende Hindernis 6).Daher ist Scrum allein kein vollständigesVorgehensmodell, sondern muss entspre-chend ergänzt werden.

Auch gemäß der offiziellen Definitionder Scrum Alliance ist Scrum (lediglich) einagiles Framework für die Produkt -entwicklung, innerhalb dessen verschiedeneProzesse und Techniken zum Einsatzgebracht werden können (vgl. [Sch11]).

Bei agilen Vorgehensmodellen bildet oftScrum die Basis, die um andere Methoden(wie beispielsweise XP) ergänzt wird.

TV: Wir haben bereits ein vergleichbaresTestwerkzeug im Einsatz. Ein andereszusätzlich zu verwenden, widersprichtunserer Ein-Tool-Strategie, auf Grundderer wir bessere Konditionen mit denWerkzeugherstellern aushandeln, Release-Wechsel besser planen und den Überblicküber die im Hause vorhandenen Lizenzenbehalten können. Zudem sind eine verein-fachte Wartung und Bereitstellung vonArbeitsplatz-Rechnern möglich. Das hatfür die Mitarbeiter den Vorteil, dass sie sichnicht in jedem Projekt oder Team an neueTools gewöhnen müssen.

HintergrundGroße Unternehmen haben häufig miteinem extremen Wildwuchs zu kämpfen,was die eingesetzten Tools betrifft. Vielenerscheint eine ausgewiesene Ein-Tool-Strategie als Ausweg. Durch eineGovernance der eingesetzten Werkzeugeerhofft man sich Kosteneinsparungen, z. B.durch Skaleneffekte bei der Lizenz be -schaffung und eine zentrale Adminis tra -tion. Dem steht der agile Anspruch gegen -über, dass Teams am besten wissen, welcheTools sie für produktive Arbeit benötigen.

LösungsvorschlagMan sollte versuchen, auf absolute Posi -tionen zu verzichten. Die Verantwortlichenfür die Ein-Tool-Strategie sollten dazubereit sein, gut begründete Abweichungenzu akzeptieren. Andererseits sollten auchdie Teams kleinere Einschränkungen dereigenen Produktivität durch ein nicht opti-males Werkzeug akzeptieren. Die Pro -duktivität des einzelnen Teams ist hier häu-fig weniger wichtig als die Produktivitätder gesamten Organisation. Bei Strei t -punkten muss gegebenenfalls durch denScrum Master eine Management entschei -dung herbeigeführt werden. Generell sollteeine Tool-Auswahl immer mit Bedacht undunter Einbeziehung der späteren Anwendergetroffen werden.

Hindernis 5: ÜbergreifendesVorgehensmodell

GesprächCSM trifft Viktor Torrino (VT), denzuständigen Verfahrenstechniker derFirma.

CSM: Guten Tag, Herrr Torrino. Wir sindein agiles Team, das Scrum als Vor -gehensmodell verwendet. Gleichzeitig sol-

schwerpunk t

Page 4: ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farben unserer Corporate

2/2013

CSM: Sie haben in dem aktuellen Revi -sionsbericht eine nicht ausreichende Doku -mentation angemahnt. Als agiles Teamgehen wir mit dem Thema Dokumentationetwas anders um, da uns funktionierendeSoftware wichtiger ist als eine ausuferndeDokumentation. Als technische Dokumen -tation gibt es die Methoden- und Klassen -beschreibungen im Javadoc. Darüber hin-aus verwenden wir Tests als Teil derSystemdokumentation. Was die Doku -mentation im Code betrifft, so setzen wirauf Code, der so klar und gut strukturiertgeschrieben wird, dass zusätzlicheKommentare kaum nötig sind. „CleanCode“ heißt hier unsere Devise. Zudem las-sen sich bei Bedarf UML-Diagramme ausdem Code generieren, wenn diese benötigtwerden. Was die fachliche Dokumentationbetrifft, so lassen sich Informationen überdie fachliche Funktionalität aus demProduct Backlog der einzelnen Sprintsgewinnen. Was fehlt Ihrer Ansicht nachnoch?

REV: Unsere Systeme müssen denGrundsätzen ordnungsmäßiger DV-ge -stützter Buchführungssysteme (GoBS) ent-sprechen. Die GoBS ist eine Vorschrift desBundesfinanzministeriums, die vorschreibt,was die Verfahrensdokumentation allesbeinhalten muss. Zentraler Bestandteildavon ist das interne Kontrollsystem (IKS),das verhindern soll, dass bei unserenFinanzflüssen etwas schief läuft. Das IKSgeht von der Dokumentation fachlicherValidierungen bis hin zur Dokumentationvon Tests, durch die belegt wird, dass beiSchnittstellen alles komplett und korrektübertragen wird.

All dies muss im Rahmen der Verfah -rensdokumentation beschrieben werden.Grundsätzlich gilt dabei, dass die Doku -mentation von sachverständigen Dritten inangemessener Zeit nachvollzogen werdenkann.

In Ihrem Fall fehlt ein Doku ment, ausdem ersichtlich ist, wie das System ausfachlicher Sicht funktioniert. Das ProduktBacklog ist dazu nicht ausreichend, da eskeine zusammenhängende Darstellung bie-tet, sondern die Infor ma tionen nur scheib-chenweise enthält. Ebenso fehlen ein tech-nisches Übersichtsdokument, das einenGesamtüberblick über die technischeSystemlandschaft und das Zusam -menwirken der darin enthaltenen Systemeliefert, und ein Betriebsdokument, das dar-

über Auskunft gibt, wie das System zubetreiben ist.

HintergrundAlle Systeme einer DV-gestützten Buchfüh -rung müssen nach GoBS entwickelt wer-den. Dazu gehören Systeme, die Zahlungengenerieren und/oder für die Finanz -berichterstattung verwendet werden. DieGoBS fordert eine Verfahrensdoku men ta -tion, die Folgendes beinhalten muss (vgl.[BMF95]):

■ eine Beschreibung der sachlogischenLösung

■ die Beschreibung der programmtechni-schen Lösung

■ eine Beschreibung, wie die Programm -identität gewahrt wird

■ eine Beschreibung, wie die Integritätder Daten gewahrt wird

■ Arbeitsanweisungen für den AnwenderDas gilt insbesondere auch für Firmen, dieSOX (Sarbanes Oxley Act), ICOFR(Internal Control over Financial Reporting)oder ähnliche Kontrollsysteme für dieFinanzberichterstattung haben.

LösungsvorschlagDa die GoBS-Anforderungen nicht nur einSystem betreffen, lassen sich viele derAnforderungen zentral erfüllen. Ein Bei -spiel hierfür sind einheitliche automatisier-te Freigabe- und Deployment-Verfahren.Diese müssen dann nur einmal beschriebenwerden und nicht für jedes System. Einanderes Beispiel hierfür ist die Vergabe undVerwaltung von Berechtigungen.

Wenn die übergreifenden Sachverhaltezentral beschrieben sind, müssen für dieeinzelnen Systeme nur noch systemspezifi-sche Dinge beschrieben werden. Auch kannman versuchen, Redundanzen in derDokumen tation möglichst zu vermeidenund die Dokumentation parallel zurEntwick lung anzufertigen, sodass mög-lichst wenig nachkorrigiert werden muss.Die Doku mentation sollte nicht erstunmittelbar vor Einsatz des Systemsgeschrieben werden, sondern ebenso itera-tiv ergänzt werden wie der Code. Es bietetsich an, dies in der Definition of Done fest-zulegen.

Hindernis 7: CMMIGesprächCSM trifft Ludwig Angerer (LA), den LeadAppraiser, der bewertet, wo die Firma beider Implementierung von CMMI steht.

CSM: Wir führen regelmäßig Retro -spektiven zur Prozessverbesserung durch.Leider kommt es immer wieder vor, dasswir daraus resultierende Verbesserungs -vorschläge nicht umsetzen dürfen, da wiruns an die CMMI-Prozesse halten müssen.Die sind unserer Ansicht nach aber teil-weise zu schwergewichtig und überregu-liert. Und genau das wollen wir eigentlichoptimieren. Können wir hier eine Ausnah -megenehmigung bekommen?

LA: Wenn Prozesse standardisiert werden,können diese zwangsläufig nicht für jedenoptimal sein, da diese übergreifend an -wendbar sein müssen. Wenn wir für jedeneine Ausnahme machen würden, gäbe eseinerseits einen unübersichtlichen Wild -wuchs an Prozessen und andererseits wür-de das den Aufwand für CMMI in nichtakzeptable Höhen treiben. Damit könntenwir unser CMMI-Ziel, den Level 3, nichterfüllen. Der Level 3 ist uns wichtig, denner bereitet mit organisationsweiten Pro -zessen eine Basis für organisationsweitesLernen. Daher kann ich Ihnen leider keineAusnahmegenehmigung geben.

HintergrundCapability Maturity Model Integration(CMMI) ist eine Serie von Referenz -modellen des Software EngineeringInstitute (SEI) an der Carnegie MellonUniversity/Pittsburgh. Diese sind vor allemdurch die darin enthaltenen Reifegrad -modelle bekannt.

In unserem Kontext ist mit CMMI dasReferenzmodell für die Softwareent wick -lung CMMI-DEV gemeint (vgl. [SEI11]).Dieses ist in verschiedene Prozessgebieteeingeteilt, gibt selbst aber keine Prozessevor. Die Prozessgebiete beinhalten Zieleund Empfehlungen für gute Praktiken zurErreichung dieser Ziele. Diese Ziele geltenjeweils nur für die Prozesse ihrer Prozess -gebiete und werden daher spezifische Ziele(Specific Goals, SP) genannt.

schwerpunk t

Page 5: ÜBER SIEBEN BRÜCKEN MUSST DU GEHEN: WIE … · konzept für unsere neue Anwendung fest-gelegt. Das wird echt cool: mit Touchpad-Bedienung und komplett in den Farben unserer Corporate

24 25

Neben den spezifischen Zielen gibt es inCMMI auch die generischen Ziele (GenericGoals, GG), die für alle Prozesse allerProzessgebiete gelten. Darin wird beispiels-weise das Thema Prozess optimierungadressiert. Beginnend mit dem ReifegradCMMI-Level 3 müssen nicht nur Prozesseorganisationsweit geregelt sein, zudemmuss auch etwas in Richtung fortlaufendernachhaltiger Prozessoptimierung getanwerden.

Bei der Implementierung von CMMIwerden die hauseigenen Prozesse beschrie-ben und es wird dargelegt, wie damit dievon CMMI vorgegebenen Ziele erreichtwerden. Bei der Bewertung und Einstufungder Prozesse, dem so genannten Appraisal,wird nicht nur geprüft, ob mit Hilfe derhauseigenen Prozesse die von CMMIgesetzten Ziele erreicht werden, sondernauch, ob die Prozesse tatsächlich so gelebtwerden, wie diese beschrieben sind. Dabeigibt es einen federführenden Prüfer, der indiesem Kontext Lead Appraiser genanntwird.

LösungsvorschlagDas Problem schwergewichtiger Prozessehat nicht wirklich mit CMMI zu tun, son-dern damit, dass im Rahmen von CMMIhauseigene schwergewichtige Prozessebeschrieben werden, die in der Regel schonvorher da waren. Schlimmstenfalls werdendiese mit CMMI noch zementiert, indem inder jeweiligen CMMI-Implementierungkein Prozessoptimierungsverfahren vorge-sehen wird.

Aber CMMI muss nicht zwangsläufig zuschwergewichtigen Prozessen führen.Daher muss bei den verwendeten Prozessenangesetzt werden. Beim Defi nieren vonProzessen sollte man sich darauf beschrän-ken, nur das zu regulieren, was reguliertwerden muss, und damit so viel Variabilitätund Freiheiten wie möglich bei derAnwendung der Prozesse zuzulassen.

Werden für CMMI agile Prozessebeschrieben, so schneiden diese teilweisesogar deutlich besser ab als viele schwerge-wichtige Prozesse, zum Beispiel, wenn dieagilen Prozesse einen voll automatisierten

Build-Prozess und automatisierte Regres -sionstests beinhalten.

Grundsätzlich ist es sinnvoll, mehrereProzessvarianten zu beschreiben, die ver-schiedene Konstellationen adressieren, z. B.unterschiedliche Projektvorgehen für Pro -jekte unterschiedlicher Größen. Das wirdauch von CMMI ab Level 3 gefordert.

FazitMeist sind es nicht die Regularien selbst, dieProbleme bereiten, sondern der Umgangdamit. Es lohnt sich daher, den Spielraumhierfür konstruktiv zu nutzen und damit dieInteressen aller Beteiligten so weit wie mög-lich zu berücksichtigen. Es hilft dabei, wenndie Beteiligten sich nicht als Gegner betrach-ten, sondern vielmehr die unterschiedlichenInteressen erfragen und dann gemeinsamüberlegen, wie innerhalb der vorgegebenenRegularien am besten damit umgegangenwerden kann. ■

Alle Brückenfotos © www.fotolia.de

schwerpunk t

Literatur & Links

[BMF95] Bundesfinanzministerium (BMF), Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme, 1995, siehe:

bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Betriebspruefung/015.pdf?__blob=publicationFile&v=3

[Sch11] K. Schwaber, J. Sutherland, Scrum Guide – Der gültige Leitfaden für Scrum: die Spielregeln, 2011, siehe:

scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf

[SEI11] Software Engineering Institute (SEI), CMMI für Entwicklung, Version 1.3, 2011, siehe: sei.cmu.edu/library/assets/whitepapers/10tr033de_v11.pdf

[Wik-a] Wikipedia, Barrierefreie-Informationstechnik-Verordnung, siehe: de.wikipedia.org/wiki/Barrierefreie-Informationstechnik-Verordnung

[Wik-b] Wikipedia ISO/IEC 27002, siehe de.wikipedia.org/wiki/ISO/IEC_27002

[Wik-c] Wikipedia, EN ISO 9241, siehe: de.wikipedia.org/wiki/EN_ISO_9241