Herzlich Willkommen. Macht sich eigentlich Semester in der Stimmung breit.
Harry Cay Festival ist auch Zeitfestival. Was für ein Zeug?
Musikfestivals. Echt? Das ist alles voll leid von dir.
Das gibt es trotzdem nicht. Wow. Ich brauche das
also nicht persönlich nehmen. Nächste Woche wird es zufrieden sein.
Das ist nicht. Tja, okay. Dann freut es mich
umso mehr, dass sie den Weg hierhin gefunden haben.
Ich hoffe, ich kann sie ein gutes Stündchen halbwegs
gut unterhalten
Und ihnen vielleicht noch ein bisschen was Neues, im Sinne von Non-Schole,
Set V, Tail Diskimus, ihnen hier erzählen.
Ja, heute wollte ich mich mit Ihnen über Projektplanung.
Und gibt es da möglicherweise, hat das kleine gallische Dorf namens Wamm,
sich auch in dieser, bezüglich dieser Fragestellung etwas ausgedacht,
was dazu passt, was man mit Werkzeugmaterial machen kann?
Bevor ich anfange, freies Assoziieren über Projektplanung.
Was fällt Ihnen dazu ein? Was haben Sie
dazu schon gehört
Das hört sich... Sie haben doch schon... Haben Sie
nicht alle letztes Semester schon Projekt Mana Argument gehört?
Ja. Was sind denn da so die Kernaussagen?
Scrum haben Sie kennengelernt, ja. Man muss schätzen.
Man schätzen kann man, indem man zu zerlebt.
Funktionale Dekkomposition? Nee, nee, das ist jetzt mehr
eine Frage.
Wie schätzen Sie denn
Ich rate. Sie pokern. Wie? Also diese verschiedene
Muster, mit denen wir schätzen. Aha. Haben Sie
auch gepokert? Ja, pokern ist auch eine Methode,
oder? So. Bei Scrum. Ja, aha.
Das heißt also, es weckt fast bedrohlich.
Ja,
sonst noch was zum Thema
Projektplanung. Die Frage war,
ob sie, letztes Semester im Rahmen ihrer Projekte,
was da so bei Projektmanagement zum Thema Projektplanung,
was sie da gehört haben.
Das ist nicht nur ein Monitor, das ist auch ein Barat.
Das ist schon ein Anspruch.
Molly 6. Energy
Ja. Control ist, also ist beim Monitoren, hat es,
also durchaus Vorteile. Ja, aha. Na gut,
so, ach, das sagen wir mal,
das ist halbwegs erwartungskonform, was sie sagen.
Wir haben uns ja jetzt, also vielleicht noch kurz so zum,
wir haben ja jetzt noch zwei inhaltliche Termine,
haben wir noch zwei bis drei,
weiß man nicht
so genau
Ja, plus minus eins. Ich werde einen Termin,
werde ich noch, das könnte ich sie auch fragen,
wollen wir noch einen Termin zur Klausurvorbereitung machen?
Ja, bitte. Wenn ich die Frage so stelle,
dann schlage ich vor, dann machen wir den,
das könnten sie dann ihren Kommilitonenden und Kommilitoninnen auch noch bitte mitteilen,
dann machen wir den vorletzten Termin.
Kalendarisch müsste das so irgendwas,
der siebte oder 8.
Juli sein
Oder? Sechs. Ich sage ja, plus minus eins,
ja. Das ist echt ein Problem. Ich meine,
die anderen haben dieses Problem auch, bloß die Informatiker merken es immer.
Also dann machen wir den 7. Juli als Klausur-Vorbereitungs-,
den 7. minus eins zum Klausur-Vorbereitungstermin.
So, weil am 13. Juli kommt nochmal ein Herr von
diesem Project Management Institute,
wird was zu modernen Formen der Projektplanung
Erzählen. So, das ist dann aber nicht mehr klausurrelevant,
deswegen, also nicht der letzte Termin, sondern der vorletzte Termin,
worötlich, also sie trotzdem herzlich einladet, an diesem Termin teilzunehmen.
Nächste Woche, das werde ich möglicherweise auch noch mal ins Comsi schreiben,
aber schon mal so auch für sie,
dass sie das möglicherweise noch ein bisschen streuen,
werden zwei Kollegen von mir hier erscheinen und die werden ihnen ein Multi-Channel-System gebaut nach den Wamm-Entwurfsmetaphern vorstellen.
Das ist mit einem Webfrontend einerseits und andererseits mit einem iPad
kann man das bedienen und was die Ihnen erläutern werden,
ist, also wie die Architektur dieses Systems sie serviceorientierte Architektur dieses Systems ausschaut.
Also dass wir mal am konkreten Beispiel so das ein oder andere Thema,
was wir hier so berührt haben,
dass sie das mal so an einem größeren Beispiel,
das in der Praxis auch eingesetzt wird,
dass sie das sehen können.
Wenn sie sich das schon mal anschauen wollen,
worum es da gehen wird, das können sie unter Www.delax.de
können Sie sich die Applikation schon mal anschauen.
Also jedenfalls den Web, den Browser-basierten, das Browser-basierte Frontend.
Das steht für Deutsch-Lernen mit Gebärdenschrift. Das ist eine Methode
in der gehörlosen Pädagogik, die wir da unterstützen.
Also da lernen gehörlose deutsche Schriftsprache können.
Also das ist die Zielgruppe für dieses Projekt.
Zum heutigen Thema Projektplanung
Vieles von denen, ich hoffe jedenfalls,
dass vieles von dem, was ich jetzt erzähle,
können sie einen Bezug herstellen zu dem,
was sie so im letzten Semester im Rahmen ihrer Projektmanagement-Vorlesung gehört haben.
Insofern würde ich mich freuen,
wenn sie sich an der einen oder anderen Stelle aktiv beteiligen würden,
also in welchem Bezug das dazu hat, was sie schon kennengelernt haben.
Die Grundidee so einer, die so einen Wammler Seit ungefähr 20 Jahren,
also ich weiß nicht, ob es damals schon diese Project-Management-Eliciative gab.
Also jedenfalls gab es, hat damals noch niemand von agilen Entwicklungsmethoden gesprochen.
Die Grundidee, der WAM-Projektplanung besteht darin, dass man gegen
jemanden plant. Das ist also die Idee. Es wird
ein Projekt Ende geben. Und es wird jemanden geben,
der am Projektende sagt, das Ziel des Projektes ist erreicht
Das ist jetzt so eine Abstraktion, natürlich so eine abstrakte Formulierung.
Und das, was mir jeweils sehr hilfreich gewesen ist,
um mir was da drunter vorstellen zu können, ist Weihnachten.
Weihnachten. Heiligabend. 24. Dezember und dieser Termin steht.
Der wird nicht verlegt. Der muss da stattfinden. Der
Heilige Abend. Und meine Projektplanung für den Heiligabend ist darauf ausgerichtet,
dass ein glückliches Kind unter dem Baum sitzt und so etwas aufmacht.
Was es aufmacht, das ist die Überraschung. Das halte ich
für hinlänglich vergleichbar mit Softwareentwicklungsprojekten. Es wird ein Ende geben und dieses Ende ist mitunter hart. Es gibt einen harten Termin etwa für ein Migrationsprojekt,
also das ist halt, weil wenn Sie sich vorstellen,
so, ach, die mega hassbar haben wir,
glaube ich, schon mal erwähnt,
die haben halt mit einem 18-monatigen Vorlauf ungefähr gesagt,
es wird das Wochenende, ich sage jetzt irgendwas,
es wird das Osterwochenende 2009 oder so wird das sein,
wo wir migrieren, weil sie genau wissen,
aus ihrer Erfahrung und der Erfahrung derjenigen,
also die sie beraten bei diesem Projekt,
die eigentliche technische Migration dauert vier Tage und in diesen vier Tagen läuft gar nichts.
Und dann kann man in den Kalender schauen und gucken,
also so im Zeitraum in ungefähr 18 Monaten,
wo haben wir mal vier Tage Zeit, an denen also wenig passiert.
Und dann bieten sich, also Weihnachten bietet sich an,
Ostern bietet sich an, 3. Oktober bietet sich an.
Und dann kann man also von da aus,
also so, was die Zielvorstellung anbetrifft, also jedenfalls,
was die terminliche Zielvorstellung anbetrifft, kann man schon mal sagen,
dagegen, gegen dieses Projektende muss ich planen.
Und ich muss auch, also die beteiligten Akteure darauf einstimmen,
dass also an diesem Tag etwas passieren wird.
Was da genau passieren wird, das ist dann eben Gegenstand,
also das Projektverlaufs, aber das Ende steht fest. Also so die Idee,
nochmal anders formuliert, Ich gehe bei so einer Wam-Projektplanung,
das allererste, was ich mache, ist, also ich versuche,
das potenzielle Ende festzulegen und dann gehe ich in der Zeit nach vorne und ich versuche,
zu möglichst frühen Zeitpunkt festzustellen, ob ich mit dem,
was ich zu tun habe, um dahin zu kommen,
ob heute ist der 22. Juni.
Sobald ich feststelle, heute müsste eigentlich der 28. Februar sein,
dann weiß ich,
ich habe heute
ein Problem
Was eine gute Sache ist, weil ich weiß das,
also jetzt, wenn wir jetzt mal Weihnachten als fiktives Projektende nehmen,
ich habe jetzt noch sechs Monate Zeit, um dieses Problem,
also in irgendeiner Art und Weise anzugehen.
Ich weiß nicht erst am 23. Dezember,
es gibt keinen Baum, es gibt keine Geschenke,
Kugeln, Kerzen, alles fällt flach.
Ich weiß jetzt schon, also ich werde nicht alles hinbekommen.
So, also das so als motivierende Grundvorstellung.
Es steht hier so etwas,
so diese Zielvorstellung
Die haben wir jetzt, da haben wir ja auch,
also so lang und breit,
oder ich jedenfalls lang und breit drüber gesprochen, die Zielvorstellung,
die ich für diesen Endtermin entwickle, die umfasst hier,
also drei, mehr oder weniger voneinander unabhängige Bereiche,
also der nicht umsonst, oder nicht zufällig,
also steht dieser Bereich hier.
Als allererstes der Anwendungsbereich. Welche Aufgaben und Arten ihrer Erledigung
soll es, in welchen Arbeitsplätzen von Anwendungsexperten geben?
Da klingeln wir Ihnen ja jetzt, also da sind jetzt hoffentlich verschiedene Pavlovsche Reaktionen,
die da jetzt so bei Ihnen ausgelöst werden. Also Aufgaben,
das, was also so einen Arbeitsplatz, seinen Arbeitsplatztyp ausmacht,
sodass wir definieren können, also wer ist also von dieser Ziel,
wer hat, wer spielt in dieser Zielvorstellung, Akteurs zentriert,
welche Arbeitsplätze spielen da eigentlich eine Rolle und nicht als solche,
sondern in dem Sinne, dass man sagt,
also welche Aufgaben sind davon, betroffen.
So, hier stehen jetzt die Anwendungsexperten,
das war ja so eine Ausprägung der Wammleitbilder,
also der Arbeitsplatz für eigenverantwortliche Expertentätigkeit,
der Funktionsplatz oder der einfache Sachbearbeitungsplatz
So, und was tun die da im Rahmen ihrer Aufgabenerledigungen?
Wie werden und welche und wie werden die fachlichen Inhalte dort unterstützt beziehungsweise verändert?
So, das ist also für jedes Projekt,
also nicht für jedes, aber die Projekte,
die wir hier betrachten, so in der Mittelzweckrelation,
ein Softwareentwicklungsprojekt, ist immer ein Mittel für einen anderen Zweck.
Und dieser Zweck liegt typischerweise im Anwendungsbereich dieses Projektes.
So, der Konstruktionsbereich, das sind sie,
die Leute,
die dieses Projekt nachher realisieren
Ohne ihn jetzt zu nahe treten zu wollen. Ich würde ungerne mit,
also welchem halben Dutzend oder sieben bis zehn,
zwei, vier, sechs, acht, zehn.
Dann sagen wir mal mit ihm, mit dem Dutzend, dass Jesus sitzt.
Ich würde ungerne mit ihnen ausschließlich mit ihnen ein Entwicklungsprojekt durchführen.
So einige, also ganz unpersönlich, so zwei, drei vielleicht.
Und das mache ich nicht von dem Klausurergebnissen abhängig, sondern einfach so,
Welche Qualifikationen, welche Erfahrungswerte sind eigentlich bei Ihnen vorhanden?
Was bedeutet das für Sie, wenn Sie sehen,
wenn Sie so eine fachliche Anwendungsspezifikation haben,
ob das jetzt ein Product-Backlog ist,
wie das bei Scrum ist, ob das ein Lastenpflichtenheft ist,
wie das in der klassischen Entwicklungsmodellen ist?
Was können Sie damit anfangen? So,
und jetzt frage ich mal mit Blick auf das letzte Semester.
Was sagt denn der gute Slavoy Gigek dazu
Naja, was unterscheidet der? Falls in der ersten Fünf-Stunde
fehlen, ein Projektiv ist. Die erste am Anfang
zusammenwachsen müssen, wo dann irgendwann mal das Team funktioniert.
Nein. Ja, mit vier. Ich hoffe,
ich führe sie nicht in der Irre durch diese Hand,
durch diese drei bis fünf Finger, die ich hier zeige.
Das sollen vier sein
Bekanntes Wissen. Ach, wie geht's denn weiter? Ein
kaltes Unwissen. Und wir können uns wissen und unbekannt ist
. Ja, so, wenn man bekanntes Wissen weiß,
also dann kann man den Rest schließen.
Ja, vielen Dank. Nicht, dass ich Ihnen das jetzt unterstelle.
Sie haben es natürlich jetzt aus Ihrem Gedächtnis oder beides.
Also sind in meinem, in meinem Konstruktionsbereich überhaupt,
also die erforderlichen Qualifikationen und Aber für den einzelnen Personen und sind die in genügender Anzahl vorhanden,
um also das hier, die hier antizipierte Situation zu erreichen.
Und nicht zuletzt, also ist die Technologie,
mit der wir es, also mit der wir das so machen wollen,
so erstens beherrschen die diese Technologie und wenn sie sie beherrschen,
kann man mit dieser Technologie,
dass da adäquat erreichen
Und das sind so, ich versuche sie jetzt mal so zu orientieren,
so nach dem Motto, das ist halt,
also wenn man in so eine Projektsituation hineingerät oder so,
die glückliche Lage gerät, also so ein Entwicklungsprojekt,
also durchführen zu können, das bezieht sich ja nicht nur auf Entwicklungsprojekte,
da könnte man sie auch sagen,
das bezieht sich genauso gut auf Migrations- und Transformationsprojekte.
Kann man das mit dieser Technologie überhaupt, in dem Sinne,
in dem ich das jetzt hier gezeigt habe, ist das überhaupt durchführbar?
Wenn man sich das in diesen drei Bereichen,
also erschlossen hat mit den Methoden, die sie ja auch schon kennengelernt haben,
Dann muss man sich, also über eins klar sein,
die Zielvorstellung, die man sich erarbeitet,
wird sich im Laufe des Entwicklungsvorhaben, hier steht es ständig verändern.
So, und dann kann man sich natürlich die Frage stellen,
aber wieso soll ich das denn dann überhaupt,
also so am Projekt anfangen,
so soll ich mich da überhaupt so fixieren,
also wo es sich das sowieso ständig ändert und ich das weiß.
Was sagen denn
die agilen Entwicklungsmethoden zu dieser Frage
Oder was sagen die klassischen Entwicklungsmethoden zu dieser Frage?
Ist das überhaupt relevant? Also sie haben doch bestimmt auch Change Management.
Das ist doch bestimmt ein Teil von Project Management.
Man kann also so, wenn man in einer klassischen Entwicklungsmethode folgt,
wenn man ja sagen, ich mache jetzt einen Plan.
Dieser Plan macht Aussage, insbesondere hierüber.
Und er macht Aussagen darüber, wann das,
was hier so inhaltlich drinsteht,
wann das
realisiert sein muss
Und dann ist also über das Monitoring und das Controlling,
also mit meiner Aktivitäten, kann ich immer über das,
was mir so vom Prozedere her das Change-Management sagt,
also kann ich also meine Zielvorstellung,
so ist das sogar legitim, das zu adaptieren.
Aber es gibt eben eigene Prozesse, die dazu dienen. Versus,
oder ist aber alternativ dazu, so eine Wamm vor,
so die Idee, wie man in Wamm evolutionär,
inkrementell, iterativ über die Welt nachdenkt.
Ich muss diese Zielvorstellung haben,
weil sonst habe ich nichts,
was ich ändern kann
So. Das ist so die Grundidee, also des Plans.
Gucken auf Pläne als Gegenstände, die uns wieder ein neues Handeln ermöglichen. So,
und um so eine Projektplanung, also nach dieser Idee,
da ist das Ziel, jetzt gucken wir, wie wir da hinkommen.
Also braucht man halt ein evolutionäres Prozessmodell und das kann eben,
also insbesondere auch ein agiles Vorgehensmodell sein, ist aber nur das,
was da so bei uns eben noch dazukommt, das fehlt ja,
das Thema kritisieren, diese agilen Vorgehensmodelle ja nicht.
Das ist also so das Leitbild. Das heißt,
dazu noch eine Vorstellung entwickle, für wen,
für wen und für welche Typen von Arbeitsplätzen,
für welche Akteure entwickle ich eigentlich dieses System.
Wäre das so ein bisschen tut, oder sagen wir mal,
was man mit diesem Gedankengut, also gut interpretieren kann,
ist, also wenn die Kollegen aus dem Usability Engineering,
wenn die teilweise von sogenannten Personas sprechen,
sagt Ihnen das was
Ja, nein, vielleicht, weiß nicht. Wir waren
, war hier nicht irgend so jemand aus MCI dabei?
Sie hat sich jetzt gerade im Lehramt, aber gut,
habe ich mich vertan. Ach so, sehr süß. So,
so eine Persona, also das, was wir ihnen ja empfehlen,
ist, sprechen Sie mit ausgewählten Repräsentanten Ihrer zukünftigen Benutzer.
Und reden Sie mit denen darüber, wie die Ihre Aufgaben erledigen?
Schreiben Sie das auf in Szenarien und machen Sie Systemvisionen und dann,
wie kann die auch bei den Zukunft erledigt werden?
Also wie können die Aufgaben in Zukunft erledigt werden.
Sonst gibt es aber Projektsituationen, in denen hat man diesen keinen direkten Zugang.
Also zu diesem Gegenüber, gegen den man jetzt also eine Systemvision zum Beispiel erstellen kann.
Und was tut man dann, ist, man erfindet eine Person,
die man, also man erfindet sich selbst,
um gegen diese fiktive Person, also Szenarien und Systemvisionen zu entwickeln.
Wenn ich kein Gegenüber habe, dann ist die Idee,
ich mache mir dann ein Gegenüber, so wie ich,
also jetzt gerade mit dem Projektplan argumentiert habe,
damit ich mein Handeln überhaupt also gegenüber einem dritten argumentieren kann und sollte sich dann herausstellen,
dass ich falsche oder nicht zutreffende Annahmen gemacht habe,
dann ändere ich halt die Annahmen,
aber zunächst mal habe ich die explizit gemacht und nicht,
also gegen einen Nebel implementiert.
Also das ist so die, das hängt dann eben unmittelbar,
also mit so der Frage des Leitbilds zusammen,
wen sehe ich da als Person,
der jetzt also zukünftig
mein Softwaresystem bedienen wird
Aber diese Annahmen, da kann ich dann eben mit jemandem
drüber reden, Fragen sagen, also sind diese Annahmen gerechtfertigt.
Das also, so was der Wammler,
so als Voraussetzung für so eine Projektplanung braucht.
Für die drei Bereiche, insbesondere in Anwendungsbereich,
ich auf der letzten Folie besprochen habe. Die Grundkonzepte,
die dazugehören, also Zielsetzung habe ich diskutiert,
die sei dann mal festgelegt und diese Zielsetzung ist halt das,
was ich am Ende des Projektes
erreichen will
Planung, so die Grundidee habe ich schon genannt,
aber so, denke ich, kann man das dann,
also kann man das auch gut merken, gut merken,
die Grobplanung von hinten nach vorne.
Das ist also so ein Standard, ein Standardmerksatz,
Planung, Grobplanung immer von hinten nach vorne.
Das heißt, vom Projektende zum Projektanfang planen.
Das Projektende ist der 24. Dezember und ich muss also
am 30. November muss ich ein bestimmtes Etappenziel erreicht haben,
um mein Projektziel am 24. Dezember erreicht zu haben
Um zu dem Etappenziel am 30. November zu kommen,
muss ich am 31. Oktober ein davorliegendes Etappenziel erreicht haben.
Und dieses Gedankengut ist jetzt also schon sehr viel älter,
als also die entsprechenden, ich habe das schon mehrfach gesagt,
als jetzt die heute gängigen agilen Entwicklungsmethoden,
aber das lässt sich total gut, also mit so einer Vorgehens,
wie zu einem Vorgehensmodell wie Scrum,
lässt sich das realisieren.
Weil was sagt denn der Sprint,
wie lang ist der typischerweise oder was sagen die Scrum-Leute
Mann, würde ich ungern mit Ihnen ein Entwicklungsprojekt bauen.
Wie lang ist denn ein Sprint? Sechs Wochen? Was
ist denn ein Sprint? Einen Anfang bis zu einem,
zweit noch im Jahr, bis zu eins.
Bis zur nächsten Auslieferung. 30 Tage, sagt man
so.
Ja, eben
30 Tage, es ist grob geschätzt, vier bis sechs Wochen.
Ich hatte jetzt gesagt, so vier bis fünf Wochen,
aber ja, sowas. Da sind die auch nicht,
also jedenfalls nicht soweit ich weiß, also besonders rigide,
aber das ist eben so im Monatstakten so etwas auszuliefern,
ist halt, scheint eine gute Idee zu sein,
weil da ist so ein Planungshorizont ist, den so unser Eins.
Also ganz gut überschauen kann. So,
also so eine Grobplanung von hinten nach vorne und dann die einzelnen,
also hier steht schon, Projektetappen,
Die einzelnen Projektetappen dann von vorne nach hinten. Das heißt also,
wenn ich einmal so die einzelnen Etappen für ein Projekt festgelegt habe,
dann kann ich die Tragfähigkeit dieser Etappenplanung,
kann ich ja dahingehend so verproben, in Anführungsstrichen,
dass ich die gerade vor mir liegende Etappe von vorne nach hinten plane.
Das steht da jetzt nicht auf der Folie,
aber das hier ist etwas, die Grobplanung,
die kann ich,
die kann ich nicht nur,
die muss ich für das gesamte Projekt machen
Sonst weiß ich ja nicht, also bin ich also überhaupt,
also mit meinem Projekt, also auch nur annähernd,
also in dem Bereich, dass es also realistisch erscheint,
es so durchzuführen, die Feinplanung,
die mache ich immer nur für die vor mir liegende Etappe von vorne nach hinten.
Also wenn ich jetzt, also was mache ich denn?
Die Geschenke kaufen, also die nächste,
dass die November-Etappe ist, dann plane ich die halt,
also im Detail jetzt für den November.
Was ich noch nicht tun werde,
ist also die Dezember-Etappe,
nämlich so Gänsebraten
Machen oder so. Das werde ich also im November
noch nicht in der Feindplanung von Folgen nach hinten.
Da werde ich das noch nicht machen. Ich weiß,
ich bin im Gottvertrauen, dass ich das hinbekomme,
aber Feindplanung ist dann eben etwas, das mache ich jeweils zu Etappenbeginn.
Referenzlinien ist, was das ist, werde ich noch kurz darauf eingehen.
So Fragen, die immer, das sind jetzt bezüglich der
Zielsetzung eigentlich nur noch mal so ein paar detaillierende Fragen.
Das ist oftmals überraschend, wie unausgesprochen,
beziehungsweise wie unterschiedlich eigentlich die Ziele sein können,
die mit der Durchführung, also gerade von E-Type-Projects sind.
Was sagt Ihnen denn die lehmannische Unterteilung in SP und E-Programme
eigentlich? Ich war so ein bisschen in Hoffnung,
dass Heribisch Ihnen das nahe bringen würde.
Sonst muss ich das noch an irgendeiner Stelle,
wahrscheinlich nächste Woche
Nochmal. Das ist, also Lehmann unterscheidet diese drei Typen
von Programmen. Essprogramme sind Spezifikationsprogramme. Programme, bei denen
man beweisen kann, dass die Implementation einer Spezifikation entspricht.
Und wo also die Herstellung des Programms insbesondere auch
keine Rückwirkung auf die Spezifikation des Programms hat.
Sagen wir mal sowas wie eine Zinsberechnung oder sowas.
Das kann man spezifizieren
Implementiert man das, kann man die Korrektheit beweisen und die
Zinsberechnung ist, damit kann man einen Haken dran machen.
Das lässt sich also mit formalen Methoden,
lässt sich das, lassen sich solche,
dieser Typ vom Programm lässt sich damit ganz gut bearbeiten.
Das gehört nicht, also dieser Typ von Programm ist nicht typischerweise das,
womit sie im Berufsalt, also eine Ecke komplizierter,
komplexer sind P-Programme, Spielprogramme, Play steht das.
Nehmen Sie mal ein Schachspiel, da können Sie, also Schachspielprogramm.
Können Sie zwar beweisen, dass dieses Programm keine falschen Züge macht,
was Sie aber nicht mehr beweisen können, ist,
jedenfalls nicht mit formalen Methoden, ist das ein gutes Schachprogramm.
Das können Sie nur durch menschliche Beurteilungen. Du kannst nicht sagen,
ja, das schlägt mich immer,
dann ist es wohl ein gutes Programm oder umgekehrt,
so scheint ein schlechtes Schachprogramm zu sein.
Also hier kommt schon menschliche Einschätzung dazu. Also ganz besonders,
das E steht nicht für eklig, sondern für Imbedded.
Es ist aber die ekligste Kategorie von von Programm,
weil schon die Definition des Problems verändert das Problem.
Und die Bearbeitung des Problems hat jeweils Rückwirkungen auf die Wahrnehmung des Problems.
Das sind alle Programme, die in menschliches Arbeitshandeln eingebettet sind.
So. Und das ist also, ist ein Problem,
das lässt sich mit formalen Methoden, lässt sich das überhaupt nicht mehr,
lässt sich das überhaupt nicht mehr angehen.
Hier, und wir können das überhaupt mit informatischen Methoden,
können wir das nicht so lösen,
dieses Problem
Will. Das Einzige, was wir tun können, ist,
dass wir den beteiligten Akteuren sagen, es gibt hier unterschiedliche Interessen.
Und wir als Softwareentwickler brauchen, leisten einen Beitrag dazu,
dass dieses Projekt ein glasklaren oder einen Auftrag bekommt,
der so glasklar formuliert ist wie möglich, damit nicht passiert,
dass anhand eines ausgelieferten Softwareentwicklungsprojektes die Leute erkennen,
wir haben hier ein Problem und denken,
dass das Softwareprojekt des Problems, wo es in Wirklichkeit,
in Anführungsstrichen, aufgrund von unterschiedlichen Zeitvorstellungen aufgrund von unterschiedlichen Interessen,
die mit einem Entwicklungsprojekt verbunden sind,
ist ein viel tiefer liegendes Problem.
Also mit, dass jetzt gegenwärtig wird, also dadurch,
dass man ein Stück Software entwickelt hat.
Ach, das ist herrlich, was alles schief gehen kann,
während eines Entwicklungsprojektes. So, Zielsetzung. Also sowas,
so explizit machen wie möglich, ich meine,
das ist ja schön, dass hier ein Gewinn von einer
Million,
was auch immer
Erwirtschaftet wird, ob man das jetzt durch,
also Wachstum macht oder durch Kostensenkung ist,
naja, es ist hier erstmal so nicht formuliert.
Also wenn man das so etwas unter,
wie hier steht, unter Planungsgesichtspunkten, wird man versuchen,
dass also etwas detaillierter zu machen.
Und das ist eben die Voraussetzung, um,
also dieses so eine definierte Zielsetzung, um zu einem Plan
kommen.
Also Kernprozesse des Arbeitsplatzsystems sollen unterstützt werden
Es soll, Achtung, Konstruktionsbereich, das soll in-house gemacht werden,
das soll nicht an irgendwieem einen externen vergeben werden.
Es sei denn, man könnte auch so etwas auf dem Markt einkaufen.
Und das ist im Übrigen auch noch ein Trend,
also mit dem sie noch viel stärker konfrontiert werden,
als also ich in dem Alter,
als ich in dem Alter war, in dem sie jetzt sind,
Individualentwicklung ist stark rückläufig.
Kann sie
sich vorstellen, warum
Warum wollen die Leute keine maßgeschneiderten Softwarelösungen mehr haben?
Wenn es teuer ist, ja, ja, ja.
Man soll irgendwie dazu was inklusiv supporten, weil man
nie überweist dann, dass es nicht zu sagen ist.
Definitiver Aufwand. Manu, falls alle das alles selber abdrücken.
Wenn sie eine Standard-Software kaufen, sind sie von
der Firma abhängig
Günstig liegt ja auch im Auge des Betrachters.
Es gibt ja auch Leute, die behaupten,
das ist also sogenannte Standardsoftware, auch ganz schön teuer werden kann.
Das ist ein Standard, ja. Stunde Software ist schon fertig.
Das ist für das Risiko, was man da so bedenkt.
Das ist eigentlich das Hauptargument, das sich,
also regelmäßig höre. Das Risiko ist total scheiterns,
ist bei Individuallösungen,
ist immer dabei
Ja, weil es ist halt, man weiß halt,
also deswegen machen wir ja hier,
so versuche ich ja jetzt hier so viel über Zielsetzung und Erreichbarkeit,
Anwendungsbereich, Konstruktionsbereich, Technologiebereich, mit Ihnen zu sprechen,
um das Risiko des Scheiterns bei Individualentwicklung zu minimieren.
Weil da können Sie ja dann auch also Statistiken rauf und runter zitieren,
60 Prozent, 80 Prozent aller Entwicklungsprojekte erreichen nicht das Ziel,
für das Sie mal gestartet worden sind.
Und das sind niederschmetternde Zahlen
Gut, jetzt muss man die Statistiken, kann man also auch beliebig hinterfragen,
aber da ist einfach so ein Eindruck entstanden und der kann nicht ganz falsch sein,
dass also die Softwareentwicklungsprojekte nicht so funktionieren,
wie sich das die Auftraggeber dieser Projekte,
wie die sich das ursprünglich vorgestellt haben.
Und deswegen, also so unter Planungsgesichtspunkten, so diese Zielsetzung,
also jeweils also zu konkretisieren oder also dingfest zu machen,
um das, was man tut,
in dem Entwicklungsprojekt gegenüber den Entscheidungsträgern transparent zu machen.
Und das ist das A und O. Zu diesem Zweck wird
dieses ganze Instrumentarium ja jetzt auch aufgebaut oder hier ausgerollt.
Was sind denn also so Projektetappen,
wenn man diese Zielsetzung mit Blick auf die Projektplanung konkretisiert hat,
dann sind wir so weit, dass wir so diese Projektetappen,
die dann im Sinne von Meilensteinen für so ein Projekt definiert werden,
Aber was sind das?
Also wesentliche Ereignisse, weil da finden Abnahmen statt oder Go
, No-Go-Entscheidungen werden da getroffen. Zeitpunkte werden definiert, Projektteilziele
erreicht werden. Jetzt können Sie ja schon immer auch dieses
ganze Scrum-Instrumentarium-Sprints, Product-Backlog, können Sie jetzt mitdenken.
Die Projektetetappen werden immer mit Blick auf das Gesamtziel festgelegt,
also jede Projektetappe, ja einen Beitrag zum Erreichen dieses Gesamtziels
leisten muss
So. Und wenn man so eine Projektetappe dann erreicht hat,
ja, dann sind wir wieder, also so in diesem Management-Zyklus,
Revisionen der gegebenenfalls Revisionen der Projektplanung.
Das ist ein ständiger Wellenritt, der da stattfindet. So in so einem Softwareentwicklungsprojekt,
wenn es darum geht, also die,
das Termintreue eine Rolle spielt und es gibt also kein mir bekanntes Projekt,
also das von sich behaupten würde, wir machen das jetzt so lange, wie es dauert.
Und wenn wir fertig sind, sind wir fertig.
Das ist eher unüblich, um es mal milde auszudrücken.
Also gerade wenn es um Projekte geht, die also eine gewisse Größe haben.
Also das habe ich ehrlich gesagt so auch noch nie,
noch nie erlebt. So, und jetzt sehen Sie hier
mal so einen, so eine Grobplanung. So,
da wollen wir hin und dann müssen wir schauen,
wie wir diese Projektetappen, also die sind,
wir sehen vier bis sechs Wochen,
ist das hier so angelegt
Welche Ziele werden mit den einzelnen Projektetappen verbunden?
Und wie können diese Ziele erreicht werden? So,
und jetzt werde ich gemein, ich habe doch letztes Semester
auch eine Vorlesung über Prototypen gehalten, oder?
Von Prototyping. Was sind denn das da für Prototypen?
Und welche Arten von Prototyping werden angewendet, um diese Prototypen herzustellen.
Jetzt sagen Sie nicht, das ist so lange her.
Ich weiß genau, wie lange das her ist.
Also ungefähr neun Monate. Ach Quatsch, acht,
sieben. Ja, eben, noch weniger.
Das war auch im Winter, oder? Ja, eben
, sowas. Und jetzt ist Juni, also sechs bis
sieben Monate
Was ist das denn hier? Wird der weiterentwickelt oder schmeißt
man den weg? Ja. Wie bitte? Den kann
man wegschmeißen, ja. Also Wegschmeißen im Sinne von,
da wird kein Code implementiert, der es wert wäre,
ihn so für spätere Verwendung in Betracht zu ziehen.
Was soll man damit? Man will die Handhabung demonstrieren. Man will von Leuten,
die damit nachher in der täglichen Arbeit nichts zu tun haben,
sagen, so ungefähr wird das aussehen,
das ist das, was man damit tun kann,
das können eure Leute damit tun und dann kann man das,
wenn man mit PowerPoint gut umgehen kann,
dann kann man das mit PowerPoint bauen.
Kann man so tun, als würde man jetzt da drauf
klicken und dann passiert irgendwas und es erweckt den Eindruck,
als wäre da Funktionalität hinter.
Dabei hat man einfach nur geschickt, eine Folie überblendet.
Echt clever. So, die Dokumenttypen hier,
die haben sie alle schon kennengelernt, Szenarios, Aufgabenbeschreibung im Ist,
mit welchen Begriffen wird da umgegangen in den Szenarios?
Visionen, was ist das,
also wie sollen die Aufgaben in der Zukunft erledigt werden?
Möglicherweise gibt es dazu noch so ergänzende Geschäftsprozessmodelle. So,
dann haben wir also, wir wissen jetzt,
in dieser Etappe, okay, im Großen und Ganzen,
was wir tun wollen, Laborprototyp,
was das?
Also vielleicht noch,
welche Art von Prototyping
wird hier durchgeführt
Die Fleutschen 3 Es. Welches E versuche ich gerade aus Ihnen
herauszuschütteln? Schüttel, Schüttel, Schüttel, Exploratives Prototyping.
Wenn die Aufgabenstellung noch unklar ist, dann bauen wir ein
Demo-Prototypen und das findet im Rahmen des explorativen Prototyping statt.
Explorativ. Den Labor-Prototyp im Rahmen welcher Art von Prototyping
baue ich den
Wie bitte? Ja, es war ein netter Versuch.
Es fängt mit E an, ja, experimentell,
experimentelles Prototyping. So. In welchem Umfang werde ich das,
was ich hier baue, später wiederverwenden können, weiterverwenden können?
Viel wenig Ich denke eher wenig, als das kann man
da und seine Implementierung gerade testen, oder?
Aha. Also ich würde mich ja,
ich würde mich ja schwarz ärgern,
wenn also mein Laborprototyp es schafft, sich mit dem,
also den ich auf einem Klienten implementiere, der schafft es,
sich in effizient mit einem Hostrechner und der darauf liegenden relationalen Datenbank zu verbinden
Und er kann also meinetwegen so lang. Was kann er denn irgendetwas,
was der hier versprochen hat, kann der so in ein Zeitfenster,
in einem definierten Zeitfenster von der relationalen Datenbank abholen,
wenn ich den wegschmeißen sollte.
Irgendwie irgendeinen dahergelaufenen Student sagen, auf der SSE,
an der Uni Hamburg, was haben Sie da gebaut, ein Experimentalprototyp wegschmeißen?
Schauen Sie hier auf die Folie. Das steht da nicht,
nee. Also Experimentalprototypen, wenn das Experiment gelungen ist,
hey, Nun ist es gelungen, dann nehmen wir das.
Ansonsten haben wir ein echtes Problem, also mit unserem Teilziel,
mit unserer Architektur möglicherweise. Wenn wir also nicht uns,
wir haben hier, haben wir versprochen, so,
hier haben wir versprochen mit Blick auf das, das klappt schon.
Wir können also so von der Ausgangssituation,
das steht hier natürlich alles nicht drauf,
die Ausgangssituation in diesem Projekt war eine richtige Host-Applikation mit
diesen 24x80 grün
auf Schwarz-Terminals
Was wir gesagt haben, ist, wir können das hinbekommen,
dass die Leute draußen, die kriegen jetzt richtig schöne PCs und dann können die mit der Maus und alles so.
Das war die Idee. Aber um das erreichen zu können,
muss halt, wir müssen diese PCs,
die müssen wir damit verbinden können, weil es war völlig klar,
wir legen nicht also auf die einzelnen PCs oder auf irgendwelche Server,
die noch vor, also der vor dem Haus sind,
also da legen wir nicht, also die zentralen Kundendaten ab und Kontendaten,
das ist echt Quatsch.
Also müssen wir beweisen, dass das geht.
Und wenn es geht und nur unter der Voraussetzung ist,
also der ist die Architektur bereit, Entschuldigung,
ist also die zentrale Entwicklung bereit, also diese Architektur abzunehmen.
Das muss man denen wirklich hart beweisen, würde ich sagen.
Sonst bleibt alles, wie es ist. Kommt nichts, kommt uns nicht.
So. Exploratives Prototyping, experimentelles Prototyping und jetzt geht los.
Welche Art, jetzt wissen wir, was wir bauen wollen,
wir wissen, wie wir es bauen wollen.
Jetzt kann man in Zyklen Was tun,
welche Art von Prototyping fehlt noch?
Evaluativ ist ganz nah dran, jedenfalls von den Buchstaben.
Was höre ich? Evolutionär. So,
jetzt sind nämlich die, wir sind jetzt direkt am Arbeitsplatz
Alles klar. Wir sind jetzt direkt am Arbeitsplatz und jetzt können wir eigentlich,
also so mit dem echten Projekt beginnen,
weil bis dahin haben wir also, ja,
es ist wichtig, dass die uns das erlauben.
Ja, es ist wichtig, dass die gesagt haben,
na gut, das könnte technisch klappen.
Und jetzt sind wir auf einmal an den Arbeitsplätzen.
Und jetzt geht der eigentliche evolutionäre Prototyping-Betrieb los. Wir entwickeln
ein Kernsystem mit Ausbaustufen. Kernsystem, Aufgaben so definiert,
dass man schon mal eine Aufgabe, also Aufgaben so realisiert,
dass man schon mal eine Aufgabe in einem Sitz mit dem Neuesystem entwickeln kann,
sodass also Handlungssicherheit für die Mitarbeiter hier existieren.
Was kann ich mit dem neuen System schon tun und
was sollte ich besser noch nicht tun?
Woran sollte ich am besten noch nicht mal denken?
Wenn man so weit ist, ist jetzt hier das nächste Teil zieht.
Und eine Machbarkeitsstudie ist dann also durchgeführt worden und wir können,
also mit unserem Projektplan weitergehen. Für jeden, sodass,
wenn man die Endtermine für die Projektetappen eben schon im Vorfeld so festgelegt hat,
können wir auch bei jeder Projektetappe steigt unsere hoffentlich jedenfalls unsere Sicherheit,
dass wir das zu dem Datum, was wir festgelegt hatten,
dass dann auch das Projektziel insgesamt erreicht werden kann.
Und es ist eben so mit der von hinten nach vorne
und hier jeweils in diesen vier bis sechs Wochen,
das sind,
glaube ich,
mehr als sechs Wochen,
Also das ist irgendwie, tja,
da sehen Sie mal ganz unscrummig, das wird hier vorgegangen,
möglicherweise gab es hier noch irgendwelche Teiletappen drin,
aber ich denke, die Grundidee ist damit auch klar.
So, und jetzt versuchen wir das
noch mal mit dem Gedankengut agiler Entwicklungsmethoden zusammenzubringen.
Ja, ja, leichtgewichtig, bla bla bla bla,
So, ich meine, da sind wir ja mit dem evolutionären Prototyping,
sind wir ja wirklich so einer Meinung. First things first,
so schnell wie möglich Geschäftswert, also in unserer,
so in der Wam-Terminologie, so schnell wie möglich,
die Benutzer in die Lage versetzen, Aufgaben zu erledigen.
Und das entspricht also dann eben auch einem hohen Geschäfts,
einem hohen Geschäftswert. Das, was man aber durchaus so,
nein, nicht zugeben muss,
das ist ja auch eine blöde Formulierung,
Welche Rolle spielt das denn hier eigentlich in Scrum?
Und das ist ja jetzt mehr so die Abstraktion von vielen agilen Entwicklungsmethoden.
Was soll das? Prozess steht regelmäßig zur Diskussion.
Was macht man da? Ja? So was
wie ein Stand-Up-Meeting zum Beispiel
Ich kriege das auf. Ich dachte, sie beenden den Satz
jetzt anders. Dass man sich gegenseitig anschreit. Nee,
das Stand-Up-Meeting, das findet ja jeden Tag statt.
So, typischerweise irgendwas kurz vorm Mittagessen, Viertelstunde.
Was ist passiert? Das ist ja, was wollen wir
jetzt demnächst machen? Was hat euch daran,
also wie weit seid ihr mit dem,
was wir uns seit gestern vorgenommen haben?
Das ist ja die Idee des Stand-Up-Meetings. Dass hier ihr,
das ist noch,
das spielt noch auf was anderes an.
Musik Nächster Versuch. Wie ist die Internation zu planen?
Nee. Das machen ja, also das ist die Iterationsplanung ist ein eigener Schritt,
genauso wie das da. Es ist also in den meisten,
Eigentlich glaube ich sogar, jedenfalls in den gängigen,
agilen Entwicklungsmethoden, wird explizit vorgesehen, dass man sich einen Tag,
also eine Zeiteinheit, einen halben Tag, einen Tag,
irgendwas in der Richtung, wenn, sagen wir mal,
so ein Sprint 30 Tage umfasst.
Wir nehmen uns die Zeit, um darüber zu sprechen,
was lief in der letzten Iteration gut und was lief nicht
so gut.
In der Kooperation zwischen uns
Damit wir in der nächsten Iteration, also wir wissen zwar,
wir machen jeden Fehler, aber wir machen den möglichst nur einmal.
Wir wollen vor allem den Prozess,
in dem wir zusammenarbeiten, diesen Prozess wollen wir verbessern.
Das ist eben unabhängig von dem, was man so im täglichen Meeting macht.
Man könnte zum Beispiel thematisieren, das Stand-up-Meeting hat sich irgendwie zu einer Quasselbude
Es ist degeneriert. Jeder erzählt zwar was,
aber dass wir danach, also schlauer sind über was,
also nicht klappt und was gut geklappt hat,
also bei der Erreichung unseres Ziels, das findet nicht mehr statt.
So, also auf einer Metaebene diskutieren,
wie können wir den Prozess mit Blick auf das,
was wir noch vor uns haben, wie können wir diesen Prozess verbessern.
Und das ist also so eine Art, das finde ich,
das ist eine echt hübsche Erweiterung zu dem,
also wie wir ursprünglich so über evolutionär, iterativ, inkrementell nachgedacht haben.
Also, dass diese Metaebene explizit in das Projekt eingebaut wird,
um die Art und Weise zu verbessern, wie wir zusammenarbeiten können.
Das ist eine echte Bereicherung. Ja, ja.
So soll es sein. Das haben Sie dann bestimmt alles
schon gelesen, oder? Was? Mal Hand hoch.
Wer kennt das? Jetzt bin ich
aber überrascht
Na gut, dass ich es mitgebracht habe. Das,
da ist so eins der berühmteren,
das können Sie denn bitte mal googeln.
Das ist so eins der berühmteren Schriftstücke der agilen Softwareentwicklung.
Und im Hintergrund sehen Sie ein Foto des offensichtlich nicht mit Photoshop retuschiert wurde.
Sie sehen kein Foto. Okay. Also ich sehe ein
Foto und wenn Sie sich das im Internet anschauen,
dann wissen Sie,
wovon ich spreche
Diejenigen, also sehen, wenn sie mal hier so schauen,
also back, coburn, conningham, fauler, Martin, kennt Schwaber.
Also Schwergewichte der agilen Softwareentwicklung, fast jeder eine eigene Methode.
Also so schlimm ist es auch nicht.
Diese Herren haben sich dann, sind alles Herren, oder?
Tja. Diese Herren haben sich also zusammengetan,
um also das Manifest für agile Softwareentwicklung
Nicht in Stein zu meißeln, sondern es in die Welt zu pusten.
Und das Manifest ist ja schon ein ziemlich starker Begriff.
Und das ist aber auch so gemeint.
Das hier sind halt so die wesentlichen Werte und Ziele,
die durch dieses Manifest niedergeschrieben wurden. Also das,
was auf der linken Seite ist, ist wichtiger als das,
was auf der rechten Seite ist,
ohne dass man das,
was auf der rechten Seite steht,
völlig vernachlässigen will
Also es ist uns für uns wichtiger,
dass wir die Individuen und die Art und Weise,
wie die miteinander interagieren, im Griff behalten,
als dass wir Prozesse, Geschäftsprozesse und realisierende Werkzeuge in den Vordergrund stellen.
Das ist leider Gottes, ist das ein häufig beobachtbares Phänomen,
das also Organisationen, in denen etwas,
also nicht reibungslos läuft nach Wahrnehmung von Leuten,
die das zu entscheiden haben, die dann sagen,
wir führen jetzt mal ein großes Werkzeug ein.
Ich habe meine, Ich habe meine, meinetwegen meine Versionsverwaltung
nicht unter Kontrolle und dann wird ein sehr teures Versionsverwaltungswerkzeug eingekauft.
Das ist, ich will nicht sagen, dass es gang
und gäbe ist, aber es ist sicherlich nicht untypisch.
Statt also sich zu überlegen, auch die Überlegung einzustellen,
müssen wir in den Projekten,
also in denen offensichtlich die Version nicht richtig verwaltet werden von den Software zu entwickeln,
den Softwaresystemen, was führt dazu, dass dieser Umstand eingetreten ist?
Das hat es möglicherweise mit der Qualifikation oder der Art und Weise
, wie die Projekte organisiert sind,
zu tun
Das ist eher so die Herangehensweise, wie sie ihnen agieren,
Softwareentwicklung, also erst das Letztere,
wie sie ihnen agieren, Softwareprojekten, gepredigt wird.
Das Wasserfallartige, wir müssen also viel dokumentieren versus Working Software.
Was, also so wie das da steht,
so heißt es ja nicht, dass wir nicht dokumentieren.
Was, also viele von ihnen, so ein
klein wenig überinterpretieren
Guter Code dokumentiert sich selbst. Das ist damit nicht gemeint. Das heißt nur,
bevor man anfängt, solche Dokumente zu schreiben,
sollte man erstmal Code haben, der so zeigt,
also das, was wir hier getan haben,
ist gut und richtig.
Und den sollte man dann dokumentieren, nicht nur den Code,
sondern weiß man, in welchem Verhältnis,
die hoffentlich gut funktionierende Working-Software,
in welchem Verhältnis
die zur Dokumentation steht
Also wenn das rennt bei uns Ihnen ja jetzt offene Türen ein,
die Art, wie wir mit unseren Kunden umgehen,
ist also, ist für uns wichtiger als das Verhandeln von Verträgen.
Das macht man genau so lange,
bis man mal von den gegnerischen Anwälten vernichtet worden ist.
Also beides. Es ist beides wichtig, aber es stimmt
schon. Erst, wenn man erst mal Rechtsanwälte anfängt,
das sollte sich mal wieder die Kamera ausschalten lassen,
aber die Vertragsverhandlungen, über was wollen wir bauen?
Also wenn die so von Rechtsanwälten im Wesentlichen bestimmt werden.
Hui, das kann zäh, das kann zäh werden. Nicht,
dass das nicht seine Berechtigung hätte, aber dass sie auf der Ebene,
kann man sich erstmal leichter verständigen, was man will.
Und dann kann man viel Detailarbeit, die notwendig ist,
auch, also mit rechtskundigem Sachbeistand erledigen.
So, und das ist so, damit bin ich
ja jetzt schon fast am Anfang der Vorlesung wieder.
Responding to change, also der Plan,
wir haben einen Plan und der ändert sich,
also das ist wichtiger,
als also den Plan selbst
zu verfolgen
Ja. Und noch schlimmer ist es ja,
den Plan zu verfolgen, wieder besseres Wissen.
Also nach dem Motto, ich hatte am Anfang einen Plan
für das Projekt und ich wusste, was ich bauen wollte.
Ich weiß, es ist mittlerweile besser,
was ich bauen sollte, kann es aber nicht tun,
weil der Plan es nicht zulässt.
Das kann, also zu Depressionen führen oder anderen Ereignissen,
die sie nicht haben wollen.
So,
dann, jetzt komme ich nochmal
So, und das hiermit möchte ich dann auch schon so langsam schließen. Also sie selber,
für sie ist es ja, das ist das,
was hier steht, also es sind ja so viele Sachen,
die für sie schon selbstverständlich sind,
aber es ist im betrieblichen Alltag, also gibt es immer noch,
also viele Organisationen, die sozusagen per Programming,
das so zwei Leute für eine Tastatur,
das kommt mir nicht ins Haus.
Das kann ich auch an vielen Stellen, kann ich das auch nachvollziehen.
Das braucht es auch dann einfach nicht. Das sind zwei Leute,
da sitzt sitzen hat, also meinetwegen jetzt zunächst mal ein paar Routine-Programmieraufgaben zu lösen.
Aber in dem Moment, also wo man weiß,
also man ist hier gerade an einem kritischen Stück oder man ist sich nicht ganz sicher,
sollte man das per Programming einfach aus seiner Methoden-Schubladenkiste holen können und sagen,
könntest du das machen wir jetzt?
Ich setze mich jetzt hier in den Driver-Seat,
du bist mein Co-Pilot und jetzt machen wir das mal zusammen.
Das ist schon so okay. Das ist also die Art von Rückkopplung auf Sekundenebene. Unit-Tests,
das beherrschen Sie auch, so die Art,
wie sich also Paro miteinander austauschen, Stand-Up-Meeting wurde genannt,
Acceptance-Test, das Testen Also nicht mehr etwas ist,
also was man am Ende eines Entwicklungsprojektes macht,
so wie das so in klassischen Entwicklungsmethoden vorgesehen ist,
sondern dass man das, also Teil einer jeweiligen,
dass das Teil jeweils einer Iteration ist.
Das ist schon, also auch so auf der Seite der Benutzung getestet wird.
Das ist, also allen agilen Methoden gleich. So,
der Release-Plan, also das, was so unser Etappenplan ist,
dass das so auf der Ebene von Monaten sein kann.
Gut, das sind also, wie gesagt,
es sind in den unterschiedlichen Ausprägungen haben es
alle agilen Methoden
Juhu. So, damit will ich es eigentlich erstmal für heute
bei sich bewenden lassen. Wir haben noch ein paar Folien über,
aber ich traue ihnen zu, sich das selbst zu erschließen.
Ich wünsche Ihnen ein schönes Wochenende,
falls Sie nächste Woche auf einem Festival sind,
wünsche ich Ihnen auch dort
viel Spaß.
Ansonsten nächste