Clean Coding Cosmos: Teil 3: Kosmische Effizienz durch Team Clean Coding

Transkript

1 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Was bedeutet eigetlich clea? Usere Atwort darauf lautet: effiziet. Als clea wurde ursprüglich ur der Quellcode bezeichet, der Begriff wird heutzutage aber viel breiter verstade. Wir dehe ih auf de gesamte Etwicklerkosmos aus. Wir glaube weiter, dass ei Appell a die Professioalität bei de meiste Etwickler icht ausreicht, soder dass es och ei stärkeres Mittel gibt, um mehr Sauberkeit im Etwickler- Kosmos zu erreiche: ämlich Teamplay. Deshalb wolle wir i diesem Artikel die Team-Clea-Codig - Methode vorstelle ud zeige, mit welche kokrete Maßahme diese Methode im Projektalltag eigeführt ud so die Clea-Codig-Metalität viel lebediger werde ka. Professioalität ist die Fähigkeit, durch spezielle Hadluge ei kokretes Ziel mit miimalem Aufwad zu erreiche. Professioell bedeutet also, etwas effiziet d.h. clea zu tu (siehe Kaste 1). Demetspreched habe die Clea Code Developer (CCD) eie Iitiative, die 2009 vo Ralf Westphal ud Stefa Lieser gegrüdet wurde (vgl. [CCD]) eie Defiitio dieses Begriffs aufgestellt, der für effiziete Softwareetwicklug (SE) wichtig ist: Professioalität = Bewusstsei + Prizipie. Uter Bewusstsei verstehe die CCD die städige Selbstkotrolle eies Etwicklers, das Wertesystem auch uter widrige Umstäde kosequet azuwede. Damit appelliere die CCD (ud wir auch) a de Berufsethos ud de Ehrgeiz vo Etwickler, ei Profi zu sei oder eier zu werde. Dieser Appell richtet sich a die meschliche Veruft eies jede eizele Etwicklers. ei Mesch, der verstade habe, was verüftig ist, schöpfe aus dieser ratioale Eisicht die Motivatio, das Verüftige auch wirklich zu tu (vgl. [Wik-c]). Diese Philosophie hätte die Welt eigetlich verbesser müsse. Tatsächlich reicht die ratioale Eisicht ur bei starke Idealiste als alleiige Motivatiosquelle aus, verüftig zu hadel. Eie zusätzliche, viel stärkere Motivatiosquelle ist eie soziale Form vo Kotrolle. Als sozialverträglich betrachte wir eie Kotrolle auf Augehöhe i Form der TCC-Qualitätssicherug (siehe Abbildug 1). Sie wirkt folgede Eistelluge etgege: Aber Saubermache ka ich das jetzt icht mehr! Diese Haltug macht deutlich, dass der iere Schweiehud auf Dauer vor allem uter Zeitdruck stärker wird als die persöliche Überzeugug, dass Clea Codig wichtig ist. Nei, ei, so mach ich das aber icht! Uterschiedliche Meiuge, die sich icht aäher, stelle offee oder versteckte Koflikte dar, die Wildwuchs ud damit Ieffiziez bewirke. TCC hilft, die Meiugsvielfalt zusammezuführe. Meie Meiug zählt ja sowieso icht! Die Durchsetzugsstarke im Team habe icht automatisch die bessere Argumete. Durch TCC habe die Durchsetzugsschwache ei Mittel, das ihre Positio stärkt. Ist doch egal, wie mei Code aussieht, es iteressiert sich ja doch keier dafür! Gege diese Eistellug hilft die Warum Team Clea Codig (TCC)? Der Philosoph Immauel Kat vertrat scho vor über 200 Jahre die Meiug, Clea ist alles, was ituitiv verstädlich ist: (Quellcode-)Dokumete, Datestrukture, Kozepte, Regel, Verfahre usw. Ituitiv verstädlich ist, was mit weig Spezialwisse i kurzer Zeit richtig verstade wird. Weig ud kurz ist dabei relativ zur vorliegede Komplexität zu sehe. Clea ist also alles, was die Softwareetwicklug beschleuigt. Das schließt die Korrektheit (vgl. [Wes12]), die Evolvierbarkeit (vgl. [Wes13-a]) ud die Produktioseffiziez (vgl. [Wes13-b]) der Software ei. Kaste 1: IT-Defiitio vo clea. Abb. 1: Das TCC-Kozept (Kaste 3) besteht aus 4 Bereiche ud acht Teilbereiche. Es hat das Ziel, Clea Code ud Clea Architectig (Kaste 5) zu gewährleiste. 52

