[0:00] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den

[0:08] IT-Berufen. In dieser Episode geht es um den sinnvollen Aufbau eines Anwendungsentwicklungs-

[0:13] Abschlussprojekts. Viel Spaß dabei! Hallo und herzlich willkommen zur 185. Episode des

[0:24] IT-Berufe-Podcast. Mein Name ist Stefan Macke und heute geht es mal um ein Thema, was mir

[0:29] persönlich sehr im Herzen liegt und zwar den sinnvollen Aufbau eines Projekts der

[0:34] Anwendungsentwicklung. So habe ich es mal für mich intern genannt. Was soll das heißen? Ich

[0:38] lese ja sehr viele Projektdokumentationen, die ich dann auch bewerten darf als IHK-Prüfer und

[0:43] ich stelle da fest, dass viele einfach nicht so richtig sinnvoll geschrieben sind, sage ich mal

[0:49] vorsichtig. Ja, da sind ganz viele Artefakte vielleicht drin, die aber irgendwie komisch

[0:53] platziert sind oder man hat den Eindruck, die werden einfach nur reingepflanscht, weil

[0:56] Überraschung, irgendwer im Internet das gesagt hat, dass man das machen soll. Da wird irgendwie

[1:01] mit Can-Ban gearbeitet, aber man erkennt das gar nicht am Projektablauf oder es wird mit Scrum

[1:06] gearbeitet, aber es gibt ein Lastenheft und ja, verschiedene komische Sachen und ich habe gedacht,

[1:12] ich mache mal eine Episode dazu, wie ich meinen eigenen Azubis empfehle, ihr Anwendungsentwicklungs-

[1:17] Abschlussprojekt aufzubauen. Ich habe ja auch eine Vorlage für die Projektdokumentation online,

[1:23] sowohl kostenfrei für LaTeX als auch kostenpflichtig für Word und OpenOffice oder

[1:27] LibreOffice und da ist ja schon ein gewisser Aufbau, sage ich mal, vorgegeben in Anführungszeichen und

[1:34] das ist, ja, wie soll ich sagen, das ist schon sinnvoll, dieser Aufbau. Den habe ich mir nicht

[1:39] einfach so ausgedacht, sondern ich möchte mal ein bisschen erklären, was so dahinter steckt,

[1:45] warum man vielleicht ein Projekt so umsetzen sollte und dann wird da auch insgesamt einfach

[1:48] ein Schuh daraus. Wenn man die Projektdokumentationen liest, dann ergibt sich ein roter Faden. Man

[1:52] merkt, aha, da wurde aufeinander aufbauend auf den einzelnen Projektphasen gearbeitet. Das ist

[1:57] auch sinnvoll, was da gemacht wurde und das ist nicht eine Sammlung von zusammenhanglosen Dingen,

[2:03] die da zusammengeklatscht werden. Ich übertreibe jetzt mal. Ich bin natürlich überzogen hart jetzt

[2:07] mit der Kritik hier, aber in manchen Dokus denkt man wirklich so, da wurde einfach was abgearbeitet,

[2:11] ohne Sinn und Verstand so ein bisschen. Und da möchte ich heute mal entgegenwirken. Und wie

[2:15] ich das heute aufgebaut habe, so wie ich mir das vorgenommen habe hier, würde ich erstmal anfangen

[2:20] mit der Auswahl des Vorgehensmodells, weil da steht und fällt schon ganz, ganz viel damit,

[2:24] wie sinnvoll das noch umzusetzen ist oder vor allem, wie sinnvoll man die Doku lesen kann. Dann,

[2:29] wie man Artefakte methodisch einsetzt und mit Artefakten meine ich sowas wie UML-Diagramme

[2:34] oder EPKs oder irgendwelche anderen Darstellungen. Das muss gar nicht unbedingt UML sein. Das kann

[2:39] auch Code sein oder, keine Ahnung, ein Testprotokoll. Irgendwas, was man halt erstellt,

[2:44] was meistens in den Anhang der Projektdokumentation dann gepackt wird. Also nichts, was Fließtext ist,

[2:49] sondern quasi alles, womit man nachweist, was man eigentlich in dem Projekt so umgesetzt hat.

[2:52] Die sollte man meiner Meinung nach sinnvoll einsetzen und nicht einfach hinklatschen. Aber

[2:56] da gehen wir dann gleich drauf ein. Und dann gehe ich mal so die üblichen Phasen eines

[2:59] Anwendungsentwicklungsprojektes durch. Das fängt an mit der Aufnahme der Anforderungen. Dann kommen

[3:04] wir zum Lösungsentwurf und das wird der längste Teil auf jeden Fall, weil da kann man am besten

[3:08] zeigen, dass man auch methodisch entwickelt und nicht einfach drauf los programmiert. Dann geht

[3:14] es natürlich auch um die Implementierung selbst. Dann auf jeden Fall Qualitätssicherung, was ganz

[3:17] wichtig ist. Dokumentation. Und am Ende habe ich dann noch einen Beispielablauf mir überlegt für

[3:23] ein fiktives Projekt mit sinnvollen Artefakten und wie man das methodisch entwickeln, umsetzen

[3:28] kann und aufeinander aufbauend dann auch in der Projektdokumentation gut nachvollziehbar und

[3:33] verständlich beschreiben kann. Das wäre so mein Ziel für heute. Und dann gucken wir mal, wie lange

[3:37] ich brauche. Könnte ein bisschen länger dauern, weil das ist echt mein Lieblingsthema gefühlt.

[3:42] Immer wenn ich die Dokus lese, denke ich mir, Mensch, in Skinner, da hätte man noch einmal

[3:45] darüber nachdenken können, was da jetzt hingeschrieben wurde. Das passt doch einfach

[3:48] nicht. Und ja, darum soll es heute gehen. Ganz wichtig vielleicht nochmal vorweg, es geht mir

[3:54] jetzt heute nicht um das gesamte Projekt mit Amortisationsrechnung und Wirtschaftlichkeit

[3:58] und Projektmanagement und Ressourcenplan und so, sondern mir geht es wirklich um die Umsetzung

[4:03] eines Softwareentwicklungsprojektes. Also für den Ausbildungsbüro, Fachinformatiker,

[4:07] Fachinformatikerin für Anwendungsentwicklung. Für die anderen IT-Berufe kann ich jetzt hier

[4:12] nicht sprechen. Dazu habe ich viel zu wenig Dokus gelesen und bin ja auch selber nicht Prüfer in

[4:16] dem Bereich. Aber für die Anwendungsentwicklung, glaube ich, habe ich jetzt ein bisschen Erfahrung

[4:20] mitgebracht. Und so wie ich mir ein Projekt sinnvoll vorstellen würde, was den Kern des

[4:25] Projekts, also den Kern dieses Berufs, die Softwareentwicklung angeht, da möchte ich heute

[4:30] mal ein bisschen drauf eingehen. Den anderen Kram bitte nicht falsch verstehen. Wirtschaftlichkeit,

[4:33] Amortisation, alles, was ich gerade genannt habe, ist absolut wichtig. Gehört in jede Dokumentreihen.

[4:37] Ja, unbedingt. Nicht jetzt hier. Der Macker hat aber gesagt, es geht nur um die Softwareentwicklung.

[4:42] Nein, nein, nein, nein. Wir machen hier auch eine kaufmännische Ausbildung. Da gehört das

[4:47] andere natürlich mit dazu. Das habe ich oft genug auch hier im Podcast gesagt. Ich sehe aber,

[4:51] dass das bei den meisten Projekten eigentlich relativ gut läuft. Aber der Kern, nämlich die

[4:56] Softwareentwicklung, da hakt es dann ganz oft. Und deswegen möchte ich da heute mal drauf eingehen.

[5:00] Bitte nicht falsch verstehen. Das andere gehört genauso dazu. Man kann nicht sagen,

[5:04] ich habe keine Wirtschaftlichkeitsbetrachtung gemacht, weil ich werde ja Softwareentwickler.

[5:08] Das geht leider nicht. Ja, das gehört auf jeden Fall auch dazu. So, dann würde ich sagen,

[5:13] starten wir doch mit der Wahl des Vorgehensmodells. Was meine ich damit? Also,

[5:19] du wirst sicherlich wahrscheinlich sogar schon für die AP1, aber spätestens für die AP2 gelernt

[5:24] haben, dass es verschiedene Vorgehensmodelle bei der Softwareentwicklung gibt. Ich nenne mal ein

[5:27] paar Wasserfallmodelle, Spiralmodelle, Scrum, XP, Kanban. Und viele Azubis oder Prüflinge sagen

[5:36] natürlich heute, ja, wir entwickeln natürlich agile Unternehmen. Scrum oder XP oder Kanban.

[5:41] Das ist so der moderne Kram. Und das ist auch sicherlich richtig. Also,

[5:45] viele Unternehmen entwickeln mit diesen Vorgehensmodellen, mit den agilen Vorgehensmodellen.

[5:49] Ich selber bin auch ganz starker Verwächter davon, finde das super. Keine Frage. Aber eine

[5:54] Frage stellt sich. Und zwar, ist es das richtige Modell für ein IHK-Abschlussprojekt? Und da muss

[5:59] ich leider sehr häufig sagen, nein, ist es nicht. Und trotzdem wird es aber gewählt, weil es halt

[6:05] man muss das halt so machen. Übrigens, ganz schlechte Begründung ist eigentlich,

[6:09] ich muss das so machen, weil bei uns im Unternehmen machen wir das halt so. Das mag

[6:14] sein, dass das so ist. Aber die Frage ist, ist das für dieses Projekt, was du selbst als Prüfling

[6:18] zu verantworten hast, denn die richtige Entscheidung? Und das wollen wir ja in der

[6:22] Prüfung herausfinden, ob du in der Lage bist, selbst Entscheidungen zu treffen und, wie sagt

[6:26] man so schön, the right tool for the job zu nehmen und nicht das, was dein Chef dir vorgibt,

[6:31] was du machen musst. Das heißt, man könnte wenigstens, wenn man gezwungen wird, irgendwas

[6:35] zu machen, also das Erste würde ich immer sagen, sprich mal mit deinem Chef und sag du,

[6:39] in der Firma ist das okay, da machen wir so, aber das hier ist ein IHK-Projekt,

[6:43] das hat andere Anforderungen. Da müssen wir in 80 Stunden als Anwendungsentwickler,

[6:47] Anwendungsentwicklerin irgendwie was umsetzen und da kann ich jetzt schlecht Scrum machen. Warum

[6:52] komme ich da nicht mal drauf? Und wenn der Chef dann sagt, du musst das aber machen,

[6:55] dann sag dir doch mal, hast du dich mal mit den Anforderungen an dieses IHK-Abschlussprojekt

[6:59] auseinandergesetzt? Das passt einfach nicht. Und vielleicht kannst du ein bisschen dann argumentieren,

[7:03] so wie ich es gleich auch erkläre, warum es nicht passt. Aber grundsätzlich finde ich es immer eine

[7:06] schlechte Begründung. Mein Chef sagt, ich soll das so machen, also mache ich das. Denn du wirst ja,

[7:11] wenn du diese Prüfung dann erfolgreich bestanden hast, ein selbstständig arbeitender Fachinformatiker

[7:17] oder eine Fachinformatikerin sein und du musst eigene Entscheidungen treffen. Du kannst nicht

[7:20] für jeden Fitzel immer deinen Chef fragen, soll ich das links oder rechts machen? Dafür

[7:24] wurdest du ausgebildet, dass du, wie sagt man so schön, berufliche Handlungskompetenz hast. Das

[7:30] heißt, du musst entscheiden, wie du deine Software am sinnvollsten entwickelst. Und wenn das irgendwie

[7:34] komisch ist und nicht passt zu dem, wie du dir das vorstellst, dann musst du es ansprechen. Das

[7:38] würde ich erwarten. Und selbst wenn das während der Ausbildung schwierig ist und du deinem Chef

[7:42] nicht widersprechen willst, was ich völlig verstehen kann, dann könntest du trotzdem

[7:46] deine Projektdokumentation ja einen Satz dazu schreiben, wie eigentlich weiß ich, dass das hier

[7:50] nicht so toll passt für dieses Projekt, aber ich habe es trotzdem gemacht, weil wir machen das

[7:55] halt so. Ja, das ist ja okay. Oder du erklärst es im Wachgespräch, wie auch immer. Gut, worauf wollte

[7:59] ich eigentlich hinaus? Es ist wichtig, dass du eigene Entscheidungen triffst und die vor allem

[8:02] auch begründest. Manchmal ist es ja auch gut, das zu machen, was das Unternehmen vorgibt, weil es

[8:07] dafür auch einen guten Grund gibt. Das ist ja in Ordnung. Also zum Beispiel jetzt, wenn ihr ein

[8:10] Unternehmen nur mit Java entwickelt, dann zu sagen, ich habe aber jetzt C Sharp genommen, weil ich das

[8:14] geiler finde. Das ist halt sehr schwer zu begründen. Also von daher muss man mal ein bisschen gucken,

[8:18] wie das jetzt im konkreten Fall dann aussieht. Aber so, wie komme ich jetzt zurück, zu dem,

[8:23] was ich eigentlich sagen wollte? Ich wollte sagen, viele Prüflinge machen heute agile Softwareentwicklung

[8:28] im Unternehmen und das ist auch super. Ich persönlich finde das aber für so ein IHK-Abschlussprojekt

[8:32] einfach sehr, sehr ungeeignet. Ja, aus verschiedenen Gründen. Fangen wir mit dem ersten an. Agile

[8:37] Softwareentwicklung zeichnet sich ja dadurch aus, dass ich den Prozess anpassen kann. Das ist ja

[8:41] quasi diese Agilität in den agilen Vorgehensmodellen. Dafür mache ich zum Beispiel bei Scrum sowas wie

[8:46] eine Retrospektive und stelle fest, passt das alles noch? Müssen wir Meetings verändern? Ist der

[8:50] Sprint zu kurz? Etc. Also wir passen den Prozess an sich an. Und diese Prozesse basieren aber sehr

[8:56] häufig darauf, dass ich auch mit mehreren Leuten im Team arbeite. Also zum Beispiel in einem

[9:00] Entwicklerteam. Ich habe einen Scrum Master, einen Product Owner oder irgendeine andere Rolle bei den

[9:04] anderen Prozessen. Und ich weiß nicht, ob du es schon wusstest, aber das IHK-Abschlussprojekt musst

[9:09] du alleine umsetzen. Und zwar komplett alleine, weil das ja deine Prüfungsleistung ist. Das heißt,

[9:14] ich weiß nicht, wie das Sinn macht, dass du in einem Prozess entwickelst, der eigentlich für ein

[9:19] Team gedacht ist, aber mit dir selber das machst. Und vor allem sind die agilen Prozesse ja auch

[9:25] darauf ausgelegt. Das ist ein wichtiger Punkt auch aus dem Agilen Manifest, dass du auf sich

[9:29] ändernde Anforderungen reagieren musst. Und das ist in echten Projekten absolut sinnvoll. Wenn man

[9:34] Projekte hat, die zwei, drei Jahre dauern oder vielleicht auch fünf Monate nur, ist okay. Da

[9:38] wird sich viel ändern. Aber in einem 80-Stunden-Projekt, wovon wir sagen wir mal 40, 50 Stunden

[9:44] für die Implementierung haben, weil du musst ja Projektenplanung und alles noch drumherum machen,

[9:48] dass sich da noch siebenmal die Anforderungen ändern, ist relativ unwahrscheinlich. Und wenn

[9:53] es passiert, hast du einfach super schlecht geplant. Weil du musst überlegen, das ist ein

[9:56] Projekt, das also Netto Programmierzeit eine Woche, insgesamte Laufzeit zwei Wochen. Wenn

[10:01] du da anfängst mittendrin festzustellen, huch, ich habe falsch rum programmiert, ich muss jetzt

[10:04] was ändern. Ich glaube, das ist doch ein bisschen klein. Das hätte man vorher vielleicht erkennen

[10:09] können, dass man es falsch macht. Also im Prinzip alles, was diese Agilen Prozessmodelle ausmacht

[10:13] und wofür die gut sind, passt nicht zu einem Jakabisches Projekt. Du hast eine fixe vorgegebene

[10:18] Zeit, die du nicht überschreiten darfst. Du hast 80 Stunden Zeit, die musst du exakt einhalten. Es

[10:23] wird weder weniger noch mehr Zeit gebraucht. Mehr ist noch schlimmer als weniger. Es gibt ja Leute,

[10:28] die so Puffer einplanen, bitte nicht machen. Ja, verplanen die 80 Stunden, das ist sowieso viel zu

[10:32] wenig Zeit für so ein Projekt, sind wir ganz ehrlich. Das weiß auch jeder. Also du hast eine

[10:36] feste Vorgabe. Du musst ganz genaue Vorgaben der IHK erfüllen, was den den Umfang, die Komplexität

[10:43] etc. dieses Projekts angeht. Und da kannst du nicht noch dreimal irgendwas ändern mit dem Kunden

[10:48] abstimmen. Das ist einfach nicht vorgesehen in dieser Zeit. Und dann kommt das Problem, wo ich

[10:53] oft darauf stoße, ich habe ein Vorgehensmodell, was halt irgendwie hip und cool ist, weil man das

[10:58] halt machen will, so Scrum und so. Aber dann stellt man fest, dass in der Projektdokumentation dann

[11:01] zum Beispiel Artefakte auftauchen, die gar nichts mit Scrum zu tun haben. Zum Beispiel Lastenpflichtenheft,

[11:06] weil natürlich die Anforderungen an dieses Projekt feststehen und man die in 80 Stunden fertig haben

[11:11] muss. Es ist nicht so, joa, ich fange jetzt mal an zu entwickeln und dann gucke ich mal, ob ich

[11:14] nächste Woche fertig bin und wenn nicht, dann machen wir halt noch einen Sprint länger. Nee, das geht halt

[11:18] nicht, weil du hast nur zwei Wochen, die musst du einhalten. Also dieser ganze Prozess passt nicht

[11:23] dazu. Und das sieht man dann, dass in der Projektdokumentation quasi die klassischen Artefakte

[11:28] wieder auftauchen, wie Lastenpflichtenheft. Oder, weiß ich nicht, man redet dann von Scrum, aber hat

[11:35] das Ding ja eigentlich alleine entwickelt. Das heißt, es gibt gar keinen Scrum Master, keinen

[11:38] Product Owner. Also warum mache ich dann Scrum mit mir selbst? Und vor allem, wie lang ist denn

[11:43] der Sprint? Drei Stunden? Also was soll ich aus einem Sprint für den nächsten Sprint lernen, wenn

[11:49] ich insgesamt nur zwei Wochen Zeit habe für das ganze Projekt? Wie soll das funktionieren? Also das

[11:52] geht gar nicht. Und mache ich dann die Retrospektive mit mir selbst? Oder was passiert dann? Also das

[11:58] passt einfach nicht. Und was man dann als allererstes sieht, ganz oft in der Projektdoku, weil das meist

[12:03] ganz weit oben steht, die klassischen Wasserfallphasen von Analyse, Entwurf, Implementierung, Test, die

[12:09] werden dann eins zu eins umgesetzt. Und danach gliedert sich auch ganz oft die Projektdokumentation,

[12:12] obwohl man die ja eigentlich gar nicht überläuft, weil man ja Scrum macht. Also wie passt das

[12:16] zusammen? Und das ist irgendwie komplett dämlich. Sorry, das muss ich einfach immer wieder sagen. Da

[12:21] wird einfach nur irgendwas genommen, weil man glaubt, dass das cool ist oder weil das Unternehmen das

[12:25] will. Aber es passt einfach null zu diesem Projekt. Also meine Erfahrung aus allen Dokus,

[12:30] die ich bislang gelesen habe, das ist jetzt meine persönliche Einschätzung. Zu einem IHK-Abschlussprojekt

[12:35] passt nur das Wasserfallmodell, weil es so eine kurze Phase ist, zwei Wochen, die man Zeit hat,

[12:41] in der alles umgesetzt sein muss, von der ersten Anforderung bis zur fertigen Implementierung. Das

[12:46] passt einfach nicht zu einem agierenden Prozess. Das ist leider einfach so. Wenn du ein anderes

[12:50] Beispiel hast, wo das gut funktioniert hat und wo du vielleicht sogar eine Doku hast, die gut

[12:54] bewertet wurde, wo das so gemacht wurde, gerne her damit. Ich lasse mich gerne von einem Gegenteil

[12:59] überzeugen. Aber meine persönliche Meinung ist, da ist einfach das Ziel dieses Prozesses nicht

[13:05] umgesetzt. Das ist einfach so. Ich habe noch ein paar mehr Beispiele. Da hat jemand Scrum gewählt,

[13:10] aber dann quasi, weil es ja auch so im Buch steht bei Scrum. Ich glaube, im Originalbuch war der

[13:14] Sprint mal irgendwie 30 Tage lang, also irgendwie vier Wochen. Und dann hat jemand das angepasst auf

[13:18] zwei Wochen. Das heißt, das gesamte Projekt war ein Sprint. Dann frage ich mich schon,

[13:22] warum mache ich dann Scrum? Also es ist, es passt einfach nicht. Ich kann ja nichts lernen in der

[13:27] Iteration, weil es keine zweite Iteration gibt. Also naja, gut. Ich habe jetzt oft genug darüber

[13:32] geredet. Ich glaube, du weißt, wo ich hin will. Ja, es muss halt irgendwie stimmig sein. Es muss

[13:36] passen. Und wenn ich dann die Doku lese und alles geht in Richtung Wasserfall, aber es wird ständig

[13:41] gesagt, dass man Scrum gemacht hat. Das passt einfach nicht. Das ist einfach nicht richtig.

[13:45] Anderes Beispiel, was ich auch schon mal hatte oder ganz oft sogar, dass jemand Extreme Programming

[13:49] benutzt hat. Ich habe, glaube ich, auch schon 27 Mal die Anekdote erzählt, dass jemand gesagt hat,

[13:53] ich habe XP gemacht. Und dann haben wir gefragt im Fachgespräch, was heißt denn eigentlich XP,

[13:57] Extreme Programming? Ja, das heißt programmieren ohne Regeln. So auf Deutsch gesagt, ich fange

[14:01] einfach mal an zu programmieren, scheiß da drauf. Passt schon irgendwie. Und das ist natürlich völlig

[14:05] falsch, weil XP hat so die härtesten Anforderungen an einen Prozess bei der Softwareentwicklung

[14:09] überhaupt. Scrum gibt überhaupt gar keine Vorgaben, ist ja nur für das Projekt Management ein

[14:13] Framework. Aber XP macht ganz harte Vorgaben, zum Beispiel die Praktiken, Pair Programming,

