Continuous Integration

Letztens hab ich als kleine Seminararbeit in der Uni was über Continuous Integration geschrieben.

Hier meine Seminararbeit:
Download: Continuous Integration: Aspects in Automation and Configuration Management (Größe: 355.51 kB; bisher 252 mal heruntergeladen)

Und hier die zugehörige Präsentation:
Download: Continuous Integration (Präsentation) (Größe: 1.4 MB; bisher 209 mal heruntergeladen)

Wer sich für CI interessiertn sollte aber vielleicht eher den einschlägigen Artikel von Martin Fowler und/oder das Buch von Paul Duvall lesen.

Agile: Wenn “agil” draufsteht…

… ist wohl nicht immer agil drin.

Leider wird Agile Softwareentwicklung oft so verstanden, wie in obigem nicht nur einmal zitiertem Dilbert-Comic. Mein Eindruck ist manchmal, dass das Wort “agil” dazu benutzt wird, dem Nichtvorhandensein einer strukturierten und durchdachten Vorgehensweise einen Namen zu geben. Aber genau das ist agile Softwareentwicklung eben *nicht*. Agile Softwareentwicklung heißt nicht einfach mal drauflos coden und hoffen, dass alles schon irgendwie gut geht.

Letztens hab ich auf heise eine interessante Umfrage gesehen, die genau das zeigt. Zumindest ist das meine Interpretation der Daten.

Nach der Umfrage nutzen 17% gar kein Vorgehensmodell. Dazu kommen die oben genannten Feigenblatt-Agilen und wohl auch ein paar Feigenblatt-Phasenorientierten. Wenn man jetzt auch noch bedenkt, wer die Fragen beantwortet hat (Tester, Entwickler, Manager, …), dann zeigt sich, dass Entwickler deutlich häufiger angeben, keinem Vorgehensmodell zu folgen. Da aber wohl die Entwickler diejenigen sind, die das am besten wissen sollten, vermute ich mal, dass die 26% (Entwickler, die angegeben haben, keinem Vorgehensmodell zu folgen) eher stimmen als die 17% (Durchschnitt über alle Rollen). Da klaffen wohl Anspruch und Wirklichkeit etwas auseinander.

Aber gucken wir mal genauer:

• 27% der “agilen” nutzen ein “eigenes agiles Vorgehensmodell”. Soso…
• 57% nutzen Scrum (weil es grad in Mode ist, das zu behaupten)
• Nur bei 43% der “agilen” Projekten sind Unit-Tests vollständig automatisiert. Knapp 30% haben eine Automatisierungsquote unter 70%. Und nennen sich dabei “agil”.

Die genannte Statistik hat sich jetzt auf Tests konzentriert. Ich schätze mal, wenn man da in andere Richtungen fragt, wird man ein ähnliches Bild erhalten: Nicht alle, die behaupten, agile Softwareentwicklung zu betreiben, tun das auch.

Pi mal Daumen schätze ich also mal, ein Drittel der agilen sind nicht wirklich agil. Grob geraten sind wohl 50% phasenorientiert 20% agil und 30% gar nix. Und die Übergänge sind fließend.

Teilweise herrscht auch ein falsches Verständnis: Auf ner Firmenkontaktmesse hab ich auch mal gehört, “agil” sei ja gar nicht neu; früher nannte man das nur iterativ. Aber so ist es natürlich nicht. Die Aussage ist in etwa genauso richtig, wie zu behaupten, dass früher (“prozedural”) Klassen einfach structs oder records geheißen haben. Technisch mag das bis zu einem gewissen Grad stimmen (aber auch nur zum Teil). Jedoch hat sich die Denkweise geändert. Und die Denkweise ist es, die den großen Unterschied macht — sowohl bei der Objektorientierung alsauch bei der agilen Softwareentwicklung.

Nichtsdestotrotz gibt es auch Firmen, die Agilität richtig verstehen und richtig anwenden. Durch die ein oder andere Exkursion hab ich da auch schon welche kennen lernen dürfen. Effektiv ist in den meisten Firmen, die ich bisher kennen gelernt habe, Agilität zumindest ein Thema. Ich denke, man kann also behaupten Agile Softwareentwicklung ist mittlerweile im Mainstream angekommen. Nur heißt das eben noch nicht, dass alle, die sich “agil” nennen, das auch sind.

Agile: Definition of Done und Failure Mode Programming

Einer der Begriffe, die bei Agilen Softwareentwicklungsprozessen immer wieder zu hören sind, ist “Definition of Done” (DoD). Man soll also vorher definieren, was man unter “fertig” versteht. Das hört sich erstmal trivial an. Und der triviale Grund, dass man ansonsten aneinander vorbei redet, leuchtet auch jedem ein.

“Ist Feature X jetzt endlich fertig?”
“Ja, hab ich gestern eingecheckt.”
“Dann können wir morgen also deployen.”
“Neinnein, da muss noch die QA drüber. Da ist noch nix getestet.”

“Ist Feature Y jetzt endlich fertig?”
“Fast. Zu 90% ist es fertig. Ich muss nur noch…”