2 Clea Code ist ei alter Begriff, der de Blick auf de Quellcode fokussiert. Die CCD- Bewegug hat mit ihre Praktike bereits deutlich gemacht, dass viel mehr als ur der Code sauber sei sollte. Um de Blick zu weite ud de gaze Softwareetwicklugsprozess i de Fokus der Effiziezsteigeruge zu brige, spreche wir im Clea Codig Cosmos (CCC) vom Clea Codig. Der CCC erweitert de Professioalitätsgedake der CCD um weitere Aspekte des Applikatios-Lebeszyklus-Maagemets (siehe Abbildug 1 i [Obe13]). Diese Erweiterug schließt sauberes Requiremets-Egieerig, Clea Architectig (siehe Kaste 4), veratwortugsvolles Projektmaagemet (siehe Kaste 6 i [Obe14]) ud effektive Zusammearbeit mit dem Betrieb ei. Als CCD uterscheide wir Prizipie, also Maßahme, die de Quellcode sauber halte, ud Praktike, d. h. eie bute Sammlug vo Maßahme, die gaz uterschiedliche Teile des Softwareetwicklugsprozesses betreffe. Im CCC verfolge wir das gazheitliche Ziel, alle Eiflussgröße auf die Software ud de Softwareetwicklugsprozess icht ur zu ee, soder sie so zu strukturiere, dass alle gleichzeitig besser im Blick behalte werde köe. Zu diesem Zweck habe wir i [Obe13] die vierdimesioale Raumzeit des Softwareetwickler-Kosmos vorgestellt. Im CCC betrachte wir icht ur die schöe, saubere Seite der Softwareetwicklug, soder auch die dukle, schmutzige Seite. Das ist wichtig, um zu erkee, i welche Bereiche des Softwareetwicklugs-Kosmos am meiste Hadlugsbedarf für Effiziezsteigerug besteht. Zu diesem Zweck habe wir i [Obe14] de kosmologische Schmutz beleuchtet. Der i [Obe14] gefudee Softwareetwicklugs-Schmutz macht deutlich, dass die Kommuikatio, die i alle vier Dimesioe des CCC eie Rolle spielt, im Kotext vo Effiziezsteigerug verachlässigt wurde. Der Appell der CCD a die Professioalität ist gut, reicht aber oft icht aus. Eie gegeseitige Qualitätskotrolle im Team ist dagege viel wirkugsvoller. Diese fuktioiert allerdigs ur mit effektiver Kommuikatio. Zu diesem Zweck gibt es im TCC zusätzliche Regel, die das Teamplay betreffe. Wie das clea aussehe ka, stelle wir i diesem Artikel vor. Kaste 2: Clea Code Developer (CCD) ud Clea Codig Cosmos (CCC). TCC-Kotrolle. Sie ist eie stärkere Motivatio als das Zuckerbrot ud Peitsche -Prizip (vgl. [Obe13]) durch eie Code-Watch. Das Team Clea Codig TCC ist Teil des Clea Codig Cosmos (CCC). Im CCC schließe wir us der Philosophie der Clea-Code-Developer (CCD) a, gehe allerdigs i eizele Pukte och weiter (siehe Kaste 2). Die Ritter der Tafelrude verbad das gemeisame Grudverstädis, dass sie erstes alle Gleiche uter Gleiche ware ud sie sich zweites eiem gemeisame Verhalteskodex uterordete. Die gleiche Idee liegt dem TCC zu Grude. Auf diesem Grudverstädis basiert das TCC- Kozept, das aus folgede vier Bereiche besteht: 1. Iitialisierug 2. Ausführug 3. Optimierug 4. Qualitätssicherug Jeder dieser Bereiche beihaltet Teilbereiche. Die isgesamt acht Teilbereiche des TCC-Kozepts lasse sich gut durch die Staatsmetapher veraschauliche (siehe Abbildug 1 ud Kaste 3). Iitialisierug 1.1 Alle Teammitglieder (TM) verpflichte sich, Regel ud Prozesse azuerkee ud eizuhalte, die für alle gleichermaße verbidlich sid. Diese Regel ud Prozesse köe bei Bedarf jederzeit agepasst werde. 1.2 Als erstes wird eie Methode zur Etscheidugsfidug festgelegt: Wie fällt das Team verbidliche Etscheiduge? 1.3 Als ächstes werde zu folgede grudsätzliche Frage verbidliche Etscheiduge getroffe: a) Dokumetatio: Welche Iformatioe werde wie festgehalte, persistiert ud für alle TMs zugäglich gemacht? b) Defiitio of Clea (DoC): Was bedeutet für us Clea Code ud Clea Architectig? c) Defiitio of Doe (DoD): Was geau muss erfüllt sei, damit eie Programmieraufgabe als fertig aerkat werde ka? d) Code Owership: Gibt es so etwas wie persöliche Code oder darf jedes TM jede beliebige Codestelle äder? Awedug 2. Alle TM wede alle festgelegte Regel ud Prozesse bei ihrer tägliche Arbeit kosequet a. Optimierug 3.1 Die TM komme regelmäßig zusamme ud tausche Iformatioe aus, ob die bisherige Regel ud Prozesse gut fuktioiere oder ob sie agepasst bzw. erweitert werde müsse. Dazu stehe Daily-Stadups, Joural Codig Club ud Retrospektive-Meetigs zur Verfügug. Darüber hiaus köe Iformatioe auch durch Pair-Programmig ud Codig Notes ausgetauscht werde. 3.2 Bei Bedarf verabschiedet das Team mit der uter Iitialisierug, Pukt 1.3, festgelegte Methode eue Regel oder ädert bestehede. Qualitätssicherug 4.1 Nach Abschluss eier Programmieraufgabe durch ei TM stellt ei aderes TM sicher, dass die vereibarte DoD erfüllt ist (Vier-Auge-Review). Erst we für beide TM die DoD vollstädig ist, gilt die Programmieraufgabe offiziell als fertig. 4.2 Das Team ka Regel beee, dere Verstoß als schwerwieged deklariert wird. Ei Verstoß gege solche Regel darf im Koses aller TM mit eier Verpflichtug zu eier 1-Euro-Spede verküpft werde. Das Team bestimmt später gemeischaftlich die Verwedug der Spedekasse. Kaste 3: Formelle Beschreibug des TCC (siehe auch Abbildug 1). 02/