[14:17] Test Driven Development, 40-Hour Workweek etc. Das sind so die Dinge, die da wirklich vorgegeben

[14:23] sind, wie man entwickeln soll. Und alles das kann man gar nicht in so einem 80-Stunden-Projekt

[14:28] machen. Allein das Pair Programming zum Beispiel, wie soll das funktionieren? Du darfst ja gar nicht

[14:33] mit jemand anderem entwickeln, sondern du musst alleine entwickeln. Das ist ja die Vorgabe für

[14:37] diese Prüfungssituation. Die anderen Sachen, sorry, habe ich gerade falsch gesagt, kann man

[14:40] natürlich machen. Du kannst natürlich Test Driven Development machen, auf jeden Fall. Aber was ich

[14:44] jetzt sagen wollte als Anekdote eigentlich, in dieser Doku wurde halt gar nichts aus dem XP-Umfeld

[14:49] gemacht. Also weder TDD noch Pair Programming, was ja eh nicht erlaubt gewesen wäre, oder andere

[14:53] Dinge. Hauptsächlich deswegen, weil die Person einfach Extreme Programming völlig falsch

[14:57] verstanden hat. Aber gut, das zeigt mal wieder, da wurde einfach irgendein Buzzword benutzt, ohne es

[15:02] eigentlich zu verstehen und dann auf so ein Projekt angewendet, wo es einfach überhaupt nicht

[15:05] passt. Und letztes Beispiel, Kanban sehe ich auch ganz oft. Und wenn man dann auf das Kanban-Board

[15:11] guckt, dessen Ziel ja eigentlich ist, zum Beispiel Flaschenhälse zu identifizieren,

[15:15] das Work in Progress Limit zu definieren und so weiter. Das macht alles bei einer einzigen

[15:20] Person, die das Projekt umsetzt, null Sinn. Ja, das ist, es bringt einfach nichts. Also ich kann

[15:27] mit mir selber ein VIP-Limit von eins machen, weil ich bin eine Person und darf eine Aufgabe

[15:31] gleichzeitig bearbeiten. Ja, aber wenn ich das als Flaschenhals erkennen sollte, ich kann ja gar

[15:35] nichts dagegen tun, weil es gibt ja keine zweite Person in meinem Team, die dann zum Beispiel

[15:39] einspringen kann oder was. Also diese ganzen Vorteile, die Prozesse mitbringen, lassen sich

[15:44] wirklich nur umsetzen, wenn ich mehrere Leute im Team habe. Und das ist ja einfach nicht so bei

[15:48] dem IHK-Projekt. Also warum das dann gemacht wird, ich weiß es nicht. Und wie sich das dann schnell

[15:52] äußert, dass man es einfach nur gemacht hat, weil das irgendwer gesagt hat, die klassischen

[15:56] Kanban-Spalten auf dem Board sind dann einfach to do, doing, done. Also das Einzige, wo sich

[16:02] Kanban individualisieren lässt, nämlich die Anzahl der Spalten und die Überschriften und die

[16:06] Reihenfolge, wurde noch nicht mal gemacht, weil es einfach sinnlos ist für so ein Projekt. Was

[16:11] mache ich? Die Anforderungen stehen fest, ich muss umsetzen. Ja, Anforderungsliste, to do, das, was

[16:15] ich gerade mache, doing und wenn ich fertig bin, ist done. Natürlich gibt es keine anderen Spalten

[16:19] dazwischen, weil es gibt ja niemanden anderen im Team, wo ich irgendwie was hinschieben kann oder

[16:23] irgendwas. Also sind jetzt nur ein paar Beispiele, um zu zeigen, dass das einfach überhaupt nicht passt

[16:27] zu so einem IHK-Projekt. Wie gesagt, hast du ein Gegenbeispiel? Gehe gerne rüber damit oder schreib

[16:31] es in den Kommentar oder schreib mich an, schick mir eine Doku. Ja, wunderbar. Aber meiner Meinung

[16:35] nach passt das nicht und ich würde sagen, Wasserfallmodell ist das einzig sinnvolle

[16:39] Vorgehensmodell für diese sehr starren Vorgaben der IHK-Abschlussprojekte von 80 Stunden, in denen

[16:44] alles drin sein muss. Alles andere finde ich nicht zielführend. Gut, erstes Teilkapitel abgeschlossen.

[16:50] Meine ganz starke Empfehlung, mach Wasserfall. Sag auch, dass du Wasserfall machst. Das ist auch

[16:55] nicht irgendwie uncool oder es gibt weniger Punkte, weil du nicht Scrum machst oder irgendwas. Es ist

[16:59] die sinnvolle Wahl für dein Abschlussprojekt. Ende. Ja, alles andere finde ich beknackt. Gut,

[17:05] wie gesagt, du kannst es anders argumentieren, wenn du es gut machst. Wunderbar. So, aber dann

[17:08] kommen wir jetzt zum nächsten Punkt und zwar den Artefakten, denn die sollen ja sinnvoll deine

[17:12] Projektumsetzung unterstützen. Und da gehe ich nochmal vielleicht kurz drauf ein. Also ich sage

[17:16] immer gerne, diese Software soll methodisch entwickelt werden. Das sollst du zeigen in

[17:21] deiner Abschlussprüfung. Du sollst nicht zeigen, dass du der geilste Coder bist und irgendwie die

[17:26] Sprache runter und drauf programmieren kannst und geilen Code schreibst, sondern du sollst eine

[17:30] Software entwickeln. Und Programmieren ist dabei nur ein Teil. Das ist ein großer Teil. In vielen

[17:36] Projekten ungefähr 50 Prozent der Arbeitszeit wird für die Implementierung, also das Coden,

[17:40] benutzt. Völlig okay. Aber es ist eben nur ein Teil. Ein wichtiger Teil, aber ein Teil. Es gibt

[17:46] noch viele andere Dinge, wie zum Beispiel die Wirtschaftlichkeitsbetrachtung oder das Aufnehmen

[17:50] der Anforderungen. Du kannst 50 Stunden lang ganz toll programmieren. Wenn du am Ende nicht das

[17:55] Problem des Kunden löst, hat das alles nichts gebracht. Dann bist du ein toller Coder, aber

[17:58] leider kein guter Softwareentwickler, weil du halt einfach das Problem des Kunden nicht gelöst hast.

[18:01] Und der dich dann übrigens auch nicht bezahlen wird. Überraschung. Weil der bezahlt dich nicht

[18:05] dafür, dass du geil coden kannst, sondern dass du sein Problem löst. Das ist immer ganz wichtig.

[18:09] So, das heißt, es geht hier eben nicht darum, hier ich habe hier was runtergerotzt und habe

[18:13] hier 3000 Zeilen JavaScript abgegeben und das ist mein Abschlussprojekt, sondern du sollst ein

[18:17] Projekt komplett umsetzen. Von vorne bis hinten. Und da gehört halt mehr dazu, als nur der Code.

[18:22] Und wie du das jetzt aufbaust und wie du zeigst, dass du auch diese anderen Dinge beherrschst,

[18:28] da bin ich der Meinung, das kannst du sehr gut mit solchen Artefakten unterstützen,

[18:32] wie ich sie ja immer gerne nenne. Zum Beispiel Diagramme, UML-Diagramme, Entity-Relationship-Model,

[18:38] EPKs, Ereignis-Gescheuerte-Prozessketten, so ein Use-Case-Diagramm oder eben auch eine Tabelle

[18:45] mit Testszenarien, die du durchgespielt hast, ein Abnahmeprotokoll, eine Liste deiner Anforderungen,

[18:50] Lastenpflichtenheft etc. You name it. Das sind alles die Dinge, die in einem Softwareentwicklungsprozess

[18:54] eingesetzt werden, die zusätzlich zum Code am Ende dabei rauskommen und mit denen du in

[18:59] der Projektdokumentation zeigen kannst, dass du eine Software entwickelt hast und nicht programmiert

[19:04] hast. Das ist für mich nochmal ein wichtiger Unterschied. Ich meine, der Beruf heißt

[19:08] Anwendungsentwickler, Anwendungsentwicklerin und nicht Code-Affe. Das ist, glaube ich,

[19:13] nochmal ein wichtiger Unterschied. Und ich weiß, viele Hardcore-Nerds, ich übertreibe jetzt mal,

[19:17] haben mehr Bock auf Programmieren und das ist auch cool. Programmieren ist richtig geil. Ich

[19:21] finde das auch super cool, ja. Nur leider gehört noch ein bisschen mehr dazu als einfach nur Coden,

[19:25] ja. Und wenn ich das hier aufnehme im Jahr 2024, ist ChatGBT schon kein Hype mehr,

[19:31] sondern eigentlich, das wird einfach eingesetzt. Es ist da und es geht auch nicht wieder weg,

[19:34] ja. Das heißt, wenn du dich als Code-Affe siehst, dann wirst du sehr bald durch ChatGBT ersetzt

[19:39] werden, weil Codeschreiben, ziemlich dummen Code, das kann ChatGBT auch heute schon. Dafür

[19:43] brauchen wir keine Menschen mehr, ja. Aber die Anforderungen aufnehmen, überlegen,

[19:47] was überhaupt für ein Problem gelöst werden soll, was dafür die richtige Lösung ist. Eine

[19:51] Architektur aufbauen, ein Deployment-Konzept, ein Benutzerhandbuch dafür vielleicht zu schreiben,

[19:56] eine Oberfläche zu entwerfen, kreativ zu sein. Ich fasse es mal kurz zusammen. Das ist das,

[20:01] wo uns noch die KI nicht das Wasser reichen kann, ja. Code generieren kann sie schon sehr gut,

[20:07] ja. Den ganzen anderen Kram drumherum kann sie noch nicht so gut. Und deswegen würde ich da auch

[20:12] gucken, dass ich das kann, damit ich noch ein paar Jährchen länger in diesem Job arbeiten kann.

[20:16] Das wäre meine persönliche Empfehlung. Aber ganz unabhängig von ChatGBT oder anderen

[20:20] Large-Language-Models, es war schon immer die Aufgabe von Softwareentwicklern und Softwareentwicklerinnen,

[20:26] die Software zu entwickeln und nicht nur zu programmieren. Das gehörte schon immer dazu und

[20:29] sollte auch immer Teil der Ausbildung sein. Es steht nicht umsonst auf dem Ausbildungsrahmenplan

[20:33] noch ein Haufen anderes Zeug drauf, außer eine objektorientierte Programmier-Sprache zu lernen.

[20:38] Ja, das ist ein Punkt von 100, die da draufstehen. Ja, so, das noch mal ganz kurz vorweg. Das ist

[20:44] nicht, dass es heißt, aber ich habe doch was Tolles programmiert, ich habe nur eine 3 gekriegt. Ja,

[20:47] weil du kannst toll programmieren, aber alles andere, was du auch noch zeigen sollst, hast du

[20:50] nicht gezeigt. Ja, und dafür finde ich am sinnvollsten, Artefakte zu nutzen, weil damit

[20:55] kannst du demonstrieren, dass du diese anderen Dinge beherrschst und dass du die sinnvoll

[21:00] eingesetzt hast. Und das ist dann mein Hauptkreditpunkt an ganz vielen anderen Dokumentationen, die ich

[21:04] lese. Da werden halt eventuell Artefakte produziert, sage ich mal, aber die stehen,

[21:10] ja, wie soll man sagen, so in so einem luftleeren Raum, die sind einfach da. So, hier ist jetzt so

[21:14] ein Use-Case-Diagramm. So, hier ist jetzt so ein Klassen-Diagramm. Ja, super, dass du ein

[21:19] Klassen-Diagramm gezeichnet hast, aber wofür hast du das denn gemacht und wann und was hast du mit

[21:23] diesem Ding gemacht? Also, was ist der Zweck, der Sinn dieses Artefakts? Und das wird ganz oft

[21:27] überhaupt nicht deutlich, sondern da merkt man wortwörtlich, also ich habe schon viele Dokus

[21:33] auch gelesen, die tatsächlich mit meiner eigenen Vorlage geschrieben sind, weil dafür stelle ich

[21:36] sie ja online, kann ja auch jeder nutzen, ja, insbesondere auch mit LaTeX oder so. Da wird

[21:39] ganz viel eingesetzt und ist ja auch gut, dafür habe ich es gemacht. Nur, dann merkt man ganz oft,

[21:43] die Leute nehmen diese Vorlage, füllen einfach die Kapitel aus und dann steht da irgendwo unter

[21:47] Kapitel 3.5, hier bitte Use-Case-Diagramm einfügen, jetzt mal ganz blöd gesagt, und dann fügen die

[21:51] den Use-Case-Diagramm mal ein und dann denken die, oh, jetzt bin ich fertig und machen mit dem

[21:53] nächsten Kapitel weiter. Aber das ist natürlich Bullshit. Darf ich Bullshit sagen hier? Weiß ich

[21:58] gar nicht, wie das bei den Podcast-Hostern hier ankommt, wenn ich böse Wörter sage. Ich sage es

[22:02] einfach mal, das ist Bullshit, weil dieses Use-Case-Diagramm erfüllt einen Zweck, ja, und das

[22:08] erfüllt nicht den Zweck, die Seite da zu füllen, weil Stefan Macke das da hingeschrieben hat oder

[22:12] irgendeiner andere, das muss ja gar nicht meine Vorlage sein, aber irgendwer anders gesagt hat,

[22:15] du musst ein Use-Case-Diagramm zeichnen. So, darum geht es nicht, sondern das Use-Case-Diagramm

[22:18] erfüllt einen Zweck in einem realen Projekt und wenn ich ein echtes Projekt umsetzen würde, ja,

[22:24] nicht falsch verstehen, natürlich sind die IHK-Projekte auch alle echt, ja, aber ein Projekt,

[22:27] wo ich vielleicht für bezahlt werde oder was mein Chef von mir haben will und nicht nur der IHK-Prüfer,

[22:32] dann würde ich auch ein Use-Case-Diagramm zeichnen, ja, und da würde ich auch nicht

[22:36] einfach, weil, ja, keine Ahnung, weil ich habe nichts Besseres zu tun, zwei Stunden lang zeichne

[22:40] ich ein Use-Case-Diagramm, sondern ich mache das, weil ich damit ein Ziel verfolge, weil ich damit

[22:44] etwas erreichen will, ja, und das gilt für jedes Artefakt oder Diagramm, was ich auch gleich an

[22:49] Beispielen durchgehe. Die male ich nicht einfach, weil das hier eine Prüfung ist, sondern die sollen

[22:53] einen Sinn ergeben, ja, und da gehen wir gleich mal darauf ein, was das heißen soll. Also, meine Punkte

[22:59] zu diesem Urpunkt Artefakte methodisch sinnvoll einsetzen. Die Software soll eben nicht einfach

[23:03] runterprogrammiert, ich sage auch gern runtergerotzt werden, sondern sie soll methodisch entwickelt

[23:08] werden, soll es zeigen, dass du dir Gedanken gemacht hast. Ich fasse es mal so zusammen, ja,

[23:12] und die Artefakte sollen dabei helfen, weil damit kannst du es gut demonstrieren, dass du dir Gedanken

[23:17] gemacht hast. Und jetzt mal nur ein Beispiel, ich lese es auch ganz, ganz oft in Dokumentationen

[23:21] oder auch in den Präsentationen nachher, da wird dann so gesagt, ist jetzt nur ein Beispiel, ich

[23:25] habe natürlich auch eine Benutzerdokumentation geschrieben und ich habe natürlich auch eine

[23:29] Entwicklerdokumentation erstellt, aber dann wird die gar nicht gezeigt. Also in der Doku wird einfach

[23:33] nur gesagt, ich habe eine Doku geschrieben und dann kann ich sagen, ja, das ist, das kann ich

[23:36] dir jetzt glauben und ich muss es dir auch glauben, weil du zeigst es mir nicht, aber irgendwie habe

[23:41] ich so den Glauben an die Prüflinge verloren, deswegen glaube ich das immer nicht. Und wenn

[23:44] da jemand schreibt, hey, ich habe eine Benutzerdoku geschrieben, dann sage ich, ja, wenn ich sie nicht

[23:48] im Anhang sehe, dann heißt das für mich, du hast sie nicht geschrieben, weil du zeigst sie mir nicht,

[23:51] ja. Und mit diesen Artefakten kannst du also glaubhaft vermitteln, dass du es wirklich gemacht

[23:56] hast, dass du wirklich methodisch die Software entwickelt hast und eben nicht runtergerotzt hast

[24:00] und im Nachhinein dann einfach noch ein paar Diagramme gezeichnet hast, ja. Das ist so das,

[24:05] worauf ich jetzt hinaus will hier. Wie gesagt, du sollst lernen, Software zu entwickeln und nicht

[24:09] einfach zu coden. Und dabei helfen die Diagramme. Wie gesagt, ich habe gleich noch viele, viele

[24:13] Beispiele, was ich meine, wo man diese Diagramme sinnvoller einsetzen kann, ja. Ich habe jetzt

[24:18] erstmal nur ein paar Beispiele genannt. So, ganz wichtig finde ich allgemein, das kannst du dir

[24:23] eigentlich bei jedem, ich nenne jetzt mal Diagramm als Oberbegriff für alle möglichen anderen Sachen,

[24:26] die du auch zeichnen kannst oder visuell darstellen kannst, sagen wir mal so. Das muss jetzt kein

[24:31] UML-Diagramm sein, kann auch was anderes sein, ja. Also diese Darstellung, diese Artefakte können

[24:35] ganz oft auf zwei verschiedene Arten eingesetzt werden. Nummer eins zur Modellierung, das heißt,

[24:40] bevor du anfängst zu programmieren, machst du dir Gedanken, zeichnest was auf, skizzierst etwas,

[24:45] entwirfst etwas und daran orientierst du dich dann bei der Entwicklung. Das heißt, es wird vor der

[24:51] Entwicklung dieses Artefakt erstellt, zur Modellierung deiner Software. Du kannst Diagramme

[24:57] aber auch nach der Implementierung erstellen zur Dokumentation. Das heißt, Beispiel Klassendiagramm,

[25:02] machen wir es daran mal fest, ja. Du kannst, wenn du Testgetriebe entwickelst, weißt du noch

[25:06] gar nicht, welche Klassen es geben soll. Das heißt, du fängst einfach an zu programmieren und guckst

[25:10] und änderst was oben und auch die Methode braucht einen anderen Parameter und hier ist noch was

[25:13] anders und hier brauche ich noch eine Abstraktion, ja. Und ganz am Ende, wenn du fertig bist, drückst

[25:17] du auf den Knopf und generierst aus deinem Code ein Klassendiagramm, damit ein anderer Entwickler,

[25:21] eine andere Entwicklerin leichter in deinen Code eintauchen kann und das Projekt schneller verstehen

[25:24] kann, weil es eben eine visuelle Darstellung ist und man die schneller überschauen kann,

[25:28] als eben 700 Zeilen Code, ja. Das heißt, da ist der Sinn des Klassendiagramms im Nachhinein,

[25:33] deinen Haufen Code verständlicher zu machen. Dokumentation, ja. Du kannst aber auch anders

[25:39] vorgehen und sagen, ich mache nicht TDD, ich mache in Anführungszeichen klassische Softwareentwicklung

[25:44] ohne Tests. Oh Gott, so was will ich gar nicht aussprechen hier, aber angenommen, du willst das

[25:48] so machen, dann kannst du das Klassendiagramm natürlich auch vor der Programmierung zeichnen

[25:52] und sagen, okay, welche Klassen soll es denn geben und wie sollen die zusammenhängen, wie sollen die

[25:56] heißen, gibt es irgendeine Vererbungsbeziehung, warum gibt es die, etc., ja. Das heißt, du machst

[26:01] dir Gedanken, bevor du die erste Zeile Code schreibst und malst das auf. Und hier ist der

[26:06] Zweck ein anderer, nämlich du möchtest dir Arbeit sparen, ja. Du malst das Diagramm auf, weil das

[26:11] schneller geht, als das runter zu coden, ja. Wenn du jetzt mal ein ganz deutliches Beispiel, wo es

[26:16] offensichtlich ist, ein Mockup zu zeichnen mit einem Bleistift auf Papier, das dauert zwei Minuten,

[26:21] ja. Eine fertige Web-Anwendung zu bauen, die so aussieht, wie du es haben willst,

[26:25] dauert mehrere Stunden oder Tage. Das heißt, du sparst dir Zeit dadurch, dass du dir vorab

[26:30] Gedanken machst und was aufmalst, etwas skizzierst. Nicht umsonst wird jeder Hollywoodfilm, bevor er

[26:36] gedreht wird, von sehr, sehr vielen Zeichnern aufgezeichnet in ein sogenanntes Storyboard.

[26:41] Das kostet zwar schon einen Haufen Geld, aber immer noch das x-fache weniger, als das Ding

[26:46] wirklich zu drehen mit echten Kameras und echten Hollywood-Schauspielern, ja. Das heißt, mach dir

[26:50] vorab Gedanken, damit du es dann bei der Implementierung einfacher hast, du nicht so lange

[26:54] brauchst und du deine Zeit besser einhalten kannst. Das ist die zweite Möglichkeit, Artefakte

[26:59] einzusetzen, also zur Modellierung, was habe ich jetzt gesagt? Vor der Implementierung. Modellieren,

[27:04] nach der Implementierung dokumentieren. Zwei unterschiedliche Szenarien, ja. Und ganz oft wird

[27:09] gar nicht gesagt, warum ein Artefakt überhaupt gemacht wurde und zu welchem Zweck, sondern es

[27:12] wird einfach gesagt, ich habe noch ein Klassendiagramm erstellt, siehe Anhang. Und dann

[27:17] frage ich mich immer, ja schön, welchem Zweck dient jetzt dieses Klassendiagramm? Und meistens

[27:21] ist der Zweck, irgendwer hat gesagt, ich muss es machen, dann gibt es mehr Punkte in der Doku. Ja,

[27:25] gibt es grundsätzlich auch. Also ganz ehrlich, wenn ich jetzt eine Doku habe, die Grütze ist,

[27:29] wo aber ein Klassendiagramm drin ist, dann gebe ich da bestimmt mehr Punkte für als eine, wo Grütze

[27:33] drin steht, aber kein Klassendiagramm. Okay, aber es gibt trotzdem keine gute Note dafür, wenn das

[27:38] Artefakt einfach nur da rein geflanscht wurde, ohne irgendeinen Sinn und Zweck oder das irgendwie

[27:43] näher zu erklären. Ja, das ist hier der Hintergrund. Also diese Diagramme, diese Darstellung, die haben

[27:47] keinen Selbstzweck. Ich mache die nicht, weil ich gerne Diagramme zeichne, sondern die sollen mir

[27:52] entweder das Leben erleichtern, indem ich später weniger Arbeit habe, Stichwort Modellierung, oder