Wenn man einmal definiert, was “fertig” bedeutet, kommt es zu weniger Missverständnissen. Mal ganz davon abgesehen, dass man so auch leichter dieses “fast fertig” ausmerzen kann. Entweder ist ein Feature “done” oder eben nicht. Zu 90% fertig bedeutet ja meist, dass noch (weitere) 90% vor einem liegen. Das ist die so genannte 90-90 rule. Und diese ist nur zu oft wahr. Auch, wenn mans vielleicht nicht wahr haben will (mich teilweise auch noch eingeschlossen; ich arbeite daran).

Das ist alles klar und allgemein bekannt. Aber es gibt noch einen anderen Grund für eine DoD: weiter lesen »

Agile: Frequency Reduces Pain

Quasi alle mir bekannten agilen Methoden basieren auf einem weiteren grundlegenden Gedanken, der allerdings nur selten genannt wird, wenn Agile Softwareentwicklung erklärt wird: Frequency Reduces Pain oder anders ausgedrückt: “if it hurts, do it more often”. Integration, Tests, Schätzungen, Refactoring, alles das kann sehr unangenehm werden. Deshalb wird das alles in agilen Prozessen viel öfter gemacht — in kleineren, überschaubareren Schritten.

Integration kann man nicht vermeiden. Irgendwann muss man eben mal alles zusammenwerfen und gucken, ob es funktioniert. Je größer die Software und je später die Integration, desto schwieriger wird das Ganze. Deshalb macht man es viel öfter. Nämlich mindestens einmal täglich. Und auf einmal wird alles viel einfacher.

Schön zusammengefasst ist das außerdem in Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Integration ist nur ein Beispiel. Das genannte Prinzip steckt in ganz vielen agilen Praktiken und ist außerdem der Grund dafür, dass agile Prozesse hochgradig iterativ sind: Wenn es schwer ist, Software fertig zu kriegen, dann kriegen wir sie eben alle zwei Wochen fertig. Wenn Schätzen schwer ist, dann schätzen wir eben alle zwei Wochen neu, aber dafür kleinere Arbeitspakete. Wenn Testen nervig ist, machen wir es zum Prinzip und schreiben Tests vor dem eigentlichen Code, sodass unser Code unweigerlich testbar wird. Wenn Refactoring fehleranfällig ist, machen wirs doch besser andauernd — immer mal wieder ein bisschen.

Softwareentwicklung ist wie Markklößchensuppe essen: Nicht alle auf einmal, sondern einer nach dem anderen.

Agile: Was ist das eigentlich?

In der letzten Zeit hab ich mich eingehend mit agiler Software-Entwicklung beschäftigt. Das hatte ich schon eine ganze Zeit lang vor, aber praktischerweise hatte ich von der Uni aus die Aufgabe mit ein paar Kommilitonen mir Scrum anzusehen und darüber zu referieren. Außerdem habe ich gerade an der Summerschool “Agile Software-Entwicklung” teilgenommen. Das hab ich dann mal zum Anlass genommen, mich etwas intensiver mit der Thematik zu beschäftigen.

Bei Agiler Softwareentwicklung gehen die Meinungen typischerweise stark auseinander. Je nachdem wem man zuhört, ist man geneigt entweder den einen oder den anderen recht zu geben. Beide Argumentationsweisen, beide Softwareentwicklungsphilosophien hören sich, für sich alleine betrachtet, vollkommen vernünftig an. Das hilft natürlich nicht sonderlich weiter, wenn man sich eine eigene Meinung bilden will und so schreibe ich das hier hauptsächlich, um mir selbst hier einigermaßen Klarheit zu verschaffen.

Ursprünglich hatte ich einen vergleichsweise langen Artikel geplant. Ich denke aber, dass mehrere kleinere Artikel eher gelesen werden als ein großer. Außerdem dauert ein großer Artikel immer so lange zu schreiben. Nachdem ich jetzt schon über zwei Monate immer mal wieder an dem Text sitze und immer noch erst etwa ein Drittel steht, habe ich mich nun entschlossen, eine Artikelserie daraus zu machen.

Die Artikelserie spiegelt meine momentanen Gedanken zu dem Thema wider. Ich kann nicht sagen, ob ich bei dieser Meinung, die ich hier mal herausarbeite, bleiben werde. Ich bin einfach selbst mal gespannt, wie ich zur Thematik stehen werde, wenn ich mit der Zeit mehr Einsicht gewinne. Nun gut. Ich hab jedenfalls einiges gelesen und mir meine Gedanken dazu gemacht. Los geht es mit einem geschichtlichen Überblick über die Thematik.
weiter lesen »

Summerschool “Agile Software Development”

Der FIT hat in diesem Jahr neben den schon mehrmals angebotenen — und im übrigen ebenfalls empfehlenswerten — Firmenexkursionen auch eine Veranstaltung zum Thema Agile Softwareentwicklung angeboten: Summerschool “Agile Software Development”.

Als ich die Ankündigung gelesen hatte, wusste ich sofort, dass ich da mitmachen wollte. Mit agiler Softwareentwicklung wollte ich mich sowieso mal beschäftigen. Außerdem sollte das Ganze auch sehr praxisnah sein. (Wenn man auf ner Uni studiert, sind wirklich praxisnahe Lehrveranstaltungen eher selten.) Und zum Dritten bot sich so mal wieder die Gelegenheit, mit ein paar Firmen in Kontakt zu kommen. weiter lesen »