3 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Abb. 2: Thumb Votig. Alle Teammitglieder werde um ei Hadzeiche gebete, bei dem diese drei Daumepositioe zulässig sid. Kostitutio/Basiskoses Am Afag steht die Eiigug aller Teammitglieder (TM) auf de kleiste gemeisame Neer: de Basiskoses (Pukt 1.1 i Kaste 3) er ist das Fudamet des TCC- Kozepts. Abb. 3: Ablauf eier Programmieraufgabe im TCC. Defiitio der Legislative/Methode zur Etscheidugsfidug Die (Meta-)Etscheidug, wie das Team zu eier Etscheidugsfidug kommt, ist für alle kommede Etscheiduge vo grudlegeder Wichtigkeit. Als Werkzeug für die Etscheidugsfidug eiget sich das Thumb Votig (siehe Abbildug 2). Für die Meta-Etscheidug gibt es vier Wege: Sauberes Umsetze eier Architekturaufgabe hat aus CCC-Sicht drei Aspekte: 1. Dokumetatio Die Beschreibug der Architektur beihaltet alle relevate Aforderuge, ist i sich schlüssig ud für alle Stakeholder gut zugäglich ud leicht verstädlich. 2. Bewertug Die gefällte Architekturetscheiduge ermögliche, dass die wichtige Aforderuge gut umgesetzt werde köe ud die Risike miimiert werde. 3. Realisierug Die beschriebee Architektur wird i der Implemetierug umgesetzt ud lässt sich im Code klar achvollziehe. Um das zu erreiche, schlage wir im TCC die Verwedug des arc42 Templates vor (vgl. [Hru13-a], [Zör12]). Zu diesem Template gehört eie Methodik, die eie gewisse Prozess ahe legt (vgl. [Hru13-b]). Die Awedug vo Template ud Prozess führt zu Clea Architectig. Kaste 4: Clea Architectig. Hierarchisches Modell: Das Team überträgt eiem Mitglied für eie bestimmte Bereich die Etscheidugshoheit, z. B. eiem Mitglied mit viel Architekturerfahrug die Etscheidugshoheit über Architekturfrage. Mehrheitsmodell: Die Alterative mit der höchste Zustimmug wird beschlosse. Koset: Die Alterative mit der gerigste Ablehug wird beschlosse (vgl. [Wik-a]). Koses: Eie Alterative wird ur beschlosse, we sie keie Ablehug erfährt (vgl. [Wik-b]). Sie muss evetuell so geädert werde, dass es keie Ablehug mehr gibt. Bei eier Kosesrude wird jeder Teilehmer explizit befragt, welche Alterative ei (gegebeefalls persöliches) Problem darstellt (vgl. [Wit11]). Vorteil der erste drei Möglichkeite ist, dass Etscheiduge relativ schell gefällt werde köe. Ihr Nachteil besteht i der Gefahr, Teamkollege zu zwige, gege ihre persöliche Überzeugug zu arbeite. Das ka zu starke offee oder versteckte Widersprüche führe. Der Vorteil der vierte Möglichkeit ist geau die Vermeidug solcher Widersprüche im Team. Ihr Nachteil ist jedoch eie uter Umstäde lagwierige Etscheidugsfidug. Grudgesetz/projektuspezifische Regel Letzter Schritt der Iitialisierug ist das gemeischaftliche Beatworte vo Frage, die grudsätzlich i jedem Projekt wichtig sid (Pukt 1.3 i Kaste 3). Dies stellt die zuvor beschlossee Meta-Etscheidug auf eie erste Probe ud ka bei größere Teams mehr als eie Nachmittag Aufwad bedeute. Wir gebe für die i Kaste 3 gestellte Frage folgede Empfehluge: Dokumetatio: Alle beschlossee Regel ud Prozesse sowie alle vom Team getroffee architektoische Etscheiduge (siehe Kaste 4) sid i eiem Wiki festzuhalte. Alle TM habe Lese- ud Schreibrechte. Darüber hiaus werde ei zetraler Problem-Lösug-Katalog ud eie zetrale Checklistesammlug gepflegt (siehe Kaste 5). DoC: Für CCD-Afäger eige sich die Regel des rote Grades (siehe ute). CCD-Fortgeschrittee köe uter Berücksichtigug der Kritikalität die für das Projekt geeigete CCD-Regel festlege (siehe Abbildug 6). DoD: Die i Kaste 3 uter 4.1 geate Maßahme verbidlich festlege (siehe Abbildug 3 i [Obe14]). Im Zusammehag mit der Testabdeckug empfehle wir bei mittlerer Kritikalität circa 80 Prozet der Programmzeile (siehe Abbildug 6). Außerdem halte wir midestes eie Itegratiostest für otwedig. Eie mauelle Utersuchug muss dabei sicherstelle, dass alle kritische Pfade ethalte sid. Code-Owership: Alle gehört alles, d. h. jeder Etwickler darf jede Codestelle äder. Das ist icht selbstverstädlich ud muss klar kommuiziert werde. 54