[27:56] die sollen anderen das Leben erleichtern, wenn sie in den Code eintauchen. Und unter anderem kannst

[28:00] du dich auch selber zusammenfassen, weil wenn du in zwei Monaten deinen Code liest, verstehst du

[28:04] wahrscheinlich selber nicht mehr. Und dann guckst du dir auch lieber ein Klassendiagramm an und

[28:07] guckst dir an, wie das war, als die ganzen Zeilen Code zu lesen. Ja, gut. So, dann muss dieser Einsatz

[28:13] aber auch zum gewählten Prozess passen. Das habe ich eben schon gesagt. Lastenpflichtenheft mache

[28:17] ich nicht in Scrum. Das passt einfach nicht dazu. Scrum macht die Anforderungen anders. Ja, da gibt es

[28:22] vielleicht User Stories, da gibt es ein Backlog, etc. Da passt Lastenpflichtenheft nicht dazu. Das

[28:27] ist einfach Schrott. Ja, und was ich leider ganz oft sehe, weil das ist auch super hip, Test-Driven

[28:32] Development haben wir gerade gehört, das macht man ja. Und ja, klar, das machen bestimmt auch

[28:35] alle dazu, wie sie jeden Tag in den Unternehmen. Ja, gut, wir kennen ja die heile Welt der IHK-Prüfung,

[28:39] das ist dann so. Aber an ein, zwei Artefakten sehe ich dann halt ganz schnell, dass es halt doch nicht

[28:44] so ist. Denn wenn ich dann sehe, vor der Implementierung habe ich ein Klassendiagramm

[28:47] gezeichnet, in dem seltsamerweise schon alle Attribute, alle Methoden drin waren, dann weiß

[28:52] ich schon, das kann nicht sein, weil das passt nicht zum Vorgehen von Test-Driven Development.

[28:55] Denn wie gerade beschrieben, bei Test-Driven Development treiben die Tests meine Implementierung.

[29:00] Ich weiß vorher noch gar nicht, welche Klassen es geben wird, wie die heißen, wie die zusammenarbeiten.

[29:04] Klar, ich habe ein grobes Bild im Kopf. Ja, aber wenn ich anfange, ein detailliertes Klassendiagramm

[29:09] zu zeichnen, bevor ich das Ganze dann mit Test-Getrieben entwickel, dann passt das einfach

[29:14] nicht zusammen. Das kann so nicht funktionieren, wenn ich das wirklich mache, wie Test-Driven

[29:19] Development gedacht ist. Ja, das passt einfach nicht zusammen. So, wie gesagt, mache ich TDD,

[29:25] kann ich trotzdem im Nachhinein ein Klassendiagramm machen. Auch einfach, wie gesagt,

[29:29] aus Dokumentationszwecken, aber eben nicht im Vorhinein. Das passt nicht dazu. Und daraus denke

[29:33] ich mir dann als Prüfer sofort, okay, die Person hat das gar nicht wirklich so gemacht, wie das da

[29:39] geschrieben ist, weil ich kann aus dieser Konstellation schon sehen, das passt nicht.

[29:42] Das hätte, wäre niemals so rausgekommen, wenn wirklich TDD gemacht worden wäre. So,

[29:48] dann Artefakte sollen auch zeitlich sinnvoll im Projekt untergebracht werden. Das heißt,

[29:52] jetzt mal ein ganz offensichtliches Beispiel. Ich kann nicht, wenn ich schon fertig programmiert

[29:56] habe, danach die Anforderung aufnehmen in einem Lastenheft. Logischerweise. Das muss schon in

[29:59] einer anderen Reihenfolge sein. Erst die Anforderung, dann die Implementierung. Aber

[30:03] auch sowas sehe ich. Und dann, ich nehme gerne wieder dieses Beispiel mit Klassendiagramm und

[30:06] TDD, weil ich das echt schon so oft gelesen habe. Dann wird halt eben zur Modellierung ein

[30:11] Klassendiagramm gemacht und danach dann testen wir, wenn und wie gesagt, das passt einfach von

[30:15] der zeitlichen Abfolge nicht. Es ist die falsche Reihenfolge. So, und dann finde ich noch mal ganz

[30:20] wichtig, dass eben diese Artefakte nicht einfach nur stumpf und dumm aneinander gereiht werden,

[30:25] hier ist das Use-Case-Diagramm, hier ist das Klassendiagramm, hier ist das Aktivitätsdiagramm,

[30:28] nött, nött, nött, siehe Anhang. So, sondern, wie gesagt, die sollen ja auch ein Mehrwert im

[30:32] Projekt bieten. Wenn ich ein Klassendiagramm vor der Implementierung male, dann wäre es gut,

[30:39] wenn ich bei der Implementierung auf dieses Klassendiagramm drauf schaue und mir nicht

[30:43] ein zweites Mal überlegen muss, welche Klassen es geben soll. Sondern das habe ich ja vorher

[30:46] alles schon fertig, also baue ich jetzt darauf auf in der Hoffnung, dass ich mir Zeit spare. Ja,

[30:51] ich zeichne erst ein Mockup, damit ich die Änderung vom Fachbereich, die es sicher geben wird,

[30:57] in drei Strichen mit einem Blatt Papier ändern kann und eben nicht alles umprogrammieren muss,

[31:02] weil die Oberfläche schon fertig ist. Das ist der Sinn dahinter. Ja, das heißt,

[31:06] die sollen irgendwie schon aufeinander aufbauen, sonst kann ich mir das Zeug auch sparen. Wenn ich

[31:10] sage, ich habe hier ein Mockup gezeichnet und dann habe ich was programmiert, was am Ende ganz

[31:13] anders aussieht, wofür habe ich das Mockup dann gezeichnet? Also was hat mir das gebracht,

[31:17] außer Zeit gekostet? Nix. Ja, das heißt, die Sachen folgen einem sinnvollen Aufbau und bauen

[31:22] auch aufeinander auf. Da kommen wir gleich nochmal zu so einem Beispiel. Ach, ich spoiler das schon

[31:28] mal. Nur mal ein Beispiel, weil ich jetzt immer von Mockups rede. Ich würde zum Beispiel immer

[31:31] erst ein Mockup zeichnen und danach meine Architektur planen bzw. auch mein Datenmodell

[31:37] planen. Denn wenn ich die Oberfläche mit dem Fachbereich abstimme, das ist ja das,

[31:41] wo der Fachbereich nachher mitarbeitet, mit der Oberfläche. Da fühlen die sich zu Hause,

[31:45] da überlegen die, kann ich damit mein Problem lösen? Dann wird ihnen dabei auffallen,

[31:49] oh, hier brauche ich aber noch ein Feld und hier, das muss noch ein Dropdown sein und da brauche ich

[31:52] noch einen Button und hier soll mein Benutzername stehen. Übrigens hatte ich noch gar nicht gesagt,

[31:55] ist mir gerade eingefallen. Und wenn ich das mit dem Fachbereich durchgekaspert habe,

[31:59] da bin ich ziemlich sicher, dass ich alles, was der Fachbereich da an Daten haben muss,

[32:03] in diesem Mockup sehen kann. Das heißt, ein logischer Schluss wäre jetzt, aus diesem Mockup

[32:08] ein Datenmodell abzuleiten. Weil das, was der Fachbereich an Daten braucht, habe ich ja gerade

[32:13] mit ihm abgeklärt und dafür das Mockup gezeichnet. Andersherum wäre das irgendwie Banane. Denn wenn

[32:18] ich erst ein Datenmodell erzeuge, wo ich glaube, wie ich es richtig machen würde und dann mache

[32:23] ich ein Mockup mit diesem Datenmodell und dann sagt mir der Fachbereich, aber das ist falsch und

[32:27] das ist falsch und das ist falsch, was muss ich dann machen? Mein Datenmodell anpassen. Habe ich

[32:32] dann viel Zeit verloren in einem 80-Stunden-Projekt? Ja. Also warum sollte ich das tun? Warum mache ich

[32:37] mir erst die Mühe, ein Datenmodell zu zeichnen, was ich dann danach sowieso wieder verändern muss?

[32:41] Mach's doch einfach andersrum. Erst Mockup und daraus leite ich das Datenmodell ab. Das ist

[32:46] zum Beispiel eine sinnvolle Vorgehensweise, die ich empfehlen würde. So, und ganz nebenbei,

[32:50] weil natürlich kommt es ja auch auf die Note an, dafür machst du den Abschlussprojekt. Du willst

[32:54] ja auch eine gute Note haben. Durch diese Vorgehensweise mit den Artefakten, passend

[32:57] zum Projektablauf und sinnvoll aufeinander aufbauen und so weiter, machst du dir nicht

[33:00] nur ganz nebenbei auch deine Arbeit leichter und solltest das vielleicht auch in der Realität mal

[33:04] anwenden. Also sowas zum Beispiel wie Mockups und Datenmodellzeichnen und sowas. Das würde

[33:09] ich in echten Projekten auf jeden Fall auch machen. Ich würde doch nicht in einem Projekt,

[33:12] was irgendwie x-tausend Euro kostet für ein Unternehmen, einfach drauf loscoden. Das ist

[33:17] doch auch hier wieder. Das ist doch Bullshit. Sowas würde man auch nicht machen als professioneller

[33:21] Entwickler. Ich mache mir erst mal eine Skizze. Ich schreibe mir zumindest mal die Anforderung

[33:24] auf, weil ich würde mit irgendwas anfangen, außer dem Code. Ja, weil der Code ist das Letzte in der

[33:29] Kette, was ich anfange. Da muss ich schon ziemlich viel wissen, damit ich den sauber umsetzen kann

[33:34] und nicht dreimal neu schreiben muss, weil auffällt, dass ich jemand falsch gemacht habe.

[33:37] Und nein, dabei hilft auch nicht Scrum. Scrum heißt nicht, dass ich mir vorab keine Gedanken

[33:41] machen muss. Ja, Scrum heißt nicht Gehirn ausschalten und wenn es nicht läuft, mache ich

[33:45] es halt alle vier Wochen nochmal neu. Das ist nicht die Idee von Scrum. Auch Scrum kennt

[33:49] Anforderungen. Stichwort Product Backlog, Sprint Backlog, etc. Das heißt auch nicht,

[33:54] dass wir einfach Code-Affen sind und loslaufen und irgendwas programmieren, nur weil Scrum dran

[33:59] steht. Das ist einfach nicht der Fall. Ja, so, was ich jetzt eigentlich sagen wollte,

[34:02] das letzte Punkt zu diesen Artefakten. Dadurch, dass du dir nicht nur Arbeit ersparst und sinnvoll

[34:07] lernst vorzugehen bei der Softwareentwicklung, durch diese Artefakte hast du auch automatisch

[34:12] den Punkt, dass du spannende Inhalte für Doku hast, die die Prüfer und Prüferinnen hoffentlich

[34:16] gut bewerten können. Denn ganz oft, wenn wir Dokus haben, die schlecht bewertet werden,

[34:20] fehlt genau das da drin. Da sind meist gar keine Diagramme drin und irgendwie nichts,

[34:26] was zeigt, dass es methodisch entwickelt wurde, das Projekt. Und das ist halt schlecht. Also die

[34:30] besten Dokus, die ich habe, übrigens auch auf meiner Website, da findest du ja viele

[34:33] Beispieldokumentationen. Guck da mal rein. Die, die am besten bewertet sind, sind meistens die,

[34:37] wo auch entsprechend viele Artefakte drin sind. Weil du halt mit diesen Artefakten deinen,

[34:41] wie soll ich sagen, deinen Methodenschatz, das, was du umsetzen kannst, deine Fähigkeiten

[34:46] demonstrieren kannst. Und das wollen wir doch sehen, ob du gut Software entwickeln kannst.

[34:50] Und das kannst du mit diesen Artefakten halt eben gut demonstrieren. Deswegen,

[34:54] mach sie nicht nur für dich, mach sie nicht nur für das Projekt, mach sie auch für die Prüfer

[34:58] und Prüferinnen wie mich, damit wir dir eine gute Note geben können. Das wäre super.

[35:02] So, ich gucke auf die Uhr und stelle fest, es wird heute auf jeden Fall länger dauern,

[35:07] das weiß ich schon. Aber ich bin noch nicht mal bei der ersten Projektphase angekommen. Das waren

[35:10] jetzt erstmal die ersten beiden Punkte. Ich hoffe, es ist klar, wo es heute hingehen soll. Nimm ein

[35:14] Vorgehensmodell, was zum Projekt passt und zum IHK-Projekt und setz diese Artefakte sinnvoll ein.

[35:20] Das ist wichtig. Und jetzt gucken wir uns die konkreten Phasen an, die so ein Projekt

[35:23] üblicherweise durchläuft. Wie gesagt, Projektmanagement etc. lassen wir alles

[35:26] außen vor. Hier geht es nur um die Software, den Softwarepart. Und da erzähle ich dann mit

[35:30] ein paar Beispielen, was du da sinnvoll machen kannst, damit dein Schuh draus wird. Und dann

[35:34] fangen wir an mit der ersten Phase, nämlich Anforderungen aufnehmen. Wie gerade schon gesagt,

[35:38] ich fange nicht an, was zu programmieren, wenn ich noch nicht mal weiß, was ich überhaupt

[35:41] programmieren soll. Das heißt, wir fangen erst an mit den Anforderungen. Und da gibt es jetzt

[35:44] verschiedene Möglichkeiten. Du kannst eine Ist-Analyse durchführen. Angenommen, du hast

[35:48] die Aufgabe, eine bestehende Software abzulösen oder eine Excel-Tabelle durch eine Software abzulösen

[35:53] oder irgendwas umzusetzen, was bislang händisch auf Papier gemacht wird oder, oder, oder. Du

[35:57] sollst irgendetwas, was es schon gibt in irgendeiner Form, neu machen, besser machen,

[36:02] schneller machen, was auch immer. Dann kannst du dir angucken, was ist aktuell der Stand und

[36:06] guckst dir dann an, warum ist das schlecht? Warum soll das abgelöst werden? Warum ist das denn blöd,

[36:09] dass drei Mitarbeiter mit sieben Zetteln und fünf Unterschriften irgendeinen Prozess abdecken? Ja,

[36:13] da kann man ja mal gucken, oh, das dauert lange, super viele Fehler, es muss immer zurück. Das

[36:18] sind Dinge, die man dann von dir erwarten würde. Guck dir den Prozess an. Was ist daran schlecht?

[36:22] Guck dir die bisherige Lösung an. Finde die Schwachstellen. Und dann kannst du gucken,

[36:26] was kann ich besser machen? So, wenn du jetzt mal überlegst, was kannst du bei diesem Schritt

[36:30] nutzen an Artefakten? Naja, wenn wir hier zum Beispiel von Prozessen reden und oft in vielen

[36:35] IHK-Projekten geht es darum, dass die Software irgendeinen Prozess digitalisieren soll. Wie

[36:40] stellt man denn Prozesse dar? Und vor allem, wie kann man dann daran Schwachstellen erkennen? Da

[36:44] gibt es verschiedene Möglichkeiten. Aktivitätsdiagramm aus der UML. Es gibt die

[36:47] ereignisgescheute Prozesskette. Es gibt die Business Process Modeling Language oder Notation.

[36:53] Du kannst auch Fotos oder Screenshots machen. Vielleicht hast du eine super komische,

[36:57] sehr schwer verständliche Excel-Datei. Dann mach doch ein Foto davon oder ein Screenshot. Dann

[37:01] sieht man es am besten, was das Problem ist. Denn ganz häufig haben die Projektdokumentationen auch

[37:06] das Problem, dass ich als Prüfer gar nicht verstehe, was da überhaupt gemacht wurde und

[37:09] warum das gemacht wurde. Gerade bei so Nischen-Software, und da zähle ich jetzt auch mal

[37:13] SAP dazu, weil nicht jeder Software-Mitglied SAP kennt, fällt es oft ganz schwer nachzuvollziehen,

[37:17] warum das Projekt überhaupt nötig ist, wenn man den Kontext nicht kennt und sieht, was das Problem

[37:22] ist. Also den Ist-Zustand darstellen. Entweder du machst einfach selber Screenshots davon oder

[37:27] Fotos, oder du modellierst das mit Hilfe eines für Prozessabläufe geeigneten Diagramms. Nämlich

[37:37] Aktivitätsdiagramm EPK oder BPMN. Kannst du machen. Dann zeichnest du den Prozess auf und

[37:42] stellst fest, hier ist ein Medienbruch, da dauert es lange, hier wird es manuell gemacht,

[37:46] hier wird etwas ausgedruckt und beim nächsten wird wieder eingescannt. Solche Scherze. Das

[37:50] kannst du dann richtig schön in so einem visuellen Ding reinzeichnen und sagen,

[37:53] so hier, hier, hier muss es besser werden. Und schon hast du ein schönes Artefakt erstellt.

[37:58] Dann guckst du dir an, was die neue Lösung denn jetzt besser machen soll oder überhaupt machen

[38:03] soll. Dafür musst du die Anforderungen erfassen. Da kannst du dann zu deinen Stakeholdern gehen,

[38:07] zu deinem Kunden, zu deinem Chef, zu deinen Mitentwicklern, zu wem auch immer, wer halt

[38:11] irgendwie Ansprüche an das Projekt hat. Definition von Stakeholder, alle die Ansprüche an das Projekt

[38:15] haben. Und fragst einfach, was soll das Ding denn machen überhaupt? Sag mir doch mal,

[38:19] schreib mir doch mal, füll diesen Fragebogen aus, erzähl es mir, was auch immer, wie auch

[38:22] immer du mit diesen Leuten da kommunizierst. Aber Fragen, das ist ganz wichtig. Und dann ist es dein

[38:27] Job als Softwareentwicklerin, das Ding sauber, strukturiert aufzuschreiben. In welcher Form auch

[38:32] immer. Du kannst User Stories benutzen, du kannst ein Lastenheft pflegen, wo einfach Prosa-Text drin

[38:38] steht. Du kannst das nach Moskau zum Beispiel, M-O-S-C-O-W, strukturieren, nach Must, Should,

[38:44] Could, Won't Anforderungen zum Beispiel. Letztlich, die Form ist egal. Du kannst

[38:48] theoretisch auch das in Prosa-Text machen, das würde ich nicht unbedingt empfehlen. Ich würde

[38:51] einfach, also wenigstens mal Stichpunkte, auf jeden Fall aber in irgendeiner Form strukturiert und

[38:55] immer gleichartig. Du kannst, wenn du es mega übertreiben willst, so Snow Cards machen.

[38:59] Kannst du mal googeln, Snow Cards, so aus dem Volere-Template für Anforderungen ist das so eine,

[39:04] ja, DIN A4 reicht schon gar nicht mehr. Da sind so viele Punkte drauf, was die Anforderungen

[39:09] definiert. Völliger Overkill. Kann man alles machen. Also du kannst von einem kleinen Satz

[39:13] bis hin zu super komplizierten Karten mit 27 Eigenschaften, kannst du alles machen,

[39:17] aber mach es irgendwie. Du musst zeigen, dass du dich um die Anforderungen gekümmert hast

[39:21] und die dokumentiert hast. Und dann kann ein Ergebnis eben sein, zum Beispiel ein Lastenheft.

[39:27] Das ist dann ein sinnvolles Artefakt zum Ende der Anforderungsanalyse. Was soll hier

[39:33] fachlich eigentlich umgesetzt werden? Das solltest du wenigstens in deinem Projekt machen.

[39:38] Und dann ist man schnell dabei, wenn man das auch mal so ein bisschen visualisieren möchte,

[39:43] aus Modellierungsgesichtspunkten und um es zum Beispiel mit dem Fachbereich ein bisschen besser

[39:47] abstimmen zu können, weil ein Bild sagt mehr als 1000 Worte und das ist hier tatsächlich so der

[39:52] Fall, dann zeichne doch mal ein Anwendungsfalldiagramm. Was soll dein System auf ganz

[39:57] abstrakter Ebene dem Benutzer bieten? Was soll der damit machen? Rein fachlich, keine technische

[40:03] Implementierung, erst dann, dann das, dann der nächste Schritt. Und das sehe ich leider sehr

[40:07] häufig bei Use-Case-Diagrammen. Das sind dann so verkappte Aktivitätsdiagramme, womit Include

[40:11] und Extend quasi ein ganzer Prozess dargestellt wird mit Fallunterscheidung. Das ist überhaupt

[40:14] nicht Sinn des Use-Case-Diagramms, sondern hier geht es nur darum zu zeigen, was soll auf ganz

[40:20] hoher Flugebene dein System in Zukunft eigentlich leisten, was es vorher nicht gab oder was vorher

[40:25] schlechter oder anders war. Ja, erstes super standardisiertes Artefakt, Use-Case-Diagramm

[40:30] aus der UML. Zack, das ist für mich ein No-Brainer, das gehört in jedes Projekt rein. Ja, ich meine

[40:35] ganz ehrlich, das sind zwei Strichmännchen, wenn du überhaupt zwei Akteure hast. Manchmal

[40:37] reicht ein Strichmännchen, ein paar Striche und ein paar Kreise und das ist ein Use-Case-Diagramm.

[40:41] So, das ist ein methodisches Werkzeug, um darzustellen, was man mit deinem Programm machen

[40:46] soll. Und das wäre ein sinnvoller erster Schritt, ein Artefakt zu erstellen, was dir auch einen

[40:52] echten Mehrwert bietet und vor allem auch mir als Leser einen Mehrwert bietet und auch sogar

[40:55] deinen Kunden, mit denen du ja zusammenarbeitest. Habe ich es richtig verstanden, dass es in diesem

[41:00] Webshop keine Möglichkeit geben wird, einen Warnkorb zu löschen. Und dann sagt der Fachbereich,

[41:05] nee, doch, das soll man doch können. Ja, und dann machst du halt noch ein Blubbel mit rein ins

[41:09] Use-Case-Diagramm. Also, da kann man super einfach drüber kommunizieren über so ein Use-Case-Diagramm

[41:14] und es ist halt auch super schnell gemalt. Das heißt, das wäre so eine sinnvolle abgerundete

[41:19] Geschichte für deine Anforderungen. Aktuellen Prozess vielleicht darstellen im Sinne der

[41:24] Dokumentation, Aktivitätsdiagramm, EPK, BPMN. Dann Anforderungen aufnehmen, zum Beispiel als

[41:29] User-Story in einem Lastenheft mit Moskau priorisiert, was auch immer. Und noch ein kleines Use-Case-Diagramm

[41:33] dazu und schwupp, sind die Anforderungen abgehakt. Und wir sehen als Prüfer, als Prüferin, Mensch,

[41:39] der hat sich Gedanken gemacht oder die hat das versucht zu visualisieren, mir verständlich zu

