wird etwas über Softwareprojekte und Prozesse euch heute erzählen und mir
ist eben mit Schrecken aufgefallen, dass ich heute keinen Comic dabei habe.
Ich bitte mich bitte um Entschuldigung nächste Woche,
gibt es wieder einen Comic-Comic hier von Geek in Poke.
Aber ihr könnt ja selber mal da gucken. Da sind
immer schöne Sachen. Gut. Ich will mit euch heute
über Softwareprojekte reden und zwar will ich euch so einen Eindruck davon geben,
was in solchen, in Softwareprojekten eigentlich alles passieren kann.
Ich habe ja die ganzen Wochen immer schon ein bisschen euch
hin und wieder Geschichten erzählt und jetzt wollen wir das mal
ein bisschen zusammenfassen und in eine Struktur bringen,
sodass ihr Einerseits ein bisschen eine Ahnung habt,
was euch in Softwareprojekten erwartet und andererseits vielleicht auch eure eigenen Erfahrungen ein bisschen einsortieren könnt.
Denn viele von euch haben ja in ihrem Leben auch schon mal Software entwickelt oder programmiert. Ja,
also die Software ist ja,
Softwareentwicklung ist eine junge Disziplin und man hat immer wieder versucht,
aus anderen Disziplinen irgendwelche Ideen zu übernehmen und ihr wisst das ja selbst,
dass wir bei Software uns sehr an Häuserbau oder Architektur oder sowas orientieren,
um etwas darüber zu sagen,
wie so
ein Projekt ablaufen sollte
Aber man muss sich immer wieder klarmachen,
dass dieser Vergleich nicht, vielleicht nicht so besonders tragfähig ist,
weil Software doch ganz schön anders ist als Häuser oder Brücken oder Autos.
Also ich erlebe in Projekten immer wieder, dass jemand zu mir sagt,
ja, aber wenn ich mir ein neues Auto bestelle,
dann wird mir das auch nach drei Wochen oder nach einem
halben Jahr fertig vor die Tür gestellt und dann funktioniert das.
Und genauso will ich das auch von der Software.
Das geht natürlich nicht. Das geht aus verschiedensten Gründen nicht.
Einer davon ist aus meiner Sicht, dass Software extrem komplex ist.
Ein anderer steht hier noch nicht drauf,
aber auf den werden wir gleich noch kommen
Die meiste Software, die heute noch entwickelt ist,
wird es eben kein Standardprodukt, was schon lange entwickelt worden ist.
Also ich meine, als VW die ersten Autos gebaut habe,
war das auch nicht so, dass man die bestellen konnte.
Und nach zwei Wochen waren die da. Sondern man bekam vielleicht irgendetwas,
ein Prototyp und musste den ausprobieren und blieb dauernd liegen und kam nicht voran.
Also Softwareentwicklung befindet sich eigentlich in dem Zeitalter der Entwicklung,
wo die ersten Autos gebaut wurden. Gut,
ihr wisst selbst, dass man mit Software alles Mögliche machen kann,
wenn man bei einem Auto die Reifen an bestimmten Punkten angebracht hat,
dann kann man das nicht mehr so leicht ändern,
weil da die Achsen sind und weil da das Blech die Öffnungen hat für die Räder.
Bei Software ist das ganz anders. Ihr wisst selbst,
dass das ein beliebig verformbarer, änderbarer Baustoff ist.
Und wenn ihr mal eine größere Software entwickelt habt oder damit irgendwie in Kontakt gekommen habt,
dann werdet ihr auch die Schwierigkeiten festgestellt haben,
die dadurch entstehen, wenn man zum Beispiel zwei Systeme,
bin ich eigentlich zu laut für euch oder ist es gut?
Nee, bei mir kommen wir ja total laut vor. Okay,
also wenn man zwei Softwaresysteme parallel entwickelt, die gemeinsam eine Schnittstelle haben,
ist das meistens der scheußlichste Punkt in der ganzen Architektur,
weil diese Schnittstelle muss relativ fix für beide Seiten sein.
Also dieses, dass ich Software beliebig verformen kann, das endet an solchen Stellen,
wo man Schnittstellen hat, zwischen zwei Softwaresystemen und sowas ist ganz gefährlich.
Also wenn ihr mal in größere Projekte kommt und Software entwickelt,
die ein oder mehrere Schnittstellen habt,
dann werdet ihr merken, diese Schnittstelle zu verändern,
ist unheimlich schwierig, weil das bedeutet,
auf der anderen Seite der Software auch Veränderung und das muss
koordiniert werden und diese geänderten Softwaresysteme müssen mit der neuen Schnittstelle auch gemeinsam irgendwann wieder in Produktion gebracht werden und den Zeitpunkt muss man auf allen Seiten gemeinsam hinkriegen.
Also da hat man so eine Grenze, wo Software sehr hart wird,
aber man kann trotzdem auf beiden Seiten beliebig ändern.
Also eigentlich ein schwieriger, aber einheitlicher Baustoff,
sehr abstrakt, man kann es gar nicht anfassen,
man kann nur die Oberflächen anfassen,
da werdet ihr auch die Erfahrung machen,
dass die Leute sagen, ja wieso,
dann ändern sie doch hier einfach mal ein bisschen was und dann wird es schon gehen.
Aber wenn man an der Oberfläche einmal mal ein bisschen was ändert,
dann bedeutet das häufig, dass man auch sehr viel im System ändern muss.
So, und die Software, die wir heute bauen,
ist mathematisch überhaupt nicht beschreibbar
Das kann man nur durch testen, überprüfen,
man kann heute kaum, man kann nichts beweisen über Software,
die eingebettet ist in soziale Prozesse.
Also Software ist ein ganz besonderer Saft und deswegen muss
die Herstellungsweise auch auf besondere Art und Weise abgestimmt werden.
Und darüber wollen wir heute ein bisschen reden.
Geht hier noch was weiter? Nö, wieso nicht?
Hallo? Oh. Jetzt geht gar nichts mehr.
Das ist hübsch. Geht noch hier was? Ah,
da ging was. Doch, jetzt geht was.
Also, die Projekte, mit denen ihr zu tun haben werdet,
sind in der Regel Einzelfertigungen, keine Massenprodukte wahrscheinlich.
Außer ihr geht zu Google oder zu Microsoft oder sowas.
Obwohl in Deutschland gibt es jetzt auch ein paar größere Firmen.
Ihr wisst ja, Xing ist in Deutschland Parship und so.
Die machen natürlich eher Produkte für den Massenmarkt.
Also das Internet gibt da Möglichkeiten, aber ich vermute,
ihr werdet erstmal in Firmen sitzen, wo ihr in Projekten Einzelfertigungen macht.
Und es sind eine unendliche Menge an Adakteuren beteiligt,
die gemeinsam versuchen zu lernen, was da eigentlich für eine Software hermüsste.
Also die
einen Lernprozess durchmachen
Und natürlich auch einen Herstellungsprozess. Und das Schwierige in Organisationen ist eigentlich meistens,
dass man da Hierarchien hat, ja,
also es gibt den Geschäftsführer und dann gibt es die Hauptabteilungsleiter,
ich sag jetzt mal irgendwas, und dann Abteilungsleiter und so weiter.
Und jeder Mensch da in diesen Firmen muss reporten an seine Chefs,
ja,
und wenn man einen Softwareentwicklungsprojekt macht und welche von den Anwendern
zum Beispiel da mit reinhaben will oder auch Entwickler aus einer anderen Abteilung,
dann steht das Projekt quer zu der Organisation, ja,
und man muss eigentlich eine Organisationsentwicklung machen,
um dabei weiterzukommen
So, und was bei Software eben auch das Schreckliche ist,
man kann das Ding nicht einfach hinstellen und dann benutzt das
einer und man muss sich nie wieder drum kümmern,
sondern man muss es warten und weiterentwickeln.
Das ist aber, wenn man es ehrlich betrachtet,
auch bei anderen Dingen natürlich so. Also gerade,
wenn man Geräte hat, wie in dem Projekt,
in dem Hafen, wo ich da sehr viel zu tun hatte,
dann hat man Containerbrücken und diese Containerbrücken müssen ständig gewartet werden.
Ja, also die gehen auch,
die kann man auch nicht einfach nur abgeben.
Aber wenn man das mit dem Haus vergleicht,
dann kann man so ein Haus den Leuten häufig
erstmal übergeben und dann können die daran alleine
weiter werkeln
So, das heißt, und das entspricht ja allem allem eurem Berufsbild,
ihr müsst kreativ sein, um neue Ideen zu haben für Software, ihr müsst kommunizieren können.
Ihr müsst Abstraktionen bilden können und ihr müsst natürlich auch das Handwerkliche können.
Ich weiß nicht, ob ihr euch noch erinnert,
ich habe euch ja mal so eine Vorlesung über das Berufsbild Architekt,
habe ich euch mal irgendwann gegönnt, hier,
das ist schon eine Weile her,
da ging es ja auch um solche Begriffe.
Das Handwerkliche, die Technologie ist zwar wichtig,
aber ihr müsst kommunizieren können mit anderen Leuten reden können,
das ist unglaublich wichtig. Ich erinnere nur wieder daran,
dass ihr Bitte, bitte geht in diese Seminare oder was
auch immer angeboten wird in eurem Studium,
wo ihr mal ausprobieren könnt, wie euer Kommunikationsverhalten ist oder sowas.
Das ist nämlich an der Uni alles noch kostenlos.
Und wenn ihr später in Firmen seid, wird es teurer.
Also nehmt das wahr und lernt was über euch selbst und über euer Kommunikationsverhalten.
Gut, also ein Softwareprojekt könnte man als Definition sagen,
ist ein organisiertes Vorhaben zur Herstellung,
Anpassung und Weiterentwicklung von Softwareprodukten und Infrastrukturen
So, und in der Regel,
das ist ein Punkt, der da oben noch steht,
zu dem ich jetzt noch gar nicht so viel gesagt habe.
Mal sehen, kann ich hier Striche machen? Oh,
das war das Falsche. Ich muss erst mal wieder umschalten, ne?
Mal sehen, ich habe das immer noch nicht Zeigeoption.
Nee, Zeigeoption. Fehlstift. Super. Hier,
dieser Punkt. Man kann heute keine Software mehr entwickeln,
die nicht auch eine Anpassung der Organisation bedarf.
Also wo auch immer ihr hinkommt, das werdet ihr auch merken,
dass IT-Abteilungen häufig keinen Blick darauf haben, dass das,
was sie da bauen, auch die Organisation des ganzen Unternehmens verändert.
Ja, gerade in größeren Firmen. Da gibt es
ganz klar vorgeschriebene Prozesse, wie irgendwelche Dinge abzulaufen haben und
ein Softwareprojekt ist eigentlich auch immer ein Organisationsentwicklungsprojekt.
Das vergessen die Leute immer wieder und es wird euch bestimmt
oft in eurem Leben begegnen, dass gerade der Punkt nicht beachtet wird.
Dann erinnert ihr euch vielleicht daran, dass ich
euch das gesagt habe
Gut, wo kommt das Wort Projekt eigentlich her?
Das kommt von einem lateinischen Wort Projektum.
Und das heißt, finde ich wunderbar, das vorausgeworfene.
Also man wirft sozusagen eine Idee voraus über etwas,
was man tut. Ja, also man hat ein Vorhaben,
das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist.
Das heißt, man hat eine Zielvorgabe,
die ist niemals wieder auf dieser Welt geben wird.
Man hat zeitliche finanzielle, personelle und sonst was Begrenzungen für dieses Projekt.
Also ein Projekt ist auch immer Es hat ein Ende.
Wenn ihr, wenn ihr zum Beispiel an Wartung denkt,
die in Softwarefirmen ja viel gemacht wird,
dann ist das kein Projekt mehr, denn das hat kein Ende.
Das ist ja das Schreckliche bei der Wartung. Man muss
immer weiter warten an dem System. Projekte sind für ein
bestimmtes Ziel und haben ein bestimmtes, bestimmten Zeitrahmen.
Ich kann euch nur empfehlen, wenn ihr mal Projektleiter seid,
euch darum ungemein zu kümmern, dass das Ziel klar ist,
was ihr habt.
Ihr habt ja auch schon ein bisschen was über agile Softwareentwicklung
gelernt und eigentlich ist agile Softwareentwicklung,
was hat agile Softwareentwicklung mit dem Ziel
zu tun
Habt ihr eine Idee? Also ich plädiere ja für starke
Ziele in Projekten. Was macht man bei agilen Softwareentwicklungsprojekten?
Was macht man da überhaupt? Wasserfall? Müssen alle
den Kopf schütteln. Nein, kein Wasserfall. Das hat
Guido euch hoffentlich beigebracht. Sondern man macht kleine Einheiten,
kurze Zeitabstände, in denen man etwas tut.
Und das Entscheidende an diesen kurzen Iterationen ist,
dass die immer ein Ziel haben.
Man hat also ganz viele kleine Ziele
Ja, also vielleicht erlebt ihr das als erst mal als Mitarbeiter in einem Projekt,
wenn ihr einen guten Projektleiter habt, dann definiert ihr klare Ziele.
Und ihr könnt auf diese Ziele hinarbeiten und euer Tun daran ausrichten.
Dass der sich dann um das Geld kümmern muss,
ist nochmal eine ganz andere Sache. Gut, durch das Ziel
ist so ein Projekt auch abgegrenzt gegenüber anderen Vorhaben, ja.
Und es hat in der Regel eine projektspezifische Organisation.
Das ist das, was ich eben schon gesagt habe.
Man hat in der Regel in einer Firma eine Organisation,
einen Aufbau, eine Aufbauorganisation,
die sieht dann so aus
Das soll ein Organigramm sein, ja, ist nicht
so gut gelungen, ne. Hier ist die Geschäftsführung,
man ist hier ein Abteilungsleiter und dann ist hier vielleicht
ein Teamleiter, könnte man sich vorstellen.
Und dann sitzt ihr vielleicht hier, ich. So. Und
ihr müsst sozusagen einmal die Woche in so einem Regeltermin,
dem da oben sagen, was ihr geschafft habt und was nicht.
Ja, das ist eigentlich eure Aufgabe in dieser Organisation.
Aber dann kommt ihr in ein Projekt und da gibt es
einen Projektleiter, sagen wir mal,
und dem seid ihr jetzt zugeordnet
Schon gibt es einen Konflikt. Also diese Organisation hier von dem Projekt,
die ist nur für die Zeit und ganz spezifisch dafür.
Aber die Leute, die in solchen Aufbauorganisationen arbeiten,
die müssen natürlich wissen, wo ihr Platz ist.
Und das ganz Schrecklichste, was dann noch passieren kann,
ist, ich bin nur zu 30 Prozent in dem Projekt.
Das ist ganz schrecklich. Und da ist noch
ein anderer Projektleiter und der hat mich zu 70 Prozent.
Das ist immer so eine ganz schöne Vorstellung von Betriebswirten,
dass man sowas machen kann mit Leuten.
Projektarbeit hat aber die Eigenart, dass man plötzlich
eine Mail kriegt und etwas tun muss
Und dass man nicht sozusagen in der Woche zwei Tage für
das eine Projekt und drei Tage für das andere Projekt arbeiten kann.
Das funktioniert nicht. Und dann entsteht in der Regel so was,
dass dieser Mensch wahrscheinlich ungefähr 130 Prozent arbeiten muss.
Ja, weil der eine von ihm 80 will und der andere 50,
also die Leute nehmen einen dann einfach in Anspruch.
Ja, wieso? Du bist noch 30 Prozent bei uns.
Also schicke ich dir jetzt eine Mail und du hast diese Aufgabe.
Also das ist eine schwierige Sache. Und wenn ihr mal
irgendwo arbeitet, dann wünsche ich euch,
dass ihr immer zu 100 Projekt Prozent einem Projekt zugeordnet seid
Ja, weil sonst seid ihr auch Diener, Zweier,
Ziele und müsst das eine Ziel verfolgen und das andere.
Das ist ganz furchtbar. Gut,
also es gibt ein Ziel, es gibt eine zeitliche Befristung.
Es gibt begrenzte Ressourcen, das heißt,
es gibt nur eine ganz bestimmte Menge von Leuten und von Geld.
Und in der Regel muss man ein Teamarbeit machen,
damit man in einem Projekt was hinkriegt.
Und man hat eine ganz neuartige und nur einmal vorhandene Aufgabenstellung.
So, das sind also die Dinge,
die Projekte auszeichnen
Kommt jetzt noch einer? Nein. Ah, so. Gut,
also jedes Projekt ist einmalig und das bedeutet im Grunde,
dass man das vorher nicht planen kann,
sondern dass man in der Projektsituation entscheiden muss, was man jetzt tut.
Ich bin gerade wieder im Hafen auch in einem Projekt zugange
und ich muss quasi täglich die Diagramme neu machen,
die ich über den Plan gemacht habe, wie die Leute arbeiten sollen.
Also es ändert sich fast täglich,
weil man immer wieder an bestimmte Probleme kommt oder man hat gedacht,
man schafft es mit dem Test oder man hat gedacht,
die Software kann jetzt das und das und dann braucht man doch noch eine neue Version.
Also man muss sozusagen situativ jeweils aus der Situation entscheiden, was mache ich jetzt?
Man hat zwar eine Vorstellung davon, wie es geht,
aber aus der Situation heraus entfaltet sich das Ganze.
Je nachdem, wie groß so ein Projekt ist,
das werden wir gleich noch sehen, dass so unterschiedliche Aktivitäten sind,
da zu tun, aber mir ist das ganz wichtig.
Also was ich euch heute mitgeben will, ist im Grunde Eine Vorstellung davon,
wie Projekte sein können und ein Werkzeugkasten, was man tun kann,
ja, aber es gibt keinen allgemein immer verwendbaren Plan oder irgendeine Vorgabe, wie Projekte ablaufen.
Dieser Punkt hier ist sehr, sehr wichtig, situativ,
also in, also das schönste Wort,
was ich den Leuten immer sage, situativ, ja,
das heißt, ich sage den Leuten immer, so,
hier habt ihr meinen Plan und der,
das ist nur ein Plan und morgen ist er wieder anders, ja, weil sich die Welt verändert hat.
Das ist ganz normal und das kann auch niemand verhindern.
Heute hat ein Kollege zu mir gesagt,
das ist aber ein bisschen chaotisch, dann habe ich gesagt,
ja, das ist so, anders kommt man nicht voran,
es ist dann chaotisch
Ja. So, und wenn wir über solche Vorgehensmodelle reden,
das hat Guido ja auch mit euch gemacht,
der hat mit euch übers Wasserfallmodell gesprochen,
über was für Modelle hat er denn noch mit euch gesprochen?
Spiralmodell, wunderbar, genau. Es war ja der erste Versuch,
irgendwie zyklisch zu werden. Was hat er euch noch erzählt
? Hat noch jemand eins? Spiralmodell. Extreme Programming,
genau, das gehört zu den Agilen, sehr schön.
Darüber hat er euch auch was erzählt,
überhaupt von iterativen Modellen hat er euch dann noch
sehr viel erzählt
So. Und all diese Theorien oder Methoden,
die geben einem nur Verständnis davon,
was da eigentlich los ist und eine Anleitung,
was man tun kann in der Situation.
Ja, es gibt keinen Waschzettel, wie man das alles
tun muss, sondern man muss sich selber entscheiden.
Deswegen ist auch Projektleitung was, was man lernen,
was man aus Erfahrung erst lernen kann.
Also ich würde euch nicht empfehlen,
nach dem Studium gleich irgendwo als Projektleiter anfangen zu wollen.
Da braucht man viele Erfahrungen für. So, und jetzt
will ich mit euch ein bisschen verschiedene Arten von Projekttypen durchgehen.
Projekte können unterschiedliche Gegenstände haben. Also was machen wir da
eigentlich? Bauen wir Individualsoftware oder führen wir ein Standardprodukt ein?
Also wenn wir zum Beispiel irgendwo hingehen und ein SAP-System einführen,
dann ist das was anderes, als wenn wir eine ganz neue Software entwickeln.
Obwohl wir da mindestens genauso viel nachher zu tun haben.
Bauen wir ein Produkt oder machen wir was an der Infrastruktur?
Also wir haben in unserer Gruppe zum Beispiel eine Firma,
die baut so eine Infrastruktur, mit der man Nachrichten verschicken kann,
bestimmte Arten von Nachrichten und stellen die dann zur Verfügung für,
also sicher, also Nachrichten,
die verschlüsselt sind und all sowas für zum Beispiel Buchläden,
die dann von den Buchhändlern über diese Schnittstellen,
über diese Infrastruktur, bestimmte Bücher abfordern oder sich Sachen liefern lassen.
Also sowas könnte man unter einem Infrastrukturprojekt sich vorstellen. Ich hoffe,
dass euch das nicht so, nicht so,
also dass das nicht das sein wird,
was ihr in eurem Leben tut, weil ich persönlich das relativ anstrengend finde.
Man hat einfach sehr hardwarenah, wenn man damit zu tun
Aber für manche Leute ist das auch genau das Richtige.
Gut, was machen wir? Machen wir neue Entwicklung?
Machen wir Weiterentwicklung? Ich habe euch ja schon bedroht
irgendwann vor einiger Zeit und euch gesagt,
dass bestimmt innerhalb von acht,
von zehn Jahren ihr ein Jahr vielleicht was Neues entwickelt und den Rest der Zeit Weiterentwicklung,
also eigentlich Wartung machen werdet in eurem Leben.
Insofern seid immer glücklich, wenn ihr mal in so
ein Projekt kommt. Meistens werdet ihr das machen.
Ist leider so
Wir haben bei uns in der Firma gerade ein Forschungsprojekt.
Sowas ist natürlich toll. Da kann man lauter neue Sachen sich ausdenken.
Wir waren heute also wieder bei unserem Kunden und haben den Prototypen,
wie man bestimmte Sachen auf einem Blackberry angucken könnte, gezeigt.
Ja, und das ist natürlich sehr befriedigend, wenn man sowas macht.
Und wenn die Kunden dann da sitzen und sagen,
boah, das ist toll, juhu, ja,
also Neuentwicklung, wenn man das gut macht,
da kann man noch ganz viel positives Feedback bekommen.
Bei Weiterentwicklung kriegt man das meistens nicht. Na,
endlich habt ihr den Fehler gefixt, der das schon seit
zehn Jahren war, kriegt man da zu hören.
Das macht also nicht so viel Spaß.
Aber so ist die Welt
Tja, könnt ihr eigene Software bauen? Das ist natürlich
auch was Tolles, wenn man eine eigene Software bauen darf.
Das dürft ihr jetzt im Studium ja immer ganz viel machen.
Aber Weiterentwicklung hat meistens den Effekt, dass man fremde Software anpassen muss.
Ich habe euch, glaube ich, auch schon mal erzählt,
dass wir seit 1999 bei einem Kunden jetzt inzwischen fünf kleinere Softwaresysteme haben.
Und es ist keiner der Entwickler mehr da,
der 99 diese Systeme gebaut hat.
Ja, also alle, die heute daran bauen,
für die ist das quasi fremde Software.
Man freundet sich dann irgendwann mit der an,
aber erstmal ist sie fremd
Ja, und wie ist das Verhältnis Auftraggeber, Auftragnehmer?
Ist auch immer noch so eine Frage. Also was ist das für eine Entwicklung?
Bin ich, arbeite ich in der IT-Abteilung eines größeren Unternehmens?
Dann habe ich ein ganz anderes Verhältnis zu den Leuten,
als wenn ich Dienstleister bin. Ja,
wenn ich Dienstleister bin, dann muss ich das irgendwie hinkriegen,
dass ich bei der Ausschreibung, die der Auftraggeber macht,
gewinnt und dem, also das Goldene vom Himmel verspreche und dann,
wenn das Projekt abläuft, mit dem Geld,
was er mir gibt, irgendwie klarkomme und nicht in die miesen Gerate.
Wenn ich IT-Abteilung in einem Unternehmen bin,
dann habe ich ganz andere,
ganz andere Situationen
Was mache ich da für eine Art von Produkt? Also baue ich was,
was, ich fange jetzt mal hier an,
was eingebettet wird in irgendeine technische Infrastruktur oder baue ich etwas, was Arbeitsprozesse unterstützt?
Das sind ganz unterschiedliche Anforderungen. Also wenn ich etwas baue,
das ist das, worüber wir hier meistens reden und Vugido
euch letzte Woche auch diese hübschen Bilder mit den Männchen gezeigt hat,
falls ihr euch, ich glaube,
das hat er euch gezeigt, so Männchenbilder, über Arbeitsprozesse,
irgendwie sowas so,
tschüss,
mit Beinen
Und manchmal auch weibliche, so, so vielleicht.
Und die tauschen dann sowas aus, so ein Ding, so.
Sowas hat er euch gezeigt. Also das sind ja sozusagen
visualisierte Arbeitsprozesse. Dafür muss man was ans anderes bauen als
für technische Systeme. Also wenn man was Technisches baut,
dann hat man in der Regel Schnittstellen, mit denen man zu tun hat,
zu den technischen Geräten und man muss sehr oft das Zeitverhalten der Software achten,
die man da baut.
Hier geht es eher darum, damit zuranne zu kommen,
dass die Menschen alles Mögliche machen und immer wieder was anderes.
Ich habe Wir haben bei dem Kunden, wo ich
jetzt bin, gerade ein neues Release in Betrieb genommen.
Und das hat einen ganz unangenehmen Effekt für einige der Anwender gehabt.
Denn die benutzen eine Software, in der sie per Hand immer Containernummern eingeben müssen.
Und die kann man sich entweder auf den Zettel schreiben oder
man kann das andere Softwaresystem nehmen und sich da die Containernummern rausholen.
Und die hatten sich das ganz schlau gemacht. Die hatten also ihr System,
wo sie die Containernummern eingaben und hatten dann immer das Fenster
von dem anderen System daneben, wo man die Container alle sah,
wie sie so auf dem draußen stehen.
Und dann sind sie mit der Maus da drüber gefahren und
dann kam der Tooltipp Und dann haben sie in dem anderen Fenster die Container-Nummer eingegeben,
die sie in dem Tooltipp sahen.
So, jetzt haben wir das neue Release eingespielt von der Software,
wo man diese Container alle sieht. Und der Effekt war der,
die Entwickler von diesem Software-System, wo man die Container immer sieht,
die haben nämlich ganz viel an der Performance ihres Systems gearbeitet,
weil das System manchmal ein bisschen langsam war.
Und was sie dabei gemacht haben, ist,
dass sie eingestellt haben, dass der Tooltipp nur noch kommt,
wenn das Fenster den Fokus hat.
Jetzt waren die anderen ganz traurig, weil wenn sie jetzt
mit der Maus da rüber gefahren sind, kam kein Tooltipp mehr.
Also sie müssen also das andere Fenster mit dem Fokus machen,
ein Unterdialog für den Container aufrufen, wo dann die Cantainer-Nummer drinsteht.
Und dann können sie wieder zu ihrem anderen Tool zurück und
dem wieder den Fokus geben und dann die Container-Nummer abtippen.
Das ist also ganz blöd. Und im Grunde hat halt
keiner gewusst, dass die ihre Arbeit so machen.
Ja, also dass ihr Arbeitsprozess so ist.
Also das ist ganz schwierig zu wissen, was machen diese Leute
hier eigentlich mit der Software, die wir ihnen bauen.
Die Frauen machen immer das Richtige und na, okay,
jedenfalls, was machen die eigentlich mit der Software da,
die sie da bauen,
die wir ihnen gebaut haben und vor allen Dingen im Zusammenhang mit den verschiedensten Softwaresystemen.
Wir haben mal Ein Student von uns hat mal eine Diplomarbeit
über die Kundenzufriedenheit bei der Einführung eines Softwaresystems gemacht.
Und das war also alles ganz schrecklich. Die Software hat
überhaupt nicht gepasst zu dem, was die Anwender wollten.
Und das wichtigste Wort oder die wichtigste Frage bei den Anwendern war,
kennst du einen Workaround? Ja, also das Workaround sozusagen,
die Hauptfrage ist. Und das ist was Anwender tun.
Also wenn ihr Software entwickelt und ihr kriegt kein Feedback darüber,
was mit eurer Software ist,
dann hat das nichts damit zu tun,
dass die so gut zu benutzen ist,
sondern dann hat das wahrscheinlich was damit zu tun,
dass die Anwender einfach irgendwie versuchen,
damit klarzukommen
Also dass sie damit irgendwie klarkommen,
das wisst ihr dann, wenn sie sich nicht melden.
Aber es ist total gut, wenn man Software entwickelt,
sich zu trauen, mal dahin zu gehen und zu gucken,
was die Leute damit machen.
Ihr werdet euch wundern. Macht das mal, guckt mal,
was die Leute mit dem System machen, was ihr programmiert habt.
Gut. Und die Frage ist aber natürlich auch noch,
wie groß ist das, was sich da entwickelt und wie lange wird es leben?
Den Effekt finde ich ganz spannend. Wir versuchen euch ja beizubringen,
dass ihr eine Sache immer, immer tun müsst.
Wisst ihr noch, was das war?
Die war Antwort auf alle Fragen von Carola
Bitte? Nein, irgendjemand hat es eben schon gesagt.
Fängt mit dir, ach so, fängt mit Tee an.
Jetzt habe ich es verstanden. Testen. Ich habe es
einfach akustisch nicht gehört. Genau, testen. Aber wenn
ihr was baut, was nur für einmaligen Einsatz ist,
für irgendeine Umfrage und noch ein paar Wochen wieder weggeworfen wird,
dann werdet ihr nicht so viel Testaufwand betreiben.
Wahrscheinlich. Kann ich euch natürlich trotzdem empfehlen.
Aber die Lebensdauer hat also auch viel damit zu tun,
was ich tue mit dem Ding.
Die Größe hat damit zu tun,
was für Planungen ich machen muss und so weiter.
Und natürlich auch das Anwendungsgebiet. Also wie stark kann ich
mich in das Anwendungsgebiet einarbeiten,
hat viel damit zu tun
Gut. Und es gibt unterschiedliche Projekttypen, bei denen ich,
ach, unterschiedlichste Basis, Softwaresysteme und was nicht noch alles habe.
Was ist das für eine Programmiersprache, mit der ich da arbeite?
Was habe ich für Entwicklungswerkzeuge? Also all diese Fragen haben Einfluss darauf,
was ich für ein Projekttyp habe und was für ein Vorgehen ich wohl einsetzen werde.
Ich zeige euch jetzt mal ein paar Projekttypen.
Das schönste Projekt. Ich habe eine Neuentwicklung. Es gibt
also noch keinen Vorgänger. Es gibt keinen Softwaresystem,
was jemals jemand für diese Art der Arbeit
verwendet hat
Das ist inzwischen selten, aber das kommt noch vor.
Was muss ich dann machen? Ich muss überhaupt eine Vision
von diesem System entwickeln. Ich muss die Vision umsetzen.
Ich muss herausfinden, was sind die Anforderungen?
Also da muss ich mich wirklich extrem mit beschäftigen.
Und dazu hat euch Guido letzte Woche ganz viel erzählt,
wie ich sowas machen kann.
Ja, ich muss also in einen Lernprozess einsteigen.
Ich muss auch die ganze Architektur mir neu ausdenken.
Und wenn es noch keinen Vorgänger davon gibt,
dann kann ich das alles auf der grünen Wiese machen,
muss aber eben auch schon an vieles denken, was später noch kommt.
Da bietet sich agiles Vorgehen an,
damit ich schnell Feedback bekomme von den Anwendern
Und ich will die Benutzer über Prototyping beteiligen,
dazu hat die du euch auch viel erzählt, zu Prototyping.
Ich will also evolutionär vorgehen. Sowas sieht in der Regel so aus.
Am Anfang stehe ich hier und blicke auf die Welt und denke,
das ist mein Ziel, das denke ich am Anfang.
Hier will ich hin, da. Und dann, und es fällt,
sieht so breit aus, so viel kann man noch machen.
Dann mache ich meinen ersten Schritt hierhin und zeige den Anwendern was.
Und dann sagen die, naja, doch nicht.
Geh mal lieber da lang und dann gehe ich ein Stück in die Richtung.
Aber das geht nur, wenn ich immer wieder Feedback bekomme.
Und so denke ich, vielleicht muss ich dahin,
muss ich dahin, muss ich dahin und langsam stabilisiert sich das.
Und das ist natürlich nachher eigentlich die Lösung. Und zwischendurch denke ich,
also hier denke ich vielleicht immer noch, dass das das Ziel ist.
Und wenn ich hier bin, dann denke ich,
gucke ich schon in die Richtung und denke,
vielleicht ist das das Ziel.
Und wenn ich da bin, dann denke ich,
oh, vielleicht ist das Ziel auch hier.
Also so wie die Software nachher gebaut ist,
das ist damit gemeint. Und hier komme ich dem Ding
schon langsam näher und schließlich ende ich da
Ja. Ein Kollege von uns, der hat,
fand ich, ein sehr schönes Bild dafür geprägt.
Er hat gesagt, Projekte sind wie eine Expedition. Also wenn ihr euch vorstellt,
jemand soll irgendein unbekanntes Gebiet ergründen, kartografieren, sich da,
also soll zu irgendeinem Berg da am Ende, dann zieht der los.
Du siehst das Ziel hinten, da will ich rauf auf
diesem Berg und unterwegs passiert alles Mögliche.
Plötzlich steht man vor einem unbekannten Fluss, muss sehen,
wie man da rüberkommt oder vor einem See und geht drumherum.
Und so ist Neuentwicklung. Neuentwicklung ist wirklich wie eine Expedition
Eigentlich muss da ein Gleichheitszeichen hin und machen wir mal so.
Neue Entwicklung ist eine Expedition. Man hat ein Ziel,
das muss man auch haben. Also man muss das hier definieren,
sonst geht das gar nicht. Sonst weiß man nämlich nicht,
in welche Richtung man geht und dann geht man vielleicht hier
lang und das wäre gar nicht gut.
Oder nach da. Also man braucht, das hier ist
total wichtig, auch wenn es nicht das Ende ist.
Also auch wenn ich da ankomme,
ich kann da nur ankommen, wenn ich dieses Ziel habe.
Sonst geht das nicht
So, eine andere Art von Projekttyp könnte man nennen,
Technologieanpassung, das ist was ganz anderes. Also wenn ich zum Beispiel feststelle,
wie wir das bei unserem einen Kunden hatten,
wir haben also 1999 mit Java angefangen zu entwickeln,
da war das alles noch ganz neu und so und es gab zwar was um Oberflächen darzustellen,
aber um an Datenbanken ranzukommen,
also um die Daten in eine Datenbank zu speichern,
gab es noch gar keine allgemeingültigen Tools oder irgendwas oder Schnittstellen,
so das haben wir dann selber entwickelt,
weil das waren natürlich relationale Datenbanken,
habt ihr schon was über relationale Datenbanken gelernt irgendwo
Überhaupt über Datenbanken? Einige schütteln den Kopf.
Also es gibt verschiedene Arten von Datenbanken, hierarchische Datenbanken,
relationale Datenbanken und objektorientierte Datenbanken, so ganz mal im Grob-Dings,
also hierarchisch, relational und objektorientiert.
Inzwischen haben die meisten Firmen
solche Datenbanken
Das heißt, da werden die Daten in Tabellen abgelegt und
zwischen den Tabellen gibt es Verknüpfungen über Schlüssel.
Dafür gibt es auch ein mathematisches Kalkül. Das ist also
total cool. Hierarchische Datenbanken war das Erste, was man hatte.
Also man stieg in so eine Datenbank ein über eine
obere Datenstruktur und konnte sich dann so nach unten hangeln.
Die gibt es heute nur noch ganz selten. Naja,
vielleicht auch nicht. Also Kobol-Datenbanken sind häufig hierarchisch und wenn
immer noch 40 Prozent aller Programmierungen im Kobel passiert,
sind die natürlich nicht so selten.
Aber ob sie euch unbedingt begegnen sollten, weiß ich nicht.
Objektorientierte Datenbanken werden in der Praxis immer noch wenig verwendet.
Da ist die Idee, dass man tatsächlich die Objekte
direkt abspeichern kann in die Datenbank
Das ist für jemanden, der objektorientiert programmiert einfach.
Dann nehme ich mein Objekt und dem sage ich dann,
das soll persistant sein und dann ist es direkt in der Datenbank.
Bei relationalen Datenbanken ist es schwieriger, denn du musst dir überlegen,
wie du dein Objekt in diese Datenbank ablegst,
wie du das auseinander nimmst, welche Teile kommen,
in welche Tabelle.
Es ist nicht so einfach. Und dazu braucht man,
ja, nee, das ist vielleicht zu viel dazu,
braucht man irgendeine Transformation, aus der objektorientierten Programmierung in diese Datenbank hinein.
Und 1999 gab es dafür, ja,
war noch nichts, da haben wir
das selber gebaut
So, aber wenn man sowas pflegen will und immer weiterentwickeln will,
dann soll das performant sein und auf dem neuesten Stand,
dann gibt es eine neue Java-Version, ist sehr aufwendig.
Das heißt, irgendwann haben wir uns überlegt,
wir müssen auf die moderneren Technologien wechseln,
also das war so ungefähr 2005,
da gab es das, was heute quasi Standard ist,
ein Softwareprodukt, was man aus Java ansprechen kann,
was in eine relationale Datenbank mappt,
das heißt Hybernate
Das Teil, das wird euch bestimmt begegnen in eurem Leben.
Da kann man also aus einem Java-Programm heraus sagen,
so dieses Objekt, so und so sollst du es ablegen,
mach das mal, speicher es mal.
Und dann mussten wir unser ganzes System auf Hybernade umstellen und
das war ein echter Akt. Ja, das heißt,
aber was passiert ist, die Software hat sich überhaupt nicht geändert.
Ja? Gar nicht. Denn die Gui, also die Oberfläche
ist gleich geblieben, die Business-Logik da drunter gleich geblieben.
Nur hier unten, nur. Wo es zur Datenbank
ging. Das wurde ausgetauscht hier
So. Und das ist total aufwendig.
Also wenn euch mal jemand sagt, aber wieso?
Du brauchst doch nur hier unten. Das stimmt natürlich nicht.
Ja, auch eine Datenbank hat Einfluss darauf,
wie die Software sie nachher benutzt und was damit passiert.
Es ist ganz, ganz schwer, eine Datenbank oder so
eine Technologie auszutauschen. Es wäre schön, wenn das nur
eine lokale Änderung in der technischen Schicht der Architektur wäre.
Dazu muss man eine ganze Menge Maßnahmen ergreifen und ich will
euch ein Modell vorstellen,
was mir sehr gut gefällt dazu
Also es gibt noch eine ganze Menge andere Maßnahmen.
Ihr könnt irgendwelche Architektur, Stile und Entwurfsmuster da finden.
Ihr könnt versuchen, die betroffenen Komponenten zu identifizieren, die da was machen.
Aber eine Sache, die ich sehr schön finde,
die nämlich auf sowas vorbereitet, ist,
dass ihr in eurer Software Anwendungs- und technische Komponenten trennt.
Da gibt es eine, also kennt ihr SD&M?
Das ist eine Beratungsfirma in Deutschland auch.
Die gehört zu Capgemini, SD und M. Und die haben
ein ganz hübsches Eine ganz hübsche Idee veröffentlicht in verschiedensten Büchern.
Und die will ich euch jetzt gerne zeigen, die sagen,
also wenn man Software entwickelt, dann muss man seine Software,
also die, die sagen erstmal Module dazu, ja,
seine Softwareteile, die man baut, kategorisieren.
Man muss sich also fragen,
ist das, was ich jetzt gerade hier baue,
eine anwendungsfachliche Klasse oder ein Package voller anwendungsfachlicher Sachen?
Oder mache ich eher was Technisches hier? Ja,
also eine Komponente der Kategorie A wäre zum Beispiel Kunde oder Auftrag oder Bestellung.
Das ist das, was meine Anwender natürlich eigentlich interessiert,
dass sie
damit arbeiten können
Wenn ich an Sachen baue, die zu der Kategorie Tee gehören,
dann baue ich eher eine technische API, also eine Schnittstelle,
zum Beispiel eine Datenbankverwaltung oder ihr habt auch Swing schon gelernt,
glaube ich, oder?
Also Oberflächen, ja. Wenn ihr sozusagen neue Swing-Komponenten bauen würdet,
weil ihr in einem Projekt eine bestimmte Art von Tabellenkalkulation braucht oder so,
dann würdet ihr etwas bauen, was in die Tee-Kategorie fällt.
Und ich springe jetzt mal über null rüber,
das erkläre ich euch gleich,
die Vermischung von A und T
ist ganz problematisch
Wenn ihr euch vorstellt, ihr würdet sozusagen in eure Kundenklasse reinbauen,
dass die auch eine Oberflächendarstellung hat, dann könntet ihr das nie austauschen.
Oder ihr müsst große Kraft abmachen,
weil das in diesem Kundenteil da alles drin ist.
Und dann auch noch in dem Auftrag und in der Bestellung.
Also trennen. Und dann gibt es noch die Null-Kategorie.
Das sind Sachen, die eigentlich unabhängig von Anwendung und Technik sind.
Sowas benutzt ihr in Java ganz viel. Collection, Strings,
weiß nicht, was ihr sonst noch so alles benutzt,
aber die Sachen,
die einfach schon da sind in der Programmiersprache
So, und sowas bauen hier ist gefährlich.
Also eine Vermischung von anwendungsfachlichen und technischen Klassen. Und zwar
ganz besonders wegen dieser Frage der Möglichkeiten, Sachen auszutauschen.
Gibt dazu noch ein schönes Bild. So würde eine Anwendung
normalerweise aussehen. Man hat also seine anwendungsfachliche Software,
das ist alles, was grün ist.
Das ist die A, das A ist ein bisschen kleiner.
Das ist A, das Grüne. Da,
wo sozusagen eigentlich der Kern der Anwendung drin steckt.
Und außenrum sind die anderen Sachen.
Also zum Beispiel hier ist Swing
Das ist das Gelbe, das ist Tee hier,
das Gelbe. So und natürlich muss man irgendwie,
irgendwie muss man ja seine Kundendaten an die Oberfläche kriegen.
Man muss also irgendwie der Oberfläche diese Daten übergeben und da
hat man in der Regel so eine kleine Transportschicht zwischen.
Das ist die R-Schicht, also Transport, ja,
für den Transport. Ja. So. Und hier gibt es
auch ein bisschen was Rotes. Das ist zum Beispiel,
wenn man, kann man sich vorstellen, ein Altsystem,
was tatsächlich eine komplette Vermischung von A und T-Software macht
Und hier unten ist zum Beispiel null Software,
die man benutzt. Also das hier könnte Hypernate sein.
Und hier benutzt man irgendwas zum Autorisieren,
also irgend so ein Eltern oder was weiß ich.
So. Und man versucht immer, das voneinander getrennt zu halten.
Was glaubt ihr denn, was Softwareentwickler am liebsten bauen?
Das ist jetzt eine gemeine Frage.
Am liebsten machen Softwareentwickler T-Software
Irgendwas, wo man genau weiß, was es soll und wie es geht.
Mit den Anwendern zu reden und rauszukriegen, was da fachlich eigentlich los ist,
erfordert eben Kommunikation und dass man sich an das Neue heranwagt.
Also ihr werdet das häufig erleben,
wenn ihr mal ein Projekt leiten solltet,
dann versucht darauf zu achten, was machen eure Leute eigentlich,
bauen die ganz viel schönen technischen Schnickschnack oder kümmern sie sich wirklich um den Anwendungskern,
den sie da bauen sollen.
Gut, das war jetzt gemein, ne?
Okay. Ah, zurück
Projekttyp, der auch hin und wieder vorkommt,
mit dem ich jetzt da im Hafen natürlich viel zu tun habe,
dass man irgendwelche technischen Geräte steuern soll.
Da gibt es, das Ziel ist dann nicht,
Software zu bauen, die alles tut,
sondern eigentlich nur einige Aufgaben mit der Software zu erledigen.
Also zum Beispiel dem Fahrer von so einer Brücke
bestimmte Dinge anzuzeigen über den Zustand von seinem technischen Gerät.
Sowas ist sehr schwierig, weil man ist im Grunde
nur der Zusatz zu dem technischen Gerät.
Also was die Leute da im Hafen interessiert, ist,
dass ihre Brücke da ist, dass sie da gebaut ist,
dass sie da steht und dass die Container von den Schiffen zieht.
Und dann kommen die Software-Leute und wollen da auch noch was machen.
Also hier braucht man ganz verbindliche Spezififikationen von Schnittstellen und meinen,
also das, was ich jetzt dort erlebe,
sagt mir, dass auch eine Containerbrücke sehr lange braucht,
bis sie wirklich reif ist.
Also auch da muss man iterativ vorgehen.
Und Integrationstests mit technischen Geräten sind nochmal eine ganz andere Klasse,
als ich spiele irgendwo Software ein und dann wird sie benutzt.
Ja, weil das technische Gerät kann unglaublich viele Fehler und
Dinge haben, die man vorher nicht weiß
Die dann ist, irgendwo ist was falsch angebracht,
irgendeine Verbindung in dem technischen Gerät ist nicht richtig und schon sieht alles anders aus.
Also da muss man unglaublich viel Zeit und Geld für Integrationstests ausgeben,
sehr, sehr viel mehr, als wenn man nur Software hat.
Also wenn ihr in solche Projekte kommt,
dann habt ihr einen Softwareentwicklungsanteil so und der Integrationsaufwand ist,
ja, ich müsste eigentlich die ganze Folie voll machen,
ja, also mehrfach so hoch,
wie das,
was man bei der Entwicklung macht
Das ist ein ganz hübscher Projekttyp,
der mehr und mehr in Mode kommt,
weil wir mehr und mehr historisch gewachsene Unternehmen haben,
die feststellen, dass es bei anderen Leuten schneller geht,
besser geht oder irgendwas,
dass die ihre Kundendaten tatsächlich zentralisiert haben und nicht jeder Vermittler,
die auf seinem eigenen Rechner hat und dass man da tatsächlich Auswertungen machen kann und den Kunden irgendwas anbieten kann.
Also das ist was,
was euch in eurem Leben auch viel begegnen wird
Ihr habt sozusagen in so einem Unternehmen dann in der Regel irgendwelche Lokalfürsten,
die sich mit irgendwelcher Software gut auskennen und die einem auch ganz genau erklären können,
warum ihre Software so sein muss und auf keinen Fall
ersetzt werden darf oder mit irgendwas anderem zusammengeht.
Also das ist sozusagen ein Projekttyp,
der sehr viel mit Organisationsentwicklung und Umgestaltung zu tun hat.
Also man muss da im Grunde sehr hoch weit oben im Management eingreifen,
um dem Unternehmen klarzumachen, was ist eigentlich sein Gesamtkonzept und in welche Richtung will es gehen.
Ich zeige euch da gleich mal ein Bild,
was wir da normalerweise machen, ist, dass wir versuchen,
die IT-Landschaft irgendeiner Form sichtbar zu machen und die problematischen Stellen aufzuzeigen.
Und was dann immer die Frage ist, was ist besser hier?
Entwickeln wir das selber neu oder kaufen wir ein Standardsystem ein? Und je nachdem,
mit wem ihr redet, werdet ihr hören, oh,
das müssen wir selber machen, weil wir sind ja so speziell,
ist nur die Frage, ob man sich das leisten kann.
Oder ihr habt mit jemandem zu tun,
der auf Standardsoftware setzen will und dem nicht klar ist,
dass das natürlich auch noch eine ganze Menge Geld kostet.
Ich zeige euch mal ein Bild von so einer,
ja, die Anwender müssen mitgenommen werden,
genau,
die habe ich vergessen an der Stelle
Das ist nicht einfach. Das ist eine IT-Landschaft von einem Unternehmen,
mit dem wir zu tun haben,
da gibt es einen ganzen Teil SAP.
Da gibt es einen Bereich, in dem Dokumentation und Dinge überrecht,
also die machen sehr viel so Steuersoftware und sowas.
Also solche Sachen produziert werden,
was sind die neuen Gesetze dafür und die haben einen Portalbereich,
in dem man sich da Sachen runterladen kann.
So, und dann haben wir mal die Baustellen da identifiziert
und das sieht dann so aus,
überall Baustellen
Die Search Engine ist nicht modern, da ist ein schwerfälliger Prozess hinter.
Hier ist der Publikationsprozess unzureichend, uneineinheitliche Usability,
redundanter Code, hier und da Performance-Problem. Naja,
das haben wir sozusagen erstellt, dieses Bild, nachdem wir,
glaube ich, mit 70 Leuten Interviews geführt hatten oder so.
Das ist ein Aufwand, aber das Ergebnis lohnt sich wirklich,
weil sich ein ganzes Unternehmen dann wiederfinden kann und sagen kann,
aha, das sind also unsere Probleme.
Und hier, ja, dann kann man auch einen Plan
machen,
wie man die angeht
In vielen Unternehmen sind solche, sind gerade diese Baustellen,
sind ja nicht, klar, identifiziert und wandern immer.
Je nachdem, wer gerade darüber was sagen will, von einem zum anderen.
Ja, wir müssen unbedingt ein CRM einführen.
Nein, wir müssen ein Portal haben. Nein und so
. Also so kann man es den Leuten klar machen und
mit ihnen reden, in welche Richtung eigentlich gegangen werden soll.
Hut, ich glaube, ja, es kommt noch
ein oder zwei Projekttypen, dann machen wir unsere Pause.
Auswahl von Standardsoftware ist auch ein hübscher Projekttyp.
Vielleicht wird euch das in eurem Leben mal begegnen,
dass ihr im Grunde,
also das ist ein ganz,
ganz amüsante Sache
Leute stellen sich hin und sagen, wir brauchen ein CRM-System. Ja,
also eins, wo wir unsere Beziehung mit den Kunden,
also unsere Kunden reinfliegen können und so vorhalten können,
was die da, was wir mit unseren Kunden gemacht haben.
Und dann geht man los und lässt sich solche Systeme von Anbietern vorführen.
Und da sind natürlich immer irgendwelche tollen Features drin. Boah,
das war aber schön, was die uns gezeigt haben.
Und hier konnte man so Listen und dann, da konnte man dies.
Und es hat sich vorher aber niemand darum gekümmert,
was die Leute eigentlich damit tun sollen nachher.
Ja, wie sollen die damit arbeiten? Also,
Was auf jeden Fall notwendig ist,
wenn man eine Standard-Software auswählen will, ist,
sich zu fragen, was für Geschäftsprozesse sollen damit eigentlich bearbeitet werden?
Und was für einen Bedarf haben die Leute? Das vergessen Firmen oft,
die gucken nur, wer jetzt alles was Tolles anzubieten hat.
Und dann kaufen sie das, was am hübsch sisten verkauft wird.
Was erzählt ihr mir der eine gestern? Oh, vorgestern
hatten wir IBM da. Das war aber wirklich toll,
sowas von professionell. Dann habe ich gesagt, ja,
das ist hübsch, aber die wollen das natürlich auch
nur verkaufen
Nichts gegen IBM. Überhaupt nichts. Gut,
also die Benutzer müssen unbedingt beteiligt werden,
damit man die typischen Geschäftsprozesse mal modelliert hat,
damit man weiß, wie die Leute damit nachher arbeiten sollen.
Das häufigste Motiv, was man natürlich sich erhofft, ist Kosteneinsparung.
Und das ist sicherlich auch so. Also nicht,
weil die Software dann plötzlich so viel schneller arbeitet,
sondern weil alle in einem Unternehmen dann gezwungen werden,
auf die gleiche Art und Weise zu arbeiten.
Das ist eigentlich der Haupteffekt. Gut. Und
da muss man die Standard-Software nachher noch einführen,
wenn man sie schon mal ausgesucht hat
Das, was man natürlich eigentlich möchte, ist,
dass man so einen geringen Aufwand viel möglich hat bei dieser Einführung.
Und da lohnt es sich natürlich sehr, dass man seine alten Geschäftsprozesse,
die man mal analysiert hat, wieder in die Hand nimmt.
So, und dann denkt man natürlich immer,
jetzt installiere ich die Standardsoftware und dann ist alles gut.
So ist das aber in der Regel nicht,
sondern in der Regel muss die Standardsoftware konfiguriert und angepasst werden.
Ja, und wenn ihr mal in die Lage kommt,
Standardsoftware auszusuchen oder sie einzuführen, guckt euch das Ding genau an.
Denn viele Firmen bauen eine Software für einen Kunden,
Und dann nehmen sie das Ding und sagen,
jetzt machen wir Standardsoftware draus, dann können das auch andere Leute benutzen.
Jetzt machen wir noch eine Weboberfläche oder irgendwas. Und man kann sich sicher sein,
wenn es das erst bei einem Kunden gab und da funktioniert,
dann heißt das noch lange nicht,
dass es in eurem Unternehmen nachher funktioniert.
Also man muss genau hingucken, ob es von diesem System
tatsächlich schon Installationen bei unterschiedlichen Firmen gibt.
Was ich in solchen Fällen immer mache,
dass ich sage, kann ich mir das mal
irgendwo angucken
Vielleicht auch bei zwei von ihren Kunden.
Da scheiden sich meistens die Geister. Wenn ich das kann,
dann ist das vielleicht ein sinnvoller Anbieter und der kann mir sogar
zufriedene Kunden liefern, wo ich mir das mal angucken kann.
Der nimmt mich damit hin und sagt,
hier darf ich Ihnen mal einen anderen,
den Firmen mögen das gerne, wenn sie eine gute Software haben,
dass sie auch dafür werben, anderen gegenüber.
Das ist eine gute Frage, die man an der Stelle
stellen kann und die Benutzer müssen natürlich überzeugt werden,
dass sie jetzt auf diese Standardsoftware umschwenken müssen,
denn sie haben natürlich ihre Software lieb gewonnen
Bei euch ist das vielleicht noch so, dass ihr gerne neue Software ausprobiert.
Das wird hoffentlich auch euer ganzes Leben so sein.
Bei Benutzern ist das nicht so. Die wollen ihre Arbeit machen
und haben dafür Software, mit der sie gut klarkommen.
Und jetzt kommt irgendjemand und sagt, mit dieser Software,
hier wird alles besser. Das muss man denen erstmal erklären
und beweisen. Denn in der Regel wissen die ziemlich gut,
was sie machen und haben überhaupt kein Interesse an Software,
sondern nur an ihrer Arbeit,
dass sie die hinkriegen.
Also das ist nicht einfach
So, das machen wir dann gleich.
Jetzt machen wir erst mal eine kurze Pause.
So. Weiter geht's. Ihr braucht gar keine Pause, was?
Oder doch? Nee. Okay. Denn ich glaube,
Guido hat euch ja in irgendeiner Vorlesung schon gefragt,
ob hier Raucher sind.
Aber es sind, glaube ich, keine da, ne?
Das ist gut. Er hat euch wahrscheinlich nicht erzählt,
dass er dieses Jahr aufgehört hat zu rauchen.
Nach 30 Jahren.
Mit Akupunktur hat gut geklappt
Er ist clean sozusagen. So, ich will jetzt wenige Worte,
aber ein paar Hinweise für euch zu Projektmanagement sagen.
Es sind, glaube ich, vier Folien oder fünf.
Wie sehr euch das detailliert begegnen wird, hängt so ein bisschen
davon ab, in was für Filmen ihr nachher geratet.
Also, ob ihr eher in kleine Software klitschen kommt oder
in größere Firmen
Alles hat seine Vor- und Nachteile, aber wenn ihr in größere Firmen kommt,
dann werdet ihr viel mit dieser Frage,
was ist Projektmanagement und wie geht das zu tun haben.
Und was man dadurch versucht, ist eigentlich die komplexe Aufgabe,
ein Projekt zu führen in systematische einzelne Teile zu unterteilen.
Und dazu will ich euch ein paar vor, ein paar Ideen geben,
damit ihr wisst, was es da so alles gibt.
Und es gibt also eine Vereinigung von professionellen Projektmanagern, das Project-Management-Institut.
Und das hat diese Themenfelder definiert und gesagt, okay,
so könnte man Projektmanagement betrachten. Aber auch das ist natürlich
wieder nur ein Werkzeugkasten mit Handwerkszeug. Also das ist keine Bandstraße,
auf der man vorne irgendwie ein Autoteil reinschüttet und am Ende
ein Auto rauskommt, sondern das ist ein Werkzeugkasten,
mit dem man losrennt und das Projekt selber macht.
Das ist auch mal hübsch, ne? Gut. Also die haben gesagt,
es gibt, jetzt muss ich mal zählen, neun,
ja, neun, neun verschiedene Feldbereiche im Projektmanagement.
Ich muss also Zeitmanagement machen, ich muss mich also mit der Frage beschäftigen,
wer wann was macht, ich muss Personalmanagement machen,
ich muss Beschaffungsmanagement machen, was glaubt ihr,
wie aufwendig es ist, dafür zu sorgen,
dass alle Leute einen Rechner und ein Telefon haben.
Man guckt ja immer nur von sich selber,
ich fange da Montag an zu arbeiten und gehe davon aus,
dass dann da schon alles sein wird.
Aber das ist ein unglaublicher Aufwand natürlich,
dass das dann tatsächlich da ist,
dass die Software auch im Netz ist,
beziehungsweise der Rechner im Netz ist und dass sie eine Telefonnummer habt und dass ihr dann auch automatisch im Telefonbuch seid.
Ich habe gerade bei einem Kunden meine Telefonnummer gewechselt und es ist also total schwierig,
weil die Leute rufen immer bei einer alten Nummer an,
weil die immer noch im unternehmensweiten Intranet steht und der Prozess,
diese Telefonnummer zu ändern,
unglaublich kompliziert ist
So, also das sind so, so die Ressourcengeschichten,
dann muss man sich um das Geld kümmern, ja,
man muss die Kosten managen, man muss managen,
wie viel Umfang hat die Software,
das hat natürlich viel miteinander zu tun,
diese beiden Sachen hier.
Man muss sich fragen, wie integriert man die verschiedensten Dinge in das Projekt,
da zeige ich euch gleich noch eine Detailfolie zu.
Mein Lieblingsthema, man muss sich um die Qualität kümmern,
ja, Qualitätsmanagement machen, was haben wir eigentlich für Ansprüche und wie geht das?
Man muss Risikomanagement machen, ich weiß nicht,
ob Guido euch das erzählt hat, ein Ding,
was ich immer in Projekten habe,
ist,
ich habe eine Risikoliste
Auf der sind die Risiken des Projekts aufgeschrieben und jeweils mit
einem Smiley, mit solchen Lippen oder so.
Also jedenfalls, wie schlimm das gerade ist. Also Risikomanagement,
auch was, was ich nur empfehlen kann und Kommunikationsmanagement,
wie erfahren eigentlich alle Leute hier, wie wir unsere Arbeit machen.
Das ist in großen Organisationen wirklich nicht so einfach.
Man hat sozusagen als Mensch, hoffe ich, die Vorstellung,
wenn man selber etwas weiß, dann wissen das auch alle anderen.
Das ist aber natürlich nicht so. Ja,
das funktioniert vielleicht noch, wenn man in einem Büro sitzt,
aber sobald man über Bürogrenzen kommt, wissen die Leute das nicht.
Die brauchen Anweisungen, man muss denen das sagen und so.
Ja, also all diese Dinge
In kleinen Organisationen macht das häufig eine Person allein.
In großen Organisationen sind das alles unterschiedliche Personen und die gucken natürlich
auf jedes von diesen Feldern sozusagen, das ist meine Rolle.
Ich bin hier Qualitätsmanager. Und wenn die Software nicht durch
meine Tests gelaufen ist, dann gebe ich die nicht frei.
Also ich hatte schon öfter dann, wenn es darum ging,
schnell Software in Produktion zu bringen, das Problem,
dass der Qualitätsmanager mir gesagt hat, ich gebe keine Freigabe.
Dann muss man gucken, ob man den overruleen kann oder nicht.
Also ob man als Projektleiter in der Hierarchie war da oben
ist und sagen kann, wir machen das aber trotzdem,
wenn man sich das traut oder das ist dann immer so die Frage.
Also wenn das alles einzelne Leute sind, dann muss man
noch eine ganze Menge tun, damit das zusammen funktioniert.
So, also was macht so ein Integrationsmanager, der macht,
der koordiniert die unterschiedlichen Aktivitäten in so einem Projekt, versucht,
die zu integrieren, dass nicht irgendwelche Dinge doppelt getan werden.
Denn in großen Projekten weiß auch der eine vom anderen nichts.
Wir haben ja heutzutage zum Glück E-Mails und wir haben auch
die Möglichkeit, eine E-Mail, die wir schicken,
an ganz viele Leute im CC
zu schicken
Das ist häufig der Ersatz für so einen Integrationsmanager,
der dafür sorgt, dass die ganzen Arbeiten koordiniert wird,
die Leute koordinieren sich über E-Mails und CCs.
Und dann spricht man mit jemandem und der sagt,
ich habe die 50 Mails,
die ich heute bekommen habe, noch nicht gelesen.
Was natürlich dann für die Integration und die Koordination sehr schwierig ist.
Ja, also der kümmert sich um Änderungen der Macht,
Projektplanentwicklung. Das ist eine Rolle, die ich euch nicht
so unbedingt wünschen würde, glaube ich, als Softwareentwickler.
Das schon vielleicht eher. Ja, also ein Projektleiter muss
sich sehr darum kümmern und das müsst ihr möglicherweise auch,
wenn ihr in diese Rolle kommt.
Was ist, wie weit sind wir eigentlich?
Was haben wir geschafft? Sind wir auf dem richtigen Weg
Geht unsere Expedition noch in die richtige Richtung. Ihr erinnert euch
vorhin an dieses Bild, wo ist das Ziel eigentlich?
Was haben wir geschafft? Was können wir das verifizieren?
Was haben wir definiert, was wir schaffen wollten?
Und wie überwachen wir das? Das ist gar nicht so einfach,
besonders weil man von Softwareentwicklern häufig den Ausspruch kriegt,
ja, ich bin zu 99 Prozent fertig.
Oder morgen ist es fertig. Deswegen versucht man ja in
der agilen Softwareentwicklung so vorzugehen, dass man so kleine Brötchen backt.
Und das eigentlich, was fertig ist, nur in der
Software ist. Also wenn die Software das tut,
was sie soll,
dann hat man
etwas fertig
Das ist also das Umfangsmanagement. Dann kommt das Zeitmanagement,
also was haben wir hier vielleicht überhaupt für Termine,
was für Vorgänge haben wir, wie lange sollen sie dauern?
Ein tolles Mittel für sowas ist so ein Plan an der Wand, wo man, wo die Leute alle ihren Urlaub eintragen. Ich weiß nicht,
ob ihr sowas schon mal gesehen habt in Firmen,
aber wenn man dann mal so einer,
vor so einer Wand steht,
wo so eine Art Excel-Tabelle ist und die Leute,
also ich zum Beispiel, ich mache hier ein Kreuz,
da bin ich nicht da und da und da,
bin ich nicht da,
dann wird einem erst klar,
was für Termine man überhaupt machen kann und für den Umfangmanager ist das natürlich auch ganz spannend,
weil der sieht,
was überhaupt zu schaffen ist
Also die müssen ja eng zusammenarbeiten, um rauszukriegen,
wer arbeitet eigentlich, wann und was können wir in der Zeit schaffen.
Es gibt ganz einfache Mittel dafür, man muss sie nur einsetzen.
Also man muss mutig sein und in eingefahrenen Organisationen,
auch mit solchen Dingen dann mal anfangen. Tja,
das Kostenmanagement, also den Job solltet ihr immer ablehnen,
wenn euch jemand den geben will.
Weil Softwareentwicklung ist immer teurer, als man dachte.
Und dann hat man immer die Arschkarte,
weil man immer neues Geld irgendwo herholen muss und so
Macht nicht viel Spaß,
aber irgendjemand muss sich natürlich darum kümmern und gerade in großen Organisationen,
oh ja, wenn ihr mal in die Rolle kommt,
dass ihr für eure Firma neue Arbeit akquirieren sollt.
Eine Frage, die ich versuche, immer zu klären,
wenn ich beim Kunden bin, wo sind ihre Budgets nächstes Jahr?
Was haben Sie geplant? Wer hat hier eigentlich Geld
und könnte mir was davon geben? Und da könnte ich
für ihn Software bauen oder Leute zur Beratung hinschicken.
Das wissen die Leute nämlich meistens schon ein Jahr vorher,
was für Budgets sie haben. Ja,
also das ist so ein bisschen die andere Seite,
dass es die Seite desjenigen,
der kommt und seine Dienste anbietet,
der will in irgendein Budget passen
Und wenn die Firma ein gutes Konstenmanagement macht,
dann kann die einem das auch sagen. Qualitätsmanagement,
das ist bei Softwareentwicklern inzwischen sehr beliebt, oder,
also ich kenne jedenfalls viele Kollegen aus unserer Firma,
die an sowas Spaß hätten, also sicherstellen, dass man,
was sind überhaupt die Qualitätsansprüche, die wir hier haben?
Wie können wir die einhalten oder sogar übertreffen?
Wann muss welche Qualität in der Software erreicht sein?
Also im ersten Schritt ist es vielleicht noch so,
dass wenn man, wenn man auf Schließen drückt,
das dann nicht gespeichert wird, aber das soll beim nächsten Mal funktionieren.
Oder wir wollen in allen Anzeigen die gleichen Daten haben,
die sollen immer konsistent sein, also solche,
sondern kann man auch schon haben.
Wie sichere ich das und wie lenke ich das?
Das ist ein schöner Job,
der macht Spaß
So, und dann Personalmanagement, also wie sorge ich eigentlich dafür,
dass die Leute den richtigen Job in einem Projekt haben?
Das ist auch eine ganz schwierige Aufgabe,
weil meistens ist es ja nicht so,
dass man genug Leute hat, aus denen man sich welche aussuchen kann,
sondern meistens hat man es so, dass man Leute hat,
die zu den Aufgaben nicht passen,
die man da hat und man muss sie irgendwie zusortieren.
Das ist ganz schwierig und in großen Firmen gibt es eigene Abteilungen dafür,
die eben auch Akquise machen und versuchen,
in der Firma Teams zu bilden,
die sich dann entwickeln
Es gibt ganz schöne Auswertungen darüber, dass jeder Mitarbeiter,
den man behält, also dass das Neueinstellen von Leuten,
ich glaube, das Zehnfache kostet, wie Leute zu motivieren,
dass sie in der Firma bleiben.
Also wenn ihr mal mit solchen Personalfragen zu tun habt,
seht zu, dass ihr eure Leute da behaltet,
denn die wissen schon, was über die Firma.
Gut, dann hatten wir noch,
also wir hatten jetzt sechs Felder,
es fehlen noch drei, Kommunikationsmanagement ist ein Teil,
da habe ich vorhin schon darauf abgehoben,
wie kriege ich eigentlich die Information in meiner Firma verteilt
Wir wissen eigentlich alle, was hier in der Firma gerade läuft, wie man arbeitet.
Ihr kennt alle, das kommen sie, ja,
selbst aus eurer Studienerfahrung, bei uns in der Firma,
in der WPS haben wir auch einen Komsi,
um sowas in der Firma zu tun.
Man kann durchaus technische Mittel einsetzen, um sowas zu machen. Ja,
also unsere Projektleiter sind angehalten,
regelmäßig im Komsi über ihr Projektbericht zu erstatten, was läuft,
wie ist der Stand, ja,
was, wie lange reicht das Geld,
was der Kunde einem noch gibt und so weiter
In vielen Projekten, also es ist immer so ein bisschen
die Frage, sind die Leute IT-affin?
Kann man das auch mit einem Wiki machen? In einer Firma,
wo ich jetzt arbeite, ist es aber schwierig,
weil die Leute finden das so schwierig,
ins Wiki was zu schreiben.
Habt ihr schon mal einen Wiki gesehen? Wisst ihr,
was das ist? Oder rede ich jetzt böhmische Dörfer?
Ihr lacht. Okay, wer kennt keinen Wiki?
Ihr kennt alle einen Wiki. Das ist schön.
Das ist ja gut. Toll. Benutzt ihr eins in
SE2 oder was? So, ja, okay.
Aber das ist natürlich ein öffentliches Wiki.
Das ist also keins, was firmeninterne Informationen.
Gut, gut
Meiner Zeit hinterher, ne? Ich habe aber wirklich an
ein firmeninternes Wiki gedacht, wo man sozusagen Firmensachen einsteht.
Gut, dann seid ihr damit angefreundet, aber den
meisten Anwendern fällt es schwer, in sowas Projektinformationen reinzuschreiben.
Die verwenden dafür lieber Word-Dokumente und die liegen dann auf irgendwelchen Laufwerken,
wo sie keiner findet in der Regel.
Also das ist dann blöd. Also insofern kann ich euch
immer nur empfehlen, die Leute auf sowas, ja,
für sowas zu interessieren und ihnen das möglichst leisten,
müßlichst leicht zu machen, damit umzugehen.
Das ist was, was ihr bestimmt tun werdet,
Risikomanagement, also regelmäßig feststellen,
was haben wir hier eigentlich für Projektrisiken,
wie können wir darauf gut reagieren,
was können wir tun
Ja. Das ist eine wichtige Aufgabe, die in der Regel
auch die Architekten oder Softwareentwickler in einem Projekt machen. So,
und das Beschaffungsmanagement, da habe ich vorhin schon drüber geredet,
es ist gar nicht so einfach, erstmal überhaupt die Dinge zu beschaffen,
die man für die tägliche Arbeit braucht,
aber andererseits auch von Dienstleistern Angebote einzuholen, das zu verhandeln,
für uns eines Dienstleister ist es zum Beispiel auch doof,
weil so eine Abteilung, die dieses Beschaffungsmanagement macht,
die haben meistens das Hauptziel,
den Preis zu drücken
Und dann haben wir uns schon über den Umfang der Software geeinigt,
die wir da bauen sollen. Und jetzt müssen wir mit Leuten,
die keine Ahnung von der Softwareentwicklung haben, darüber reden,
für welchen Preis wir das machen. Das macht nicht besonders viel Spaß,
aber das führt dann dazu, dass wir uns demnächst auch jemanden zulegen,
der für uns wiederum die Verhandlungen über den Preis von der anderen Seite macht,
ohne was von Software zu verstehen,
aber eben eine harter Verhandlungspartner zu sein.
Also das ist immer so ein bisschen so eine Wellenbewegung.
Wenn die einen mit sowas anfangen, dann machen die anderen
das auch. Aber für große Organisationen natürlich total sinnvoll,
dass man eine Abteilung hat,
die sich mit diesem ganzen Angebotskram und sowas beschäftigt
Wir in der SPT-Gruppe wünschen uns ja zum Beispiel auch,
dass es irgendwie eine Abteilung gäbe, die sich mit den Klausuren beschäftigt.
Ja, also wir würden am liebsten die Klausur fertig machen,
für euch sie jemandem geben und der macht die Abwicklung.
Ja, das wäre eigentlich ganz leicht,
aber das gibt es nicht in der Uni.
Stattdessen machen wir eine Klausurdurchführung und alle möglichen anderen Leute machen das auch.
Und jeder entwickelt sein eigenes Modell darüber und Vorgehen,
wie man das macht.
Es ist eigentlich dumm. Eigentlich braucht man für sowas
eine zentrale Funktion,
die das macht
Gut, das war so ein bisschen was zu den Dingen,
die man als im Projektmanagement zu erwarten hat.
Und ich will euch jetzt noch etwas sagen, was euch ganz bestimmt,
wenn ihr Software entwickelt, immer wieder begegnen wird,
weil ihr werdet Software-Invasionen entwickeln, ich weiß nicht,
ob ihr schon mal mit einem Versionsmanagementsystem zu tun gehabt habt,
das werde ich gleich mal eine Abfrage machen.
Wenn ihr Software entwickelt im Moment in euren Übungen,
dann schreibt ihr die Klasse einmal oder das Programm einmal,
vielleicht bearbeitet ihr das beim nächsten Mal auch nochmal.
Das ist noch einfach. Aber wenn ihr Software im großen Stil
entwickelt oder überhaupt entwickeln, sodass das irgendjemand nachher benutzt,
Dann müsst ihr euch Gedanken darüber machen,
ich habe hier diese Klasse und da habe ich jene Klasse und die Klassen haben verschiedene Zwecke.
Ihr habt zum Beispiel die Version, auf der ihr gerade arbeitet,
dann ist eine frühere Version von eurer Software schon im Test
und eine noch viel frühere Version ist wahrscheinlich in Produktion eingespielt.
Und das führt auch dazu, dass man in der Regel drei verschiedene,
mindestens drei verschiedene Rechner hat, mit denen man zu tun hat.
Oder ich hoffe, ihr habt das dann nicht nachher nicht. Also man hat einmal seinen Entwicklungsrechner,
ich male das jetzt mal so hier, Entwicklung,
da arbeitet man drauf, da ist gerade die Version,
an der man arbeitet, dann hat man einen Test-Server,
ja, da ist die ältere Version, ich mache mal vier,
drei.
So, das ist aber euer Entwicklungstest-Server wahrscheinlich.
Dann gibt es noch einen für die Benutzer. Zum Testen,
da ist die Version 2 drauf und dann gibt es noch
das, was schon läuft in Produktion.
Da ist die Version 1 drauf
Die ist vielleicht von Mai, Anfang Mai,
vom 1. Mai, diese Version ist vielleicht vom 15. Mai.
Die Version ist wahrscheinlich hoffentlich von gestern oder so.
Was war denn gestern? Zweiter, sechster. Und diese
Version ist von heute, weil ihr da gerade wann baut.
Es war der dritte? Ich weiß es gar nicht.
Ist ja auch egal. So. Und damit muss man umgehen bei
der Entwicklung, denn es kann ja zum Beispiel sein,
dass ihr hier schon ganz viele tolle neue Features gebaut habt
Feature plus plus, ja.
Und hier in Produktion tritt plötzlich ein Fehler auf.
Ja. So, jetzt könntet ihr den Fehler fixen.
Aber in welcher Version würde man den denn jetzt fixen?
Der in Produktion, genau. Man muss ihn auf der
Version hier fixen. Und dann, also, fixen,
ja. Aber das muss man dann ja auf dem System
hier hinten tun,
Und dann muss das wieder durch diese Kette gehen.
Und außerdem muss man es natürlich auch in der Version fixen und in der Version fixen.
Kann man schon ziemlich durcheinander kommen. Also es ist wichtig zu wissen,
auf was man arbeitet, man da gerade und wo ist was.
Um das sinnvoll hinzukriegen, hat man Versionsnummern für Systeme
oder für Dateien oder für ganze Systeme und Komponententeile.
Das ist ein Etikett, man hat auch auf größeren Sammlungsebenen
eine Etikette und in der Regel werden ein Inversionsverwaltungssystem dann
Differenzen gespeichert zwischen diesen einzelnen Versionen
So, es gibt eine ganze Reihe von Produkten, die ihr hier seht,
hat jemand von euch schon mal mit einem von dem gearbeitet,
dann hebe er mal die Hand.
Eine Hand habe ich gesehen, noch eine Hand, noch eine Hand.
Also ein bisschen Erfahrung gibt es schon dazu, noch eine Hand.
Okay. Also, wenn ihr professionell Software entwickelt,
dann müsst ihr eine Versionsverwaltungssystem benutzen, irgend sowas hier.
Ich war mal bei einer Firma,
da hatten die sowas nicht und da ging Softwareentwicklung so,
der eine hat auf seinem Rechner was programmiert und wenn er einen Stand hatte,
der ihm gefiel,
dann hat er das auf den USB-Stick getan und den anderen
zwei Entwicklern übergeben und die haben dann ihre Änderungen da reingepflegt
Und dann haben die das noch zusammengeführt und dann dem ersten wiedergegeben.
Ich hoffe, ihr könnt euch vorstellen, wie viel Arbeit das ist.
Das versucht man durch so einen Versionsverwaltungssystem zu umgehen. Die unterstützen einen dabei,
dass man sozusagen wenigstens irgendwie auf einem gemeinsamen Stand arbeiten kann.
So, und in der Regel ist es so,
dass man also in einem Java, in einem Eclipse-Projekt oder sowas,
sagen wir mal, fünf Files hat da drin,
fünf Klassen, ja,
so ein Versionsverwaltungssystem arbeitet immer auf Pfeilebene.
Man kann also in so einem System auch Dokumente einchecken,
also Word-Dokumente oder irgendwas und die mitversionieren, wenn man das will.
Und diese Files kriegen jedes Mal,
jedes Mal, wenn sie jemand speichert,
eine neue Versionsnummer
Das ist, das kommt einem erstmal ein bisschen übertrieben vor,
aber wenn ihr mal selber zum Beispiel einen Text geschrieben habt,
einen längeren Text und gemerkt habt, dass ihr, wenn ihr das,
also oder mit anderen Leuten zusammen einen Text geschrieben habt,
will ich mal so sagen,
dann werdet ihr gemerkt haben, dass ihr anfangt,
die Word-Dokumente abzuspeichern mit eurem Namenskürtel dahinter oder mit einem Datum.
Also ihr fangt selber an, so was zu tun,
so eine Versionierung. Und es ist doch klasse, wenn
ein System einen dabei unterstützen kann. Ja, und die Software,
die dann entweder auf dem Produktionsserver oder auf dem Testserver oder wo ist,
setzt sich also zusammen aus verschiedenen Version von diesen Falls.
Das muss noch auch noch bestimmt werden. Was gehört eigentlich
zusammen und lässt sich als System verwenden und sowas nennt man in der Regel einen Tag.
Ja, wir machen jetzt mal wieder in unserem Versionsverwaltungssystem
einen Tag und dann haben wir mal wieder eine Software hergestellt, die zusammen funktioniert.
So, Und wenn man jetzt noch anfängt,
dass verschiedene Leute an verschiedenen Sachen gleichzeitig arbeiten,
dann entwickeln sich solche Branches in Software.
Das heißt, es gibt den Hauptentwicklungszweig und wenn man davon,
wenn man etwas anfängt zu bauen, an so einem Softwaresystem,
dann geht man in so einen Nebenbranch.
Ja, man macht also eine Revision davon und fängt seine eigenen Sachen an zu malen.
Aber der erste war aber der hier, ne?
Erstmal der 1-5-4er-Branch und dann,
nee, der 1-5-2er war vorher,
okay, an der Nummer erkennt man die dann.
Und dann gibt es hiervon wieder nochmal einen Branch und beliebig
viele verschiedene Branches, die alle ihre eigene Versionsnummer haben.
Und immer am Ende kommt eine neue Nummer hinzu.
Also das ist 1,5,4. Und wenn man davon wieder eine andere Variante macht,
dann gibt es die 1,37 und der unterscheidet sich von dem hier über die zwei.
Die haben alle zwei hier. Und dahinter geht es dann weiter.
Also das kann beliebig kompliziert werden. Und diese Branches alle
wieder zusammenzuführen, das ist dann die große Kunst,
damit man irgendwann hier auf seinem Hauptentwicklungszweig wieder ein System hat.
Wenn ihr Sommer an diesem Softwareentwicklungspraktikum teilnimmt, was wir da in SPT veranstalten,
dann werdet ihr auch eure ersten Erfahrungen mit solchen Versionsverwaltungssystemen zu tun haben und bekommen.
Ich kann das jedem, der das noch nie gemacht hat,
auch nur empfehlen, dass in der Uni mal zu lernen,
wie sowas geht, bevor ihr in der Praxis damit zu tun habt.
Und jeder kann hier auf seinem Pfad sozusagen alleine entwickeln und
irgendwann muss man sich aber wieder zusammenführen.
Gut, was sagt die Uhr? Ich glaube,
jetzt werde ich mal Ich habe mir, glaube ich,
zu viel vorgenommen für heute,
deswegen werde ich jetzt mal springen und drehe deswegen meinen Rechner mal um,
damit ich da besser rankomme.
Mal sehen, ob das geht, ohne dass das sich verabschiedet.
Flub. Ja, das geht. Weil ich will nämlich
jetzt mal hier raus verwerfen und will nach hinten springen und
euch noch was hier erzählen.
Doch. Okay. Also es kommen jetzt die letzten
drei Folien und dann könnt ihr nach Hause gehen
Mir ist noch wichtig, euch zu vermitteln, dass es
auch Modelle wiederum darüber gibt, wie gut Software-Prozesse sind.
Und weil in der Informatik so Kürze so beliebt sind,
möchte ich, dass ihr wisst, wie, nee,
ach Mann, ich wollte doch da.
So, und jetzt zurück. So, eins der
heutzutage bekanntesten Modelle ist das CMM
Also, das Capability-Moturity-Modell, das wurde an der Carnegie Melan University entwickelt,
wenn ihr mal ein Jahr oder ein halbes oder ein Semester
ins Ausland gehen wollt, dann geht an die Carnegie Melan University.
Das ist eine wirklich tolle Universität,
die machen da ganz tolle Sachen mit Softwarearchitektur und so.
Also, nur falls jemand sich das überlegt.
Aber unabhängig von diesem Modell,
die machen ganz viele Sachen im Bereich Architektur und dieses Modell
ist also schon ein bisschen älter von 1977 und es dient
dazu zu beurteilen,
wie gut
ein Software-Lieferant ist
Und Firmen bemühen sich also,
sich einen möglichst hohen Standard in diesem Modell zu haben,
damit man sagen kann, oh,
wir sind aber auf Ebene 5 von dem CMI oder CMM und sind deswegen besonders gute Lieferanten und man kann sich auf uns verlassen.
Es gibt fünf Prozessstufen und die aufeinander aufbauen und wenn wir die gleich mal angucken,
dann werdet ihr sehen, dass je nachdem, in was für eines,
von der Größe der Firma hängt das sicherlich auch ab,
aber wo ihr da hinkommt, werdet ihr sehen,
dass ihr,
wenn ihr in eine Firma reinkommt,
auch die Firma so ein bisschen einordnen könnt mit diesem Modell
Also heute wird es, deswegen war ich eben in Verwirrung,
CMMI genannt und ich überlege die ganze Zeit,
was dieses I eigentlich heißt, aber das ist auch nicht so wichtig.
Das könnt ihr ja bei der Carnegie Melan dann mal nachlesen und mir dann erzählen.
Also, wenn man in einer neu gegründeten kleinen Firma ist,
dann wird man in der Regel wahrscheinlich in einer Firma arbeiten,
die relativ chaotisch vorgeht.
Das heißt, es gibt keine Prozesse, keine Vorgaben,
wie Software entwickelt wird, wie Qualitätsmanagement gemacht wird,
sondern die Leute arbeiten einfach ab ad hoc.
Es ist nicht klar, was es kosten wird,
man weiß auch nicht,
wie lange es dauert und welche Qualität es hat,
weiß man auch nicht
Man hat also so etwas wie so eine Künstler-Mentalität in
der Software-Firma und die Leute arbeiten halt irgendwie.
Hat jemand von euch schon mal bei so einer Firma gearbeitet?
Die man auf dieser Ebene einordnen könnte? Wow, dann
wart ihr ja einen richtig tollen Firmen. Gut. Wenn man in Firmen kommt,
die sich schon ein bisschen entwickelt haben,
also auf die zweite Stufe, das ist Stufe 1,
das ist Stufe 2, 3, 4, 5,
dann läuft zwar immer noch alles nicht wirklich aufgeschrieben,
aber es gibt sozusagen in der Firma vorgehen.
Also die Leute können einem sagen, wie sie Software entwickeln, ja,
in der Firma. Es gibt also ein informelles Vorgehen,
das hat aber auch sehr viel mit den Leuten zu tun.
Da würde man dann so Sachen hören wie, ja,
Herr Meier macht immer genau das und das, ja,
oder wegen Herrn XY gehen wir genau so vor.
Also das ist dann sehr an die Person,
an die Individuen gebunden. Man hat so ein bisschen Terminkontrolle,
aber was die Kosten und die Qualität angeht,
ist man immer noch nicht wirklich auf einem Vorhersehbar, sehr sagbaren Zweich.
So, wenn man auf CMM 3 angekommen ist,
dann ist das schon ganz gut.
Man hat, kann zuverlässig was über Kosten und Termine sagen
Man hat den Prozess irgendwie institutionalisiert. Das heißt,
es gibt jemanden, der sich darum kümmert,
dass der Prozess eingehalten wird und der ist auch irgendwo beschrieben.
Was noch für Verbesserungswürdig ist, ist die Qualität an der Stelle.
Da kann man immer noch nicht so viele Aussagen drüber machen.
So, wenn man auf Level 4 angekommen ist,
dann kann man das messen.
Deswegen steht hier qualitativ und da steht quantitativ.
Wenn etwas quantitativ ist, dann ist es immer messbar.
Bei qualitativen Sachen kann man nur etwas darüber aussagen. Also ja,
wir machen das schon ganz gut und wir haben da,
so sind ungefähr immer die Kosten und so
Hier gibt es also eine richtig gute statistische Kontrolle darüber,
über die Produktqualität und auch der Prozess wird über Metriken gesteuert,
dass man also, wenn ihr an agile Prozesse zum Beispiel denkt,
da kann man sich locker auf diese Ebene begeben,
weil man macht, wie ihr bei dem Lego-Beispiel ja hoffentlich gelernt habt,
wenn ihr schon das gemacht habt in den Gruppen,
man schreibt Storycards und man schätzt,
wie lange man wohl braucht und man könnte theoretisch hinterher auch draufschreiben,
wie viele Minuten man nun gebraucht hat,
um eine Mondbasis zu bauen, wo, weiß ich,
was Betten drin sind oder irgend so was, ja,
also ein agiler Prozess ist eigentlich schon auf der Ebene,
Vielleicht sogar auf der nächsten.
Wollen wir uns den mal angucken? Also rückgekoppelt. Das heißt,
wir haben eine Basis von Zahlen. Und wir können vorhersagen,
was passiert und vor allen Dingen den Prozess verbessern.
Also wir können aus diesen Zahlen gleichzeitig etwas sagen,
wie es besser gehen soll, wo wir uns kostenmäßig verbessern können.
Das ist dann auch die hohe Kunst bei Agilen. Prozessen,
aber mindestens hier, wenn man es richtig macht,
ist ein Scrum oder ein agiler Prozess
Ihr habt ja, naja gut,
ihr habt das gar nicht unter dem Titel Scrum gelernt wahrscheinlich,
was ihr mit dem Lego gemacht habt, das war agil.
Okay, dann vergesst Scrum wieder, das lernt ihr irgendwann anders. Gut,
die Hoffnung ist, dass je mehr man in einer Firma
nach oben kommt hier, dass das Risiko singt,
was am Ende bei so einem Projekt rauskommt.
Das ist sicherlich eine wichtige Sache,
wenn man das da oben, aber sehr bürokratisch treibt,
dann singt natürlich auch die Geschwindigkeit, mit der man was hinkriegt.
Also das ist immer so ein bisschen,
wenn man in einer kleinen Firma arbeitet,
wo sehr viel ad hoc läuft,
kann es auch einfach
viel schneller gehen
Oben muss man alle möglichen Leute informieren. Also man kann
sich das fragen, ob sozusagen die Zeit für Änderungen
hier unten nicht schneller ist als da oben.
Aber was nützt es einem, eine schnelle Änderung zu kriegen,
wenn der Rest des Systems zusammenbricht?
Das müsste einem wenig. Gut. Das lassen wir mal
hinter uns und wenden uns der Zusammenfassung an,
damit ihr auch noch ein bisschen was von dem schönen Wetter haben könnt heute.
Software haben wir heute hoffentlich gelernt, wird also in Projekten entwickelt,
normalerweise und Projekte sind auf ein Ziel ausgerichtet und deswegen auch zeitlich begrenzt,
weil man irgendwann dieses Ziel normalerweise erreicht hat.
Ja, also es gibt einen vorübergehenden Zusammenhalt in einer Projektgruppe.
Man kann eine ganze Menge tun im Bereich Projektmanagement und auch viel lernen über Softwareverwaltung.
Da habe ich euch eben so nur so einen kleinen Blick
drauf gegeben auf Versionen von Softwaresystemen und deren Teilen.
Das Ganze ist aber immer situativ. Ja, also es
gibt keine Vorgaben darüber, wie ein Softwareprojekt sein muss.
Genau, es gibt verschiedene Projekttypen und die erfordern ganz unterschiedliche Maßnahmen
So, diesen Punkt haben wir uns nicht angeguckt heute,
den lernt ihr, glaube ich, auch mehr in den Übungen.
Deswegen habe ich das eben weggelassen, weil es einfach
zu viel war. Was wir uns angeguckt haben,
ist, dass Softwareprojekte anhand des CMMIs auf ihren Reifegrad hin
überprüft werden können und auch ganze Firmen natürlich.
Gut, dann war es das für heute.
Ich wünsche euch noch einen schönen Tag und wir sehen uns
nächste Woche