4 Exekutive/Awedug Der Projektalltag eies Etwicklers besteht im Wesetliche aus der Aalyse vo Aforderuge, dem Umsetze dieser Aforderuge ud der Qualitätssicherug. Bei dieser Arbeit werde alle im Team abgesprochee Regel ud Prozesse agewadt. Dabei gehört es zum Berufsethos, diese Regel auch gege widrige Umstäde wie Termidruck ud de iere Schweiehud professioell zu verteidige. Parlamet/Meiugsaustausch Für eie städige Optimierug des TCC braucht das Team ei Forum zum Diskutiere ud zur Meiugsbildug. Im TCC stehe dafür drei verschiedee Forme vo Parlametssitzuge zur Verfügug: Do t Repeat Mistakes Vieles i der Softwareetwicklug lässt sich icht automatisiere ud muss mauell erledigt werde. Dabei geschehe immer wieder Fehler. Damit diese Fehler icht wiederholt auftrete, ist es wichtig festzuhalte, wie sie vermiede werde köe. Für mauelle Arbeitsschritte eiget sich eie Checkliste, die jede Schritt i der richtige Reihefolge beet. Do t Re-uravel Mysteries Bei komplexe Systeme kommt es immer wieder vor, dass sich das System völlig uerwartet verhält. Die Ursachefidug dauert machmal lage ud hält die Softwareetwicklug sehr auf. Nach Abschluss eier solche Rätselsuche ist es deshalb wichtig, das Problem zusamme mit seier Lösug zu dokumetiere. Dafür eiget sich ei Problem-Lösug-Katalog. Dieser ka mit der Zeit für ei spezielles Problem (Symptom) mehrere Lösuge beihalte. Auf diese Weise muss ei Rätsel ur eimal gelöst werde. Kaste 5: Die DoReMi- ud DoReMy-Regel. Daily Stadups: Nach dem Vorbild vo Scrum sehr kurze Meetigs, die täglich zur selbe Zeit im Stehe durchgeführt werde. Jedes TM beschreibt kurz seie aktuelle Tätigkeit ud et gegebeefalls Probleme, die es aufhalte. Koste: Circa zwei Miute pro Perso ud Tag, circa 0,5 Persoetage (PT) pro Moat für ei füfköpfiges Team. Nutze: Aufdecke vo Querverbiduge zwische Programmieraufgabe, Hilfeagebote vo TM, die Möglichkeit zur tägliche Optimierug vo Regel ud Prozesse. Joural Codig Club: Wöchetliche oder 14-tägige Team-Meetigs, die Fortbildugscharakter mit direktem Projektbezug habe. Koste: Circa 2 PT pro Moat für ei füfköpfiges Team. Ihalt: Besprechug vo Fachliteratur, Code-Reviews, Vorstellug vo aktuell oder zuküftig eigesetzte Techologie. Nutze: Agleichug des Wissesstads im Team, eiheitliche Vorstellug davo, was sauber ist ud was icht, eiheitliche Meiug, mit welcher Lösugsstrategie wiederkehrede Probleme agegage werde. Retrospektive-Meetigs: Nach dem Vorbild vo Scrum moatliche oder quartalsweise zwei- bis dreistüdige Team-Meetigs. Ihalt: Was lief gut, was schlecht? sowie Lessos Leared. Koste: Circa 1,5 PT pro Moat für ei füfköpfiges Team. Nutze: Regelmäßige Reflexio der aktuelle TCC-Regel ud -Prozesse über eie lägere Zeitraum. Diese drei Team-Meetigs beötige zusamme für ei füfköpfiges Team ca. 4 PT pro Moat a Kommuikatiosaufwad. Dieser Aufwad ist aber kei reier Zusatzaufwad für TCC, de Kommuikatio fidet auch ohe TCC statt. Bei Teams, die vo sich aus viel kommuiziere, ist der Zusatzaufwad für TCC gerig, die Kommuikatio erfolgt ur i strukturierterer Form. Parlametsmitglieder tausche auch außerhalb der Parlametssitzuge Iformatioe aus. Für TCC-Mitglieder stehe dazu Pair-Programmig (vgl. [Wik-f]) ud Codig-Notes zur Verfügug: Pair-Programmig ist besoders effektiv, we es gezielt bei kifflige Probleme zum Eisatz kommt. Eie gute Lösug wird so meistes viel scheller gefude als allei. Zugleich wird das Wisse über diese Lösug im Team verbreitet ud uerfahree Etwickler köe dabei extrem gut vo erfahree lere. Codig Notes sid ei Mittel, um wertvolle Iformatioe zu verbreite ud auch zu koserviere. Die eifachste Form eier Codig Note ist die a de Team-Verteiler. Auf diese Weise köe Hiweise über eue Utilities im Code oder Liks zu eier iteressate Webseite eifach mitgeteilt werde. Werde solche s mit eiem spezielle Schlüsselbegriff im Betreff markiert, ka jeder Etwickler i seiem Postfach sehr eifach eie Wissesdatebak aufbaue. Abb. 4: Schematische Darstellug vo Team-Type ([Wiki-e]). Jeder Pfeil stellt die Wirkrichtug eies Etwicklers ud desse Stärke dar. Jeder Kreis stellt ei Team dar. Die Summe der Wirkrichtuge i eiem Team stellt die Team-Performace (die Effiziez des Teams) dar. Nur i echte Teams ist die Performace hoch. Arbeite die Teammitglieder icht gut zusamme, hadelt es sich eher um eie Gruppe oder sogar um eie Haufe. TCC ermöglicht, aus Haufe Gruppe ud aus Gruppe echte Teams zu mache. Dazu müsse aber auch die Rahmebediguge stimme. 02/