[41:44] machen. Wunderbar, Check, Haken dran, Next. So, und das Next, das ist jetzt der Part, wo ich besonders

[41:50] lange darauf eingehen werde. Das hatte ich ja vorhin schon gesagt und zwar Entwurf der Lösung. Also,

[41:55] bevor es an die Programmierung geht, erstmal überlegen, was muss ich denn eigentlich jetzt

[41:58] überhaupt machen? Und Überraschung, in vielen modernen Projekten ist es halt nicht einfach

[42:02] IDI aufmachen in einer Programmiersprache, was programmieren und dann bin ich fertig,

[42:05] sondern es gibt halt nach links und rechts tausend andere Sachen, die noch mit berücksichtigt werden

[42:08] müssen. Und um dir mal einen Denkanstoss zu geben, gehe ich dir jetzt mal durch, so ungefähr, wie ich

[42:12] auch die Reihenfolge empfehlen würde. Darum soll es mir heute gehen, dass es auch sinnvoll ist. Und

[42:17] als allererstes, bevor ich was programmieren würde, würde ich mir überlegen, wie ist denn jetzt der

[42:20] neue Ablauf? Angenommen, ich muss einen Workflow umsetzen, einen Prozess neu modellieren, was auch

[42:24] immer. Was soll denn überhaupt passieren und zwar in welcher Reihenfolge? Denn bei den Use Cases

[42:28] hatte ich ja eben schon gesagt, geht es nur darum, was das System macht, aber nicht, wie. Mit

[42:33] Fallunterscheidungen, Parallelisierung und was. Das hat in dem Use Cases nicht zu suchen. Das

[42:37] interessiert übrigens auch nicht den Fachbereich, sondern der will nur wissen, was man fachlich

[42:42] damit machen kann und nicht, wie genau das programmiert werden soll. Das ist da einfach

[42:47] zu früh. Das machen wir jetzt aber als allererstes, wenn wir eine Lösung entwerfen. Weil wir wissen

[42:52] ja jetzt, was das System machen soll, aber wie es das tun soll. Das ist ja jetzt genau der Teil

[42:56] in unserem Projekt, der so Spaß macht. Wir können uns jetzt eine Lösung überlegen. Und wie machen

[43:00] wir das? Naja, jetzt könnten wir die gleichen Diagramme benutzen wie oben, nämlich Aktivitätsdiagramme,

[43:04] EPK und BPM, aber eben unter dem anderen Gesichtspunkt, nämlich der Modellierung. Wir

[43:10] überlegen uns jetzt einen zukünftigen perfekten Prozess, den wir gerne hätten und modellieren den

[43:15] mit so einem Diagramm. Und das ist jetzt unser Zielbild, an dem wir uns langhangeln. Das heißt

[43:20] hier, wir malen das nicht einfach, weil irgendwer das gesagt hat, sondern das könnte ich mir jetzt,

[43:23] ja ganz praktisch, ich könnte mir so ein EPK zum Beispiel an die Wand heften, ausdrucken an die

[43:30] Wand heften und überlegen, ach ja, genau so sollte das ja sein. Erst das, dann das und Vorsicht, hier ist

[43:34] ja was parallel. Das soll mir jetzt helfen, bei der späteren Implementierung, das vor Augen zu

[43:39] halten, wo ich hin will. Mein Zielbild, an dem ich mich orientieren kann. Und da sollte dann hervorgehen,

[43:45] was ist an dieser neuen Lösung besser? Was ist hier besonders wichtig? Sind zum Beispiel Medienbrüche

[43:49] ohne Ende drin gewesen? Dann sollte ich die jetzt besser vermeiden, sonst wird der Prozess ja nicht

[43:52] besser. Welche Personen sind beteiligt? Welche Systeme muss ich berechtigen, etc. Das kann man

[43:57] alles wunderbar mit so einem Diagramm darstellen und dann spare ich mir ganz, ganz, ganz viele

[44:01] Überlegungen im späteren Verlauf, denn auch dieses Diagramm kann ich jetzt ja nehmen zum Beispiel und

[44:06] schon mal direkt mit dem Fachbereich abklären. Ist das wirklich so, dass die Datei von hier nach da

[44:11] noch mal kopiert werden muss oder kann das nicht anders gemacht werden? Das ist mal ein ausgedachtes

[44:14] Beispiel. Auch hier wieder so ein Aktivitätsdiagramm der UML. Das ist etwas, das kann man nach fünf

[44:19] Minuten Einarbeitungszeit verstehen. Der Fachbereich muss das ja nicht selber zeichnen, der muss nur den

[44:24] Pfeilen folgen und gucken, was da passiert. Und so eine Fallunterscheidung, ist es heiß, ja linksrum,

[44:28] nein rechtsrum, das kann man nach ganz wenig Zeit verstehen. Hier wieder ein Bild sagt mehr als 1000

[44:35] Worte. Nutz das doch. Zeichne das. Halt noch mal Rücksprache mit dem Kunden, dem Fachbereich, ob das

[44:40] wirklich alles so ist. So, nächstes Artefakt. Und das ist sogar das gleiche Artefakt wie oben, bloß mit

[44:46] einem anderen Zweck, einem anderen Ziel. Eben Dokumentation, jetzt Modellierung. So, wenn wir

[44:51] jetzt wissen, wie das gemacht werden soll, dann könnten wir uns vielleicht als nächstes überlegen,

[44:55] mit welcher Plattform, wie soll der Kunde denn überhaupt unterstützt werden? Ist das eine UI-Anwendung,

[44:59] ist das eine Web-Anwendung, ist das eine App auf dem iPhone, auf dem Android, wo läuft das? Also wie

[45:03] genau soll das denn technisch jetzt umgesetzt werden? Welche Plattform? Und auch hier habe ich

[45:08] einige Dokus schon gelesen, wo nicht drin stand, welche Plattform eingesetzt wird oder welche

[45:13] Programmiersprache. Das glaubt man nicht, weil das ist zentraler Bestandteil so eines Projekts, aber

[45:17] das ist wirklich so. Ich musste anhand von Source-Code-Beispielen aus dem Anhang mir selber

[45:22] herleiten, welche Programmiersprache eingesetzt wurde. Das war schon traurig, ja. Und zu diesem

[45:26] Zeitpunkt könnte man sagen, ich will eine Web-Anwendung bauen, weil, und jetzt kommt das

[45:31] Interessante für alle weiteren Punkte, das weil, das muss Teil deiner Dokumentation sein. Und hier

[45:36] darf jetzt nicht stehen, weil wir das immer schon so gemacht haben, sondern weil ich ja oben

[45:40] herausgefunden habe, dem Kunden ist besonders wichtig, dass diese Anwendung auf all unseren

[45:44] Geräten im Haus läuft, deswegen mache ich es als Web-Anwendung. Jetzt mal nur als Beispiel, weil das

[45:49] eben so besonders wichtig war in den Anforderungen. Wenn das nicht wichtig war, wird es halt eine

[45:53] andere Plattform, ja. Also warum nutzt du diese Plattform? Was ist das Ziel? Darf man gerne dazu

[45:59] sagen, ich habe mich für eine Web-Entwicklung entschieden, weil ich das einfacher deployen

[46:02] kann. Ich muss nichts auf den Clients installieren. Die Berechtigungsverwaltung ist super

[46:06] einfach. Ich kann das ans X-Directory anbinden, schlag mich tot. Irgendwas, was begründet, warum

[46:10] das gemacht wird. So, da habe ich auch kein Artefakt, was am Ende rauskommt. Da würde ich mir

[46:16] einfach einen kurzen Satz wünschen, warum was, wie umgesetzt wird, welche Plattform. So, jetzt

[46:21] kommen wir zu was, wo es wieder ein Artefakt gibt, und zwar das UI. Irgendeine Form von UI wird es

[46:26] ja geben. Und bitte jetzt nicht UI verstehen, als da ist irgendwas zum Anklicken oder sonst

[46:29] irgendwas. Das kann eine Konsolen-Applikation sein, die hat auch ein UI, bloß halt in Textform. Das

[46:34] kann eine REST-API sein. Das ist auch ein UI, was ich von draußen, das ist natürlich nicht für

[46:39] Menschen gedacht, okay. Aber man kann sich ja so vorstellen, das ist die Schnittstelle zu deinem

[46:43] System. Das ist zwar nicht von einem Menschen dann bedient, aber irgendeine Form von Interaktion von

[46:48] extern wird es ja geben. Und das meine ich jetzt mit UI. Das muss also nicht eine grafische

[46:53] Oberfläche sein, sondern wie interagiert die Außenwelt mit deinem Projekt. Und dafür kann

[46:59] man natürlich solche Sachen machen, wie ein Mockup oder Wireframes. Unterschied kannst du mal

[47:04] googeln. Es gibt ein Screen-Design. Pixel-Perfect kannst du auch machen, wenn du Bock hast. Du kannst

[47:08] Workflows gestalten, zum Beispiel mit der BPMN oder sowas. Du kannst dich am Corporate-Design

[47:12] orientieren, wenn es wirklich eine grafische Oberfläche ist. Auch hier, du kannst ein

[47:15] Aktivitätsdiagramm zeichnen, wenn es ein Workflow ist. Wer macht was, in welcher Reihenfolge zum

[47:20] Beispiel. Die REST-API. Theoretisch könnte man sogar noch ein Sequenzdiagramm malen. Hier wird

[47:25] erst das aufgerufen, dann kommt zurück Status 200, dann kommt wieder das nächste rein. Selbst das

[47:29] könnte man hier schon machen. Also wie interagiert die Außenwelt mit deinem System? Und warum ich

[47:36] das jetzt hier schon mache, ist, weil ich daraus später das Datenmodell ableiten will. Ich muss

[47:40] wissen, welche Daten verwaltet deine Anwendung überhaupt? Welche Daten kriegt sie rein? Was

[47:44] gibt sie raus? Was wird persistiert, später angezeigt, ausgewertet? Worum geht es überhaupt

[47:49] in meiner Anwendung? Was bietet die für einen Mehrwert? Und wenn ich das weiß, kann ich dann

[47:54] im nächsten Schritt, und da würde ich schon direkt zu übergehen, das Datenmodell entwerfen. Weil,

[47:58] gehen wir mal davon aus, ich habe wirklich ein echtes UI, ich baue eine Webanwendung und ich

[48:01] habe einen ein Mockup gezeichnet, mit ein paar Buttons und Dropdown-Feldern und so weiter. Da

[48:06] kann ich super einfach mit dem Fachbereich fragen, ist das hier so richtig? Fehlt dir noch was? Ist

[48:10] das die richtige Reihenfolge? Soll das blau, rot, grün? Wie soll das aussehen? Und das ist viel

[48:16] einfacher für den Fachbereich oder den Kunden, dir dazu eine Rückmeldung zu geben, als abstrakt

[48:20] in einer Word-Datei, wo dann steht, hier ein Dropdown-Feld mit Name oder so was. Mal das

[48:25] einfach auf, ja? Und das musst du auch nicht mit einer coolen Anwendung machen oder Photoshop oder

[48:29] sonst was. Es reicht wirklich auf ein Blatt Papier, ja? Es muss ja so einfach wie möglich sein und zur

[48:33] realen Welt passen. Und wenn du das einfach mal machen willst, mach das doch. Ich habe schon Dokus

[48:37] gelesen, wo dann am Ende einfach jemand ein Foto gemacht hat von diesem Ding, was irgendwie an der

[48:41] Wand hing, auf einem Post-it oder auf einem DIN A4-Blatt mit Bleistift aufgemalt. Das ist völlig

[48:46] okay. Ja, es geht hier nicht darum, dass du irgendeine Software noch lernen musst, mit der

[48:51] man Mock-Ups zeichnet, sondern du sollst zeigen, dass du dir vorab Gedanken gemacht hast und das

[48:55] UI mit dem Kunden zusammen entwickelt hast, dem um ein Feedback gebeten hast, dem was gezeigt hast.

[49:01] Vielleicht auch eine Iteration gemacht hast, das erste Blatt Papier weggeschmissen, nochmal neu

[49:04] gezeichnet. Dann kannst du ja vorher, nachher zeigen, so hey, aus dem Kundengespräch ging hervor,

[49:08] was ich mir da überlegt habe, war Schrott, wir haben das ganz anders gemacht. So eine Entwicklung,

[49:13] dass du da dir ein Feedback eingeholt hast. Das kann man wunderbar zeigen mit so super billigen

[49:17] DIN A4-Blättern, wo du drauf rummalst. Warum nicht? Gut, also da kommt dann, wie gesagt,

[49:23] so ein bisschen UI raus und dann gehen wir zum Datenmodell und gucken, was brauchen wir jetzt

[49:26] alles für Daten? Oh, da oben braucht ihr den Benutzernamen. Ja, Mensch, da brauche ich

[49:29] wahrscheinlich wohl eine Entität Benutzer. Und hier sollen die Kundendaten angezeigt werden.

[49:33] Da gibt es wahrscheinlich eine Entität Kunde oder oder oder. Daraus kannst du jetzt ein echtes

[49:37] Datenmodell machen und dir überlegen, welche Entitätstypen gibt es in deinem Projekt,

[49:41] welche Attribute haben die, wie hängen die zusammen, wie sind die Karnealitäten,

[49:45] welche Anwendungsfälle benötigen welche Daten. Ja, wenn man jetzt aus dem UI nicht alles ablesen

[49:50] kann, denkt man auch mal einen Schritt weiter, ist zum Beispiel eine Historisierung gewünscht

[49:53] oder sowas. Ja, daraus ergeben sich natürlich auch Entitäten fürs Datenmodell. Oder,

[49:57] ja, also einfach alles, was du jetzt an Daten brauchst, um das, was du dein Projekt halt

[50:02] umsetzen soll, umzusetzen, das zeichnest du da jetzt rein. Und da bietet sich natürlich

[50:06] ein fantastisches Modell an, und zwar das Entity Relationship Model. Und zwar wäre meine Anforderung

[50:11] zu diesem Zeitpunkt im Projekt, ein abstraktes und von einer konkreten Speicherlösung völlig

[50:17] unabhängiges Modell deiner Daten darzustellen. Und das ist das ER-Modell. Das heißt, hier geht

[50:22] es gar nicht darum, dass du später eine relationale Datenbank hast. Das steht zu

[50:25] diesem Zeitpunkt noch gar nicht fest, sondern du zeigst nur, welche Daten werden in deinem

[50:29] Projekt verarbeitet. Und dafür ist das ER-Modell da. Das ist völlig unabhängig von einer konkreten

[50:34] Speichertechnologie. Du kannst aus einem ER-Modell dir eine Struktur für Textdateien,

[50:38] für XML, für relationale Daten, für objektorientierte Datenbanken, für – weiß

[50:43] ich nicht, was gibt es noch – dokumentenorientierte Datenbanken ableiten. Das ER-Modell ist

[50:48] implementierungsagnostisch, um mal schön klug zu scheißen. Das weiß nicht, was daraus später

[50:54] wird. In vielen Fällen wird es eine relationale Datenbank, aber das muss nicht der Fall sein.

[50:59] Deswegen fange ich immer mit einem ER-Modell an, um eine grobe Idee zu haben, was für Daten gibt

[51:04] es überhaupt. Und dann kannst du – und das wäre jetzt wieder ein sinnvoller Flow – am Ende sagen,

[51:08] ich habe jetzt hier so ein ER-Modell und ich leite daraus ein Tabellenmodell für eine

[51:12] relationale Datenbank ab, weil das die beste Möglichkeit ist, das zu speichern. Ich habe hier

[51:17] so komplexe Darstellungen etc., das passt nicht in eine CSV-Datei oder sowas. Ich brauche dafür

[51:22] ein relationales Datenmodell. Und dann entwirfst du das auf Basis des ER-Modells. Und schon wird

[51:27] eine Geschichte, ein roter Faden erkenntlich. Du modellierst ein UI, daraus leitest du ein

[51:34] allgemeines Datenmodell ab und daraus überlegst du dir jetzt, wie kann ich das am besten speichern?

[51:38] Relationale Datenbank. Und dann malst du ein Tabellenmodell. Ja, super. Und schon hast du

[51:42] drei Artefakte, die eine sinnvolle Story erzählen und dein Projekt wirklich voranbringen und dir vor

[51:47] allem auch in den späteren Schritten Arbeit sparen. Du könntest auch anfangen, direkt ein

[51:51] relationales Tabellenmodell zu zeichnen. Und dann stellst du aber nach der dritten Implementierung

[51:55] fest, oh, da habe ich auch noch 27 Daten vergessen. Das ist aber blöd. Und dann machst du halt die

[52:00] Arbeit doppelt. Ist doch blöd. Ja, also UI, dann das Datenmodell, dann konkrete Implementierung,

[52:06] zum Beispiel Tabellenmodell, was auch immer. Ja, so. Next, Architektur. Die sollte man auch nicht

[52:13] vergessen. Ja, angenommen, wir haben uns für eine Webanwendung entschieden, dann wäre es jetzt

[52:16] vielleicht an der Zeit zu überlegen, wie mache ich es denn? Domain-Driven-Design, MVC, MVVM,

[52:20] Client-Server, Monolith, REST-API, was baue ich denn hier eigentlich? Ja, also nach welcher

[52:25] Architektur will ich meine Anforderungen umsetzen? Und hier ist die gleiche Frage wie bei der Plattform,

[52:30] was löst die Probleme denn am besten? Also mache ich Domain-Driven-Design, weil ich dazu ein Buch

[52:36] gelesen habe? Oder passt das wirklich am besten zu der Problemstellung? Wenn ich zum Beispiel eine

[52:41] 0815-CRUD-Anwendung habe, dann brauche ich kein Domain-Driven-Design, wenn es nur darum geht, eine

[52:46] Oberfläche zu bauen, um Tabellen zu füllen. Da muss ich nicht den Overhead zusätzlich zum Beispiel

[52:50] von Domain-Driven-Design nutzen. Und wenn ich weiß, dass ich die Oberfläche und Datenhaltung nie

[52:54] wieder austauschen werde, warum muss ich dann nach MVC vorgehen? Ich weiß sowieso, dass das

[52:58] nicht notwendig ist. Jetzt mal übertrieben gesagt, ich habe eine Wegwerfanwendung, die einmal benutzt

[53:01] wird. Ja, das sollte das IHK-Projekt nicht sein, aber angenommen, das wäre so, warum soll ich dann

[53:05] den Overhead einer super komplizierten Architektur eingehen? Aber wenn ich jetzt schon weiß, Mensch,

[53:09] das Ding wird eingesetzt und wird auch nächstes Jahr noch weiterentwickelt, weil ich jetzt schon

[53:12] weiß, was Version 2 des Projekts umsetzen soll, dann mache ich natürlich MVC, damit es erweiterbar

[53:16] und austauschbar ist. Ist doch klar, ja? Aber diese Entscheidung muss ich ja treffen. Und hier

[53:21] wäre jetzt ein guter Zeitpunkt, weil du weißt jetzt, aha, das ist mein Datenmüll, das ist das

[53:25] UI und du siehst schon, okay, ganz oft werden die Daten in unterschiedlichen Views angezeigt,

[53:30] die Use Cases haben sich überschneidende Parameter und ich weiß nicht was. Und dann

[53:33] kannst du gedanklich schon mal überlegen, welche Architektur deckt das denn am besten ab? Ja,

[53:37] du darfst schon mal Gedanken machen. Und zu diesem Zeitpunkt könntest du jetzt noch mal

[53:41] voll aus der UML schöpfen. Du könntest ein Komponentendiagramm zeichnen, weil,

[53:45] ich will gleich darauf hinaus, dass man bei der Implementierung Testgetriebe entwickelt,

[53:48] das heißt ein Klassendiagramm wäre mir jetzt schon zu detailliert, aber selbst wenn du das

[53:53] machen möchtest, könntest du ja auch ein Klassendiagramm zeichnen. Könnt ihr ja auch

[53:55] mit leben, wenn du es gut begründest, ja? Komponentendiagramm wäre allerdings meine

[53:59] Empfehlung. Was sind die groben Komponenten meiner Software? Wie arbeiten die zusammen?

[54:03] Und hier würde ich immer genau auf die Pfeile gucken. Wer ruft wen auf? Wie sind da die

[54:07] Abhängigkeiten? Greift das UI auf die Datenbank zu? Okay. Greift die Datenbank auf das UI zu?

[54:13] Nee, nicht so gut. So, solche Ideen kann man sich hier schon mal überlegen und dann einmal die

[54:18] grobe Architektur deiner Anwendung skizzieren. Da würde ich einfach ein Komponentendiagramm

[54:23] aus der UML nehmen. Das ist standardisiert, das ist genau dafür da. Da brauchst du dir nicht

[54:26] selber was ausdenken, sondern nimmst einfach das. Hast du schon wieder die nächste Methodik

[54:29] eingebaut. Du kannst aber auch hier wieder Aktivitätsdiagramm, Sequenzdiagramm nutzen,

[54:34] wenn du noch was genauer spezifizieren willst. Hier du hast, keine Ahnung, eine Client-Server-Anwendung,

[54:39] die über REST kommuniziert. Dann kannst du natürlich per Sequenzdiagramm die REST-Aufrufe

[54:42] zum Beispiel modellieren oder sowas. Kannst du alles machen. Meine zentrale Empfehlung hier

[54:46] wäre ein Komponentendiagramm. Was aber zum Beispiel auch ein sinnvolles Artefakt wäre in

[54:51] einem echten Projekt zu diesem Zeitpunkt, wäre ein Glossar. Und damit meine ich jetzt nicht

[54:56] Glossare, die ich in sehr vielen Dokus lese. DSL heißt Domain-Specific-Language und ISDN heißt,

[55:02] das meine ich nicht, sondern ein Glossar speziell für dein Projekt für die Domänenbegriffe. Mein

[55:09] Beispiel. Ich bin ja in der Krankenversicherung tätig. Da schreibe ich dann auf, was ist denn

[55:12] eigentlich ein Vertrag, eine Police, ein Tarif, ein Risiko? Was heißt das denn eigentlich? Denn

[55:20] zu diesem Zeitpunkt habe ich ja noch nichts programmiert. Ich habe mir noch nicht überlegt,

[55:22] wie meine Klassen heißen. Aber ich kenne schon die Domänenbegriffe, weil aus dem UI und dem

[55:26] Datenmodell habe ich ja schon einiges abgeleitet. Und das könnte ich jetzt schön aufschreiben,

[55:30] auch für mich selber später, weil ich vielleicht als Entwickler gar kein Versicherungsexperte bin.

[55:35] Ich mache gerade mein erstes Versicherungsprojekt, aber ich muss das ja alles sauber umsetzen. Dann

[55:39] könnte ich mir jetzt ein Glossar erstellen. Risiko heißt folgendes. Police heißt folgendes.

