Guten Morgen und herzlich willkommen zur letzten Vorlesung im
Sommersemester 2018 in der Softwaretechnik 1.
Ja, wunderbar.
Jetzt hören wir auch alle zu oder fast alle.
Wir werden uns heute mit Prozessmodellen beschäftigen.
Das heißt also, nachdem wir am Montag schon in unserem schönen
Wasserfallmodell einen Schritt zurückgegangen sind und uns mal
angeschaut haben, wie macht man denn eigentlich Schätzung, gehen wir
heute noch einen Schritt weiter zurück und überlegen uns mal, ist denn
dieses Wasserfallmodell eigentlich das richtige Prozessmodell, um
Software zu entwickeln.
Das ist ja das, was wir beispielhaft in der Vorlesung besprechen.
Aber es gibt natürlich viele, viele andere und wir werden die heute
zumindest mal anreißen, Ihnen kurz vorstellen, paar Vor- und Nachteile
diskutieren, aber sicherlich nicht erschöpfend durchsprechen können.
Dafür gibt es andere Vorlesungen oder Sie müssen das im Selbststudium
dann erledigen, wenn Sie sich dafür weiter interessieren.
Interessant wird es für Sie auf jeden Fall werden, denn mit
Prozessmodellen werden Sie sich krummschlagen müssen.
Im besten Fall dürfen Sie vielleicht mal später selber entscheiden,
nach welchem Prozessmodell Software entwickelt wird oder aber Sie
kriegen, und das ist der wahrscheinlichere Fall, eins übergestülpt und
dann müssen Sie auch ein bisschen damit klarkommen, welche Vor- und
Nachteile das jeweilige Prozessmodell so hat.
So, schauen wir mal kurz auf die Agenda, was schauen wir uns heute an.
Wir fangen an mit den klassischen Prozessmodellen, Programmieren durch
Probieren, Wasserfallmodell, V-Modell und so weiter.
Das sind so die Klassiker, die älteren.
Und dann kommen die ganz hippen, modernen, agilen Methoden.
Extreme Programming und Scrum haben wir da ausgewählt, das mal zu
präsentieren.
Scrum ist ja eh gerade ganz groß, deshalb wollen wir das natürlich
hier auch in der Vorlesung besprechen.
Ich übernehme die langweiligen, klassischen Modelle und die
spannenden, hippen Sachen darf dann so wie er es machen.
Nichtsdestotrotz, schon mal vorneweg, verdammen Sie die klassischen
Modelle nicht.
Die haben auch ihre Daseinsberechtigung, auch wenn im Moment so
ziemlich alles mit Scrum gemacht wird.
Überlegen Sie sich mal, was bei wirklich großen Softwareentwicklungen
passiert, ob dann wirklich agile Entwicklungen alleine funktionieren
können.
Das können wir vielleicht nachher bei Scrum auch nochmal kurz
diskutieren.
Oder überlegen Sie sich mal, ob nicht vielleicht so Dokumente wie beim
Wasserfallmodell rauskommen, auch sinnvoll sein können.
Wenn man strenge Vertragsregeln hat zum Beispiel, dann ist vielleicht
so agil sein auch gar nicht so gut.
Okay, ich würde sagen, wir fangen mal an mit meinem absoluten
Lieblingsprozessmodell zur Entwicklung von Software.
Und dem Lieblingsmodell von Erstsemestern und Hackern.
Das Programmieren durch Probieren, auch Code & Fix oder Trial & Error
genannt.
Das ist wahrscheinlich auch das, was sie hauptsächlich gemacht haben
für die Übungsblätter und ist auch völlig okay.
Aber das ist natürlich nicht das, wie man eine Software entwickeln
sollte, soviel schon mal vorneweg.
Und warum?
Naja, was wir machen bei Code & Fix ist einfach mal drauf
losprogrammieren.
Wir erstellen einfach mal eine Lösung für das Problem, ganz ad hoc.
Und naja, es gibt im Grunde keine Anforderungen, keinen Entwurf,
keinen Testen, keine Wartung.
Das wird alles so auf den Weg gemacht, wenn überhaupt.
Wenn man zwischendrin merkt, naja, das funktioniert irgendwie nicht,
dann kommt man halt in diesen Test & Fix Moment rein, wo man dann halt
versucht, seinen Code noch irgendwie zu retten.
Was da meistens rauskommt, ist der häufig genannte Spaghetti-Code.
Das heißt, man hat halt was runterprogrammiert, merkt, es funktioniert
nicht, dann muss man halt da nochmal einen Switch-Case reinbauen für
den Sonderfall.
Am Ende sieht es dann halt meistens ein bisschen gruselig aus.
Das ist das, was da passiert.
Was sind die Eigenschaften?
Naja, offensichtlich ist das schnell, deshalb macht man das häufig.
Man hat diesen furchtbaren, nutzlosen Zusatzaufwand nicht.
Wie zum Beispiel bei unserem Wasserfall-Modell, erst irgendwelche
Sachen definieren, entwerfen, bis eh alles nutzlos ist.
Lass uns doch einfach sofort drauf losprogrammieren.
Dementsprechend sieht es dann halt auch aus.
Und das ist eigentlich genau das Hauptproblem, was dort auch schon
steht.
Wir haben eben diesen schlecht strukturierten Code.
Und insbesondere diese unsystematischen Verbesserungen daran sind
problematisch.
Weitere Probleme sind, dass man die Anforderungsanalyse am Anfang
völlig außen vor lässt.
Das heißt, man hat so eine ungefähre Idee von dem, was man da
implementieren möchte und macht das halt.
Aber man macht sich halt keine Gedanken darüber, was denn eigentlich
die genauen Anforderungen sind.
Und dementsprechend erfüllt man dann halt viele davon auch gar nicht.
Das habe ich schon gesagt, Wartung und Pflege sind extrem kostspielig.
Wer schon mal versucht hat, seinen eigenen Spaghetti-Code
weiterzuentwickeln, wird das gemerkt haben.
Das ist nicht besonders schön.
Deshalb versuchen wir Ihnen ja so viel über Entwurfsmuster und so
weiter zu erzählen, damit Sie sowas benutzen.
Weil sowas lässt sich gut erweitern, warten.
Wenn Sie eine Strategie benutzen, können Sie einfach neue Strategien
hinzufügen.
Das funktioniert halt bei Code-and-Fix-erzeugten Code halt eher nicht.
Es gibt außerdem keine Dokumentationen normalerweise.
Wenn man schon dieses schnelle-Prozess-Modell wählt, dann fängt man
nicht noch an zu dokumentieren, was man denn da gerade getan hat, weil
man programmiert ja einfach drauf los.
Und das ist auch was ganz Schlimmes.
Teamarbeit geht natürlich zu gut und gar nicht, weil wir haben einfach
keine definierten Grenzen normalerweise, sondern wir haben ja einfach
unseren Code runtergeschrieben, wie soll da irgendjemand anders mit
dran arbeiten können.
Also spätestens wenn Sie im Team arbeiten, müssen Sie sich ein
bisschen Gedanken darüber machen, wie Sie denn Code entwickeln und das
wird sich ja wahrscheinlich schon im nächsten Semester betreffen.
Gut, soviel zu Code-and-Fix.
Jemand Fragen?
Alles klar, das war auch nur so die Aufwärmrunde.
Jetzt kommt das, was wir schon das ganze Semester über gesehen haben.
Das Wasserfall-Modell ist der ganz große Klassiker von 1956.
Ist auch als Phasen-Modell bekannt.
Wir haben ein Dokument getrieben, wie schon gesagt, das ist das Gute
am Wasserfall-Modell.
Wir haben am Ende jeder Phase auf jeden Fall ein Dokument, auf das wir
uns stützen können für die nächste Phase und natürlich auch hinterher.
Wir sehen immer, was ist denn aus der jeweiligen Phase jetzt
herausgekommen.
Zu diesem Wasserfall-Modell gibt es noch eine Erweiterung.
Man kann das nämlich einfach auch wieder zurücklaufen, wie ein Lachs
den Wasserfall hochspringt.
Das geht.
Das hat sich jemand 1970 ausgedacht, der Herr Royce.
14 Jahre hat es gedauert, auf die Idee zu kommen, dass man die
einzelnen Phasen auch noch validieren könnte.
Wichtig an der Stelle ist, es ist nur vorgesehen, dass man zu einer
Phase direkt zurückkommt.
Also wenn Sie zum Beispiel in der Implementierung feststellen, da
funktioniert was nicht, dann machen Sie den Schritt zurück zum
Entwurf.
Dann versuchen Sie neu zu entwerfen und wenn Sie feststellen, Entwurf
funktioniert wieder nicht, dann gehen Sie zurück zur Definition.
So ist das gedacht, was auch ein Problem ist, das wir gleich nochmal
besprechen werden.
Wie ist das Vorgehen beim Wasserfall-Modell?
Wir sagen, jede Aktivität wird in einer angegebenen Reihenfolge
vollständig durchgeführt.
Das klingt sehr starr und das ist es auch.
Das ist ja auch so der Hauptkritikpunkt am Wasserfall-Modell.
Wir haben eben diese klare Richtlinie, dass diese Schritte, die wir
jetzt auch im Semester kennengelernt haben, nacheinander ausgeführt
werden.
Das ist streng sequenziell und schränkt einen dann doch sehr stark
ein.
Und ein Vorteil, habe ich schon gesagt, ist eben dieses fertige
Dokument am Ende jeder Aktivität.
Das ist tatsächlich schön, weil man sich darauf stützen kann.
Das Ganze ist einfach und verständlich.
Also wenn man irgendwie, wie ich letzte Woche ja auch erzählt habe,
mit Leuten zusammenarbeitet, die vielleicht aus einem fremden Umfeld
kommen, weil sie Biologie studiert haben oder Physik, dann ist es ganz
gut, vielleicht ein einfaches Prozessmodell zu verwenden, was auch
klar strukturiert ist.
Also klare Strukturen können ja auch Vorteile mit sich bringen.
Die Leute wissen ganz klar, was wann zu tun ist.
Was ein großes Problem ist, und da setzt ja zum Beispiel auch Scrum
an, diese Benutzerbeteiligung.
Also das, was der Kunde am Ende haben will, das ist nur in der
Definitionsphase vorgesehen.
Und das erzeugt dann auch einige Probleme.
Gerade eben habe ich schon gesagt, es gibt keine phasenübergreifende
Rückkopplung, was die Fehlersuche und Korrektur ein bisschen
problematisch macht.
Vielleicht gehe ich dafür nochmal kurz zurück.
Wenn Sie also feststellen, beim Testen haben Sie einen Fehler gemacht,
dann müssen Sie halt über die Implementierung den Entwurf und die
Definition zurückspringen, um da einen möglichen Fehler zu finden.
Das ist ziemlich aufwendig, weil Sie müssen jeweils den Fehler finden.
Sie können also nicht direkt vom Testen zurück zur Definition, so ist
es zumindest nicht vorgesehen.
Und das macht es natürlich ein bisschen aufwendig, da nochmal komplett
durchhüpfen zu müssen.
Ein weiteres Problem, natürlich, Parallelisierungspotential.
Das nicht besonders gut ausgeschöpft wird, eben dadurch, dass das
Modell so starr ist.
Und das macht das Modell ziemlich langsam.
Also Software, die mit dem Wasserfallmodell entwickelt wird, hat
normalerweise ziemlich lange Zyklen.
Die Markteinführung verzögert sich und Zeit ist Geld, das ist
natürlich nicht das, was man heutzutage haben möchte.
Das man ewig braucht, bis die neue Software auf dem Markt ist.
Und jetzt kommen wir genau zu dem Punkt der Benutzerinteraktion oder
der Kundeninteraktion.
Wir werden beim Wasserfallmodell dadurch, dass wir die
Definitionsphase da alleine stehen haben und danach der Entwurf kommt,
gezwungen an der Stelle tatsächlich zu verstehen, was der Kunde haben
möchte.
An dieser einen Stelle im ganzen Modell.
Und das führt dazu, dass wenn Missverständnisse auftreten, bei den
Anforderungen, die die mit durchziehen, normalerweise bis zum Ende der
Softwareentwicklung.
Das heißt, man muss in der Definitionsphase auch schlecht verstandene
Anforderungen genau durchdefinieren.
Baut da gegebenenfalls Fehler ein, baut vielleicht auch einfach zu
viele Anforderungen, was dabei herauskommt, dass sehr viel Nutzloses
oder Falsches tatsächlich entwickelt wird.
Gut, und was sagt uns das?
Naja, das Wasserfallmodell ist für uns hier in der Vorlesung eher ein
pädagogisches Modell.
Früher kamen immer viele Anmerkungen in der Evaluation von wegen,
warum lehrt ihr denn eigentlich noch das Wasserfallmodell, das ist ja
überhaupt nicht mehr relevant heutzutage.
Das stimmt so nicht, also das Wasserfallmodell wird auch noch benutzt,
das ist das eine.
Das andere ist, ja, das ist nicht mehr das modernste, aber es hat
viele Vorteile, gerade wenn man hier Dinge beibringen möchte.
Man sieht gut die einzelnen Aktivitäten, die man hat, wenn man
Software entwickelt und das kann man dann auch wunderbar übertragen
auf die anderen Prozessmodelle.
Wir haben die schöne sequenzielle Reihenfolge und, naja, das haben wir
halt auch in der Vorlesung.
Wir möchten schrittweise klar machen, was alles zum
Softwareentwicklungsprozess dazugehört und deshalb erklären wir alles
anhand des Wasserfallmodells.
Soll aber nicht heißen, dass wir Verfechter des Wasserfallmodells
sind.
Gut.
Und letzter Punkt, ganz wichtig, Softwareentwicklung ist mehr als
Codieren, tatsächlich ist das nur ein kleines Stück.
Da gehört sehr viel mehr dazu und viele Prozessmodelle, naja,
versuchen das ein bisschen auszublenden oder sagen, ja, die anderen
Sachen müssen auch noch gemacht werden.
Und deshalb ist es ganz gut, einmal anhand des Wasserfallmodells
verstanden zu haben, was denn überhaupt alles dazu gehört.
Und es ist immer noch besser als vorne und fix benutzen.
Dementsprechend verdammen Sie nicht das Wasserfallmodell, das ist auf
jeden Fall von der didaktischen Seite her hilfreich, daran kann man
sehr gut verstehen, was denn überhaupt alles zu tun ist auf der
Entwicklung.
So, dann gehen wir mal weiter zu einem anderen klassischen Modell.
Es gibt eine Frage?
Ich habe eine Frage.
Du hast eine Frage, Tobias hat eine Frage.
Was mache ich denn jetzt im Wasserfallmodell, wenn ich mittendrin vom
Kunden eine neue Anforderung kriege?
Dann, also die Frage von Tobias ist, ich weiß nicht, hast du gerade
mich beangabt?
Hm?
Hast du mich beangabt?
Ja, ne?
Ja, mein Mikro ist da.
Also, dann wiederhole ich die Frage nicht.
Also, die Frage kann ich leicht beantworten.
Sie gehen nochmal zum Kunden und sagen, wir machen da jetzt ein neues
Projekt draus und das kostet nochmal das gleiche.
Also, normalerweise zwischendrin Anforderungen dazunehmen, ist im
Wasserfallmodell nicht vorgesehen.
Man könnte natürlich sagen, man geht nochmal komplett zurück, wenn man
mittendrin ist und nimmt noch die Anforderung auf.
Wenn wir die rückgekoppelte Version des Wasserfallmodells zugrunde
legen, würde das vielleicht gehen, aber eigentlich ist es nicht
vorgesehen.
Eigentlich würde man dann sagen, okay, beim nächsten Projekt, gerne
wieder.
Ja, ein Punkt beim Wasserfallmodell ist ja, dass das, was man in der
Definitions - und Planungsphase festlegt, ja vom Kunden abgenommen
ist.
Das heißt, es ist wie ein Vertrag, den man ansetzen kann.
Genau, das ist ja auch das, was ich vorhin meinte.
Man hat ja das Dokument, dann kann man dann immer wieder sagen, so
lieber Kunde, wir haben hier in der Definition festgelegt, wir machen
genau das, das und das und dafür werden wir bezahlt und jetzt hast du
eine neue Anforderung.
Das ist schön für dich, aber melde dich doch, wenn das Projekt fertig
ist, dann formen wir einfach das nächste.
Genau, so ist das eigentlich gedacht.
Dementsprechend klar strukturiert, man kann es gut verkaufen, man hat
immer die Dokumente, aber es ist halt nicht besonders flexibel.
Genau, das nächste Modell, was wir uns anschauen wollen, wenn es nicht
sonst noch Fragen gibt, ist das V-Modell, auch bekannt als das
handelsübliche.
Das ist tatsächlich ein Prozessmodell, was aus Deutschland kommt,
deshalb auch V-Modell, wie Vorgehensmodell.
Und dort definiert man Aktivitäten und zugehörige Prüfschritte.
Und wenn man sich mal überlegt, was da rauskommt, dann ist das eben
genau auch ein schönes V.
Also nicht nur V gehen, sondern es sieht auch aus wie ein V, weil man
bereits bei der Anforderungsdefinition sich überlegt, was sind denn
mögliche Anwendungsszenarien später und daraus baut man dann gleich
Abnahmetests.
Das heißt, das macht man einfach direkt am Anfang gleich mit.
Das gleiche gilt für den Grobentwurf, auch da kann man Testfälle
bauen, Feinentwurf, Modulimplementierung ist ganz klar, da kann man
dann eben die bekannten Modultests oder Unitests bauen.
Das ist das V-Modell.
Davon gibt es Weiterentwicklungen, ich glaube die letzte von 2017
sogar.
Das ist auch tatsächlich das, was in Deutschland als
Entwicklungsstandard für IT-Systeme der öffentlichen Hand eingesetzt
wird, aber auch von sehr, sehr vielen privaten Firmen und auch
außerhalb der IT.
Und weil man gemerkt hat, dass das halt überall eingesetzt wird in
unterschiedlichen Umgebungen, hat man mehrfach dieses Modell
angepasst, bisschen aufgeweicht und diese erste Aufweichung ist dieses
V -Modell XT.
Wer kann sich vorstellen, wofür XT steht?
Keiner eine Idee?
Ist auch ein bisschen an den Hahn herbeigezogen.
Wie war es?
Extreme Tailoring.
Sind wir wieder bei dem Punkt, wenn Deutsche englische Begriffe
erfinden, die auch ganz klar, man nimmt das V-Modell mit dem deutschen
Namen und hängt dann Extreme Tailoring hinten dran.
Ich hätte es genauso gemacht.
Und das hat man deshalb gemacht, weil man gesagt hat, wir möchten das
V -Modell so gestalten, dass es sich möglichst gut an ein Software
-Projekt anpassen kann.
Und deshalb sagt man dann, wir definieren nur noch Aktivitäten und
Produkte und Verantwortlichkeiten, geben aber keine Reihenfolge vor.
Das heißt, es wird festgelegt, was muss getan werden, um die Software
zu entwickeln.
Das ist die Aktivität.
Was kommt jeweils dabei heraus und wer tut das?
Und damit ist man sehr flexibel.
Man kann, wenn man dieses V-Modell definiert hat für seine Software,
dann noch ein anderes Prozessmodell quasi drumherum packen und man
kann dann zum Beispiel mit V-Modell im Wasserfallmodell entwickeln.
Also man hat die Aktivitäten festgelegt und die entsprechen dann
gerade den Aktivitäten im Wasserfall und dann haupt man die halt
hintereinander.
Man kann aber genauso gut auch das V-Modell benutzen, um dann Scrum zu
entwickeln.
Also auch das gibt es.
Macht sich da nicht ganz so gut, aber ist möglich.
Also habe ich auch schon gesehen.
Ist denn dann jetzt das V-Modell wirklich ein Prozessmodell?
Das ist tatsächlich eine gute Frage, ob das V-Modell tatsächlich ein
Prozessmodell ist.
Naja, es sagt ja, es ist ein Vorgehensmodell.
Ich würde da in der aktuellen Variante fast ein bisschen
widersprechen, weil wir nur sagen, was getan wird.
Wir sagen ja nicht, in welche Reihenfolge und wie, sondern wir legen
einfach nur Aktivitäten fest und sagen dann, ja okay, kümmer sich mal
bitte jemand drum.
Aber wir sagen nicht, in welche Reihenfolge.
Das macht es flexibel, aber das macht es natürlich auch weniger strikt
und man hat weniger, woran man sich entlanghangeln kann.
Aber man kann es natürlich wunderbar für den jeweiligen
Softwareprozess oder für die Unternehmenskultur, in der man sich nun
mal gerade bewegt, anpassen.
So, hier nochmal ein bisschen runter definiert, was ist eigentlich
eine Aktivität?
Eine Aktivität ist ganz allgemein erstmal eine Tätigkeit, die in Bezug
auf das Ergebnis und ihre Durchführung genau beschrieben werden kann.
Also, wenn wir mal zurückgehen, im ersten V-Modell ist zum Beispiel
Anforderungsdefinition, Probenentwurf, Feinentwurf, das sind solche
Aktivitäten.
Wir können sagen, was da rauskommt.
Was ist so ein Ergebnis?
Das ist eben genau das Produkt, was da oben drin steht, das mit
definiert werden muss.
Das ist eben das, was aus der jeweiligen Aktivität rauskommt.
Und hier sehen wir schon wieder, okay, wenn das so ist, dann können
wir natürlich das Wasserfallmodell in ein V-Modell reinpacken und
sagen einfach, alle Aktivitäten aus dem Wasserfallmodell sind eben
unsere V-Modell-Aktivitäten.
Gut.
Großer Vorteil ist, wir können eben dadurch, dass wir diese
Verantwortlichkeiten festlegen, das Projekt aus vielen möglichen
Perspektiven betrachten.
Das kann ein großer Vorteil sein, weil man dann eben besseren Einblick
darauf hat, wie denn das Projekt oder wie das Softwareprodukt
hinterher genutzt werden soll.
Man sieht eher Probleme sowohl in den Anforderungen als auch im Code
später selbst.
Das hat immer viele Vorteile, wenn man einfach aus unterschiedlichen
Blickwinkeln auf etwas drauf schaut, klar.
Das hatte ich schon gesagt, das ist eine Weiterentwicklung des
ursprünglichen V-Modell 97.
Was haben wir noch?
Die Produktzustände.
Genau, jedes von diesen Produkten, die wir gerade angerissen haben,
geht durch vier Zustände.
Das haben Sie vielleicht schon mal gesehen, wenn Sie zum Beispiel
Issue -Checker benutzen, da sieht das so ähnlich aus, da hat man auch
normalerweise diese Zustände, dass etwas in Bearbeitung ist, dann ist
es gelöst, wird vorgelegt zur Begutachtung.
Und wenn das in Ordnung ist, dann gilt das Produkt als fertiggestellt.
Man kann das auch überspringen, wenn keine Prüfung notwendig ist, wenn
derjenige, der das hier vorne bearbeitet hat, auch einfach sagen kann,
okay, das ist jetzt fertig.
Und von dem Fertigzustand kommt man natürlich auch immer wieder zurück
in den Bearbeitungszustand, wenn dann jemand feststellt, naja, das
Produkt, was du mir da gerade vorgelegt hast, das war eigentlich noch
gar nicht fertig.
Das gleiche gilt natürlich für den vorgelegten Zustand, das ist,
glaube ich, auch klar.
Wenn man etwas vorgelegt hat, dann kann man das natürlich auch wieder
zurückweisen.
Gut, das war's schon zum V-Modell.
Gibt es Fragen bisher?
Bitte?
Der Kommilitone fragt, ob ich nochmal auf die Unterschiede zwischen
Wasserfallmodell und V-Modell eingehen kann.
Und die Antwort ist eigentlich nein, weil das ist eine mögliche
Ausprägung des V-Modells, das Wasserfallmodell.
Also wir können sagen, wir benutzen das V-Modell und sagen, wir
brauchen die Aktivität Definition, wir brauchen die Aktivität Entwurf,
wir brauchen die Aktivität Implementierung, wir brauchen die Aktivität
Testen und so weiter und so fort.
Und dann sagen wir, für uns, das ist im V-Modell nicht vorgeschrieben,
sagen dann, okay, die sollen jetzt nacheinander sequentiell ausgeführt
werden.
Dann haben wir es geschafft, in das V-Modell das Wasserfallmodell
reinzustecken.
Das ist der eine Punkt.
Der andere Punkt ist, im V-Modell ist strikt vorgesehen, dass man für
jede Aktivität, zumindest im ursprünglichen V-Modell, direkt Tests
entwickelt.
Das hat man ja im Wasserfallmodell so nicht unbedingt.
Da hat man ja die Testphase am Ende für sich gesehen.
Dann nimmt man Informationen natürlich aus Definitionsphase,
Entwurfsphase, Implementierung, aber man macht sich eigentlich da noch
keine Gedanken darum, wie die Tests aussehen sollen.
Das ist so der wesentliche Unterschied.
Wie gesagt, die können das Wasserfallmodell in das V-Modell
reinstecken.
Insofern kann ich nicht wirklich sagen, was die weiteren Unterschiede
sind.
Möchtest du noch was ergänzen?
Nee, passt.
Wunderbar.
Dann mache ich weiter.
Oder gibt es noch Fragen zum V-Modell?
Gut.
Keine weiteren Fragen.
Dann mache ich weiter mit einem weiteren sehr beliebten und häufig
falsch verwendeten Modell.
Das Prototypmodell.
Das Prototypmodell ist insofern ganz schön, als dass man sehr schnell
zeigen kann, was man denn jetzt eigentlich gerade lösen möchte.
Man kann mal eine, hier ist es so schön, explorative Entwicklung
genannt, durchführen.
Man kann einfach mal dem Kunden zeigen, was man sich so vorstellt, was
mal passieren soll mit dem Produkt.
Man kann mal schnell was zusammenbauen.
Das wird auch tatsächlich häufig gemacht.
Und das ist natürlich insofern gut, als dass man dem Kunden zeigen
kann, naja, wir können das lösen, was du von uns haben möchtest.
Auch wenn das jetzt noch keine fertige und perfekte Lösung ist, aber
wir können das prinzipiell.
Gleichzeitig steigert das natürlich auch so ein bisschen die
Arbeitsmoral im Team, wenn man merkt, okay, wir können dieses Problem
lösen.
Dafür ist das Prototypmodell super.
Aber ganz wichtig, wenn man einen Prototyp entwickelt hat, muss man
den hinterher wegwerfen.
Und das ist genau der Punkt, wo es häufig falsch gemacht wird.
Viele versuchen am Prototyp weiterzuschrauben.
Ich habe da jetzt gerade mal mit Code & Fix was zusammengebaut.
Das ist jetzt ein schöner Prototyp.
Ich habe dem Kunden gezeigt, dass das funktioniert.
Und dann neigt man ja schnell dazu zu sagen, ich habe da jetzt so viel
Arbeit reingesteckt.
Das ist so schön.
Das funktioniert ja jetzt erstmal.
Warum soll ich das denn wegwerfen?
Aber wir haben an der Stelle genau das Problem, dass wir es halt
schnell runterprogrammiert haben, schnell mal zusammengebaut haben.
Und das führt normalerweise dazu, dass man den Code nicht besonders
gut weiterentwickeln kann.
Das heißt, wenn Sie Prototypen entwickeln, super.
Benutzen Sie das unbedingt, um zu zeigen, was Ihr Team kann.
Benutzen Sie das, um ein Produkt zu verkaufen.
Und wenn Sie das getan haben, dann werfen Sie es weg und bauen Sie es
richtig.
Weil dann haben Sie normalerweise auch einen Auftrag bekommen und
werden eh dafür bezahlt.
Also können Sie es auch einfach nochmal richtig machen.
Es bringt nicht viel weiter am Prototyp zu beschrauben.
So, wie sieht das als Prozessmodell aus?
Es ist ganz einfach.
Man geht zum Beispiel zum Kunden, analysiert zusammen, was soll denn
das System eigentlich sein, was soll es mal werden.
Dann entwirft man den Prototyp und implementiert ihn und führt ihn
vor.
Und das ist eigentlich der Hauptzweck, weil an der Stelle kann man
dann wunderbar Fragen und Unsicherheiten klären.
Das ist der ganz, ganz große Vorteil.
Häufig, gerade in der Softwareentwicklung, hat man ja das Problem,
dass man Kunden hat, die nicht besonders viel Ahnung von Software
haben.
Und selbst wenn, wissen sie wahrscheinlich nicht, was sie haben
möchten als Produkt.
Das heißt, sie sagen Ihnen irgendwas, Sie versuchen das zu verstehen.
Da passieren normalerweise schon die ersten Ungenauigkeiten.
Und dann entwickeln Sie oder Ihr Team was und dann zeigen Sie es dem
Kunden und dann sagt er an der Stelle normalerweise, ja, aber das ist
ja gar nicht das, was wir haben wollen.
Das sieht ja völlig unbenutzbar aus und das tut auch nicht das, was es
soll.
Und das ist genau der große Vorteil vom Prototypmodell.
Da haben Sie einfach viel früher Rückkopplung.
Hier sieht das so schön sequenziell aus, aber es spricht nichts
dagegen, von der Vorführung nochmal hier vorzugehen und einfach
nochmal einen neuen Prototyp zu entwickeln oder an dem Prototyp
nochmal rumzuschrauben, solange bis es eben dem Kunden passt oder bis
es Ihren Vorstellungen entspricht.
Aber wenn Sie dort sind, dann werfen Sie den Prototyp weg und sagen,
okay, jetzt machen wir Softwareentwicklung und zwar richtig und
benutzen V-Modell oder Wasserfallmodell, was eben bei Ihnen vorgesehen
ist.
Genau.
Gibt es dazu Fragen vom Prototypmodell?
Wunderbar.
Dann machen wir weiter mit dem iterativen Modell und damit, dass ich
gleich erstmal mir selber widersprechen muss, denn wenn man sich ein
bisschen Gedanken macht, wie man den Prototyp entwickelt, dann kann
man ihn vielleicht auch weiter benutzen.
Und diese Annahme trifft das iterative Modell und ist deshalb eine
Erweiterung des Prototypmodells, in dem man sagt, naja, vielleicht
können wir zumindest Teile der Funktionalität unseres Prototypen
weiter benutzen.
Und zwar die Teile, die wir bereits vorher klar definiert haben.
Also wir haben ja vorhin gesagt, wir machen eine Problemanalyse
zusammen mit dem Kunden und wir wissen, das ist nicht immer genau
möglich, aber manche Teile sind vielleicht einfach Standardbauteile
oder manche Teile sind ganz klar definiert.
Dann spricht nichts dagegen, die entsprechend wegzukapseln, zu bauen,
in den Prototyp einzubauen, aber hinterher eben auch weiter zu
benutzen.
Und wenn man das als Prozessmodell zusammenschnürt, dann ist die Idee
eben, dass die Funktionalität Schritt für Schritt erstellt wird und
zum Produkt hinzugefügt wird.
Das ist dann schon so ein bisschen dynamisch, so ein bisschen agil,
wir werden nachher sehen, Scrum geht ja auch diesen Schritt für
Schritt Entwicklung von Produkten.
Wir haben natürlich die gleichen Vorteile und Einsatzgebiete vom
Prototypmodell, aber wir können natürlich uns viel Arbeit sparen, weil
wir Teile weiter benutzen können.
Und das iterative Modell wiederum gibt es in unterschiedlichen
Ausprägungen, die unterschiedlich funktionieren.
Da schauen wir jetzt auch noch ganz kurz drauf.
Es gibt einmal das evolutionäre Modell, da sagt man, man plant und
analysiert nur einen Teil, der als nächstes hinzugefügt wird.
Das ist so ungefähr das, was auch bei Scrum passiert.
Und machen dann für jeden Teil, den wir jetzt gerade bauen wollen,
eben zum Beispiel das Wasserfallmodell oder ein anderes Prozessmodell.
Aber wir sagen immer, wir haben gewisse Bausteine, die wir klar
definieren können und die bauen wir jetzt erst mal.
Das hat natürlich auch Nachteile.
Es kann gut passieren, dass eben dieser nächste Baustein, den wir
bauen, entweder nicht zu dem davor passt oder nicht zu dem nächsten
dazu passt.
Da müssen wir mal schauen, dass das ein großes Ganzes ergibt.
Aber das ist auch ein Problem, was wir vielleicht noch bei Scrum sehen
werden.
Man kann sehr viel stückchenweise definieren, aber am Ende muss es ein
großes und ganzes ergeben.
Das ist auch das, was ich am Anfang meinte mit, verdammen Sie die
klassischen Prozessmodelle nicht, wenn Sie große und zwar richtig
große Softwareprojekte entwickeln müssen, dann sollte man sich
vielleicht schon mal vorher ein bisschen Gedanken machen um die
Struktur.
Dann ist es immer schwierig, wirklich inkrementell zu entwickeln.
Sonst bauen Sie halt Steine übereinander und am Ende haben Sie zwar
vielleicht ein Haus rausbekommen, aber eben nicht das, was Sie
wollten.
Gut, was haben wir noch?
Das inkrementelle Modell.
Da macht man das eben genau anders.
Da sagt man einmal für das komplette Produkt, was man entwickeln will,
wie soll das aussehen, analysiert das einmal komplett durch und geht
dann nur mehrfach über Entwurf, Inkrementierung und Testphase rüber.
Das heißt, man hat am Anfang einen kompletten Plan, wie ich das gerade
gesagt habe, für das ganze Haus, aber man weiß vielleicht noch nicht,
wie man die einzelnen Wände reinsetzt.
Und dann macht man halt für jede Wand einmal hier Entwurf,
Inkrementierung und Testphase.
Das hat natürlich wieder genau den einen Nachteil, dass man sich
vorher komplett Gedanken machen muss um das Produkt, was rauskommen
soll.
Also ich muss vorher wissen, wie mein Haus aussehen soll.
Hat aber eben auch genau den Vorteil, dass ich vorher auch genau weiß,
was am Ende mal rauskommen wird.
Das heißt, es kommt natürlich auch immer so ein bisschen darauf an,
wie sind Ihre Anforderungen, wissen Sie überhaupt schon vorher, was
rauskommen soll, dann will man vielleicht eher inkrementell entwickeln
oder weiß man vielleicht am Anfang noch gar nicht, was rauskommen
soll, dann ist es vielleicht eher das evolutionäre Modell, was ich
angehe.
Und wenn nichts davon zutrifft, gilt immer, seien Sie kreativ, seien
Sie auch mal so frei, das Prozessmodell anzupassen für Ihre
Notwendigkeiten.
Man kann immer Sachen mischen, sagen, das passt nur zu 90% auf unsere
Firmenkultur und jetzt passen wir das halt an.
Das gilt auch für agile Softwareentwicklung, also auch für Scrum.
Auch wenn das immer sehr dogmatisch erscheint, wer sich schon mal mit
Scrum beschäftigt hat, auch da darf man gerne Dinge anpassen.
Gut.
Jetzt nochmal ganz kurz reingeschaut, wie müssen wir uns das
vorstellen beim iterativen Modell.
Ich habe gerade eben gesagt, man geht da nochmal zurück.
Wenn wir feststellen am Ende, wenn wir es gebaut haben, wir sind nicht
zufrieden, dann muss man eben vielleicht nochmal zurück in den
Entwurf.
Wenn man nochmal zurück zur Planung geht, dann hat man eben genau
dieses evolutionäre Modell.
Wenn man nur zurück geht zum Entwurf, dann hat man das inkrementelle
Modell.
Also nochmal zur Unterscheidung.
Wenn Sie stückchenweise bauen, aber schon vorher wissen, was am Ende
rauskommen soll, dann haben Sie das inkrementelle Modell.
Das heißt, Sie gehen dann auch nur zurück zum Entwurf, weil Sie wissen
ja schon hier, was soll rauskommen.
Wenn das anders ist, wenn Sie vorneweg noch gar nicht wissen, was Sie
überhaupt insgesamt bauen wollen, dann planen Sie halt nur den
Teilschritt, gehen das Wasserfallmodell durch, sehen was rausgekommen
ist, gehen wieder zurück zur Planung und planen den nächsten
Teilschritt.
Das ganze geht natürlich auch über die Definitionsphase, also wenn Sie
beim inkrementellen Modell feststellen, naja, das Problem tritt
irgendwie schon vorher auf, dann muss man vielleicht auch nochmal
zurück zur Definition.
Das kann einem natürlich auch immer passieren.
Genau.
Das Sprungziel ist immer so ein bisschen abhängig, da habe ich gerade
eben schon mal drauf hingewiesen, wie viel war denn eigentlich vorher
geplant.
Es kann ja auch sein, dass die, auch beim evolutionären, beim
inkrementellen Modell kann es ja sein, dass die komplette Planung
schon fertig ist.
Nein, beim evolutionären Modell kann es sein, dass die komplette
Planung schon fertig ist, dann muss man nur noch zur Definition
zurückspringen und nicht mehr komplett zur Planung.
Das heißt, es kommt immer so ein bisschen drauf an, wie viel denn
vorneweg schon definiert wurde.
Das ist das eine.
Und das andere natürlich, wie gut funktioniert es.
Also wenn wir feststellen, es gibt noch grundsätzliche Probleme in der
Software, dann muss man vielleicht auch nochmal zur Planung
zurückbringen.
Gut.
Fragen bisher her?
Wunderbar.
Dann kommen wir jetzt zu einem sehr prominenten Prozessmodell.
Nämlich zu Synchronisiere und Stabilisiere.
Auch bekannt als das Microsoft-Modell.
Und zwar deshalb, weil das bei Microsoft seit jeher eingesetzt wurde
und soweit ich weiß auch größtenteils immer noch wird.
Und das V-Modell hat so ein bisschen als Idee zu sagen, naja wir haben
ganz viele fähige Programmierer und diese ganzen Prozessmodelle, das
schränkt die irgendwie ein.
Wenn die sich an Vorgaben halten müssen, dann sind die nicht mehr so
kreativ, nicht mehr so produktiv.
Also lass uns doch einfach kleine Hacker-Teams bilden und die einfach
frei entwickeln lassen.
Wir sagen denen, okay, das ist eure Aufgabe, das sollt ihr entwickeln,
jetzt macht das, egal wie.
Baut das fertig.
Hier in dem Beispiel waren es tatsächlich 200 Programmierer für
Windows 95.
Okay, das Beispiel ist ein bisschen alt.
Aber so in der Größenordnung können sie sich das trotzdem vorstellen.
Und wir bauen dann kleine Hacker-Teams, Größe 5, 20 Leute, völlig
egal, sodass sie halt noch gut miteinander arbeiten können, ohne dass
zu viel Kommunikationsaufwand entsteht.
Und die können dann tun und lassen, was sie wollen und Dinge
entwickeln, wie sie das für richtig halten.
Unter der Annahme, dass sie dann eben am produktivsten sind.
Klar, das ist halt irgendwie das Problem.
Gleichzeitig, dass man dann halt viele kleine Codeschnipsel bekommt,
die wahrscheinlich auch zum Großteil in Code&Fix entstanden sind.
Die vielleicht Probleme mit Schnittstellen haben zu anderen Stücken,
die andere Hacker-Teams zusammengebaut haben.
Und deshalb muss man dann hinterher irgendwie sehen, dass man das
aufgeräumt bekommt.
Das heißt, man muss diese Hacker-Teams dann synchronisieren und das
Gesamtprodukt stabilisieren.
Und deshalb heißt dieses Modell auch so.
Das heißt, was man eigentlich macht, ist, man setzt diese Hacker-Teams
an die Projekte und sagt, jetzt entwickelt das mal.
Und synchronisiert dann aber regelmäßig, zum Beispiel nächtlich, über
einen Build-Server.
Also, alle entwickeln, zum Feierabend wird einmal eingerucht, der
Server baut das Gesamtprojekt und sagt, ne, hier ist was kaputt, das,
was ihr heute gebaut habt, das tut nicht.
Bitte morgen nochmal dransetzen.
Sowas kann man ja wunderbar machen mit Continuous Integration.
Denken Sie an die erste Vorlesung.
Da haben wir das mal kurz angerissen.
Das ist ja alles möglich.
Und wenn man das getan hat, dann hat man schon viele Probleme im
Vorhinein ausgeschlossen.
Alles, was man über Unitests abfangen kann.
Man weiß aber immer noch nicht, ob das Gesamtprojekt zusammenpasst.
Das heißt, man braucht eine Stabilisierungsphase und die hat man
normalerweise immer nach drei Meilensteinen.
So nennt sich das in diesem Modell.
Man baut im Grunde Meilensteine ein, in das Prozessmodell sagt, das
sind jetzt so Stücke, die sollt ihr zusammenbauen und wenn drei davon
fertig sind, dann stabilisieren wir wieder das Gesamtprojekt.
Wir schauen uns das gleich nochmal im Detail an.
Das Modell definiert drei Phasen.
Eine Planungsphase, in der man eben plant, was denn überhaupt zu tun
ist.
Dann Entwicklungsphasen, in denen drei Subprojekte jeweils gebaut
werden.
Das sind drei Meilensteine.
Und wenn drei Meilensteine zusammengekommen sind, dann fangen wir an,
das Projekt zu stabilisieren.
Gut.
So sieht es dann grafisch aus.
Wir haben hier vorneweg Planung.
Da wird im Grunde wie auch im Wasserfallmodell das komplette Projekt
durchgeplant, die Arbeit verteilt an die Hacker-Teams.
Dann gibt es eben mehrere Meilensteine, die eben zu diesem
Entwicklungsteil gehören.
Und dort sieht man dann wiederum, gibt es diese Einzelaktivitäten,
Implementierung, das Testen, die Stabilisierung im Team intern.
Also dass man sagt, wir haben jetzt hier unsere kleine Aufgabe, die
wir lösen sollen.
Das haben wir jetzt erstmal getan und auch getestet.
Jetzt müssen wir schauen, dass das Ganze noch zusammenpasst.
Also das passiert im Team schon das erste Mal.
Dann Integration, immer so ein kleiner Waffer.
Und das macht man im Grunde dreimal hintereinander, damit das so ein
bisschen unterteilt ist, dass man nicht im Grunde sagt, hier liebe
Hacker -Teams, ihr habt jetzt 18 Monate Zeit, schwimmt mal frei drauf
los, sondern man versucht zwischendrin eben diese Milestones zu
setzen, damit man sagen kann, bis dahin ist jetzt erstmal das
Teilstück fertig und wenn ihr das habt, dann bitte das nächste
Teilstück bauen.
So ist die Idee.
Und wenn man dann durch ist, durch die Entwicklung, dann kommt eben
diese Stabilisierung, bei der man im Grunde alles dann zusammenbringt,
sagt, okay, bis hierhin sind wir jetzt gekommen, jetzt müssen wir
fertig sein, das sagt der Projektplan, das heißt bitte jetzt keine
neuen Features mehr entwickeln und jetzt bauen wir das einfach, jetzt
sind wir hier, und dann müssen wir noch testen, müssen noch Bugs
finden, müssen das Ganze zusammenbauen und dann haben wir hoffentlich
am Ende ein stabiles Produkt.
Das heißt also, was da normalerweise passiert, und jetzt nochmal kurz
zurück zum Anfang, wir haben ganz viele Hacker-Teams, die bauen drauf
los, haben ihre Verantwortlichkeiten, am Ende kommt hier irgendwas
zusammen, was hoffentlich das Produkt darstellt, und dann versucht man
das halt so stabil zu bekommen, dass es am Ende funktioniert.
So, dementsprechend hat das Ganze natürlich viele Vor- und Nachteile.
Wir haben kurze Produktzyklen durch dieses Prozessmodell, wir können
relativ schnell damit Softwareentwicklung betreiben, man kann sehr gut
nach Funktionen priorisieren, indem man sagt, im Meilenstein 1 sind
folgende Funktionen definiert, und dann kann man auch schauen, dass
die bis dahin wirklich fertig sind.
Man kann sehr gut Fortschritt generieren ohne vollständige
Spezifikationen, ja klar, das passiert halt in Hacker-Teams, und die
Annahme ist immer noch, viele Entwickler arbeiten in kleinen Teams
deutlich effektiver als in großen Teams, oder wenn ihnen ein
Standardmodell vorgesetzt wird, und Rückmeldungen können frühzeitig
einfließen.
Ja, okay, mag sein, geht in anderen Modellen denke ich mal auch,
gerade in den Agilen wahrscheinlich sogar noch deutlich besser.
So, das hat natürlich auch sehr sehr viele Nachteile, das sind mal so
die größten, die ich da mitgebracht habe.
Je nachdem, welche Software man entwickeln möchte, ist das Vorgehen
völlig fehl am Platz, insbesondere das hier ist ein großes Problem,
die mangelnde Fehler-Toleranz.
Also wenn Sie wirklich was bauen wollen, was beweisbar funktioniert,
dann ist das ganz schlecht mit kleinen Hacker-Teams zu arbeiten, weil
da haben Sie keine Kontrolle drüber, was da wirklich passiert im Code.
Genauso haben Sie natürlich das Problem mit Echtzeitfähigkeit, wenn da
Code -in-Fix passiert, dann wird der Code halt so zusammengeschraubt,
dass er tut, aber normalerweise ist es dann nicht besonders effizient
und schnell, also Echtzeitprobleme werden Sie da auch bekommen.
Und etwas, womit sich ja Microsoft auch immer wieder mal rumschlägt,
Architekturprobleme, die Sie logischerweise bekommen, weil viele
kleine Hacker-Teams für sich Code schreiben, dann kommt da keine große
Architektur bei.
Das ist einfach so.
Das heißt, damit werden Sie auch zu kämpfen haben, wenn Sie das
benutzen.
Effizient ist es natürlich trotzdem.
Nächstes Problem ist, wir haben in den Hacker-Teams natürlich Ad-hoc
-Prozesse, nichts, was irgendwie dokumentgetrieben ist, das heißt,
dort verbreitet sich Wissen normalerweise mündlich und das führt dazu,
dass wir keine Lernprozesse über das Team hinaus haben.
Also wenn Hacker-Team 5 was rausgefunden hat, was total super ist und
was die Software fünfmal schneller macht, dann erfährt das Hacker-Team
4 wahrscheinlich nie, weil die außer in der Kantine nie miteinander
sprechen und dann über andere Dinge.
Das heißt, da gibt es einfach keine Schnittstellen, die das explizit
vorsehen, dass da Wissen weitergetragen wird.
Und man muss sich bewusst sein, dass alle 18 Monate, das ist glaube
ich wieder aus den konkreten Beispielen, 50% des Codes überarbeitet
worden sind, weil es eben furchtbar instabil war.
Das heißt, ihre Hacker arbeiten zwar dann schneller und entwickeln
schneller Software, aber vieles davon muss man auch wieder wegwerfen.
Ob das schlimm ist, da kann man jetzt überstreiten, ist vielleicht gar
nicht schlecht, dass da so viel überarbeitet wird, aber es wird halt
sehr sehr viel Nonsens erstmal erzeugt, den man wieder überarbeiten
muss oder der zumindest instabil war.
Ganz einfach deshalb, weil das eine Team nicht weiß, dass das andere.
Gut.
Das war es sogar dann schon für die klassischen Prozessmodelle,
richtig?
Ja, richtig.
Bei Daten noch ein kleines bisschen zu synchronisieren und
stabilisieren.
Naja, wir wissen ja, Microsoft hat nur Produkte rausgebracht, die nach
dem Stabilisieren vollkommen stabil waren.
Natürlich.
War nie Fehler drin in der Software oder sonstiges.
Weiß nicht, steht hier irgendwann... Ah ja, hier steht Release.
Zero Bug Release.
Ja, Zero Bug Release.
Bin mir nicht sicher, ob das ein bisschen optimistisch war.
Ja, schon an manchen Stellen.
Also ich würde ja das Release eher hier hinziehen.
Und ich meine, testen können ja die Nutzer noch.
Gut.
Genau.
Also, das zu den klassischen Prozessmodellen.
Gibt es noch Fragen dazu?
Keine weiteren Fragen.
Wunderbar.
Dann übergebe ich an dieser Stelle für die hippen Sachen an Tobias,
der sich allerdings weigert.
Deshalb mache ich jetzt erstmal noch weiter.
Also, wir haben jetzt die ganzen klassischen Prozessmodelle gesehen.
Die wirken irgendwie alle recht starr.
Bis auf jetzt das V-Modell und vielleicht das iterative Modell, was
schon so ein bisschen Agilität reinbringt.
In den letzten 10, 15, 20 Jahren hat man festgestellt, dass man
irgendwie was tun muss, um Software schneller zu entwickeln.
Auch zum Beispiel auf neue Anforderungen eingehen können während der
Produktentwicklung.
Und hat sich dann überlegt, naja, Software-Prozessmodelle müssten
vielleicht ein bisschen agiler sein.
Und da ist jetzt einiges passiert.
Und Tobias erklärt Ihnen das jetzt.
Ja, also wir haben ja eben die ganzen relativ starren klassischen
Modelle gesehen.
Wobei ja auch nicht alle so starr sind, wie es immer behauptet wird.
Das iterative Modell zum Beispiel ist ja schon an vielen Stellen recht
nah dran an dem, was die agilen Methoden zumindest fordern.
Aber schauen wir uns das zunächst mal an.
Also diese Gegenbewegung, von der Sebastian gerade sprach, kam dann
irgendwann auf.
Und naja, es war eine Entwicklergruppe quasi, die sehr stark damit
gehadert hat, was diese klassischen Modelle vorgeschrieben haben.
Sie fanden das zu starr, fanden das Entwickeln auch in diesen Modellen
nicht zielführend an der Stelle.
Und haben sich dann ein sogenanntes agiles Manifest überlegt.
Angelehnt an das kommunistische Manifest.
Also wirklich, sie hatten vor, da eine Revolution in der
Softwareentwicklung zu starten.
Und haben mit diesen ersten vier Thesen, oder eigentlich nur mit
diesen vier Thesen angefangen.
Nämlich, dass sie Individuen und Interaktionen wichtiger, also mehr
gewichten wollen, als die Prozesse und die Werkzeuge.
Das heißt, sie wollen eigentlich viel mehr miteinander reden,
miteinander kommunizieren.
Anstatt sich Gedanken darüber zu machen, dass man sich an die Prozesse
hält und dass man feste Werkzeuge oder feste Artefakte vorschreibt an
der Stelle.
Außerdem war eines der Positionen, die sie dann bezogen haben, dass
laufendes Software wichtiger ist als die vollständige Dokumentation.
Sie haben sich also daran gestört, dass zum Beispiel im
Wasserfallmodell man sehr viel Zeit damit zugebracht hat,
Dokumentationen zu schreiben, die vielleicht später niemand mehr
liest, niemand mehr benutzt.
Sondern wollten lieber, dass die Software besser wird, dass diese
Zeit, die sie da rein in Dokumentationen gesteckt wurde,
klassischerweise, dann tatsächlich für bessere Software eingesetzt
wird, anstatt die Dokumentation.
Und der dritte Punkt, da hat Sebastian gerade eben schon so ein
bisschen darauf hingewiesen, der ist sogar meiner Meinung nach einer
der wichtigsten Punkte an der Stelle, die auch die agilen Methoden von
den klassischen unterscheiden, ist, dass sie vor allem die
Kundenmitarbeit deutlich wichtiger sehen als die Vertragsverhandlung.
Das heißt, weniger Interaktion mit dem Kunden nur dafür, um
irgendwelche Verträge abzuschließen oder im Vorhinein in der
Definitionsphase oder sonstigen festzulegen, was man jetzt entwickeln
will, sondern vielmehr den Kunden permanent in den Prozess mit
einbinden.
Ihn immer wieder befragen können, aber auch immer wieder auf seine
Anforderungen und seine Wünsche reagieren zu können.
Das bedeutet aber natürlich auch als Konsequenz, dass der Kunde das
mitmachen möchte, was nicht immer gegeben ist.
Das bedeutet nämlich auch sehr viel Arbeit für den Kunden.
Er muss immer verfügbar sein, er muss jemanden wahrscheinlich sogar
zur Verfügung stellen, der permanent in diesem Entwicklungsprozess mit
eingebunden ist.
Am besten, wir haben nachher noch eine Folie, wo draufsteht, am besten
im selben Raum, wie der Entwickler sitzt.
Denn wenn man agil entwickelt und versucht, immer wieder sich auf die
Kundenwünsche und die Anweisungen anzupassen, beziehungsweise man hat
keine große Planung am Anfang gemacht, dann muss man die Möglichkeit
haben, einen Ansprechpartner zu haben, mit dem man die Dinge
durchsprechen kann, die man jetzt gerade entwickelt.
Und der letzte Punkt ist, dass man sich auf Änderungen einstellt,
anstatt man, dass man dem Plan ganz strikt folgt.
Das ist genau, mit dem, dreht mein Mikro noch?
Ja.
Dass man halt eben nicht sagt, das Wasserfallmodell ist jetzt so
strikt, ich muss mich daran halten, ich kann jetzt nichts anderes
machen, als mich an diesen Plan zu halten, den ich von Anfang an
hatte, sondern jederzeit auf neue Entwicklungen, neue Wünsche, neue
Anforderungen, Änderungen oder auch Gegebenheiten, die sich einfach
geändert haben.
Zum Beispiel, man hat gedacht, man kann das mit Werkzeug X umsetzen,
geht jetzt aber doch nicht.
Dass man jederzeit auf diese Änderungen flexibel reagieren kann,
anstatt sich strikt an den Plan zu halten, nur weil man es am Anfang
einmal so definiert hat.
Darf ich noch kurz dazwischen quetschen?
Ja.
An der Stelle gibt es häufig Missverständnisse.
Viele, die das Agile Manifesto lesen, sagen, ja okay, Individuen sind
wichtig, laufende Software ist wichtig, Kundenmitarbeit ist wichtig,
Änderungen sind wichtig.
Ja, das ist komplett richtig soweit, aber dort steht nur wichtiger
als.
Es gibt überall auch in Scrum Prozesse, es gibt dort auch
Dokumentation, es gibt dort auch Verträge und es gibt dort auch Pläne.
Die Idee ist nur zu sagen, wir stellen andere Sachen noch darüber, das
heißt nicht, dass wir das andere runterfallen lassen.
Das verwechseln leider viele und sagen dann, okay, wir brauchen keine
Dokumentation mehr und wir entwickeln einfach so von uns hin.
Vertrag brauchen wir auch nicht, am Ende schenken wir das Produkt
einfach dem Kunden, der freut sich bestimmt.
Also so geht es natürlich nicht, dementsprechend es gibt das auf alles
in den agilen Modellen, bloß die anderen Sachen werden halt als
wichtiger abgelegt.
Ja, der wichtige Punkt ist, sie versuchen es, die anderen Dinge auf
ein Minimum zu reduzieren, also keine unnötige Dokumentation zu
erzeugen, nicht unnötig sich an Prozessen und Werkzeugen aufzuhalten,
sondern eben nur das, was wirklich essentiell ist für die Entwicklung,
für das jeweilige Projekt.
Genau.
Das ist das agile Manifest.
Das wurde von einer gewissen Gruppe, die findet man, wenn man da auf
die schöne Website geht, vorgestellt.
Einer derjenigen, der das vorgestellt hat, war Kent und dieser hat
auch das... okay, das kommt erst noch auf die Folie.
Okay, das mache ich erst noch.
Das ist der Begründer von Extreme Programming, nur da wollte ich
gerade hinaus.
Das habe ich aber, glaube ich, schon fast alles gesagt.
Also man möchte halt möglichst wenig im Vorhinein schon planen.
Die Planung erfolgt inkrementell, dann haben wir so ein bisschen den
Bezug auf das iterative Modell, was wir eben schon gesehen haben.
Das inkrementelle, iterative Modell.
Und ja, die anderen Sachen habe ich schon genannt.
Wir werden uns gleich zwei Vertreter davon anschauen, nämlich einmal
Extreme Programming und Scrum.
Wobei man jetzt sagen kann, dass diese, wenn wir das gleich sehen, ein
bisschen verwandt sind.
Denn Scrum benutzt viele Dinge, die Extreme Programming schon
definiert hat.
Also Extreme Programming ist ein bisschen älter.
Ist aber heute deutlich verbreiteter.
Ion hat schon mal was von Scrum gehört.
Also Scrum ist so gerade das Thema an Prozessmodellen, was überall
gemacht wird.
Man muss ein bisschen sagen, man muss Scrum auch mit einer gewissen
Intelligenz rangehen an die Vorgaben, die Scrum einem bietet.
Man kann Scrum sehr gut benutzen, man muss es aber anpassen auf die
Gegebenheiten, die man hat.
Und auch nicht zu starr da rangehen.
Was ich aber sagen wollte, ist, dass Extreme Programming eigentlich
eher ein ganzer Werkzeugkasten an Möglichkeiten ist, die man für die
Softwareentwicklung benutzt.
Also nicht nur ein Prozessmodell.
Ein Teil davon definiert ein Prozessmodell, aber es sind noch viel
mehr Dinge, die dort mit rein spielen.
Und gerade dieses Prozessmodell, was Extreme Programming vorgibt, ist
eigentlich der Vorgänger für Scrum oder das Bezugsobjekt, woran Scrum
sich orientiert hat, um das Ganze zu entwickeln.
Also schauen wir uns doch jetzt zum nächsten Mal das Extreme
Programming an.
Übrigens, da hätten wir wieder den Grund warum, also da hätten wir XP.
Warum heißt das XP?
Naja, angelegt an Extreme Sports und dann hätten wir auch den Grund,
warum vielleicht die Deutschen dann auf einmal auf die Idee kamen,
Extreme Tailoring für das V-Modell zu benutzen.
Genau, das sind jetzt so Praktiken, die das Extreme Programming
vorgibt.
Einer der großen Punkte an der Stelle ist die Paarprogrammierung.
Das heißt, jedes Stück Software, was entwickelt wird, wird im Paar
programmiert.
Das heißt, sie sitzen zu zweit, vor allem Rechner, vielleicht mit
einer Tastatur, vielleicht auch mit zwei, vielleicht mit zwei Mäusen.
Das könnte allerdings ein bisschen unübersichtlich werden, zumindest
wenn der Rechner nicht dafür vorgesehen ist.
Die Idee dahinter ist, man versucht die Qualitätssicherung, die sonst
durch Durchsichten, Inspektionen oder sonstiges erzeugt wird,
wegzulassen, dadurch, dass man, wenn man zwei Entwickler davor sitzen
hat, direkt eine Kontrolle des geschriebenen Codes hat und
dementsprechend sich auf den Standpunkt stellt, dass wenn man zu zweit
das programmiert, sowieso schon qualitativ höherwertiger Code
herauskommt, der nachher nicht mehr durch aufwendiges Durchschauen
oder irgendwelche Reviews oder sonstiges verifiziert werden muss an
der Stelle.
Ein weiterer Punkt, der noch zu Extreme Programming gehört, ist die
Testgetriebenentwicklung.
Hat jemand eine Idee, was damit gemeint ist?
Alle noch am Schlafen.
Das sind nicht so viele einfache Fragen, Sven.
Da hinten ist eine Antwort.
Genau.
Also die Kommiliton hat gesagt, man überlegt sich erst die Tests,
bevor man den Code für die bestimmten Module, die man jetzt schreiben
möchte, eigentlich angeht.
Das ist genau die Idee dahinter.
Man versucht sich vorher schon objektiv Gedanken zu machen, was ist
denn die Funktionalität, die ich hier anbieten will und schreibt dafür
Testfälle und schreibt dann den Anwendungscode, was dafür sorgen kann,
dass man nicht vorher schon, also wenn man den Anwendungscode zuerst
geschrieben hätte, hat man ja schon ein Gefühl dafür, was man denn
überhaupt geschrieben hat am Code und vergisst vielleicht Fälle, die
man hätte testen sollen.
Das, was ich eben meinte zum Prozessmodell im Extreme Programming, das
ist diese iterative Planung mit kurzen Zyklen, dem sogenannten
Planungsspiel, was dann auch den Prozess vorgibt, den Scrum dann
adaptiert später.
Und wie ich schon sagte, braucht man für das Ganze natürlich eine
aktive Beteiligung des Kunden, um immer wieder auf die neuen
Anforderungen einzugehen oder auch immer wieder überhaupt neue
Anforderungen einzuholen, denn man macht das Ganze ja iterativ, muss
sich jedes Mal wieder überlegen, was ist denn jetzt eigentlich das,
was ich als nächstes entwickeln möchte, muss das priorisieren zusammen
mit dem Kunden und dieser muss auch überhaupt nennen, was braucht er
denn an der Stelle.
Ein weiterer Punkt ist die fortlaufende Integration, das hat Sebastian
ja eben auch schon angesprochen, das heißt mit dem Build Server, weil
synchronisiere und stabilisiere jede Nacht das Ganze zu testen, wenn
man jetzt testgetriebene Entwicklungen macht, hat natürlich auch viele
Testfälle an der Stelle und möchte diese nutzen, dann immer wieder,
wenn man ein neues Stück Anwendungscode geschrieben hat, diesen auch
direkt wieder zu testen, das Zusammenspiel zu testen und das
fortlaufend immer wieder zu integrieren und somit auch immer wieder
neue Adresse haben, die man ausliefern kann an der Stelle.
Das mit dem gemeinsamen Quelltext-Besitz ist glaube ich etwas, was
mittlerweile nicht mehr so ein großer Faktor ist.
Es ist früher so gewesen, dass viele Leute dann nur ihre Sicht auf den
Quelltext gehabt haben und auch diesen zum Teil erst dann in das
Gesamtprojekt eingepflegt haben, wenn es nötig war an der Stelle und
man möchte in den agilen Methoden eigentlich, dass immer jeglicher
Quelltext an der Stelle für alle zugänglich ist und auch von allen
angepasst werden kann.
Man muss natürlich dann die Kommunikation an der Stelle richtig
durchführen.
Textuelle Beschreibung der Anwendungsfälle auf Karteikarten.
Das sehen wir nachher nochmal bei Scrum ein bisschen besser.
Man macht jetzt keinen Pflichtenheft mehr oder Lastenheft, wie es im
Wasserfall war, sondern man überlegt sich Anwendungsfälle der Software
und beschreibt quasi die Anforderungen, die man an das System hat,
durch sogenannte User Stories, die diese Anwendungsfälle sind und auf
Karteikarten definiert werden.
Das heißt, man schreibt nicht mehr formale Anforderungen, sondern nur
das, was bestimmte Funktionalitäten aus der Anwendungssicht zur
Verfügung stellen müssen.
Man benutzt diese als eigentliche Beschreibung der Anforderungen, die
man benutzt oder die man umsetzen möchte.
Das ist der letzte Punkt hier mit der 40-Stunden-Woche.
Naja, das klingt jetzt für uns Europäer als etwas ganz Normales, ist
aber in den USA oder an anderen Orten nicht ganz so gegeben.
Das heißt, diejenigen, die das Extreme Programming definiert haben,
haben gesagt, man kann eigentlich nicht mehr als 40 Stunden sinnvoll
Software entwickeln in der Woche.
Man sollte dies auch umsetzen.
Ich glaube, für uns Europäer ist das einleuchtend.
Manche anderen Staaten sollten das vielleicht auch noch einsehen.
Schauen wir uns nochmal kurz ein, zwei Sachen davon genauer an.
Die Paarprogrammierung, das habe ich eben alles schon gesagt.
Man setzt sich also zu zweit vor einen Rechner und bekommt eine
Aufgabe, zum Beispiel ein Modul, was man jetzt entwickeln soll.
Ein großer Punkt an der Stelle ist, man muss ein eingespieltes Team
sein, denn es ist gar nicht so einfach, zusammen im Team Software zu
entwickeln.
Man sagt zwar, man versucht das so ein bisschen aufzuteilen in einen
Fahrer und einen Beifahrer, das heißt der Fahrer implementiert jetzt
gerade das, was als nächstes gemacht wird und der Beifahrer denkt
eigentlich nur mit und gibt Tipps oder hat das große Ganze im Blick an
der Stelle, aber häufig verschwimmt das aus der Erfahrung, wenn man zu
zweit programmiert.
Die besten Paarprogrammierteams sind sogar so, dass sie sich gar nicht
mehr groß gegenseitig austauschen müssen, sondern sie wissen einfach,
was der andere gerade im Sinn hat oder sie müssen nur noch mit
Halbsätzen kommunizieren, weil sie so viel Erfahrung darin haben,
zusammen zu programmieren.
Das macht sie natürlich dann noch umso effektiver an dieser Stelle.
Aber so oder so heißt natürlich Paarprogrammierung, ich setze zwei
Entwickler an dasselbe Problem, was sonst in der klassischen
Entwicklung natürlich nicht der Fall war.
Das heißt, ich habe erstmal doppelte Kosten an der Stelle.
Aber die Hypothese, die natürlich hier im Extreme Programming gefahren
wurde, ist, naja, ich muss danach, aber ich habe danach bessere
Qualität und muss keine Durchsichten mehr machen.
Aber wir schauen uns gleich noch an, ob das jetzt wirklich der Fall
ist.
Also es wurden Studien dazu gemacht, auch bei uns am Lehrstuhl, ob das
wirklich so ist, ob dieser Quelltext wirklich nachweisbar eine höhere
Qualität hat.
Und das konnte tatsächlich nachgewiesen werden an der Stelle.
Und somit konnten auch, konnte Paarprogrammierung auch fehlende
Inspektionen und Reviews ersetzen.
Aber die Aussage, dass das jetzt effektiver ist und kostengünstiger
als Einzelprogrammierung mit Inspektionen, lässt sich so nicht
nachweisen.
Die Signifikanz an der Stelle war nicht gegeben.
Das heißt, das Einzige, was man herausfinden konnte an der Stelle, ist
das Vermut, dass die Kosten sich zwar verdoppeln, wenn man jetzt aber
das mit den Inspektionen nachgegenrechnet, dass die Kosten von
Paarprogrammierung so im Bereich von sieben Prozent höher liegen als
mit Einzelprogrammierung und Inspektionen.
Jetzt kann man immer noch überlegen, ob das natürlich trotzdem eine
valide Variante ist, denn wenn die Qualität wirklich so viel besser
ist an der Stelle oder man einfach schneller ist, dadurch, dass man
zwei Programmierer hinsetzt, kann das natürlich eine valide Option
sein.
Man kann aber nicht sagen, dass jetzt Paarprogrammierung generell
besser ist als Einzelprogrammierung mit Inspektionen.
Schneller bist du ja an der Stelle auch nicht.
Ich meine, du musst ja zwei Leute für die Arbeit bezahlen bei der
Paarprogrammierung, wo du halt ansonsten den einen bezahlst, um den
Code zu entwickeln und der andere, um die Inspektion durchzuführen und
dann tauschst du.
Also es kommt im Endeffekt auch das Gleiche raus.
Genau.
Etwas, was aber auf jeden Fall zu erkennen war in der Studie, ist,
dass Paarprogrammierung sehr stark unerfahrenen Entwicklern hilft, vor
allen Dingen, wenn man die Paare so bildet, dass Erfahrene und
Unerfahrene zusammenarbeiten, dann ist es sehr sinnvoll.
Der Effekt mit der höheren Qualität von einem erfahrenen Entwickler,
der schafft das auch schon mit Einzelprogrammierung, braucht keinen
zweiten mehr, der daneben sitzt.
Das heißt, es ist etwas, was man sich überlegen kann, wenn man gerade
jemanden neu in der Firma eingestellt hat und möchte den einlernen
oder sonstiges.
Genau.
Jetzt kommen wir nochmal zum Testen.
Im Extreme Programming war es so, dass das Testen ein essenzieller
Bestandteil sein sollte, des gesamten Prozesses und auch immer wieder
mit eingebaut werden sollte.
Das haben wir ja schon gesehen.
Das Ganze funktioniert.
Continuous Integration, regelmässige Unit-Tests schreiben, die immer
wieder ausführen und das Ganze sollte sogar noch Spaß machen.
Ob das jetzt Spaß macht, ist, glaube ich, jedem überlassen, aber wenn
man Testen möglichst einfach hält, kann es tatsächlich Spaß machen,
weil man sich überlegen kann, wie man das Ganze umsetzt, was sind denn
die Klassen, die man testen möchte und so weiter.
Natürlich ist auch hier immer nur Fehler finden das Ziel und nicht
Fehlerfreiheit zu beweisen, denn das ist mit den Möglichkeiten, die
wir hier auch vorgestellt haben, einfach nicht möglich.
Genau.
Das ist eine Aussage von Ken Beck an der Stelle, einem der Väter von
Extreme Programming.
Any program feature without an automated test simply doesn't exist.
Das heißt, in Extreme Programming ist es tatsächlich so, dass jedes
Feature, was keinen Test hat, gar nicht als valide angesehen wird.
Das heißt, es muss alles getestet werden, was auch ausgeliefert wird.
Genau.
Die automatischen Komponententests kennen wir schon und der Kunde
macht zusätzlich noch Akzeptanztests, das kennen wir auch schon aus
den klassischen Modellen zum Teil, die dann auch trotzdem vom Team
implementiert werden und man testet immer wieder weiter.
Aber wichtig an der Stelle ist, dass ein essenzieller Bestandteil ist
und nicht wie im Wasserfallmodell erst ganz am Ende eine Phase gibt,
in der das explizit getan wird, sondern jederzeit und immer wieder
werden Tests geschrieben.
Was dann auch zur testgetriebenen Entwicklung passt, wie ich eben
schon kurz angesprochen habe.
Testgetriebene Entwicklung beinhaltet immer das Testen, das
Implementieren, aber auch ganz wichtig, das Umstrukturieren an der
Stelle.
Das heißt, jegliche Verhaltensänderung des Quelltextes wird durch
einen automatisierten Test abgedeckt und immer bevor ich diese
Änderung am Quelltext durchführe, schreibe ich die Tests.
Umstrukturierung an der Stelle ist dann immer dann, wenn ich nur den
Quelltext umbaue, keine neue Funktionalität hinzufüge, erhalte die
Funktionalität, möchte aber das ganze einfacher machen, möchte quasi
den Entwurf verbessern, den ich dort gerade durchgeführt habe.
Vielleicht schauen wir uns das einfach mal an diesem Schaubild hier
an.
Wir haben quasi die beiden Zustände grün und rot.
Das sind die grünen Tests und die roten Tests.
Und wenn ich anfange jetzt zu entwickeln, habe ich erstmal vielleicht
keine Testfälle.
Ich bin also grün bei all meinen Testfällen, fange dann immer damit
an, Testcode zu schreiben für das Modul, was ich jetzt als nächstes
entwickeln möchte oder die Funktionalität, die ich als nächstes
einbauen möchte und habe dann erstmal einen Testfall, der natürlich
rot wird, weil diese Funktionalität ist ja noch gar nicht da.
Ich kann jetzt dann an der Stelle Anwendungscode schreiben, der diese
Funktionalität erfüllt oder schreibe Anwendungscode, der erstmal noch
gar nicht erfüllt, sondern nur hinreichend ist für vielleicht andere
Testfälle, habe also immer noch Testfälle, die rot sind und kann dann
irgendwann dazu kommen, dass wieder all meine Testfälle grün werden
und bin wieder in dem Zustand, hier liegt es.
Wenn ich jetzt einen neuen Testcode schreiben kann, dann schreibe ich
auch keinen neuen Anwendungscode.
Häufig ist es aber jetzt so, wenn ich natürlich so rum entwickelt
habe, ist meine Software, naja, vielleicht nicht so schön strukturiert
und ich möchte mit dem Umstrukturieren dafür sorgen, dass das Ganze
lesbarer ist, für andere besser verständlich, leichter erweiterbar,
weniger Duplikate oder sonstiges.
Genau dafür setze ich das Umstrukturieren ein.
Deswegen bei testgetriebener Entwicklung immer darauf achten, dass das
Refactoring oder Umstrukturieren an der Stelle ein essenzieller
Bestandteil ist, denn sonst ist der Code, den wir da am Ende
rausbekommen, immer noch unlesbar, nicht schön und auch nicht viel
besser als alles, was wir mit anderen Varianten bekommen.
Genau.
Das habe ich, glaube ich, alles schon soweit gesagt.
Das ist auch das, was ich gerade eben schon beschrieben habe, da gehen
wir jetzt mal kurz drüber.
Nochmal kurz zur Umstrukturierung.
Naja, es geht halt immer darum, dass strukturerhaltend bzw.
funktionalitätserhaltend an der Stelle umstrukturiert wird.
Das heißt, ich habe automatische Tests, die sicherstellen, dass meine
Umstrukturierung direkt ist und versuche dann, quasi so
umzustrukturieren, dass es verständlicher wird.
Das heißt, ich möchte eine möglichst einfache Form für die bisher
implementierten Anforderungen erreichen.
Möglichst einfach heißt an der Stelle, naja, zum einen müssen
natürlich die Tests noch erfüllt sein, aber das Publikum sollte auch
verstehen können, was ich denn da jetzt umgesetzt habe.
Genau.
So Sachen wie keine duplizierte Logik und sonstige Geschichte.
Meistens wird das gemacht anhand sogenannter Bad Smells, auch in
Gerüchen auf deutsch, die duplizierter Programmtext, parallele
Vererbungsbäume, die nicht nötig wären, die man zusammenlegen könnte.
Sowas wie Schrotflintenschirurgie, das heißt, wenn ich eine Änderung
an einer Funktion mache, muss ich viele andere Stellen im Programm
anpassen.
Shotgun Surgery im Englischen, ich finde das eine sehr schöne
Übersetzung übrigens.
Und so weiter.
Genau.
Jetzt kommen wir zum nächsten Punkt, dem inkrementellen Design.
Das heißt, früher war es immer so, man implementiert für jetzt und der
Entwurf war eigentlich für die Zukunft.
Das heißt, wenn ich in einem Wasserfallmodell den Entwurf gemacht
habe, ist das halt für die nächsten vier Monate irgendwann relevant.
Bei XP ist es jetzt so, dass das System so einfach wie möglich
entworfen werden sollte, aber zu jedem Zeitpunkt ja quasi den
momentanen Stand entworfen haben sollte.
Und jegliche extra Komplexität, die man einfügt, sollte vermieden
werden.
Das heißt, man reduziert sich tatsächlich auf das Wesentliche an der
Stelle.
Das Planungsspiel ist jetzt dieses Prozessmodell, das in XP
stattfindet.
Das heißt, wir planen jetzt hier den Umfang, die Zeit und die Kosten
der nächsten Iterationen, denn wir haben hier ein iteratives Vorgehen
an der Stelle und die nächsten Auslieferungen.
Das heißt, man definiert Auslieferungen, die man an den Kunden oder
wie auch immer, wer auch immer der Kunde ist.
Könnte ja auch nur in Online-Stellen irgendwelche Sachen sein.
Definiert man, das ist so ein vierteljährlichen Zyklus und hat darin,
bis man zu dieser Auslieferung kommt, Zyklen.
Und passt diesen Plan, den man jetzt dort macht, immer wieder an.
Das heißt, man hat am Anfang eine Auslieferungsplanung, die jetzt
bestimmt, was soll denn in meiner nächsten Auslieferung überhaupt
enthalten sein.
Was sind denn die Features, die Funktionalitäten, die ich an der
Stelle ausliefern möchte.
Dann beginne ich mit einer Iterationsplanung, die mir jetzt plant, was
mache ich in den nächsten vier Wochen, was ist jetzt mein erster
Arbeitsschritt, um in Richtung dieser Auslieferung, dieser
Funktionalität zu kommen.
Dann iteriere ich, mache eine Iteration, arbeite, produziere
Quelltext, Testcases und so weiter.
Dann kommt die nächste Iterationsplanung und so weiter.
Bis man dann irgendwann zu diesem Standpunkt kommt, dass man die
Funktionalität erfüllt hat, die man ausliefern möchte.
Und hat dann die erste Auslieferung.
Benutzt dann das, was man zu diesem Zeitpunkt ausgeliefert hat, um
wieder weiterzuarbeiten.
Macht jetzt wieder diese gesamte Iteration ein weiteres Mal.
Überlegt sich also, was ist in der nächsten Auslieferung.
Da ist wahrscheinlich irgendwas aus der ersten, plus weitere
Funktionalität, die man in der zweiten ausliefern will.
Und führt das Ganze so weiter durch, bis man die Auslieferung erreicht
hat, die man eigentlich am Ende für sein Produkt haben möchte.
Wichtig dabei ist natürlich auch, dass der Kunde vor Ort ist, dass er
anwesend ist, denn ohne eine Rücksprache mit dem Kunden, wie ich eben
schon sagte, ist das nur sehr schwierig umsetzbar.
Denn man muss ihn immer wieder fragen können, weil wir ja iterativ,
also ich gehe nochmal zurück, wenn wir hier immer die Auslieferung
planen, müssen wir den Kunden fragen, was ist denn das, was du als
nächstes unbedingt in der Software haben möchtest.
Was sind diejenigen Anforderungen, die dir wichtig sind an der Stelle.
Und der Kunde ist hier in diesem Prozess immer wieder mit eingebunden.
Er macht in der Auslieferungsplanung, sagt er, was möchte ich jetzt
haben.
Er ist aber auch immer wieder für Fragen bereit in den einzelnen
Iterationen, um klarzustellen, was denn jetzt eigentlich gemeint war
mit den einzelnen Anwendungsfällen, die auf den Karteikalen stehen.
Genau.
Hier haben wir natürlich das Problem, dass der Kunde halt nicht immer
im selben Raum sitzt oder halt, wenn er im selben Raum sitzt,
vielleicht auch zwischenzeitlich Leerlauf hat, weil er nicht immer
ausgelastet ist, weil er nicht immer ständig gefragt wird für
irgendwelche Dinge.
Das heißt, es ist gar nicht so einfach, hier den richtigen Mittelweg
zu finden zwischen, der Kunde wird mit einbezogen, aber er kann auch
noch andere Dinge tun an der Stelle.
Meistens wollen die Kunden gar nicht so sehr eingebunden werden und
dann hat man das Problem bei Scrum oder jeglichen anderen agilen
Methoden.
Jetzt noch kurz ein bisschen was zu, warum das Ganze außerdem
eingeführt wurde.
Naja, Kent Beck's Behauptung war, dass im konventionellen
Entwicklungsprozess die Kosten für Änderungen exponentiell mit der
Zeit ansteigen, weil man ja vorher festgelegt hat, was denn eigentlich
ausgeliefert werden soll und man stellt halt irgendwo in der
Implementierung fest, dass jetzt doch was anders gemacht werden soll
und man muss dann alles wieder von vorne machen und wieder das ganze
System anpassen.
Das stimmt, ist fragwürdig, ist nicht nachgewiesen an der Stelle, dass
wirklich ein exponentieller Zusammenhang an der Stelle ist, aber seine
Aussage, dass mit Extreme Programming die Kurve eher so aussieht, ist
ebenso fragwürdig.
Denn ein Plateau an der Stelle zu erreichen und keine weiteren
Änderungen, die nicht mehr zu erhöhten Kosten führen, sind auch
unrealistisch.
Deswegen wird vermutlich eher ein derartiger Verlauf angenommen
werden.
Genau.
So, was ist jetzt die Kritik, die an Extreme Programming gestellt
wird?
Naja, diese asymptotische Kostenkurve an der Stelle beruht halt auf
einer Erfahrung Einzelner, ist aber wie gesagt nicht nachgewiesen.
Wir haben keine Produktimplementation, die ist nicht vorgesehen an der
Stelle.
Das heißt, wenn man die benötigt, kann man sie zwar schon machen, aber
dann ist auch wieder die Zeit, die man benötigt und die Kosten wieder
größer.
Das Ganze ist nicht reproduzierbar, da es ein Ad-Hoc-Prozess ist.
Jede Entscheidung wird immer wieder iterativ an der Stelle
entschieden, wo sie relevant ist.
Und das hängt dann auch stark von der Erfahrung der Entwickler an der
Stelle ab oder des Teams, dass das Ganze umsetzt.
Das heißt, man kann nicht sagen, wenn ich jetzt das Projekt, wie
letztes Mal den Pascal-Übersetzer mit XP umgesetzt habe, dass ich es,
wenn ich es jetzt nochmal machen würde, einen ähnlichen Verlauf
erkennen könnte.
Und die Paarprogrammierung ist also unklar, ob dies wirklich diesen
Zuwachs an Qualität kompensiert oder dass der Zuwachs an Qualität
diese erhöhten Kosten kompensieren kann an der Stelle.
Außerdem hat man natürlich das Problem, wenn man jetzt Extreme
Programming in seiner Firma einführen will, dass der Kunde, der vorher
vielleicht nie eingebunden war, sagt, warum soll ich mich jetzt
ständig jede Woche mit euch zusammensetzen und euch Fragen
beantworten.
Ich will das gar nicht.
Ich will euch einmal sagen, was ihr tun sollt und ihr macht es dann.
Das ist nicht immer einfach.
Und auch die Software-Ingenieure, die vorher mit klassischen Modellen
gearbeitet haben, müssen an der Stelle umdenken, denn sie tendieren
eher dazu, einen zu komplexen Entwurf, zu umfangreichen Entwurf zu
machen an der Stelle, der in XP gar nicht vorgesehen ist.
Und auch die Testgetriebene Entwicklung ist natürlich, wenn man sie
nicht selber immer gemacht hat, ein Umdenken und muss auch vom
Entwickler gewollt sein an der Stelle.
Man kann recht schnell sehen, dass wenn man die Testgetriebene
Entwicklung nur so leichtfertig macht und sich nicht genügend Gedanken
an der Stelle macht, dass man umfassend das Testing macht, bevor man
den Anwendungscode schreibt, dass das Ganze nach hinten losgehen kann.
Genau.
Das sind die Sachen, glaube ich, auch klar an der Stelle, dass
natürlich für die Paarprogrammierung eine gleiche Wellenlänge für der
beiden Teilnehmer an der Stelle vorausgesetzt wird.
Und, dass man Respekt für fremden Welltext haben muss, wenn dieser
offen ist für alle.
Genau.
Ist jetzt Extreme Programming nicht eigentlich wieder Programmieren
durch Probieren?
Nein, nicht wirklich, denn es gibt ja schon klare Planungsschritte.
Das Planungsspiel wird durchgeführt.
Es werden erfolgreiche Tests gefordert, die nicht unbedingt gefordert
sein müssen bei Programmieren durch Probieren.
Und die Restrukturierung, also die Umstrukturierung und die
Testgetriebene Entwicklung kompensieren zum Teil für die fehlende
Entwurfphase.
Das heißt nicht, dass da am Ende eine große schöne Architektur
rauskommt, sondern dass zumindest eine Architektur rauskommt, die an
einigen Stellen erweiterbar ist und auch einsetzbar ist.
Und vielleicht reicht das auch an der Stelle.
Das muss man immer pro Projekt sehen.
Cowboy-Programmierer werden diszipliniert.
Ich weiß nicht genau, was das aussagen soll, aber...
Ich würde sagen, dass Leute, die sonst nur Code-and-Fix gewohnt sind,
die z.B.
Quereinsteiger sind, wahrscheinlich einfacher auf Extreme-Programming
getrimmt sind als auf ein klassisches Prozessmodell.
Das ist wohl wahr.
Tatsachen.
Ja, genau.
Das heißt man ist eigentlich bei den beiden Varianten, wenn man jetzt
mal XP gegenüber Wasserfallmodell vergleicht, an zwei Enden der Skala.
Man hat bei XP leichtgewichtige und änderbare Planung.
Im Wasserfallmodell hingegen die schwergewichtige und feste Planung.
Man muss aber jeweils sehen, was zum eigenen Projekt, den eigenen
Strukturen und dem eigenen Team passt.
Denn man kann sich natürlich auch überlegen, dass man innerhalb des
Wasserfallmodells immer noch im Entwicklerteam Extreme-Programming
einsetzt.
Oder auch Scrum, wie wir es gleich sehen.
Das heißt, diese ganzen Prozessmodelle sollte man nicht als komplett
voneinander getrennte Objekte sehen, wie Sebastian es eben auch schon
sagte.
Man kann diese immer kombinieren, man kann immer anpassen und man
sollte auch immer anpassen.
Gerade bei den agilen Methoden, dass das Ganze auf die Prozesse passt,
die man in der Firma einsetzt.
Genau.
Hier noch die kurze Zusammenfassung zu XP und dann kommen wir auch
schon zu Scrum.
Das heißt, XP ist eigentlich ein Softwareprozess, der geeignet ist für
vage und sich schnell ändernde Anforderungen, was ja häufig der Fall
ist in Softwareentwicklung.
Außer man hat so Riesenprojekte wie Toll Collect oder sonstige
Geschichten.
Für kleine Entwicklerteams natürlich, denn sobald man größere Teams
hat, muss man sich wieder überlegen, wie organisiert man diese Teams
untereinander.
Dann kann man sich natürlich überlegen, ob man intern im Team Extreme
-Programming einsetzt.
Darüber hinaus wieder ein größeres Prozessmodell fährt, was mit mehr
Kommunikation an der Stelle die Verwaltung quasi macht.
Man hat aber in dem Extreme-Programming-Prozess weniger
Verwaltungsaufwand.
Das heißt, man hat eigentlich eine Softwareentwicklung mit relativ
leichtem Gepäck.
Ich würde nicht sagen mit ganz leichtem Gepäck, weil das wäre Code-and
-Fix.
Aber man hat zumindest eine strukturiertere Herangehensweise an der
Stelle.
Und bei großen Projekten, wie gesagt, braucht man vielleicht trotzdem
eine Entwurfsphase, die eine Architektur an der Stelle vorgibt.
So, und jetzt kommen wir schon zu Scrum.
Denn Scrum, wie gesagt, ist eigentlich nur eine Abwandlung oder
zumindest eine Präzisierung des Ablaufes des Planungsspiels an der
Stelle des iterativen Vorgehens von Extreme-Programming.
Das heißt, Scrum definiert ein Vorgehensmodell für das agile
Projektmanagement.
Das heißt, wir haben jetzt all die Geschichten mit testgetriebenen
Entwicklungen und ein paar Programmierungen erstmal außen vor, sondern
beschäftigen uns in Scrum nur mit dem Vorgehensmodell an der Stelle.
Das Ganze beginnt damit, dass man in Zusammenarbeit mit dem Kunden
eine Anforderungsliste erstellt, die auch auf so Karteikarten
geschiebt, die sogenannten User-Stories festlegt, die mir sagen, was
sind denn eigentlich die Sachen, die jetzt die Software erfüllen soll.
Das ist die gesamte Liste, die aber jederzeit auch angepasst werden
kann in Scrum.
Der sogenannte Product Backlog an der Stelle, das ist diese Liste
hier, oder auch Anforderungsliste.
Und dann definiert man für jeden Sprint, Sprint sind die Iterationen
in Scrum, einen sogenannten Sprint Backlog, also eine Aufgabenliste
für den aktuellen Sprint, die jetzt in Zusammenarbeit mit dem Kunden
bestimmt wird, was sind jetzt die Punkte, die wir für die nächste
Auslieferung eigentlich definieren wollen.
Was sind die Sachen von dieser kompletten Anforderungsliste, die wir
jetzt im nächsten Sprint umsetzen.
Und so ein Sprint ist dann normalerweise zwei bis vier Wochen und in
dieser Zeit wird die Aufgabenliste abgearbeitet.
Das heißt, die Aufgaben, die hier in der Aufgabenliste sind, werden
den einzelnen Entwicklern zugeteilt, diese arbeiten die ab und das
dauert zwei bis vier Wochen.
Diese 24 Stunden hier deuten darauf hin, dass man sich bei Scrum jeden
Tag zusammensetzt.
Das ist das Entwicklerteam mit dem Scrum Master, wir sehen gleich
noch, was der eigentlich macht.
Und es wird durchgesprochen, was mache ich denn heute, was ist mein
Ziel für heute, was habe ich geschafft gestern und wie lief das Ganze.
Das ist einfach ein kurzer Austausch.
Diese Treffen sollen möglichst kurz gehalten werden, denn wenn man
etwas ausartet, dann kommt man gar nicht mehr zum Programmieren an der
Stelle.
Und nach so einem Sprint hat man dann einen auslieferbaren
Produktteil.
Wichtig, auslieferbarer Produktteil heißt jetzt nicht, dass es die
fertige Software ist, sondern wir haben hier ein Inkrement der
Software.
Und fangen dann wieder an, aus der Anforderungsliste wieder eine
Aufgabenliste für den nächsten Sprint zu erstellen und so weiter.
Das heißt hier nochmal kurz aufgeschrieben, was jetzt diese Artefakte
sind.
Wie gesagt, die Anforderungsliste, der Product Backlog definiert alle
Produktanforderungen, kann jederzeit aber wieder angepasst werden,
neue Sachen hinzugefügt werden und aus denen wird dann mit dem
Auftraggeber zusammen priorisiert, was für den nächsten Sprint
abgearbeitet werden soll.
Das ist dann der Sprint Backlog, das hatte ich gerade schon gesagt.
Und es gibt noch so eine sogenannte Hindernisliste, den Impediment
Backlog, welcher definiert, was sind denn die möglichen Sachen, die
das Projekt zum Scheitern bringen können.
Was sind die Sachen, die schwierig sein könnten, die man dann mit dem
Team besprechen kann und versucht diese auszurollen.
Man überlegt sich dann im Team, wie viel Zeit man für die einzelnen,
für jeden Sprint macht man eine Planung, wie lange dauert dieser
Sprint, das ist die Geschichte mit dem Planungsbroker, die wir letzte
Woche hatten.
Das heißt für jede dieser User Stories oder Anforderungen, die man
dann jetzt da reinkriegt auf den Karteikarten, wird geschätzt, wie
lange braucht man wohl dafür und trägt das Ganze dann auf und versucht
dann mit Restaufwands, im Englisch Burn Down Chart, Professor Tichy
hat das auch mal zwischendurch als Unterbrenn-Diagramm übersetzt.
Ich finde Restaufwands-Diagramm ist passender an der Stelle.
Im Idealen Fall soll das so aussehen, dass natürlich die Entwicklung
nach unten geht.
Man hat noch so und so viel zu tun an Stunden, die man abarbeiten muss
und plant dann und lässt das Ganze ablaufen.
Im Normalfall sieht das eher so aus, weil man das auf irgendeiner Wand
im Büro vielleicht macht und man hat jetzt hier in Rot die wirkliche
Abarbeitung der User Stories und der Plan war das blaue.
Sorry, dass das hier in, ich weiß nicht welche Sprache das ist, aber
ich glaube es wird klar, worum es geht.
Das Ganze sorgt dafür, dass jeder Entwickler immer weiß, wo stehen wir
gerade im Projekt und somit man darüber auch sprechen kann, wie man
jetzt weiterverfahren muss.
Genau.
Noch kurz die Rollen in Scrum.
Man hat den Auftraggeber, den sogenannten Product Owner, welcher das
entweder der Kunde wirklich selbst ist oder jemand ist, der den Kunden
vertritt und mit dem kommuniziert.
Das heißt, derjenige ist verantwortlich zu priorisieren, was sind die
nächsten Schritte, was machen wir als nächstes im next Sprint und so
weiter.
Dann gibt es den Scrum Master.
Der Scrum Master hat als Aufgabe den Prozess zu überwachen.
Das heißt, seine eigentliche Aufgabe ist dafür zu sorgen, dass das
Team sich an die Scrum Prozesse hält, dass dort alles für das Team
getan wird, dass das Team möglichst gut funktioniert, dass alle
Informationen zur Verfügung stehen, die das Team braucht und beseitigt
sonstige Hindernisse, die es sonst noch gibt.
Und dann gibt es natürlich das Entwicklungsteam, was die eigentliche
Implementierung an der Stelle macht, die sich selbst organisiert an
der Stelle.
Die Treffen, die bei Scrum definiert werden, ist zu einmal das Sprint
Planning Meeting.
Sprintplanung, das ist das Ganze am Anfang, wo dann priorisiert wird,
also vor jedem Sprint priorisiert wird, was denn jetzt als nächstes in
die Aufgabenliste übertragen werden soll von den User Stories, die man
zur Verfügung hat.
Und dann gibt es das Daily Scrum, das tägliche Scrum Treffen, was ich
gerade eben schon genannt habe, das jeden Tag stattfindet.
Die Idee dahinter ist tatsächlich, dass man das im Stehen macht, damit
man halt nicht so viel Zeit an der Stelle verbringt, meistens an der
Kaffeemaschine oder sonstiges.
Es geht darum, möglichst kurz dem gesamten Team den Überblick zu
geben, was ist denn der aktuelle Stand, wer macht was, welche
Hindernisse hat jemand überwunden zum Beispiel, damit man genau dieses
Problem nicht hat, dass die Teams nicht wissen, oder die anderen nicht
wissen, was die anderen schon ausgemerzt haben an der Stelle.
Dann gibt es das Review Treffen, welches immer am Ende eines Sprints
durchgeführt wird.
Das ist quasi das Vorstellen des auslieferbaren Produktteiles, wird
dem Kunden vorgestellt und die Ergebnisse werden dann besprochen und
der Auftraggeber kann dann sagen, das passt mir so oder wir müssen die
Anforderungen nochmal anpassen oder in der nächsten Iteration müssen
wir was anders machen an der Stelle.
Und es gibt noch eine Sprint Retrospective an der Stelle, in der sich
das Entwicklungsteam und der Scrum Master zusammensetzen und sich
überlegen, was lief denn jetzt gut in dem Prozess, haben wir alles
richtig gemacht, was waren unsere Probleme, was können wir daraus für
Konsequenzen für den nächsten Sprint ableiten.
Genau, das war es auch schon zu Scrum.
Wie gesagt, auch Scrum kann man anpassen auf den jeweiligen Prozess.
Wird auch die meisten Fällen in den Firmen gemacht, die Scrum
einsetzen oder die überhaupt agile Entwicklung machen wollen.
Ich glaube, keiner benutzt es einfach in seiner Reinform oder es muss
halt immer ein bisschen mit Vorsicht genossen werden an der Stelle.
Aber es gibt einen ganz guten Baukasten, mit dem man weiß, worüber man
spricht an vielen Stellen und auch ein ganz gutes Vorgehen an der
Stelle.
Gibt es dazu noch Fragen?
Ja.
Die Frage war, was ist die typische Teamgröße für ein Scrum-Team und
was ist, wenn mein Team, mit dem ich arbeite, einfach größer ist als
das, was möglich ist in so einem Daily Scrum, zum Beispiel auch
abzuarbeiten.
Man will ja nicht, dass das Ganze jetzt mehrere Stunden dauert oder
sonstiges.
Genau da kommt das Anpassen des Prozesses so ein bisschen zum Tragen.
Ich glaube, an der Stelle braucht man, wie gesagt, eine Kombination.
Man macht vielleicht in seinem eigenen Team Scrum, hat einen Product
-Owner für seinen Bereich, muss aber das Gesamtprojekt vielleicht in
unterschiedliche Teile schneiden, die dann nebeneinander entwickelt
werden können.
Oder man hängt darüber tatsächlich eins von den klassischen Modellen
und integriert Scrum dann für die einzelnen Entwicklungsteams.
Scrum ist schwierig umzusetzen bei einer Größe von, ich würde mal
sagen, größer 15 wird schon langsam schwierig, vielleicht auch schon
größer 10.
Das kommt drauf an, wie gut man kommuniziert an der Stelle.
Dann lieber mehrere Scrum-Teams, die parallel arbeiten.
Man kann ja die Sprints tatsächlich auch ausrichten, dass sie zu
selben Zeitpunkten fertig sind.
Man muss dann natürlich mit Management nochmal überlegen, wie man die
Kommunikation zwischen diesen einzelnen Teams dann durchführt.
Es gibt aber tatsächlich auch Ansätze, habe ich mal gesehen, nennt
sich Scrum in the Large, also Scrum im Großen, dass man im Grunde über
Scrum noch mehrere Scrum-Schichten drüber setzt, vom Managen einzelner
Scrum -Teams bis hin zum Management der kompletten Firmenstruktur.
Das geht schon auch, wie gut es funktioniert, ist zweifelhaft.
Also ich glaube, Scrum ist tatsächlich eher was für kleine Teams und
darüber sollte man dann eher was Klassisches setzen, so wie Tobias
auch schon gesagt hat.
So, letzter Programmpunkt.
Noch schnell?
Zwei Minuten hast du noch.
Zwei Minuten?
Du darfst das gerne machen, wenn du willst.
Ich darf?
Nee.
Gut, genau.
Wir haben noch zwei Minuten, aber wir haben ja versprochen, dass wir
auch noch den Sieger des Parallelisierungswettbewerbs küren.
Das haben wir getan.
Wir haben ihre Lösungen für Aufgabe A4 des Übungsblattes angeschaut
und mit diesem Test-Setup vermessen.
Das heißt, wir haben mit einem Core i7 mit 4 Kernen, dann hat er 4
Hardware -Fäden plus 4 virtuelle Hyper-Threading-Fäden, also 8 Fäden
eigentlich an der Stelle mit 16 GB RAM und diesem Testbild hier, recht
schön groß, damit man auch die Effekte sieht und den vorgegebenen
Parametern durchgeführt.
Schauen wir uns mal die Ergebnisse an für die folgenden Lösungen.
Das ist jetzt erstmal die sequenzielle Ausführungszeit.
Die ist bei den meisten gleich, weil das ist ja die sequenzielle
Variante, die wir vorgegeben haben.
Das ist also eigentlich nur ein bisschen Messschwankung, die man jetzt
hier sieht.
Die erste Lösung hat jetzt bei der... also hier ist die
Ausführungszeit aufgetragen, hier sind die unterschiedlichen Lösungen.
Es gibt eine Lösung, die hat es geschafft ein bisschen langsamer zu
werden als die sequenzielle Lösung, so ein bisschen sehr.
Ich glaube, die schafft es nicht ganz zu gewinnen an der Stelle.
Deswegen schneiden wir das ganze Diagramm jetzt hier mal ein bisschen
ab, weil wenn ich jetzt diese Skala hier lasse, dann sieht man nachher
nicht mehr, wie es bei den anderen weitergeht.
Das heißt, wir sind jetzt hier einen Schritt weiter, haben jetzt nur
noch eine Skala bis 2500 Millisekunden.
Die blaue Zeit ist jetzt das, was diejenigen für eine sequenzielle,
also was ihre einfädrige Laufzeit war, die zum Teil nicht unsere
Musterlösung ist, sondern wie man hier schon sieht, auch deutlich
schneller werden kann.
Ich sage gleich noch kurz was dazu, wie das erreicht wurde an der
Stelle.
Schauen wir uns aber erstmal mal die ersten Lösungen hier an.
Die haben allesamt irgendwas mit Rastern gemacht und ein bisschen
Aufteilung und darüber parallelisiert.
Also auch die Threadpools immer noch benutzt, an der Stelle aber ein
bisschen anders.
Und kommen auch schon auf recht gute Ausführungszeiten, hier im
Bereich der 1000.
Wir haben aber tatsächlich noch schnellere Lösungen an der Stelle.
Ich muss vielleicht an der Stelle sagen, was Parallelisierung
betrifft, sind das schon sehr gute Lösungen.
Also alles, was schneller ist als Faktor 2, ist schon sehr gut
eigentlich für das Problem.
Genau.
Wir haben aber auch noch Lösungen, die noch ein bisschen schneller
sind.
Der Punkt an der Stelle, also 4 von diesen Lösungen haben das so
gelöst, dass sie Graphics2D benutzt haben und dabei die DrawImage
-Methode oder ein Writable Raster, welche tatsächlich mit Hardware
-Beschleunigung arbeiten.
Das heißt, sie haben eigentlich die GPU benutzt.
Wir hatten aber ja gesagt, dass dies eigentlich nicht erlaubt war an
der Stelle.
Das heißt, die Lösungen sind super und super schnell und eine gute
Lösung an der Stelle, definitiv.
Aber wir hatten gesagt, wir wollen auf der CPU parallelisieren.
Das heißt, wir haben die 4 Lösungen und dabei auch die schnellste, die
tatsächlich leider die GPU benutzt haben.
Also wir haben das dann zum Vergleich auch mal auf einer Maschine
laufen lassen, die keine GPU hat und dann hat man halt eine
Beschleunigung von 0.
Also dann ist es halt genauso schnell wie sonst auch.
Und naja, das ist dann halt offensichtlich nicht das, was man haben
will.
Das ist echt schade, weil die Leute haben sich sicherlich Gedanken
gemacht.
Das sind, wie du ja schon sagst, sehr gute Lösungen, weil sie eben
genau das Richtige gefunden haben, das richtige Konstrukt, um das
einfach zu beschleunigen.
Also die Benutzung ist auch super einfach, um die Beschleunigung
hinzubekommen.
Insofern super Lösung, aber sorry, reißt halt leider die eine
Anforderung, die wir hatten.
Genau.
Das heißt, wir haben da jetzt noch eine Lösung, die ist übrig
geblieben.
Da in der Mitte.
Die hat zwei Varianten gebaut.
Eine mit Caching und eine ohne.
Da Caching jetzt ja vielleicht an der Stelle auch nicht unbedingt die
richtige Variante ist.
Du sollst vielleicht mal erklären, was da gemacht wurde mit Caching.
Ich glaube, das ist der spannende Teil.
Genau, also die Person hat beim Caching zum einen die Wasserzeichen,
die skalierten Wasserzeichen gecached.
Das heißt, wenn wir mehrmals denselben Aufruf machen, mit derselben
Skalierung, hat er schon das Wasserzeichen zwischengespeichert.
Was ziemlich schlau ist, weil wir auch beim Testen festgestellt haben,
dass das eigentlich der Bottleneck ist.
Also an der Stelle wird es eigentlich langsam.
Den Rest parallelisieren bringt gar nicht so furchtbar viel, sondern
das Skalieren ist das, was langsam ist.
Das heißt, das zu cachen für unterschiedliche Wasserzeichengrößen ist
hilfreich.
Aber er hat nicht nur das gecached, er hat tatsächlich auch das
Ergebnisbild gecached.
Das ergibt dann übrigens die Laufzeit.
Das war tatsächlich Premiere.
Ich mache das jetzt schon seit vielen Jahren, aber das habe ich noch
nicht gesehen, dass jemand Laufzeit von 0 hinbekommt.
Das war echt super.
Naja gut, der Punkt ist, wir lassen halt immer wieder mit denselben
Bildern laufen.
Das heißt, das funktioniert natürlich an der Stelle.
Wir haben natürlich aus Vergleichbarkeit die andere Variante bemessen
und auch in dem Fall die Variante ohne das Caching der Wasserzeichen.
Was der Kommilitonen an der Stelle noch gemacht hat, ist, er hat diese
ScaleWith -Methode, die er in der Funktionalität von Java benutzt,
nachgebaut und schneller gemacht.
Das gibt schon einen enormen Vorteil.
Er schafft aber trotzdem dieselbe Lösung zu erzeugen wie unsere
Variante.
Außerdem, das ist also der Grund, warum er hier mit dem blauen Balken
schon auf die Höhe kommt, aber auch da hat er noch einen Speedup von
10 weiter geschafft, denn er hat dann noch andere Cache-Effekte
ausgenutzt, nämlich die im Prozessor.
Er hat nämlich die Gebietsterlegung für die Threadpools anders
gemacht.
Und so, dass dort Cache-Effekte ausgenutzt werden können.
Und hat damit quasi die beste Lösung an der Stelle erreicht.
Jetzt ist die Frage, ist die Person dort?
Also hier.
Gratulation und Sie können runterkommen.
Genau, wir haben natürlich...
Also erstmal natürlich Glückwunsch zu der wirklich hervorragenden
Lösung.
Bitte weiter so machen und noch besser, bitte bei uns am Lehrstuhl
Bachelor - und Masterarbeit schreiben, weil wir machen ja auch sehr
viel in Richtung Parallelität.
Du könntest noch fragen, ob wir gerade irgendeinen Quatsch erzählt
haben, weil er sollte es besser wissen.
Genau, haben wir noch irgendwas vergessen, was Sie noch zusätzlich
getan haben, noch besser getan haben, als wir gerade schon beschrieben
haben?
Okay, also die Motivation war Schokoriegel, sehr schön.
Ansonsten stimmt das so, wie wir das erklärt haben.
Mach du doch mal die Übergabe.
Genau, also es gibt jetzt eine Urkunde.
Das ist erstmal nur die Urkunde, denn wir haben ja gesagt, es gibt
auch noch einen weiteren Preis.
Es ist tatsächlich ein 30 Euro Amazon-Gutschein, den Sie bekommen.
Den werden wir Ihnen zusenden.
Gratulation.
Genau, weiter so.
Glückwunsch.
Das war sehr gut.
Gut, wenn wir vielleicht noch eine Minute erübrigen können, noch mal
kurz Hinweis zur Klausur.
Erster Hinweis, ich wünsche Ihnen allen sehr viel Erfolg für die
Klausur.
Das war's.
Zweiter Hinweis, noch mal zu der Gedächtnisschütze.
Noch mal für alle, bitte nur einseitig ein DIN A4-Blatt beschreiben.
Wie Sie das beschreiben, ist uns völlig egal.
Handschriftlich aber.
Bitte, handschriftlich, genau.
Nichts kopiert, auch nicht handschriftlich und dann kopiert, sondern
wirklich echt handschriftlich.
Wir werden das kontrollieren und gegebenenfalls abnehmen, wenn das
nicht eingehalten wird.
Ansonsten...
Genau, es wird an die Klausur hinten dran geheftet.
Sie können aber dann selber entscheiden, wie rum, je nachdem, wie Sie
es uns hinhalten.
Überlegen Sie sich auch schon mal, ob das nicht vielleicht umgekehrt
dran heften, schlauer ist.
Probieren Sie es einfach mal zu Hause aus, ob das vielleicht...
Sie machen das aber am Anfang der Klausur.
Sie können nicht die Klausur schreiben und dann wird es dran geheftet.
Wir müssen das leider vorneweg machen, ansonsten funktioniert es
organisatorisch einfach nicht.
Gut, genau.
Das war es dann und dann, wie gesagt, viel Erfolg.
Bis nächste Woche.