5 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Alle im Team vereibarte CCD-Regel wurde eigehalte (DoC). Es gibt keie als ufertig markierte Codestelle mehr (siehe Kaste 6). Der Quellcode ist leicht verstädlich (dazu zählt uter aderem die Code- Dokumetatio). Die Testabdeckug ist ausreiched. Erst achdem auch der Reviewer sei OK abgegebe hat, gilt die Programmieraufgabe offiziell als erledigt. Bei Fehler bzw. Mägel, die im Nachhiei auftrete, trägt der Reviewer eie ebeso große Veratwortug wie der Autor des Codes. Uterstütze lässt sich diese Vorgehesweise durch das (leider ur auf GIT ud Jekis basierede) Tool Gerrit (vgl. [Ger13]). Diese Vorgehesweise hat folgede füf Vorteile: Abb. 5: Das TCC-Startup-Kid (DoD = Defiitio of Doe, DoC = Defiitio of Clea). Legislative/Weiteretwicklug des Regelwerks I de frühe Phase eies Projekts reiche die projektuspezifische Grudregel zuächst aus, um effektiv im Team zu arbeite. Jedes Projekt stellt jedoch eie eigee kleie oder große Welt dar, die spezifische Umstäde ud Situatioe mit sich brigt. Deshalb dauert es i der Regel icht lage, bis die Notwedigkeit ach projektspezifische Regel ud Prozesse deutlich wird. Es gibt immer wieder Phase im Projekt, i dee die Komplexität wächst ud mit dem Projekt etwickel sich auch die TM weiter. Aus diesem Grud ist es wichtig, die bestehede Regel ud Prozesse städig zu reflektiere ud gegebeefalls zu optimiere. Die im Abschitt Parlamet/Meiugsaustausch agesprochee Möglichkeite zur Diskussio ud zum Iformatiosaustausch führe bei de TM zu eier Meiugsbildug, die sich da immer wieder i der Überarbeitug der bestehede Regel ud Prozesse oder i der Formulierug euer Regel ud Prozesse maifestiert. Der Verfassugsschutz/ Vier-Auge-Review Das Vier-Auge-Review prüft die Eihaltug der Defiitio of Doe (DoD), beruht auf dem Vier-Auge-Prizip ud stellt ei bewährtes Review-Verfahre dar: die Stellugahme (vgl. [Poh10]). Betrachtet ei TM eie Programmieraufgabe (Bugfix oder eues Feature) als vollstädig umgesetzt, bittet es ei aderes TM seier Wahl, ei Vier-Auge-Review für diese Programmieraufgabe durchzuführe (siehe Abbildug 3). Der Reviewer prüft Folgedes: Alle fuktioale ud icht-fuktioale Aforderuge wurde umgesetzt. Mit folgeder Sytax köe Codestelle, die i irgedeier Form och eie Überarbeitug beötige, markiert werde: <Tag> <Datum> <Autor des Tags> <Beschreibug> Folgede Tags stehe zur Verfügug: FIXME: Diese Codestelle muss och bearbeitet ud der Tag etfert werde, um die DoD zu erreiche. TODO: Diese Codestelle (ud der Tag) dürfe für die DoD ur verbleibe, we dafür im verwedete Issue- Tracker ei Issue agelegt wurde. REFACTORME: Diese Tags zeige a, dass eie Codestelle icht optimal gelöst wurde. Sie sid aber icht DoD-relevat ud sollte sparsam verwedet werde. Kaste 6: Das TCC-Code-Taggig- System. 1) Alle Softwarefehler, die der Reviewer fidet, köe sofort ud zeitah vom Autor behobe werde. Ohe das Review falle diese Fehler meistes erst ach der ächste Auslieferug auf oft erst ach Woche ud Moate. Das macht zusätzliche Verwaltugsaufwad dieses Bugs i eiem Issue- Tracker ud eie häufig lagwierige achträgliche Aalyse otwedig. 2) Trotz Eisatz vo automatische Code- Aalyse bleibt der meschliche Code- Review das eizig sichere Mittel, die Verstädlichkeit vo Quellcode festzustelle. 3) Für Besuch macht ma zu Hause i der Regel grüdlicher sauber als für sich allei. Das Gleiche gilt beim Programmiere: Wer möchte scho, dass ei TM Schmutz im selbst geschriebee Code fidet? 4) Kostruktive Kritik ist für viele Etwickler motiviereder als Desiteresse a geleisteter Arbeit. 5) Fidet ei Reviewer weig oder keie Kritikpukte, stellt dieses Review-Ergebis für de Autor ei uausgesprochees Lob dar eie wortlose Aerkeug für gute Arbeit. Das Lob darf aber auch gere offe ausgesproche werde. Die Judikative/die 1-Euro-Regel Fehler zu mache, ist meschlich. Fehler wiederholt zu mache, reduziert aber die Effiziez der Softwareetwicklug (siehe Kaste 5). Immer wiederkehrede Fehler, die adere behider, schaffe schlechte Teamstimmug, die ebefalls die Effiziez reduziert. Hier ei Beispiel: Zum Feier- 56