[55:44] Vertrag heißt folgendes. Und Überraschung, das kann man wunderbar auch wieder dem Kunden zeigen,

[55:48] dem Fachbereich. Stimmt das denn alles? Habe ich das richtig verstanden? Und so ein Ding könnte

[55:52] man auch wunderbar in so eine Projekt-Doku packen. Warum denn nicht? Macht es den Prüfer und

[55:55] Prüferinnen auch viel einfacher, das Zeug dann zu verstehen, wenn man eine Branchen-Software

[55:59] programmiert. Nicht jeder kennt sich mit Krankenversicherung aus. Nicht jeder weiß,

[56:03] was eine Police ist. Woher soll man das wissen? Also, zur Not reicht eine Punktliste mit fetten

[56:10] Überschriften. Police, Doppelpunkt, Erklärung, fertig. Dann nächster Punkt, Datenhaltung

[56:15] definieren. Jetzt wäre eigentlich erst der Zeitpunkt in meinem, eben habe ich schon gesagt,

[56:19] aus dem ER-Modell kannst du direkt auch ein Tabellenmodell ableiten. Ja, kannst du machen.

[56:23] Du kannst aber auch erst mal die Architektur skizzieren und dann überlegen, wo kommt denn

[56:27] überhaupt Datenhaltung vor? Brauche ich überhaupt Datenhaltung oder gibt es einfach nur eine REST

[56:31] API, zustandslos und die Daten kommen von draußen rein. Ich muss gar nichts persistieren. Ist ja

[56:34] auch okay. Kann ja auch ein valides Abschlussprojekt sein, ja. Aber da musst du dir auf jeden Fall

[56:38] Gedanken drüber machen. Welche Daten müssen wie und wo gespeichert werden oder übertragen werden

[56:43] oder exportiert, importiert werden, was auch immer, ja. Und da kann jetzt eine Datenbank mal rauskommen.

[56:48] Textdateien, XML-Dateien, JSON, REST API, Cloud-Speicher, Schlagmethod, was auch immer. Ja,

[56:55] vielleicht musst du ja PDF-Dateien in der Cloud ablegen, weiß der Geier. Aber diese Datenhaltung,

[56:59] da solltest du dir Gedanken machen und das einmal skizzieren, wie das umgesetzt werden soll. Auch für

[57:04] deine spätere Umsetzung. Wie programmierst du das denn? Brauchst du noch eine Cloud-Bibliothek oder

[57:09] ist es einfach plain Java, um, weiß nicht, Dateien von einer Festplatte einzulesen? Das ist ja schon

[57:14] ein Unterschied, ja. Und wenn du hier eine Wahl hast, wie du Daten speichern kannst, nur ein

[57:19] Beispiel. Du hast die Wahl, ich nehme entweder eine relationale Datenbank oder eine dokumentenorientierte

[57:23] Datenbank. Kann ja beides valide sein, wenn du diese Möglichkeit hast. Könntest du hier zum

[57:28] Beispiel eine Nutzwertanalyse erstellen, um für dich zu entscheiden, was denn die beste Lösung

[57:32] ist. Ja, nur mal ein Beispiel. Dokumentenorientierte Datenbank, relationale Datenbank. Wenn wirklich

[57:36] beides valide Optionen sind und nicht sowieso schon feststeht, dass du nur relationale Datenbanken nutzt,

[57:41] weil du ja gar nichts anderes einsetzt im Unternehmen, dann kannst du die Nutzwertanalyse

[57:43] auch sparen, ja. Dann kannst du eine echte Nutzwertanalyse machen, um diese Entscheidung

[57:47] zu unterstützen, ja. Denn in einem echten Projekt müsstest du dir ja auch Gedanken machen. Da geht

[57:52] es auch nicht nach Bauchentscheidung, ich nehme die Oracle für 100.000, wenn die gar nicht alle

[57:57] Anforderungen abdeckt, die du brauchst. Und zu diesem Zeitpunkt weißt du schon relativ viele

[58:01] Anforderungen. Du hast ja das Datenmodell schon entworfen, du weißt, was für Kriminalitäten es da

[58:05] gibt und so weiter. Das heißt, du kannst jetzt wirklich mit diesem Vorwissen auch hier wieder

[58:09] darauf aufbauend jetzt eine Entscheidung treffen, wie du es sinnvoll umsetzen könntest. Und das

[58:15] könntest du damit eine Nutzwertanalyse unterstützen, wenn es wirklich eine realistische Entscheidung zu

[58:19] treffen gibt. Ja, und dann wird es auch vielleicht mal irgendwann Zeit, Programmiersprache und

[58:24] Framework auszuwählen. Wenn du schon weißt, ich mache eine Web-Anwendung, dann wäre es jetzt

[58:27] vielleicht an der Zeit, zu sagen, hey, übrigens, ich mache das mit Programmiersprache X und

[58:30] Framework Y, weil … und das Weil bitte nicht vergessen. Begründung, Begründung, Begründung,

[58:36] warum hast du es gemacht? Und wenn eine Wahl möglich ist, und ich sage ehrlicherweise,

[58:42] in ganz vielen Projekten ist das nicht möglich, weil da wird einfach vorgegeben vom Unternehmen,

[58:45] du machst das so und dann hält man sich daran. Und dann ist das, wenn man das vernünftig erklärt,

[58:50] auch okay. Wenn man eigentlich zu einer Programmiersprache gezwungen wird, wo eigentlich

[58:53] jeder weiß, das passt überhaupt nicht zur Anwendung, dann ist es nicht so ganz okay.

[58:57] Wenn ich zum Beispiel in einem Java-Shop arbeite und ich mache alles mit Java und ich baue eine

[59:01] klassische Web-Anwendung, dann kann ich das mit Java machen, völlig okay. Aber wenn jetzt

[59:04] irgendwer um die Ecke kommt und sagt, ja, du sollst übrigens eine Anwendung für Apple-Geräte

[59:09] machen, aber du darfst nur Java nehmen, dann würde ich sagen, ja, das geht nicht. Also,

[59:12] wie soll ich das machen? Selbst wenn es ginge, wäre das so umständlich, dass einfach die falsche

[59:16] Wahl wäre. Von daher, ganz oft hat man einfach nicht die Wahl, sich eine Programmiersprache

[59:22] auszusuchen, aber wenn doch, dann kann man das jetzt hier auch wieder mit einer Nutzerwertanalyse

[59:26] zum Beispiel unterstützen und sagen, ich hätte die Wahl zwischen PHP, Python und Java und jetzt

[59:30] mache ich meine Nutzerwertanalyse und entscheide mich für X. Ich darf auch gerne dann in der Doku

[59:36] zu diesem Zeitpunkt sagen, ich nehme jetzt Programmiersprache Y mit Framework so und so,

[59:40] weil eben kurze Begründung und dann hat man sich halt dafür entschieden und dann ist das in Ordnung.

[59:45] Da muss jetzt nicht noch irgendwie ein großes Diagramm gezeichnet werden. Reicht auch zu sagen,

[59:48] ich nehme Java in Version so und so und Quarkus in Version tralala und dann ist das an der Stelle

[59:54] hier fällig. Daraus ergibt sich natürlich auch ganz viel für seine Programmierung. Wenn du jetzt

[59:58] zum Beispiel Quarkus, wer das nicht kennt, wenn du das nicht kennst, so eines im Jahr 2024 von

[1:00:04] einem sehr beliebtes Web-Framework für Java-Anwendungen oder gerade für REST-Architekturen

[1:00:12] sehr etabliert und sehr cool geeignet. Wenn man das nutzt, gerne zwei Sätze dazu schreiben,

[1:00:16] warum man das nutzt und warum das auch gut ist für diese Anwendung und dann kann es weitergehen.

[1:00:20] Aber hier könnte jetzt als Ergebnis rauskommen, Liste der eingesetzten Technologien, Quarkus

[1:00:25] Version so und so, Java Version tralala, eine Nutzerwertanalyse, wenn man wirklich eine Wahl

[1:00:29] treffen kann. Man kann auch sagen, ich entwickle übrigens auch objektorientiert oder funktional

[1:00:33] mit Sprache Y und so weiter. Das dürfte man jetzt hier entscheiden und dann eben aufschreiben.

[1:00:39] So, jetzt steht eigentlich alles fest, was die Technologie angeht.

[1:00:42] Und jetzt müssen wir uns um den kleinen, unwichtigen Teil der Geschäftslogik und der Domäne kümmern.

[1:00:47] Denn, Überraschung, hatte ich vorhin glaube ich schon mal gesagt, wir programmieren ja nicht einfach nur, weil das so viel Spaß macht,

[1:00:51] sondern wir sollen ja ein Problem lösen.

[1:00:53] Und dieses Problem ist ganz offensichtlich oft ein fachliches Problem und kein technisches Problem.

[1:00:57] Das heißt, jetzt wird es irgendwann auch mal Zeit, sich um die Geschäftslogik, also die Domäne meines Projekts zu kümmern.

[1:01:03] Und die sollte jetzt unbedingt einmal vorab geplant werden.

[1:01:06] Ich hatte eben schon dieses Glossar angesprochen, das könnte man hier wieder zurate ziehen.

[1:01:10] Ihr seht, oder du siehst, wo wollte ich eigentlich immer hier die Leute ansprechen, das basiert aufeinander.

[1:01:15] Ich habe oben das Glossar geschrieben und jetzt kann ich es nutzen, um daraus zum Beispiel meine Domänenstruktur,

[1:01:20] meine Klassen, wenn du so willst, in der Objektorientierung abzuleiten.

[1:01:24] Weil die sollten bestenfalls so heißen, wie im Glossar beschrieben und irgendwie andere Begriffe benutzen.

[1:01:29] Stichwort Ubiquitous Language aus dem Domain Driven Design.

[1:01:32] Ich möchte meine Domänensprache überall durchziehen.

[1:01:35] Von der Technik bis zur Fachlichkeit möchte ich überall die gleiche Sprache benutzen.

[1:01:39] Also, das baut aufeinander auf. Ich habe es schon ein paar Mal gesagt.

[1:01:42] So, gibt es jetzt zum Beispiel irgendwelche schwierigen Probleme in meiner Domäne?

[1:01:46] Gibt es ganz komplizierte Algorithmen, Versicherungsmathematik, wo ich erstmal irgendwie, keine Ahnung, noch mathematische Formeln übersetzen muss oder irgendwie was?

[1:01:54] Gibt es eine grobe Idee, wie ich die Anforderungen überhaupt umsetze?

[1:01:57] Brauche ich dafür noch bestimmte Frameworks oder Bibliotheken für Finanzmathematik oder schlag mich tot.

[1:02:03] Da muss man sich ja dann mal Gedanken machen.

[1:02:05] Welche Entitätstypen, die ich zwei, drei Schritte vorher herausbekommen habe bei meinem ER-Modell, brauche ich denn eigentlich?

[1:02:12] Wie arbeiten die zusammen? Welche sind wichtig? Mit welchen fange ich an?

[1:02:15] Welche sind vielleicht eher unwichtig? Worauf fokussiere ich mich jetzt?

[1:02:19] Gibt es vielleicht eine Art Workflow durch das System? Wo ist der Einstieg?

[1:02:23] Gibt es vielleicht irgendwie Screens, die aneinander übergehen? Wie übertrage ich die Daten zwischen den Komponenten?

[1:02:28] Solche Sachen kann ich mir hier jetzt überlegen, ja?

[1:02:30] Und da habe ich wieder eine Fülle an Möglichkeiten, wie ich das modelliere.

[1:02:34] Und zwar Aktivitätsdiagramm, EPK, BPM.

[1:02:37] Haben wir schon ein paar mal gehört jetzt, ne? Kann ich zu diesem Zeitpunkt immer noch machen.

[1:02:40] Ich kann ein Sequenzdiagramm der UML benutzen, wenn ich wirklich ganz tief runter will.

[1:02:44] Die Methode ruft das auf.

[1:02:45] Ich kann das aber auch abstrakter machen, denn vielleicht noch mal ganz allgemein, die UML-Diagramme kann ich beliebig konkret oder abstrakt machen.

[1:02:52] Keiner erwartet, dass das perfekt so ist, dass ich daraus Code generieren kann.

[1:02:56] Sondern sie dienen halt unter anderem dem Zweck der Dokumentation und auch der Modellierung.

[1:03:00] Und das kann auch eine grobe Modellierung sein. Das muss nicht perfekt sein, ne?

[1:03:04] Ich muss nicht jedes Detail und jeden String bis zur x-ten Stelle genau in dieses Diagramm zeichnen.

[1:03:10] Das ist gar nicht der Sinn, wenn ich da modelliere.

[1:03:13] Denn der Sinn der Modellierung soll ja sein, dass das schneller geht, als es zu coden.

[1:03:16] Und wenn ich jetzt aufzeichne, jeden einzelnen Parameter mit Rückgabewert und tralala,

[1:03:21] dann dauert das ja noch länger, als wenn ich es einfach programmiere.

[1:03:23] Also von daher, der Abstraktionsgrad dieser Diagramme ist frei wählbar.

[1:03:27] Du machst das nur genau so detailliert, wie es dir hilft und wie es für dein Projekt sinnvoll ist.

[1:03:33] Von daher, du kannst dir ein Sequenzdiagramm zeichnen, Aktivitätsdiagramm.

[1:03:36] Du kannst auch, wenn du oldschool drauf bist, einen Programmablaufplan machen.

[1:03:39] Du kannst ein Struktogramm Nassi Schneiderman zeichnen. Alles gut.

[1:03:42] Wenn du so einen zentralen krassen Algorithmus hast, wo du dich erstmal mit einem Mathematiker abstimmen musst, wie das eigentlich geht,

[1:03:48] dann mal doch den Algorithmus auf. Mach Pseudocode. Sogar das wäre möglich, bevor du es runterprogrammierst in Java oder was für einer Programmiersprache.

[1:03:55] Und natürlich darfst du hier auch gerne ein Klassendiagramm machen, wenn du das denn möchtest. Ist auch okay.

[1:04:00] Das heißt, du könntest jetzt zum Beispiel aus dem ER-Modell, was du weiter oben gezeichnet hast,

[1:04:04] Klassendiagramme ableiten, mit einer Vererbungsbeziehung oder weiß ich nicht was.

[1:04:09] Die können ja schön aufeinander aufbauen. Da wird wieder dieser rote Faden deutlich.

[1:04:13] Vorher hast du dir ganz abstrakt ein ER-Modell überlegt und jetzt machst du ein konkretes Klassendiagramm draus,

[1:04:20] wo du dann zum Beispiel die M-zu-N-Beziehungen entsprechend korrekt auflösen und solche Sachen.

[1:04:24] So wird da ein Schuh draus. Das ist ein roter Faden.

[1:04:27] Und jetzt darfst du dir gerne auch, bevor du anfängst zu programmieren, noch mal ein paar Gedanken machen über den Bild und das Deployment.

[1:04:37] Das würde für mich heute auch dazu gehören.

[1:04:39] Du weißt, dass es inzwischen AP2 sogar abgefragt wird.

[1:04:42] CICD-Pipelines, Bildprozess, Unit-Testing etc. Das gehört zu moderner Softwareentwicklung dazu.

[1:04:47] Das gehört auch zu deinem Projekt dazu.

[1:04:49] Und selbst wenn dein Deployment so aussieht wie, ich sippe das Zeug und lade es auf dem Web-Server hoch, ist ja okay.

[1:04:54] Aber irgendwie muss das Ding deployed werden.

[1:04:56] Du wirst wahrscheinlich nicht hart auf dem Produktions-Server arbeiten, sondern irgendwie muss dein Code von A nach B kommen.

[1:05:01] Und da wäre es vielleicht heute cool, wenn du das automatisieren würdest mit einer Build-Pipeline, wenn es sowas gibt in eurem Unternehmen.

[1:05:07] Bitte nicht falsch verstehen, du musst keinen Build-Server aufsetzen für ein IHK-Projekt, wenn ihr sowas noch nicht hattet.

[1:05:11] Aber du musst zumindest wissen, dass man es heute eigentlich so machen würde.

[1:05:15] Und wenn ich jetzt mal von einem vernünftigen Unternehmen ausgehe, wo sowas gemacht wird, dann gehört es für mich zumindest auch dazu,

[1:05:21] für so ein Abschlussprojekt, dir so eine grobe Build-Pipeline mal zu überlegen oder so ein Deployment mal zu modellieren.

[1:05:26] Wo soll das ganze Zeug denn laufen?

[1:05:28] Zum Beispiel, welche Komponente, UI, Logik, Datenbank, wo läuft das denn?

[1:05:33] Gibt es einen Datenbank-Server? Läuft das alles in einem Container? Gibt es überhaupt eine Datenbank?

[1:05:37] Ist das ein Wegwerf-Container, der von Kubernetes automatisch neu gestartet wird, wenn er tot ist?

[1:05:41] Wie genau läuft das Zeug denn?

[1:05:44] Denn ganz häufig entwickeln wir heute einfach nicht in unserer eigenen kleinen Welt auf unserer Entwicklermaschine ein kleines Tool,

[1:05:49] was wir dann doppelklick starten und danach dann wegschmeißen, sondern alleine eine Web-Anwendung.

[1:05:53] Die muss ja in einem Web-Server irgendwo deployed werden, die muss erreichbar sein, es muss eine URL dafür geben.

[1:05:58] Das heißt, diese ganze Infrastruktur-Geschichte, die ist inzwischen enorm komplex geworden.

[1:06:03] Das ist nicht mehr so einfach, wie ich programmiere was und starte das dann.

[1:06:06] Und das darf man gerne mit berücksichtigen, sofern es die Komplexität deines Projekts denn zulässt oder erforderlich macht.

[1:06:13] Wenn du SAP entwickelst und das ist sowieso alles in einer Umgebung und da kannst du nicht raus, okay, dann ist das so.

[1:06:18] Aber wenn du ein bisschen eine moderne Entwicklungsumgebung hast, wo du vielleicht zum Beispiel in Kubernetes oder so etwas betreibst,

[1:06:25] dann wäre jetzt ein guter Zeitpunkt, das schon mal grob zu planen.

[1:06:28] Gerade wenn deine Anwendung sich vielleicht auf mehrere Komponenten aufteilt, eine kleinen Server-Komponente.

[1:06:33] Was läuft wo? Wie kommunizieren die? Wie authentifizieren die sich? Und so weiter.

[1:06:37] Das muss ja auch geplant werden.

[1:06:39] Also überleg dir, welche Komponenten gibt es überhaupt? Sind die getrennt?

[1:06:42] Wenn ja, wo laufen die? Auf welchen physikalischen Servern? Wie reden die miteinander?

[1:06:46] Wie, wo wird überhaupt entwickelt? Machst du das lokal? Machst du es in der Cloud?

[1:06:51] Wird da Code generiert von JGBT? Was auch immer.

[1:06:54] Wie läuft deine Entwicklung überhaupt ab? Hast du eine IDE? Wenn ja, welche und warum?

[1:06:58] Dann gibt es ein Build-Tool.

[1:07:00] Ich gehe mal einfach davon aus, in jeder Programmier-Sprache, die ich kenne, gibt es Build-Tools, damit du dort nicht alles händisch machen musst.

[1:07:05] Von Compile über Test bis Deployment.

[1:07:07] Das heißt, entscheide dich für ein Build-Tool.

[1:07:09] Bau das Build-Skript. Wo soll der Build eigentlich laufen?

[1:07:12] Welche Schritte sind überhaupt notwendig?

[1:07:14] Das gehört für mich alles dazu zu so einem Software-Projekt.

[1:07:17] Wenn wir noch einen Schritt weiter gehen in der Build-Pipeline, welche Stages gibt es?

[1:07:20] Gibt es so etwas wie Entwicklung, QS, Prod? Wie kriegst du das von der einen Stage in die andere?

[1:07:24] Machst du das händisch? Macht das ein CI-Server?

[1:07:27] Macht das der Admin, dem du das rüberschmeißen musst?

[1:07:29] Gibt es da irgendwelche Prozesse, die du einhalten musst?

[1:07:32] Lässt du das ganze Zeug an Containern laufen?

[1:07:34] Wenn ja, welche? Ist das Docker? Ist es was auch immer? Läuft es in Kubernetes? Läuft es bei dir lokal?

[1:07:39] Solche Sachen muss man sich vielleicht mal überlegen.

[1:07:42] Und auch hier kannst du wieder aus dem Vollen schöpfen, was die Artefakte angeht.

[1:07:45] Das aus meiner Sicht am besten geeignete wäre hier ein Deployment-Diagramm.

[1:07:49] Ein Verteilungs-Diagramm aus der UML. Das ist standardisiert.

[1:07:52] Eines der 14 Diagramm-Typen kennt normalerweise jeder Prüfer oder jede Prüferin.

[1:07:56] Das ist genau dafür da, welche Komponente läuft in welcher Version, in welchem Application-Server,

[1:08:01] auf welchem physikalischen Server, in welchem Cluster und so weiter.

[1:08:04] Mit welcher Betriebssystem-Version läuft das?

[1:08:06] Und genau für solche Sachen ist das Deployment-Diagramm da.

[1:08:09] Das kannst du wunderbar dafür nutzen.

[1:08:11] Du kannst auch ein Aktivitäts-Diagramm zeichnen, wenn ihr sowas nicht habt, wie gerade beschrieben.

[1:08:15] Zum Beispiel SAP mit drei Stages, Entwicklung, QS-Prod oder so.

[1:08:19] Dann malst du halt ein Aktivitäts-Diagramm.

[1:08:21] Hier übernimmt der Admin ab da, entscheidet das, ist jetzt auf der nächsten Stage.

[1:08:24] Und dann machst du die Swimlanes zum Beispiel für die Stages.

[1:08:27] Du kannst aus dem Vollen schöpfen.

[1:08:29] Du kannst nicht sagen, ich mache SAP, also kann ich das alles nicht aufzeichnen.

[1:08:32] Nee, das kannst du gerne zur Dokumentation oder Modellierung jetzt zum Beispiel machen mit einem Aktivitäts-Diagramm.

[1:08:36] Oder wieder mit einem Sequenz-Diagramm.

[1:08:38] Oder du modellierst wirklich eine Build-Pipeline und zeigst das zum Beispiel als Source-Code in deinem Anhang.

[1:08:43] Die Build-Pipeline, weiß ich nicht, ein Jenkins-File zum Beispiel.

[1:08:46] Oder ein Docker-File oder ein Build-File.

[1:08:48] Wir arbeiten mit Java zum Beispiel ein Gradle-Build-File.

[1:08:51] Kannst du einen Ausschnitt von dem.

[1:08:52] Hast du schon wieder das nächste Aktivität, ein bisschen Code.