6 abed schließt ei TM seie Tagesarbeit mit eiem gutem Gefühl ab ud überträgt de aktuelle Etwicklugsstad is zetrale Repository. Ei automatischer Prozess holt i seier Abweseheit die aktuelle Source aus dem zetrale Repository, kompiliert sie, testet sie ud baut die Software. Tritt dabei ei Fehler auf, steht ei aderes TM spätestes morges früh vor eiem fremde Hideris. Diese Feierabed- Check-I-Metalität ist ei typisches Beispiel für chroische Usitte, gege die das Team mit der im Kaste 3 beschriebee 1-Euro-Regel vorgehe ka. Die Erfahrug hat gezeigt, dass diese etwas skurril wirkede Regel für uageehme Kratzer am eigee Etwicklerstolz ud damit eie erhöhte Motivatio für die Eihaltug der Vereibaruge sorgt. Nach eier lägere Projektphase ka das Team vo de erworbee Spede zusamme esse gehe. TCC-Rahmebediguge Es gibt teils mehr, teils weiger klare Greze der Selbstbestimmug eies TCC-Teams. Deshalb hikt der obe gezogee Vergleich zu de Ritter der Tafelrude, de die Ritter ware kaum fremdbestimmt, viele Etwicklerteams sid es aber maßgeblich ud zwar durch folgede Faktore: Abb. 6: CCC-Zuordug vo CCD-Regel zur Kritikalität vo Software. Die Farbe zeige de jeweilige CCD-Grad der Regel a. Die liks aufgeführte Regel schlage wir im CCC-Kotext als CCD-Basisregel vor. * Im CCC-Kotext setze wir Test First mit TDD gleich. Diese Etwicklugstechik birgt gewaltiges Effiziez-Potezial, ist aber sehr aufwädig im Erlere. Für TDD- Neulige sollte das Set der CCD-Basisregel weigstes eie TDD-Fortbildug beihalte. Jedes Team arbeitet für eie Auftraggeber, der Rahmebediguge vorgibt. Dazu zähle z.b. die räumliche Ifrastruktur, Hardware ud Software. Ei Etwicklugsteam ist i der Regel icht für de gesamte Lebeszyklus der Software veratwortlich (vgl. auch die Dimesio Prozess i [Obe13]). Die eigetliche Etwicklug ist meistes i eie größere ALM-Prozess eigebude. Deshalb muss das Team auf extere Faktore, z.b. de Betrieb, der die Software i der Produktio pflegt, Rücksicht ehme. Bei große Uterehme ist ei eizeles Team häufig Teil eier gaze Etwicklugsabteilug. Aus Sicht der Leitug der Gesamtetwicklug ist es ieffiziet, falls die eizele Teams voeiader völlig losgelöst ud autark eie Staat im Staate bilde. Um Wildwuchs ud Ieffiziez aus team- ud projektübergreifeder Sicht zu vermeide, muss ei TCC-Team Vorgabe der Gesamtetwicklug (z.b. bezüglich Qualitätssicherug) i ihrem Regelwerk berücksichtige. Die Kust des Etwicklugsleiters liegt i der Gratwaderug zwische teamübergreifeder Vereiheitlichug ud Wahrug der Selbstbestimmug der eizele Teams. Selbstorgaisatio des Teams uterstütze Das Umfeld vo TCC-Teams sollte die Selbstorgaisatio der Teams akzeptiere ud uterstütze. Beispielsweise muss die beötigte Ifrastruktur wie ausreichede starke Software ud Hardware für CI-Server ud adere Qualitätssicherugsmaßahme bereitgestellt werde. Kommuikatio im Team eiplae Es muss ausreiched Zeit für die Kommuikatio im Team eigeplat werde (siehe obe, Abschitt Parlamet/Meiugsaustausch ), für ei füfköpfiges Etwicklerteam etwa vier PT pro Moat. Fortbildug der firmeeigee Mitarbeiter förder Die Fortbildug der TM sollte uterstützt werde. I der schelllebige Welt der IT gilt: Stillstad ist Rückgag. Um vo eue modere Lösuge zu profitiere, muss regelmäßig eues Kow-how vo auße i die Firma, i die Abteilug ud i die Teams geholt werde. Außerdem erhöht die Fortbildug die Motivatio vieler Etwickler auch i ihrem Etwickleralltag. Teamstimmug berücksichtige ud förder Nicht selte werde eue TM, speziell extere Mitarbeiter, ahad so gea- ter Skillsets (Teil ihres Profils) ausgewählt ud die persöliche Eigeschafte ud die meschliche Kompatibilität der TM werde verachlässigt. Das ka schell zu schlechter Teamstimmug, magelder Kommuikatio ud iedriger Performaz führe (siehe Abbildug 4). Daily Stadups ermögliche es, solche frühzeitig aufzudecke. Persöliche Kofliktsituatioe ka das Team i der Regel icht selbst löse. I solche Fälle ist ei Eigreife des Projektleiters bzw. Scrum Masters gefragt. Ei ützliches Forum dafür stelle auch die Retrospektive-Meetigs dar (siehe obe, Abschitt Parlamet/Meiugsaustausch ). I eiige Fälle sollte eie eue Teamzusammestellug i Betracht gezoge werde, was bei (Feature-getriebee) agile Teams ohehi gebräuchlich ist. TCC eiführe TCC ist eie Zusammestellug vo Maßahme, die alle icht eu, aber im Teamplay bewährt sid. Die Motivatio, diese Maßahme azuwede, muss wie auch bei adere Etwicklugsmethode (wie Scrum, OOP oder TDD) vo de Etwickler selbst komme. Sie lasse sich icht verorde. Der Versuch, eue Arbeitsweise i Teams eizuführe, ist deshalb grudsätzlich ei Problem. Isbesodere we es sich um ei och icht allgemei aerkates Verfahre hadelt, sid viele Akteure sehr skeptisch. Um das so geate Not-Ivited-Here-Sydrom 02/