[1:08:54] Du kannst aber auch die Build-Pipeline in Jenkins einfach abfotografieren oder ein Screenshot von machen.

[1:08:58] So, schön bunt, mit grün und roten Blöppeln drin und so. Wunderbar.

[1:09:02] Alles Dinge, die du zu diesem Zeitpunkt schon machen kannst und die deinen Anhang füllen.

[1:09:06] Und die auch Sinn ergeben.

[1:09:08] Denn, wenn wir auch hier wieder von der Reihenfolge her mal gucken.

[1:09:10] Es nützt dir gar nichts, wenn du erst anfängst zu programmieren.

[1:09:13] Und danach dann feststellst, oh scheiße, ich krieg den Code gar nicht auf die Produktion.

[1:09:16] Es wäre vielleicht umgekehrt sinnvoller, erst zu überlegen, wie du den Code da hinkriegst.

[1:09:20] Und dann anzufangen zu programmieren.

[1:09:22] Und ich sag mal so, in vielen Unternehmen wird das standardisiert sein.

[1:09:25] Wenn ich an Projekte denke, bei mir im Unternehmen, dann fangen wir nicht mit Java-Code an.

[1:09:29] Sondern fangen wir als allererstes mit dem Build-File an.

[1:09:31] Denn ohne Build-Prozess komme ich nicht weiter.

[1:09:33] Ich brauche immer einen automatisierten Build in Jenkins, der das Zeug dann baut und irgendwo hinschiebt.

[1:09:37] Und wenn ich keinen Build-File habe, dann passiert einfach nichts.

[1:09:39] Das heißt, der erste Schritt ist bei uns nicht der Java-Code, sondern das Build-File zu schreiben.

[1:09:43] Und dann wäre der logische nächste Schritt, die Build-Pipeline zu definieren.

[1:09:47] Und das Deployment zu definieren.

[1:09:49] Und dann mal so eine Art Hello World zu machen.

[1:09:51] Und zu gucken, ob das Zeug auch auf dem richtigen Web-Server landet.

[1:09:53] Und ich das aufrufen kann.

[1:09:54] Das wäre schon mal ein erster Spike aus dem XP.

[1:09:57] So ein Durchstich von vorn bis hinten durch alle Systeme.

[1:10:00] Um zu zeigen, ja, ich kriege meine Zeile Hello World auf den echten Server, wo es später auch landen soll.

[1:10:05] Das wäre ein guter Schritt zu diesem Zeitpunkt im Projekt.

[1:10:09] Wie gesagt, Aktivitätsdiagramm, Sequenzdiagramm, Build-Pipeline, Dockerfile, Build-File.

[1:10:12] Denk dir was aus. Das kannst du alles als Ergebnis produzieren.

[1:10:15] So, dann kommen wir zum Punkt Qualitätssicherung.

[1:10:18] Bitte auch vor dem Coden überlegen, wie du die Qualität denn sichern möchtest.

[1:10:23] Was für Qualitätskriterien gibt es denn überhaupt bei dir?

[1:10:26] Du kennst sicherlich die Qualitätskriterien nach ISO-Norm.

[1:10:28] Habe ich auch schon mal ein Podcast-Episode dazu gemacht und auch ein YouTube-Video.

[1:10:31] Ich hoffe, du kennst die. Allein für AB2 ist die wichtig.

[1:10:33] Aber überleg dir mal für dein Projekt, welche Kriterien sind denn für dein Projekt besonders wichtig?

[1:10:37] Ist Usability dir besonders wichtig?

[1:10:39] Weil du zum Beispiel eine ganz unterschiedliche, diverse Benutzergruppe hast und die alle damit arbeiten können müssen.

[1:10:44] Oder ist das ein Experten-System, wo es gar nicht so wichtig ist, wie Usability mäßig da, wie das läuft?

[1:10:49] Ist Effizienz dir wichtig? Ist dir Sicherheit wichtig?

[1:10:52] Alle diese ganzen Qualitätskriterien.

[1:10:54] Vielleicht gibt es ja 1, 2, 3, die besonders wichtig sind in deinem Projekt.

[1:10:57] Dann wäre es gut zu wissen, wie du das denn sicherstellen willst, dass du dich auch einhältst.

[1:11:00] Wie stellst du sicher, und das ist jetzt immer ein schönes Beispiel, was ich in vielen Dokus lese,

[1:11:05] dass dein Projekt benutzerfreundliche Oberflächen benutzt, die intuitiv bedienbar sind.

[1:11:11] Da lese ich dann wirklich, und das ist jetzt kein Spaß, einfach Sätze, so was wie

[1:11:14] Bei der Gestaltung der Oberflächen wurde darauf geachtet, dass diese intuitiv bedienbar sind.

[1:11:18] Ja, herzlichen Glückwunsch.

[1:11:20] Was heißt das denn jetzt genau? Was ist denn intuitiv bedienbar?

[1:11:23] Was hast du denn jetzt gemacht, damit die intuitiv bedienbar sind?

[1:11:27] Da würde ich mir schon ein bisschen mehr wünschen, als einfach nur so eine hohle Floskel.

[1:11:31] Und auch hier könnte man zum Beispiel wieder Mockups zeichnen, wenn eben die Usability besonders wichtig ist.

[1:11:36] Dann zeig doch auch ein Mockup, wo genau darauf geachtet wurde, auf die Usability.

[1:11:40] Das wäre doch was.

[1:11:41] Oder mach dir einen Plan, wenn Effizienz besonders wichtig ist, für einen Test unter Last,

[1:11:46] wo die CPU nicht über 50% kommen darf.

[1:11:49] Oder was auch immer.

[1:11:50] Mach dir Gedanken, wie du das sicherstellen willst, und zwar bevor du es entwickelst.

[1:11:55] So, und dann noch mal ganz wichtig, nicht nur die technische Qualität, auch die Fachlehrqualität.

[1:11:59] Wer testet denn überhaupt?

[1:12:00] Gibt es einen Fachbereich, der das ganze Zeug abnimmt?

[1:12:02] Gibt es einen Abnahmeprozess beim Kunden?

[1:12:04] Wer sagt dir, dass du es eigentlich richtig gemacht hast?

[1:12:07] Das wäre vielleicht auch ganz wichtig zu wissen, weil du selber kannst dir das nicht abnehmen.

[1:12:10] Das muss irgendwer machen.

[1:12:12] Wahrscheinlich ein Mensch.

[1:12:13] Vielleicht kann man es aber auch automatisieren.

[1:12:14] Überleg mal, und dann plan das hier an der Stelle.

[1:12:17] Was kann da rauskommen?

[1:12:19] Ein Testkonzept, ein Testplan.

[1:12:21] Es kann sogar eine Branching-Strategie für dein Git-Repo dabei rauskommen.

[1:12:24] Wenn du sowas wie Pull-Requests machen willst, weil ein anderer Kollege Vier-Augen-Prinzip drüber gucken soll,

[1:12:28] dann brauchst du vielleicht Feature-Branches mit Pull-Requests etc.

[1:12:31] Das kann hier als Ergebnis rauskommen.

[1:12:32] Eine Build-Pipeline kann hier wieder rauskommen, wo du drei, vier, fünf Schritte hast,

[1:12:36] die sich nur ums Testen drehen zum Beispiel.

[1:12:38] Unit-Test, Integrations-Test, System-Test als Beispiel.

[1:12:41] Ein Schulungskonzept, wo du dir überlegst, welche Benutzergruppe schule ich wann,

[1:12:45] damit die das Ding auch einsetzen können.

[1:12:47] Du kannst dir jetzt schon Gedanken machen, welche Dokumentationen du erstellen willst.

[1:12:51] Entwickler-Doku, Benutzer-Doku, was brauchst du eigentlich?

[1:12:54] Du kannst zu diesem Zeitpunkt schon die statische Code-Analyse einrichten,

[1:12:57] wenn du sowas wie Sona-Cube zum Beispiel im Einsatz hast oder ein Linter oder sowas.

[1:13:00] Jetzt schon mit einplanen.

[1:13:02] Aber auch der Entwicklungsprozess an sich, dass es Pull-Requests zum Beispiel geben soll,

[1:13:06] mit wem du da zusammenarbeitest, wer deinen Code abnimmt, solche Dinge.

[1:13:10] Das ist alles schon vor der ersten Implementierung sinnvoll zu planen,

[1:13:15] weil du musst es ja eigentlich bei der Implementierung schon direkt umsetzen.

[1:13:18] Jetzt mal wieder nur ein Beispiel.

[1:13:20] Ich will anfangen zu entwickeln und weiß, dass ich Feature-Branches nutze.

[1:13:24] Dann ist das allererste, bevor ich eine Zeile Code schreibe, in Git erstmal den Branch anzulegen.

[1:13:28] Sonst kann ich gar nicht sinnvoll anfangen zu entwickeln.

[1:13:30] Das heißt, das muss ich doch vorher wissen, welche Branching-Strategie ich anwende.

[1:13:34] Sonst bringt mir das ganze Coden auch nichts, weil ich im falschen Branch arbeite zum Beispiel.

[1:13:37] Dann kriege ich das ganze Zeug nie auf die Produktion.

[1:13:39] Das ist doch dämlich.

[1:13:41] Also sinnvoll ist, das alles vorher zu klären, bevor ich die erste Zeile Code schreibe.

[1:13:45] Und was kommt jetzt als Ergebnis raus dieser ganzen Bemühungen?

[1:13:48] Ein Pflichtenheft!

[1:13:51] Denn alles das, was wir gerade gehört haben, gehört in den Pflichtenheft.

[1:13:54] Das ist nämlich, wir erinnern uns kurz, Lastenheft.

[1:13:56] Was soll gemacht werden? Der Kunde schreibt die Anforderung.

[1:13:59] Pflichtenheft wird Vertragsbestandteil und da sagt der Auftragnehmer, und das bist du,

[1:14:03] du als Entwickler deines Projekts bist der Auftragnehmer,

[1:14:06] und der sagt, wie wird das denn jetzt konkret technisch gelöst?

[1:14:10] Und alles das, was wir gerade gehört haben, beschreibt genau das.

[1:14:13] Du hast ein schönes Datenmodell, du hast Mockups, du hast die Qualitätssicherung geplant,

[1:14:16] du weißt, wie das Zeug gebaut werden soll, wer es wo läuft, welche Architektur, welche Pormiersprache.

[1:14:21] Genau diese ganzen Gedanken sind Teil des Pflichtenhefts.

[1:14:25] Das ist jetzt der sinnvolle Abschluss dieser Entwurfsphase.

[1:14:28] Das Dokument, was all diese technischen Entscheidungen zusammenfasst.

[1:14:33] Und das kannst du wunderbar in deinen Anhang packen als nächstes Artefakt für die Prüfer und Prüferinnen.

[1:14:39] Ganz kurz dazu, meistens sind das nur Auszüge,

[1:14:42] weil das Pflichtenheft würde jetzt wirklich alle die oben genannten Artefakte enthalten.

[1:14:46] Das wäre natürlich wahrscheinlich länger als die ganze Doku.

[1:14:49] Deswegen wird es oft nur in Auszügen gezeigt.

[1:14:52] So, nachdem dieser große Meilenstein, das Pflichtenheft fertig ist,

[1:14:58] darfst du jetzt endlich anfangen zu programmieren.

[1:15:01] Und das passt auch ganz gut, denn ich habe immer so den Spruch, den ich meinen eigenen Zubis sage,

[1:15:06] das Pflichtenheft, das ist das Ding, was du einem Entwickler oder einer Entwicklerin auf den Tisch legen kannst

[1:15:10] und sagen kannst, hier, mach mal, in zwei Wochen sehen wir uns wieder, dann ist das fertig.

[1:15:14] So detailliert und genau muss das Pflichtenheft eigentlich formuliert sein.

[1:15:18] Eine Anleitung, wie man es programmieren muss.

[1:15:20] Und du siehst schon, wenn du das alles so machst, dann ist das Umsetzen in Code jetzt der kleinere Teil,

[1:15:26] der jetzt halt noch gemacht werden muss.

[1:15:28] Aber alle Entscheidungen sind eigentlich schon längst getroffen.

[1:15:31] Du weißt, welche Daten man, du kennst das Datenmodell, du weißt, wie die Oberflächen, das ist alles schon fertig.

[1:15:35] Jetzt musst du es nur noch in Code übersetzen.

[1:15:38] Und das ist der Punkt, der vielleicht in ein paar Jahren keinen Menschen mehr erfordert,

[1:15:43] sondern wo ich einfach chat.gpt sage, generieren wir das mal.

[1:15:46] Hier ist das Pflichtenheft, bauen wir die Software.

[1:15:48] Wir hoffen alle, dass das Schreiben des Pflichtenheftes weiterhin nur von Menschen gemacht werden kann,

[1:15:52] aber da werden wir dann die nächsten Jahre mal abwarten müssen.

[1:15:55] Aber so detailliert ist jetzt das Pflichtenheft und jetzt kommt ein ganz kurzer Part, nämlich implementieren.

[1:16:00] Und das wirst du jetzt auch sehen, allein wie lange ich darüber rede, das geht ganz schnell,

[1:16:03] denn das meiste ist jetzt eigentlich schon fertig, haben wir ja gerade schon gesagt.

[1:16:06] Und die meisten Artefakte sind auch schon fertig, die sind schon längst im Anhang.

[1:16:09] Und jetzt geht's an die Umsetzung.

[1:16:11] Das heißt, du fängst es an zu entwickeln, im besten Fall passend zu deinem Vorgehensmodell.

[1:16:17] Wie ganz am Anfang schon gesagt, test-driven development würde ich empfehlen.

[1:16:20] Ist gängige Praxis, kann man gerne machen.

[1:16:22] Sollte aber eben zu deinem Vorgehen auch passen.

[1:16:24] Das heißt, wenn du jetzt ganz weit oben schon ein detailliertes Klassendiagramm entworfen hast,

[1:16:28] ist es jetzt zu spät für TDD.

[1:16:30] Deswegen orientieren wir uns jetzt mal meinem Vorgehen.

[1:16:32] Ich habe ein Komponentendiagramm, weiß, wo ich hin will, aber ich habe die Klassen noch nicht konkret vor mir.

[1:16:37] Die entwickle ich jetzt mit TDD und dann wird ein Schuh draus.

[1:16:40] Du kannst jetzt überlegen, mache ich zum Beispiel, wenn du eine Datenhaltung hast,

[1:16:43] mache ich Code-first, also fange ich an, die Klassen zu schreiben und generiere mir dann die Tabellen daraus,

[1:16:47] was ganz viele Frameworks heutzutage zum Beispiel standardmäßig machen.

[1:16:50] Oder modelliere ich wirklich erst eine Datenbank, also Database-first und leite dann daraus meinen Code ab.

[1:16:57] Das sind ja zwei valide Vorgehensmodelle und viele OEMs unterstützen beides.

[1:17:00] Aber ich muss mich halt für eins entscheiden und ich kann nicht mal so oder mal so machen.

[1:17:03] Und in meiner Welt würde ich mich zum Beispiel ehrlich gesagt gar nicht um die Datenbank kümmern.

[1:17:07] Deswegen würde ich auch nie ein Tabellenmodell modellieren, weil das kommt sowieso am Ende einfach raus.

[1:17:12] Denn wenn ich jetzt überlege, ich arbeite Testgetrieben, ich baue meine Klasse und schreibe dann,

[1:17:17] in unserem Fall in Java, schreibe ich einfach AddEntity an den Klassennamen dran und dann landet das Ding einfach in der Tabelle.

[1:17:22] Darum muss ich mich gar nicht kümmern.

[1:17:24] Ich muss weder die Tabelle anlegen, noch die Benennen oder Keinitalitäten auflösen, weil das macht das OEM für mich.

[1:17:29] In Java, Hibernate zum Beispiel, macht aus meinem Code einfach die Tabelle.

[1:17:33] Ich habe null Kontakt zur Datenbank. Ich arbeite einfach nur im Code.

[1:17:36] Code-first halt.

[1:17:38] Von daher würde es, wenn ich so vorgehe und in vielen Projekten wird das so gemacht,

[1:17:42] überhaupt keinen Sinn ergeben, wenn ich vorher schon ein Tabellenmodell entwerfe.

[1:17:46] Weil das Tabellenmodell ist ein Abfallprodukt, weil der Code die Wahrheit enthält und aus dem Code die Tabelle generiert wird.

[1:17:53] Also, wenn ich überhaupt ein Tabellenmodell zeichne, dann als allerletztes zur Dokumentation,

[1:17:58] aber niemals zur Modellierung, weil das in der Realität gar nicht passiert,

[1:18:02] sondern das kommt am Ende automatisch raus.

[1:18:05] Die Datenbank ist ein Abfallprodukt. So sehe ich das.

[1:18:09] Wenn du es anders machst, völlig okay. Ich will das gar nicht bewerten.

[1:18:13] Beide Vorgehensweisen, Code-first, Database-first, haben ihren Sinn und Zweck. Völlig in Ordnung.

[1:18:17] Aber in vielen Projekten, die ich sehe, ist es halt Code-first.

[1:18:21] Und da ergibt es überhaupt keinen Sinn, vorher eine Tabelle zu entwerfen, wie gesagt.

[1:18:25] So, jetzt brauchen wir wieder einen Anhang. Was kommt da jetzt raus?

[1:18:28] Du programmierst das jetzt, du setzt es jetzt um. Da sollte natürlich Code bei rauskommen.

[1:18:31] Und wie ich schon 700 Mal gesagt habe, bitte nur interessanter Code.

[1:18:35] Und nicht Klassen mit Gettern und Settern und sonst nichts.

[1:18:38] Das ist langweilig. Das will niemand sehen.

[1:18:41] Wenn du einen schönen Algorithmus hast, zeig den.

[1:18:44] Mach verschiedene Programmiersprachen, zum Beispiel Frontend.

[1:18:46] Ganz oft haben wir Webanwendungen, ein bisschen was im Frontend mit JavaScript,

[1:18:49] ein bisschen was im Frontend mit Python, PHP, Java, whatever.

[1:18:52] Verschiedene Programmiersprachen, das ist spannend.

[1:18:54] Also Frontend, Backend, SQL-Abfragen, HTML.

[1:18:57] Zeig, dass du verschiedene Sprachen beherrschst, zum Beispiel.

[1:19:00] Das macht dein Projekt natürlich interessanter, komplexer und führt vielleicht zu einer besseren Note.

[1:19:05] Also zeig deine Vielfältigkeit, dass du nicht nur Java kannst zum Beispiel,

[1:19:09] sondern auch noch andere Sprachen und Sprachen im weitesten Sinne.

[1:19:12] HTML als Gestaltungssprache für Oberflächen, beziehungsweise als natürlich Auszeichnungssprache,

[1:19:17] ist halt eben auch etwas anderes als Java-Code.

[1:19:19] Also zeig doch, dass du hier viele Sachen beherrschst.

[1:19:21] Da kommt bestimmt was bei dir rum.

[1:19:23] Und du kannst natürlich auch ein Klassendiagramm erstellen im Nachhinein.

[1:19:27] Du kannst ein Sequenzdiagramm nochmal machen.

[1:19:29] Du kannst Screenshots der Anwendung machen, wenn das Ding endlich läuft.

[1:19:32] Ich habe schon so viele Dokus gelesen, wo nicht mal im Ansatz zu sehen war, wie das Ding am Ende aussah.

[1:19:36] Super traurig. Das ist ein Screenshot.

[1:19:38] Das würde ich unbedingt erwarten in jeder Projektdokumentation,

[1:19:40] wie das Ding am Ende ausschaut, was man da gebaut hat.

[1:19:43] Du kannst ein Tabellenmodell machen.

[1:19:45] Oder auch ein Screenshot der Projektstruktur.

[1:19:47] Wenn du zum Beispiel Eclipse oder IntelliJ in deiner IDE hast,

[1:19:50] du deine Packages strukturiert oder kannst ein Screenshot davon machen.

[1:19:54] Weil das ja auch Teil deiner Modellierungsaufgabe ist.

[1:19:56] Wie strukturiere ich meine Projektdateien?

[1:19:59] Das kannst du auch zum Beispiel in einen Anhang packen.

[1:20:01] Also sowas.

[1:20:02] Also das, was bei deiner echten Arbeit im Code jetzt wirklich rauskommt,

[1:20:06] das darfst du als Artefakt natürlich auch für die Projektdokumentation benutzen.

[1:20:11] So, und dann wäre es natürlich schön, wenn das Ding nicht nur programmiert ist, sondern natürlich auch deployed wird auf die echte Umgebung, auf die Zielumgebung, auf die Produktion.

[1:20:18] Das heißt, zu diesem Zeitpunkt kann sowas rauskommen, vielleicht wie ein Docker-File. Ja, du möchtest das Ding in Docker betreiben. Ja, wunderbar, baust ein Docker-File drauf.

[1:20:26] Oder du machst ein Screenshot der Build-Pipeline. Wie gerade, ne? Wir haben, kannst du auch bei der Qualitätssicherung machen, kannst du auch hier machen, ne?

[1:20:33] Du hast das jetzt im Nachhinein vielleicht nur angepasst, machst ein Screenshot. Hier, so wird mein Ding deployed. Das ist die Jenkins-Pipeline, so sieht es aus.

[1:20:39] Du kannst Screenshots von, wenn du ein Ticketsystem hast, wie Jira zum Beispiel, wir benutzen Redmine, kann irgendein anderes sein, ja?

[1:20:45] Mach ein Screenshot von einem Ticket, wo du dich mit einem Fachbereich über eine, keine Ahnung, über eine technische oder fachliche Implementierung ausgetauscht hast.

[1:20:52] So, hier, so habe ich mit dem Fachbereich kommuniziert. Zack, Artefakt für einen Anhang.

[1:20:55] Du kannst ein Screenshot der finalen Umgebung machen, also Screenshot des Browsers, wo wirklich die echte URL oben drin steht, dass man sieht, hey Mensch, das Ding läuft wirklich auf dem Server.

[1:21:03] Wenn das interessant wäre, ne? So, das sind Artefakte, die daraus purzeln.

[1:21:07] Und du siehst, allein von der Menge her, das ist gar nicht so viel. Das meiste hast du vorher alles schon fertig gehabt, bei der Modellierungsphase, ne, im Entwurf.

[1:21:13] Und hier beim Code, joa, da kommt halt Code raus, joa, und noch ein bisschen was anderes.

[1:21:16] Aber ganz viele andere Diagramme, wenn man so vorgeht, wie ich das empfehle, sind mehr oder weniger Abfallprodukte, ne?

[1:21:22] Klassendiagramm, Tabellmodell, kommt halt raus, wenn du Code-first Test-Stream-Development gemacht hast, ne?

[1:21:30] So, das war's zum Code, du siehst schon, also zur Implementierung, ne? So schnell kann das gehen. Wir gehen direkt weiter zur nächsten Phase.

[1:21:36] Und das wäre jetzt die Qualitätssicherung, ja? Ich hatte vorhin schon mal die Unterphase Qualitätssicherung planen.

[1:21:42] Jetzt kommt die Qualitätssicherung umsetzen, weil das musst du natürlich auch machen.

[1:21:45] Und da wäre es natürlich schön, wenn du die Sachen, die du dir vorher schon überlegt hast, auch wirklich umgesetzt hast, bei der Implementierung.

[1:21:50] Also, zum Beispiel Unit-Test, Integrations-Test, System-Test, Oberflächentest, auch wirklich geschrieben hast.

[1:21:56] Und da kannst du natürlich auch diesen Code wieder als Beispiel in den Anhang packen.

[1:21:59] Nicht nur Produktiv-Code, auch Test-Code ist natürlich spannend für Prüfer und Prüferinnen.

[1:22:04] Rein damit in den Anhang. Du kannst ein Screenshot machen, zum Beispiel der statischen Code-Analyse.

[1:22:08] Geil, 90% Code-Coverage, coole Sache, mach doch ein Screenshot von.

[1:22:12] Oder 0 Bugs gefunden oder 3 Codesmails von 700 oder was, ja? Solche Sachen.

[1:22:18] Ist doch geil, mach ein Screenshot davon, zeig das einfach, ne?

[1:22:21] So eine Bewertung deines Codes, am besten relativ objektiv mit statischer Code-Analyse, ne?

[1:22:26] Oder du kannst ein Screenshot von einem Ticket machen, wo jemand ein Code-Review gemacht hat.

[1:22:31] Oder wo dein PR abgenommen wurde, ne? Und da steht ein Kommentar drin.

[1:22:34] Hier in der Zeile, das und das besser machen.

[1:22:36] Damit man auch mal sieht, dass da auch wirklich was bei rumgekommen ist.

[1:22:38] Dass wirklich jemand auf den Code drauf geguckt hat. Solche Sachen, ja? Kannst du alles machen.

[1:22:42] Das kann ein Prosa-formuliertes Protokoll sein.

[1:22:46] Das kann ein Screenshot eines Tickets sein, eines Pull-Requests.

[1:22:49] Ein Test-Protokoll, wo jemand unterschrieben hat, hier das und das und das habe ich getestet und das funktioniert auch wirklich.

[1:22:55] Ein Abnahme-Protokoll, eine Test-Suite in deinem Test-Tool, ja?

[1:22:59] Es gibt zum Beispiel Unternehmen, die verwalten ihre manuellen Tests in extra Test-Tools, ja?

[1:23:04] Und da kannst du ein Screenshot von machen. Nur als Beispiel, ja?

[1:23:07] Also alles, was irgendwie glaubhaft vermittelt, dass wirklich Qualität auch gesichert wurde,

[1:23:12] darfst du hier an der Stelle dann in den Anhang packen.

[1:23:15] Und einiges kommt automatisch dabei raus, wenn du dir vorher schon Gedanken gemacht hast, wie du die Qualität sichern willst.

[1:23:21] Wie gesagt, Test-Protokoll kannst du vorher schon schreiben.

[1:23:24] Und am Ende machst du ein Screenshot oder ein Foto von dem unterschriebenen, wirklich ausgeführten Test-Protokoll.

[1:23:28] Und dann wird wieder so ein Schuh draus, ein roter Faden. Es baut aufeinander auf. Es ist sinnvoll, ja?

[1:23:35] So, dann habe ich noch eine letzte Phase, die mache ich noch gleich mit.

[1:23:39] Das ist die Dokumentation. Die darfst du bitte nicht vergessen.

[1:23:41] Dokumentation bei vielen IAKen Teil des Bewertungsschemas.

[1:23:44] Ich habe IAKen gesehen, wenn du keinerlei Dokumentation anbietest,

[1:23:47] also Benutzer-Doku, Entwickler-Doku, Admin-Doku, REST-API-Doku, was auch immer,

[1:23:51] dann sind das 10 bis 15 Prozent der Gesamtnote. Die fallen einfach weg dann, ja?

[1:23:55] Also, du musst dokumentieren. Es gibt keine Software ohne Dokumentation. Fertig.

[1:23:58] Und da kannst du natürlich auch nicht rausreden, dass du Scrum gemacht hast,

[1:24:01] denn auch bei Scrum gehört die Dokumentation mit dazu, ja?

[1:24:04] Es gibt im Magee-Manifest nicht die Aussage, wir wollen nur Code und keine Dokumentation.

[1:24:08] Nein, nein, nein, nein, nein. Da steht drin, im Zweifel machen wir lieber Code statt Dokumentation,

[1:24:13] aber wir machen trotzdem auch immer Dokumentation und die gehört dazu, ja?

[1:24:16] Also, unbedingt machen. Und das wäre vielleicht sinnvoll, dann zu gucken,

[1:24:20] welche Doku denn interessant wäre für dein Projekt, ne?

[1:24:23] Wenn du eine REST-API gebaut hast, dann brauchst du vielleicht nur eine Entwickler-Doku.

[1:24:27] Hast du eine UI, brauchst du vielleicht ein Benutzer-Handbuch.

[1:24:29] Vielleicht brauchst du aber einfach nur ein paar Tool-Tipps in der Oberfläche,

[1:24:32] die die Buttons erklären, weil der Rest so selbsterklärend ist,

[1:24:35] dass du keinen PDF dafür erstellen musst, wo es erklärt wird oder so, ne?

[1:24:38] Das muss halt Zielgruppen gerecht sein.

[1:24:40] Wer benutzt das Ding und was haben die für Ansprüche an eine Dokumentation?

[1:24:44] Und da kann jetzt herauskommen, als Artefakt wieder, eine Kunden-Doku, eine Benutzer-Doku.

[1:24:49] Das heißt, richtig schön in Word mit Screenshots und Pfeilen und rot umschlängelten Dingern.

[1:24:54] Das kannst du wunderbar grafisch aufbereiten als Handbuch, was du ausdrucken kannst, ja?

[1:24:59] Du kannst eine Entwickler-Dokumentation machen.

[1:25:01] Du kannst zum Beispiel mit Java-Doc in Java Kommentare reinschreiben

[1:25:04] und daraus eine Oberfläche generieren lassen oder was auch immer.

[1:25:07] Du kannst eine REST-API zum Beispiel mit Swagger dokumentieren,

[1:25:10] dass es diese netten Oberflächen hat, in denen man sogar die REST-Calls ausprobieren kann und so etwas.

[1:25:15] Du kannst eine Admin-Doku schreiben, wie man das Zeug installieren muss,

[1:25:18] ein README-File kannst du in deinen Repo legen und davon zum Beispiel ein Screenshot machen.

[1:25:22] Du machst ein Screenshot deines Git-Repos und unten wird die README gerendert so, als Beispiel.

[1:25:26] Wie man das Ding installiert, wie man die Entwicklungsumgebung aufsetzt,

[1:25:28] welche Bildbefehle man eingeben muss, so etwas, ja?

[1:25:31] Du kannst hier auch nochmal ein Verteilungsdiagramm im Nachhinein zeichnen, ja?

[1:25:35] Nicht als Modellierung, sondern als Dokumentation.

[1:25:38] Wo läuft denn jetzt wirklich die Anwendung?

[1:25:40] Welche Server gibt es? Wie wird das deployed, etc.?

[1:25:42] Kann das Ergebnis der Dokumentation sein.

[1:25:44] Du kannst ein Wiki-Artikel schreiben, ja?

[1:25:46] Es muss ja nicht immer die Hochglanz-Doku sein.

[1:25:48] Wenn bei euch im Unternehmen im Wiki dokumentiert wird, dann macht doch ein Screenshot aus dem Wiki.

[1:25:52] Fertig. Ist doch alles gut.

[1:25:54] Bildpipeline. Wenn die erst im Nachhinein erstellt wurde, kannst du Fotos machen oder irgendwie anders dokumentieren.

[1:26:00] Den Code zum Beispiel auch zeigen, ja?

[1:26:02] Oder eben meine beiden Lieblings-Artefakte, Klassendiagramm und Tabellmodell.

[1:26:06] Ich gucke fast immer bei jeder Doku, ob es ein Klassendiagramm und ein Tabellmodell gibt,

[1:26:10] mache da so meinen gedanklichen Haken.

[1:26:12] Ich gucke halt immer nur, ob es sinnvoll ist, ne?

[1:26:14] Und in meinem Vorgehen wäre es halt sinnvoll, das Ganze am Ende zu machen, wenn alles fertig ist.

[1:26:18] Dann einmal auf den Knopf zu drücken und dann kommt mit dem entsprechenden UML-Tool eben ein Klassendiagramm raus.

[1:26:22] Musst du noch ein bisschen hin- und herschieben, dass das schön aussieht.

[1:26:24] Oder, jetzt mal Beispiel, du hast MariaDB oder MySQL.

[1:26:27] Da kannst du auf Knopfdruck aus der Oberfläche einfach ein Tabellmodell,

[1:26:31] schön farbig, mit Karnieritäten, mit einem Schnickschnack einfach als JPEG speichern und bist fertig.

[1:26:35] Oder sogar als Vektorgrafik.

[1:26:37] Wenn du mit LaTeX arbeitest, natürlich nimmst du die Vektorgrafik, klar.

[1:26:39] Aber das kommt einfach fertig raus.

[1:26:42] Dafür musst du nichts tun.

[1:26:44] Du musst nur auf den Knopf drücken, ja?

[1:26:46] Und das sind so die low-hanging fruits.

[1:26:48] Die kannst du einfach reinballern.

[1:26:50] Dafür hast du so gut wie keinen Mehrwert.

[1:26:52] Aber es bringt dem Prüfer und der Prüferin ganz viel.

[1:26:54] Weil man natürlich am Klassendiagramm und Tabellendiagramm viel schneller sieht,

[1:26:57] wie die Komplexität deines Projekts war, als an so ein paar Zeilen Code, bürgerlichweise, ne?

[1:27:02] Also mach das doch.

[1:27:03] Das ist so einfach und so schnell gemacht.

[1:27:05] Ja, wunderbar.

[1:27:07] So, ich merke schon, wie ich mich in Rage rede,

[1:27:09] aber es ist mir einfach auch wichtig,

[1:27:11] dass wir ein paar coole, spannende und gut dokumentierte Projekte einfach bekommen,

[1:27:14] weil ich muss die ja auch lesen.

[1:27:16] Und ich finde es immer so schade, wenn das nicht umgesetzt wird.

[1:27:18] So, zum Abschluss habe ich jetzt noch ein Beispiel von vorn bis hinten,

[1:27:21] um nach einem von mir geschilderten Vorgehen jetzt halt eine sinnvolle Geschichte zu erzählen,

[1:27:26] einen roten Faden festzustellen

[1:27:28] und mit ein paar konkreten Technologien, wie ich das machen würde,

[1:27:32] einfach mal ein Beispiel, dass du es dir ein bisschen besser vorstellen kannst.

[1:27:35] Das gucken wir uns zum Abschluss an und dann bin ich auch fertig für heute.

[1:27:38] So, stelle mal uns mal vor, wir wollen was umsetzen.

[1:27:42] Es gibt irgend so ein altes Excel-Zeug.

[1:27:44] Ist mir jetzt auch ehrlich ganz egal, worum es geht, irgendein Versicherungskram oder so.

[1:27:47] Und das soll abgelöst werden durch eine Web-Anwendung.

[1:27:49] Ganz klassisch, in ganz vielen Projekten wird irgendwie sowas gemacht, ja?

[1:27:52] Ich habe so eine Excel-Lösung oder eine Access-Lösung oder was auch immer

[1:27:56] und da soll jetzt eine Web-Anwendung draus gemacht werden.

[1:27:58] Das nehmen wir jetzt mal als Beispiel.

[1:27:59] Dann fange ich ganz vorne an, Ist-Analyse.

[1:28:01] Ich spreche mal mit den bisherigen Anwendern.

[1:28:03] Was ist aktuell blöd? Was machen die überhaupt?

[1:28:05] Fehlt denen irgendwie was?

[1:28:06] Sind die genervt? Was soll da besser werden?

[1:28:08] Dann, damit ich selber verstehe, modelliere ich diesen Ablauf als EPK.

[1:28:13] Allerdings nicht mit Modellierungszweck, sondern zum Dokumentationszweck.

[1:28:16] Das heißt, ich baue ein EPK, wo ich dann selber besser nachvollziehen kann,

[1:28:20] wer macht was, wann, in welcher Reihenfolge.

[1:28:22] Und ich validiere das auch mit dem Fachbereich, ob ich das richtig verstanden habe.

[1:28:25] Das hilft mir auch dabei, das Projektziel zu definieren.

[1:28:28] Und daran kann ich dann Schwachstellen herleiten.

[1:28:31] Ich kann zum Beispiel sehen, oh, hier wird was ausgedruckt, da wird es wieder eingescannt.

[1:28:34] Das ist irgendwie uncool, das sollten wir digital lösen.

[1:28:36] Also Medienbrüche aufzeigen.

[1:28:38] Und währenddessen mache ich mir schon mal so ein paar Notizen.

[1:28:40] Ich höre immer zu, der Fachbereich sagt dir, das ist besonders nervig.

[1:28:43] Oder das kostet mich richtig viel Zeit.

[1:28:45] Das notiere ich mir schon mal, um zu gucken, ob ich das umsetzen kann.

[1:28:48] So, dabei kommt ganz nebenbei raus ein EPK des alten Zustands

[1:28:52] und ein Screenshot der bisherigen Excel-Datei.

[1:28:55] Und ich denke zu diesem Zeitpunkt auch schon an meine spätere Projektpräsentation,

[1:28:59] weil da hast du noch weniger Zeit, um den Prüfern und Prüferinnen zu erklären,

[1:29:02] was du eigentlich gemacht hast.

[1:29:03] Und mit so einem Screenshot der bisherigen Excel-Datei,

[1:29:05] da sparst du dir fünf Minuten Erklärung, weil die sehen sofort,

[1:29:08] oh Gott, alles redundant, super viele Filter und Formeln drin,

[1:29:11] ach du Scheiße, das versteht ja keiner.

[1:29:13] Und schon hast du alles erklärt mit ganz wenig Aufwand.

[1:29:16] Einfach einen Screenshot machen.

[1:29:17] So, gleich schon mal abgelegt für die Präsi.

[1:29:19] Dann geht es los.

[1:29:20] Ich habe mir nur ein paar Stichpunkte gemacht.

[1:29:21] Jetzt müssen die Anforderungen strukturiert werden.

[1:29:23] Ich gucke meine Notizen durch.

[1:29:24] Ich gucke, wen muss ich denn noch fragen?

[1:29:26] Gibt es noch andere Stakeholder?

[1:29:27] Gibt es andere Entwickler, wenn ich ein Teilprojekt zum Beispiel mache,

[1:29:30] muss ich mir mit denen abstimmen?

[1:29:31] Gibt es Schnittstellen? Gibt es irgendwie etwas?

[1:29:33] Und dann versuche ich, die einheitlich zu formulieren.

[1:29:35] Zum Beispiel als User Story.

[1:29:37] Das heißt, da bediene ich mich gerne auch aus einem agilen Prozess

[1:29:40] und nutze User Stories, weil die sind kurz und knackig

[1:29:42] und das ist das Wichtigste drin.

[1:29:43] Die gehen schnell von der Hand, die kann ich runterschreiben,

[1:29:45] die sehen immer alle einheitlich aus, wunderbar.

[1:29:48] Ich schreibe alle Anforderungen schön als User Story auf

[1:29:51] und packe die in einen, weiß nicht, kann eine Word-Datei sein

[1:29:53] oder in einen Wiki oder in einen Markdown-File, scheißegal.

[1:29:56] Hauptsache einheitlich.

[1:29:57] Und dann modelliere ich tatsächlich auch schon Use-Case-Diagrammen,

[1:30:00] damit ich im Fachbereich klären kann, ist es das,

[1:30:02] was das System für euch tun soll?

[1:30:04] Und dann sagen die ja oder nee, du hast noch was vergessen.

[1:30:06] Da kommt raus, Use-Case-Diagramm und ein Lastenheft.

[1:30:09] Das ist nämlich dann einfach die Liste meiner User Stories.

[1:30:11] Ein bisschen schön aufbereitet, ein bisschen priorisiert,

[1:30:13] was ist must, should, could, won't.

[1:30:15] Um das ein bisschen mit Moscow zu verknüpfen,

[1:30:16] habe ich mein Lastenheft schon fertig.

[1:30:17] Nächstes Artefakt.

[1:30:19] Dann kommt Skizzierung der neuen Lösung.

[1:30:21] Ich überlege mir den Prozess für die neue Lösung.

[1:30:24] Was war vorher schlecht? Stichwort Medienbruch.

[1:30:26] Was mache ich jetzt besser?

[1:30:27] Und das Ganze modelliere ich jetzt gerne wieder als EPK,

[1:30:30] weil dann habe ich die gleiche Diagrammform für Vorher und Nachher

[1:30:34] und kann es gut vergleichen.

[1:30:35] Da kann man einfach direkt den Unterschied sehen,

[1:30:37] was jetzt besser ist.

[1:30:38] Schon habe ich das nächste Artefakt EPK des neuen Zustands.

[1:30:41] Dann überlege ich mir die Plattform.

[1:30:43] Das wusste ich eigentlich schon vorher,

[1:30:44] soll eine Web-Anwendung werden.

[1:30:45] Okay, dann kann ich es gut begründen.

[1:30:46] Zum Beispiel kann man am einfachsten deployen.

[1:30:48] Jeder hat einen Browser, macht das einfach auf.

[1:30:50] Ich muss mich um nichts mehr kümmern.

[1:30:51] Deployment ist super einfach.

[1:30:52] Los geht's.

[1:30:53] Dann gehe ich zum UI.

[1:30:55] Ich überlege mir, was wollen die jetzt machen.

[1:30:57] Gucke mir die Excel-Datei an.

[1:30:58] Versuche das Ganze mal in der Oberfläche zu basteln.

[1:31:01] Und das mache ich tatsächlich auf dem iPad mit dem Pencil.

[1:31:04] Male ich da ein bisschen was auf.

[1:31:05] Ich nehme kein Tool aus dem Internet oder sonst irgendwas

[1:31:07] oder Pixel Perfect und Photoshop.

[1:31:09] Viel zu umständlich.

[1:31:10] Und das brauchen wir zu diesem Zeitpunkt noch gar nicht.

[1:31:12] Sondern es soll darum gehen,

[1:31:13] was soll die Anwendung überhaupt machen

[1:31:14] und wie unterstützt sie dabei.

[1:31:16] Und das zeichne ich mit dem Pencil eben auf.

[1:31:18] Und wenn das falsch ist,

[1:31:19] dann schiebe ich das von links nach rechts

[1:31:21] und dann muss ich nicht drei Stunden daran arbeiten,

[1:31:23] um die Pixel wieder gerade zu rücken.

[1:31:25] Also schnell runtergezeichnet.

[1:31:27] Am besten im gleichen Raum mit den Anwendern,

[1:31:29] damit die mir direkt sagen können, was alles anders soll.

[1:31:32] Und dann meinetwegen auch auf Papier

[1:31:34] und nachher abfotografieren.

[1:31:35] Ganz egal.

[1:31:36] Auf jeden Fall kommt am Ende raus ein Mockup.

[1:31:38] Oder mehrere Mockups auch.

[1:31:40] Meistens ist die Anwendung komplexer

[1:31:42] und es ist nicht nur ein Screen,

[1:31:43] sondern vielleicht ein paar mehr

[1:31:44] mit Übergängen dazwischen und so weiter.

[1:31:46] Das heißt, da würde ich mir wirklich die Arbeit machen,

[1:31:48] jeden Screen als Mockup aufzuschreiben.

[1:31:50] Weil diese Arbeit ist fünf Minuten auf dem Papier

[1:31:53] oder auf dem iPad ein bisschen was zeichnen.

[1:31:55] Das ist halt, wenn man das vergleicht

[1:31:57] mit der Implementierung später,

[1:31:59] viel, viel, viel, viel weniger Zeit.

[1:32:01] Also eben schnell skizzieren.

[1:32:03] Geht ganz schnell.

[1:32:04] Und dann weiß ich aber, wo ich hin muss

[1:32:05] und kann mich daran später orientieren.

[1:32:07] Das heißt, im Zweifel würde ich hier

[1:32:09] lieber drei Stunden mehr investieren bei den Mockups

[1:32:12] als später bei der Implementierung.

[1:32:13] Weil das hole ich vielfach wieder raus,

[1:32:15] wenn ich jetzt schon abgestimmt habe,

[1:32:16] wie es eigentlich aussehen soll.

[1:32:17] Also Mockups auf jeden Fall

[1:32:19] möglichst vollständig erfassen.

[1:32:21] Dann ziehe ich mich zurück in mein Kämmerlein

[1:32:24] und leite aus den Mockups ein Datenmodell ab.

[1:32:26] Und zwar als Entity Relationship Model.

[1:32:28] Entitätstypen mit Kriminalitäten und allem Schnickschnack.

[1:32:30] Mal das schön abstrakt auf.

[1:32:32] Und dann gehe ich in Richtung der Architektur.

[1:32:34] Ich weiß, in meinem konkreten Fall,

[1:32:36] ich darf mir ja was wünschen,

[1:32:37] mache ich das mit Domain Driven Design.

[1:32:39] Das heißt, ich fange mit der Domäne an,

[1:32:41] versuche, die ohne Abhängigkeiten aufzubauen,

[1:32:43] ziehe die Datenbank nach außen,

[1:32:45] ziehe die Infrastruktur nach außen.

[1:32:46] Wenn ich zum Beispiel Dateizugriffe habe,

[1:32:47] gehören die nicht in die Domäne rein.

[1:32:48] Ich weiß, wie ich meine Domäne vor der Außenwelt schütze.

[1:32:51] Ich mache Repositories da rein.

[1:32:53] Ich mache Services da rein.

[1:32:54] Ich weiß schon grob,

[1:32:55] wie meine Komponenten aufgebaut sein sollen.

[1:32:58] Deswegen kommt als Ergebnis ein Komponenten-Diagramm raus.

[1:33:01] Und für mich,

[1:33:02] weil ich jetzt zum ersten Mal in dieser Domäne arbeite,

[1:33:04] auch ein kleines Glossar der zentralen Begriffe.

[1:33:07] Das heißt, wenn die Komponente in der Domäne etwas enthält,

[1:33:10] was Versicherungspolice heißt,

[1:33:12] dann habe ich jetzt im Glossar einen kleinen Mini-Absatz

[1:33:15] oder vielleicht wirklich nur einen Satz,