7 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig (vgl. [Wik-d]) zu vermeide, muss jedes TM bewusst a de Etscheidugsprozesse beteiligt werde. TCC uter der Haube eiführe Der TCC-Maßahmekatalog ist kei moolithischer Prozess. Die eizele Maßahme des Katalogs köe bei Bedarf eizel agewadt werde. Die Motivatio dafür stammt i der Regel aus Schmerze, die eie ieffiziete SE verursacht. TCC ka also auch schrittweise pai drive eigeführt werde. Dabei ist jedoch der Basiskoses grudsätzlich immer otwedig. TCC im Start-Up-Kit eiführe Um zu teste, wie sich TCC afühlt, ohe das volle Programm azuwede, ka ei Team eie reduzierte Maßahme-Katalog, das TCC-Start-Up-Kit, ausprobiere (siehe Abbildug 5). Nach etwa zwei Woche stellt sich da ei erstes TCC-Gefühl ei. TCC ohe CCD-Ketisse eiführe De Effiziezgewi der gemeisame Awedug vo TCC- ud CCD-Regel halte wir für eorm. Die CCD gebe keie Prioritäte für ihre Regel a ud die Eiteilug i die farbige Grade ist eher eie Lerhilfe. Im CCC schlage wir vor, die Priorität der CCD- Regel mithilfe der Kritikalität der Software zu bewerte (siehe Abbildug 6). Vor dem Hitergrud der Kritikalität sehe wir eiige eifache, leicht verstädliche Basisregel, die wirklich immer als Miimum- Muss agewedet werde sollte. Teams, die plae, TCC ohe CCD-Vorketisse eizusetze, empfehle wir weigstes die i Abbildug 6 geate Regel für gerige Kritikalität zu berücksichtige. Literatur & Liks [CCD] Clea Code Developer, siehe: [Hru13-a] P. Hruschka, G. Starke, arc42 Ressource für Software-Architekte - Template, 2013, siehe: [Hru13-b] P. Hruschka, G. Starke, arc42 Ressource für Software-Architekte Prozess, siehe: [Obe13] R. Oberrath, J. Vollmer, Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler, i: OBJEKTspektrum 6/2013 [Obe14] R. Oberrath, J. Vollmer, Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz, i: OBJEKTspektrum 1/2014 [Poh10] K. Pohl, C. Rupp, Basiswisse Requiremets Egieerig (2. Auflage), dpukt.verlag 2010 [Wes12] R. Westphal, Clea Code Developer: Korrektheit als Wert, i: OBJEKTspektrum 06/2012 [Wes13-a] R. Westphal, Clea Code Developer, Teil 3: Evolvierbarkeit als Wert, i: OBJEKTspektrum 01/2013 [Wes13-b] R. Westphal, Clea Code Developer, Teil 4: Produktioseffiziez als Wert, i: OBJEKTspektrum 02/2013 [Wik-a] Wikipedia, Soziokratie, siehe: [Wik-b] Wikipedia, Koses, siehe [Wik-c] Wikipedia, Kritik der praktische Veruft, siehe: [Wik-d] Wikipedia, Not-ivited-here-Sydrom, siehe: [Wik-e] Wikipedia, Teambildug, siehe: [Wik-f] Wikipedia, Pairprogrammig, siehe: [Wit11] M. Wittwer, Etscheide im Koses, 2011, siehe: [Zör12] S. Zörer, Softwarearchitekture dokumetiere ud kommuiziere: Etwürfe, Etscheiduge ud Lösuge achvollziehbar ud wirkugsvoll festhalte, Haser Verlag 2012 läutert habe. Es ist aber keie Weltformel eher eie Eischwekhilfe i eie güstige Orbit, d.h. ei Wegweiser zu eiem Softwareetwicklugsprozess, der zu eiem bestimmte Ster, d.h. Projekt, ud Die Autore Fazit Team Clea Codig ist eie Methode, um die Clea-Codig-Regel im Etwicklerteam lebedig werde zu lasse. Dadurch wird der Softwareetwicklugsprozess erheblich effizieter, weil die Teammitglieder sich so gegeseitig motiviere, voeiader lere ud a eiem Strag ziehe. Als Herzstück des Softwareetwicklugsprozesses wirkt das TCC i alle Dimesioe des Etwicklerkosmos hiei, die wir i Teil 1 dieses Artikels (vgl. [Obe13]) vorgestellt habe. Ud es wirkt gege alle Forme vo kosmischem Schmutz, die wir i Teil 2 dieses Artikels (vgl. [Obe14]) erde dortige Akteure gut passt. Das TCC besitzt eiige kokrete Startregel, jedoch weige allgemeigültige Regel ud lässt somit viele Apassugsmöglichkeite für spezielle Projektsituatioe offe. Dr. Reik Oberrath (R.Oberrath@iks-gmbh.com) ist als IT-Berater bei der iks Gesellschaft für Iformatios- ud Kommuikatiossysteme tätig. Er beschäftigt sich seit viele Jahre mit der Etwicklug vo idividuelle Geschäftsaweduge ud mit der Architektur kompoetebasierter Systeme. Jörg Vollmer (ifo@iformatikbuero.com) ist freiberuflicher IT-Berater ud verfügt über lagjährige Erfahrug als Etwickler, Softwarearchitekt ud Traier im Java-Umfeld, speziell Java EE ud Sprig. Seie Leideschaft gehört dem Vermittel vo Software-Qualitätsbewusstsei. 58