[1:33:17] der erklärt, was eine Police ist.

[1:33:19] Und da kann ich später immer wieder draufgucken,

[1:33:21] wenn ich mir nicht mehr ganz sicher bin,

[1:33:23] ob das Ding, was ich da gerade bearbeite,

[1:33:24] jetzt eine Police ist oder ein Vertrag.

[1:33:26] In dem Glossar kann ich es nachlesen.

[1:33:27] Das erspart mir vielfache Telefonate oder Chats mit meinen Kollegen,

[1:33:32] die mir das zum x-mal erklären müssen.

[1:33:34] Dann Datenhaltung.

[1:33:35] Wie will ich speichern?

[1:33:36] Ja, mein Projekt passt ganz gut.

[1:33:38] MariaDB haben wir auch in anderen Projekten im Einsatz.

[1:33:40] Kenne ich mich gut mit aus.

[1:33:41] Ist alles schon dokkerisiert bei uns.

[1:33:42] Nehme ich. Wunderbar.

[1:33:43] Nehme ich einfach.

[1:33:44] Gibt auch keinen Grund für mich, eine andere Datenbank zu nehmen.

[1:33:47] Kann ich machen.

[1:33:48] So, Premiere-Sprache.

[1:33:49] Nehme ich das, was etabliert ist,

[1:33:50] gibt das Unternehmen vor und es passt aber auch gut zum Umfeld.

[1:33:52] Ich nehme Java mit Quarkus,

[1:33:54] weil viele andere Projekte auch schon damit arbeiten.

[1:33:56] Ich habe damit auch schon fünfmal gearbeitet.

[1:33:58] Und das nochmal ein wichtiger Tipp.

[1:33:59] Nutz keinen Framework und keine Sprache,

[1:34:01] die du noch nie benutzt hast.

[1:34:02] Das geht nur nach hinten los.

[1:34:03] Nimm etwas, was du kennst.

[1:34:04] Und das kannst du auch vernünftig begründen.

[1:34:06] Du kannst sagen, ich habe mich dafür entschieden,

[1:34:08] weil ich das schon kenne.

[1:34:09] Und das ist ein valider Grund,

[1:34:10] weil du sollst hier ein vernünftiges Projekt umsetzen

[1:34:12] und nicht die Hälfte deiner Zeit damit verbringen,

[1:34:14] eine neue Premiere-Sprache zu lernen.

[1:34:15] Das ist nicht deine Aufgabe.

[1:34:17] Also, ich nehme Java mit Quarkus.

[1:34:19] Es ist schon etabliert und ich kenne das gut.

[1:34:21] Und außerdem passt es gut zum Anwendungsfall,

[1:34:23] denn das läuft gut in Containern

[1:34:24] und ich will die Anwendung in Containern betreiben.

[1:34:26] Das habe ich mir gerade überlegt und deswegen nehme ich das dafür.

[1:34:29] Was kommt daraus?

[1:34:30] Eine kleine Liste mit den Technologien,

[1:34:32] wo ich hinterschreibe hier Java 21, Quarkus 3 etc.

[1:34:35] Das kann sehr spezifisch schon sein.

[1:34:37] Dann überlege ich mir die Geschäftslogik und Domäne aus dem Datenmodell.

[1:34:41] Ich habe jetzt mein ER-Modell.

[1:34:42] Ich kann mir das ausdrucken

[1:34:43] oder ich kann es mir einfach auf dem Bildschirm anzeigen.

[1:34:44] Ich muss ja kein Papier verschwenden.

[1:34:46] Und dann überlege ich mir, was kommt da jetzt daraus?

[1:34:48] Ich kann mir vielleicht ein grobes Klassendiagramm

[1:34:50] für so ein paar interessante Punkte rausnehmen,

[1:34:52] wo ich nochmal ein bisschen drüber nachdenke,

[1:34:54] bevor ich das programmiere.

[1:34:55] Da würde ich jetzt aber zum Beispiel

[1:34:56] keine Methoden und Attribute reinschreiben,

[1:34:58] sondern wirklich nur die Namen der Klassen,

[1:34:59] dass ich eine grobe Idee habe, wo ich hin will,

[1:35:01] wie ich die benenne.

[1:35:02] Vielleicht gibt es hier nochmal einen Unterschied

[1:35:04] zwischen dem Datenmodell und den Klassen.

[1:35:05] Vielleicht muss ich was aufteilen.

[1:35:06] Ich brauche noch ein paar mehr Namen.

[1:35:08] Sowas in diese Richtung.

[1:35:09] Eine grobe Idee, wo ich hin will.

[1:35:11] Und weil ich einen super komplizierten Algorithmus habe,

[1:35:14] mache ich mir dafür sogar ein Sequenzdiagramm,

[1:35:16] weil der so kompliziert ist.

[1:35:18] Habe ich mir gerade ausgedacht.

[1:35:19] Muss es in deinem Projekt nicht geben.

[1:35:20] Und dann überlege ich mir Bild und Deployment.

[1:35:23] Wie gerade schon gesagt,

[1:35:24] ich muss mir das Bildfile schreiben,

[1:35:26] bevor ich überhaupt eine Zeile Code schreiben kann.

[1:35:28] Also muss ich mir entscheiden, was nehme ich?

[1:35:29] Und dann nehme ich auch natürlich das,

[1:35:31] was im Unternehmen etabliert ist.

[1:35:32] In meinem Fall jetzt Gradle als Bildtool

[1:35:34] und Jenkins als Bildserver.

[1:35:35] Das heißt, ich erstelle mir ein Bildfile

[1:35:37] und ein Jenkins-File

[1:35:38] und teste das dann erstmal, ob das funktioniert.

[1:35:40] Lege mir ein Git-Repo an,

[1:35:42] pushe das Zeug da rein,

[1:35:43] gucke, ob der Jenkins das bauen kann.

[1:35:44] Das heißt, ob die Infrastruktur da ist.

[1:35:46] Das teste ich,

[1:35:47] bevor ich eine Zeile Code überhaupt schreibe.

[1:35:49] Bzw. ich schreibe eine Zeile Code

[1:35:51] und zwar 0815 Addere-Funktion

[1:35:53] und einen Test dafür,

[1:35:54] damit ich testen kann,

[1:35:55] ob die Build-Pipeline auch Unit-Tests ausführt.

[1:35:59] Was kommt dabei raus?

[1:36:00] Deployment-Diagramm.

[1:36:04] Wo war ich da?

[1:36:05] Ja genau, beim Deployment-Diagramm.

[1:36:06] Genau, jetzt sage ich,

[1:36:07] das läuft auf dem Server,

[1:36:08] das läuft in Kubernetes,

[1:36:09] das mache ich lokal

[1:36:10] und wie kommt das da endlich hin?

[1:36:11] Über Git und Jenkins und wie hängt das alles zusammen?

[1:36:13] Das male ich in das Deployment-Diagramm rein.

[1:36:15] Dann habe ich eine Build-Pipeline gerade geschrieben.

[1:36:17] Das ist Code, kann den anhangen.

[1:36:18] Dockerfile habe ich gerade geschrieben.

[1:36:19] Code, Buildfile, Code.

[1:36:20] Da habe ich schon drei verschiedene Technologien.

[1:36:22] Buildfile, Dockerfile und Buildpipeline,

[1:36:25] also Pipeline as Code,

[1:36:26] sind schon drei verschiedene Technologien,

[1:36:28] verschiedene Sprachen vielleicht sogar,

[1:36:30] die ich zeigen kann.

[1:36:31] Wie geil, oder?

[1:36:32] So kompliziert und komplex ist mein Projekt.

[1:36:34] Mensch, bin ich ein geiler Coder.

[1:36:35] Perfekt.

[1:36:36] Und dann überlege ich mir die Qualitätssicherung.

[1:36:38] Ich will natürlich mit TDD entwickeln,

[1:36:39] wie es sich gehört.

[1:36:40] Da ist ja schon mal Unit-Testing mit eingebaut.

[1:36:42] Hervorragend.

[1:36:43] Dann gibt es technische Abnahme über Pull-Requests,

[1:36:44] weil ich arbeite mit Feature-Branches.

[1:36:46] Auch wenn ich ehrlicherweise gar nicht mit Featuren hier arbeite,

[1:36:49] weil ich habe nur ein Projekt.

[1:36:50] In zwei Wochen werde ich jetzt keine fünf Feature-Branches aufmachen.

[1:36:52] Aber wenn das halt abgenommen werden muss vielleicht,

[1:36:55] weil der Prozess es vorgibt,

[1:36:56] dann mache ich halt Feature-Branches mit Pull-Requests.

[1:36:58] Außerdem werde ich sofort die statische Code-Analyse,

[1:37:00] in unserem Fall mit Zona-Kube, einbauen.

[1:37:02] Check also schon mal nach dem ersten Commit,

[1:37:05] ob das in Zona-Kube auch richtig ankommt.

[1:37:07] Kann da vielleicht schon mal nachsteuern,

[1:37:09] wenn ich noch Plugins nachinstallieren muss oder was auch immer.

[1:37:11] Ich will, dass die ganze Infrastruktur läuft,

[1:37:13] bevor ich meine erste Zeile codeschreibe.

[1:37:15] Denn wenn ich erst mal anfange zu programmieren,

[1:37:17] will ich auch möglichst schnell ein Feedback haben.

[1:37:19] Und wenn ich dann anfangen muss,

[1:37:21] bevor ich es dem Fachbereich zeigen kann,

[1:37:22] erst mal drei Wochen meine Build-Pipeline aufzusetzen,

[1:37:24] das ist eine schlechte Idee.

[1:37:26] Deswegen, das muss einfach alles da sein

[1:37:28] und dann fange ich an zu programmieren.

[1:37:30] Übrigens, es muss in deinem Projekt nicht so sein,

[1:37:32] dass du das alles selber umsetzt.

[1:37:34] Wenn das in deinem Unternehmen nicht so ist

[1:37:36] und wenn du das einfach geschenkt bekommst,

[1:37:38] weil ihr einen DevOps-Spezialisten habt,

[1:37:40] der euch das zur Verfügung stellt,

[1:37:42] dann mach das, es ist okay.

[1:37:44] Kümmer dich aber nur einfach darum, dass es deployed wird.

[1:37:46] Und in meinem Fall ist es halt so,

[1:37:48] dass die Entwickler das selber mitmachen.

[1:37:50] Gehört also auch zu diesem Projekt mit dazu.

[1:37:52] Und genau, habe ich jetzt schon mal wieder was,

[1:37:54] was ich in den Anhang packen kann.

[1:37:56] Daraus mache ich jetzt ein Pflichtenheft.

[1:37:58] Ich zeige jetzt ein paar wilde Artefakte,

[1:38:00] die ich vielleicht noch nicht an anderer Stelle gezeigt habe.

[1:38:02] Also jetzt bitte nicht,

[1:38:04] ich habe jetzt nur als Beispiel oben ein Klassendiagramm gemalt

[1:38:06] und jetzt zeige ich die eine Seite meines Pflichtenhefts,

[1:38:08] auf der genau das gleiche Klassendiagramm steht.

[1:38:10] Das ist verschwendeter Platz.

[1:38:12] Also ich habe zwei Seiten verschenkt,

[1:38:14] habe aber das gleiche Klassendiagramm gezeigt.

[1:38:16] Das ist natürlich dämlich.

[1:38:18] Das heißt, ich würde das ER-Modell,

[1:38:20] das Klassendiagramm von oben in den Anhang packen

[1:38:22] und im Pflichtenheft zeige ich dann was,

[1:38:24] was ich nicht vorher schon sowieso gezeigt habe.

[1:38:26] Was noch nicht zu sehen war.

[1:38:28] Im Auszug aus dem Pflichtenheft,

[1:38:30] weil das natürlich so lange ist,

[1:38:32] dass ich es nicht komplett zeigen kann.

[1:38:34] Damit ich dem Prüfer oder der Prüferin

[1:38:36] eben ein bisschen mehr zeigen kann

[1:38:38] und nicht dreimal das gleiche.

[1:38:40] Das ist irgendwie ziemlich dämlich.

[1:38:42] So, dann fange ich endlich an zu programmieren

[1:38:44] und ich mache das natürlich Code-first mit TDD.

[1:38:46] Ich fange jetzt an zu programmieren.

[1:38:48] Erstmal den Test, dann die Klassen

[1:38:50] und baue mir das alles auf

[1:38:52] und orientiere mich an meinem Datenmodell.

[1:38:54] Ist das eine Domänenklasse?

[1:38:56] Ist das ein Value-Object?

[1:38:58] Was baue ich eigentlich gerade?

[1:39:00] Damit ich weiß, wo ich mich gerade befinde.

[1:39:02] Und dabei hilft mir wirklich so ein Komponenten-Diagramm,

[1:39:04] an dem ich mich orientiere.

[1:39:06] Dann mache ich ein Feature-Branch auf im Git,

[1:39:08] push das ganze Zeug, lasse ein PR schon mal abnehmen

[1:39:10] und so weiter und habe ganz viele Artefakte,

[1:39:12] die daraus purzeln.

[1:39:14] Nämlich Code-Beispiele, Produktiv- und Test-Code,

[1:39:16] denn ich habe ja TDD benutzt, also habe ich beides.

[1:39:18] Ich kann schon mal ein Screenshot machen

[1:39:20] von der Anwendung, wenn ich fertig bin,

[1:39:22] hier meine Code-Coverage über 80%,

[1:39:24] Foto machen zum Beispiel,

[1:39:26] Screenshot von meinem Pull-Request.

[1:39:28] Der Kollege hat reingeschrieben, hier die Klasse würde ich aber anders benennen,

[1:39:30] weil bei uns heißt das so und so.

[1:39:32] Ja geil, schon mal gezeigt, dass auch ein Mensch drüber geguckt hat.

[1:39:34] Vier-Augen-Prinzip, rein in den Anhang.

[1:39:36] Und wenn er auch einen Kommentar dazu geschrieben hat,

[1:39:38] gerne auch mit fotografieren.

[1:39:40] So, dann ist das Ding komplett fertig,

[1:39:42] dann mache ich jetzt das Deployment.

[1:39:44] Das heißt, ich drücke auf den Knopf,

[1:39:46] weil ich habe ja alles schon vorher vorbereitet

[1:39:48] und der Jenkins deployed mir das auf mein Zielsystem

[1:39:50] und der letzte Schritt ist halt

[1:39:52] Deploy to Production und davon mache ich ein Foto

[1:39:54] und sage hier, deployed.

[1:39:56] Und dann mache ich noch ein Foto, wie ich diese URL in den Browser eintippe

[1:39:58] und sehe, Mensch, da ist ja meine Anwendung zu sehen, Überraschung.

[1:40:00] Und schon habe ich gezeigt,

[1:40:02] das Ding läuft auch wirklich, es gibt es auf dem echten Server

[1:40:04] und ich habe nachgewiesen,

[1:40:06] dass das Ding umgesetzt wurde.

[1:40:08] Und dann schreibe ich nochmal eben die Doku,

[1:40:10] wobei schreiben, naja, ich kann mir auch viel generieren lassen,

[1:40:12] denn wir haben ja schon gemerkt, ich habe TDD gemacht

[1:40:14] und Code-First,

[1:40:16] das heißt, lassen wir erstmal auf Knopfdruck

[1:40:18] erzeugen, schiebe nochmal ein bisschen die Klassen von A nach B,

[1:40:20] dass es ein bisschen netter aussieht

[1:40:22] und das Tabellenmodell auch.

[1:40:23] Zwei weitere Artefakte für den Andrang, für die ich genau nichts gemacht habe, außer fünf Minuten irgendwo auf den Button gedrückt und dann schreibe ich noch eine Benutzer-Doku, weil ich eine super komplizierte Anwendung für den Fachbereich habe und die brauchen eine Anleitung, also mache ich Word auf oder LaTeX, mache ein paar Screenshots rein, mache ein paar Pfeile drauf und sage hier klicken, wenn sie was anlegen wollen und so und meine API-Dokumentation habe ich natürlich während der Entwicklung schon gemacht, das heißt die öffentlichen Methoden, bitte nicht falsch verstehen, ich will nicht jede private Methode dokumentieren, das ist völliger Quatsch, aber die öffentliche Dokumentation meiner Software, das kann die REST-API sein, das kann einfach nur die

[1:40:52] Public-Methoden von meinen Klassen sein, die habe ich mit Javadoc dokumentiert und drücke jetzt auf den Knopf und wenn ich ganz schlau bin, muss ich nicht mehr auf den Knopf drücken, weil zum Beispiel Javadoc Teil meiner Build-Pipeline ist, ja, das heißt es wird automatisch nach den Unitests, nach dem Compile, wird automatisch Javadoc aufgerufen, das kann man in dem Build-Prozess einfach machen, das heißt dann muss ich hier gar nichts mehr machen, im wahrsten Sinne des Wortes, es kommt automatisch raus, ja, ich muss nur den Browser aufmachen und einen Screenshot davon machen, bin fertig mit der Doku, ja und als allerletztes, damit andere Entwickler auch einsteigen können und

[1:41:22] ich in fünf Monaten auch noch, schreibe ich noch eine Readme und packe die ins Git-Repo, hier, mach folgendes, Gradle Build oder Gradle Idea oder was auch immer und mach das Ding in IntelliJ auf und programmiere weiter als Entwickler-Doku, um daran weiterarbeiten zu können, davon mache ich auch noch einen Screenshot und dann bin ich fertig und dann habe ich schon so viel Zeug, dass ich schon gucken muss, was ich davon eigentlich noch wieder löschen muss, damit ich meinen Anhang einhalte, denn viele IHKs machen natürlich Vorgaben, was die Seitenzahl angeht und wenn man mal hier durchzählt, das ist mehr als eine Handvoll Artefakte, das sind ganz schön viele, das heißt,

[1:41:52] das sage ich auch immer wieder, wenn du Probleme hast, deine Seiten zu füllen in der Doku,

[1:41:57] dann hast du einfach irgendwie grundsätzlich was falsch gemacht, denn wenn du so vorgehst, wie ich es hier beschrieben habe, wir haben ja noch nicht mal die Wirtschaftlichkeit, die Amortisationsrechnung, deine Projektphasen, dein Gantt-Diagramm, dein was auch immer, das haben wir alles noch nicht mal mit drin und ich habe jetzt schon 10, 15, 20 Artefakte,

[1:42:13] die quasi fast nebenbei rauskommen, wenn du dein Projekt einigermaßen sinnvoll und aufeinander aufbauend umsetzt, also du solltest kein Problem haben, deine Anhang-Seiten in der Doku zu füllen, Fließ-Text könnte immer ein bisschen schwieriger werden, aber die Artefakte, die kommen fast automatisch dabei raus, wenn du dich so ein bisschen methodisch an die Softwareentwicklung hältst.

[1:42:35] So, das war mein Appell heute mit einem konkreten Beispiel, wie du dein Projekt vielleicht so umsetzen kannst, dass du eine gute Note dafür bekommst, aber, und das ist mir eigentlich viel, viel wichtiger, dass du das auch für die Praxis mitnimmst und in echten Projekten auch anwendest, weil das ist absolut sinnvoll, das zu tun, in keinem Projekt fängt man einfach an zu coden, das ist der falsche Weg und diese Zeit, die du für einen Mockup investierst, ich habe es schon jetzt so oft gesagt, die holst du x-fach wieder rein,

[1:43:04] weil du nicht mit dem Fachbereich siebenmal telefonieren musst oder das, ich sehe es bei meinen eigenen dazu bisher auch, die setzen einfach irgendwas um, weil sie denken, dass es so ist und dann kann ich denen nach einer Minute sagen, wenn ich drauf geguckt habe, ja, sorry, falsch verstanden, muss anders, ja, und die Programmierzeit, die da verloren geht einfach, anstatt einmal, weiß ich nicht, per Teams Screenshots zu schicken, hey, willst du das so oder so, ja, ich will es linksrum, ja, super.

[1:43:26] Also diese eine Nachfrage von 30 Sekunden, die hat einem tagelanges Entwickeln und am Ende sagt der Kunde, nee, muss anders, ja, also warum, warum sowas machen, ne, verschenkte Lebenszeit, schade und das ist ja auch super frustrierend, ich habe was geiles umgesetzt und finde das gut und am Ende sagt der Kunde, ja, nö, ist eigentlich Mist, ja, hättest du mal gestern schon gefragt, hätte ich dir das direkt gesagt, dass das Mist ist, ja, hättest du dir die Zeit sparen können, also, so wollen wir doch bitte nicht entwickeln, unsere Lebenszeit ist endlich und wir wollen nicht dreimal das gleiche entwickeln, weil wir es zweimal falsch verstanden haben,

[1:43:56] das ist Banane, also, das ist meine Empfehlung, wie man methodisch Anwendungs- und Entwicklungsprojekte umsetzt, ich hoffe, du konntest ein bisschen was mitnehmen, ich drücke dir beide Daumen so für deine Projektdokumentation, dass sie auch gut bewertet wird und dass du es gut umsetzen kannst, ich hoffe, es war heute ein bisschen was für dich dabei, wenn du noch mehr Tipps von mir haben willst, rund um die Projektdoku vor allem, ich glaube, der größte Part in meinem Newsletter ist tatsächlich zu Projektdokumentation und Präsentation, da wirst du ganz, ganz viel mitnehmen, wenn du dich da anmeldest,

[1:44:25] unter itberufepodcast.de slash newsletter, völlig kostenfrei und so im Durchschnitt kriegst du einmal die Woche eine Mail, in den ersten paar Wochen kriegst du sehr viele Mails, weil so zum Start der Ausbildung gibt es da ganz viel Zeug, aber ansonsten wird sich das so auf eine Mail pro Woche reduzieren, ganz viele konkrete Inhalte zu deiner jeweiligen Situation in der Ausbildung, erstes, zweites, drittes Ausbildungsjahr, auch für Ausbilder und Ausbilderinnen übrigens, da gibt es jede Woche eine Mail, passend zu den Ausbildungsjahren, also, kannst dir gerne angucken, wenn du keinen Bock mehr drauf hast, einfach abbestellen und fertig und wie immer kriegst du natürlich das, was ich heute

[1:44:54] erzählt habe, noch in den Shownotes zum Nachlesen, die findest du wie immer unter itberufepodcast.de slash 185 für die 185. Episode, die das hier heute war. Ich hoffe, du konntest ein bisschen was mitnehmen, wenn nicht, schreibe es mir in die Kommentare, wenn ich was vergessen habe, wenn du was völlig anders siehst, haust mir um die Ohren, du kannst mich überall erreichen, gerne aber als Kommentar unter dieser Episode, dann sehen auch alle anderen das. Ich würde mich freuen, von dir zu hören, ansonsten sage ich vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss!