Wie immer interessiert mich: Wie steht Ihr zum Thema Softwareentwicklung? Wie geht ihr da ran? Was ist bei Euch der problematischste Schritt in dem Prozess selbst? Was vermeidet ihr und welche Erfahrungen habt ihr damit gemacht? Und wie immer: wenn Euch das Thema interessiert, helft mir und unterstützt den Kanal mit Likes und einem *Abo* - Danke!
Ich habe angefangen, mir Deine Videos der Reihe nach anzusehen - ausgehend von Deinem Video bezüglich der Standard-Fehler in einer Software-Firma (fehlende Besetzung aller Rollen). Mir Deine Videos vorzustellen war eine Idee von UA-cam - es war eine gute :-)!
Spitze! Ich hätte mir nur gewünscht dieses Video schon während meiner Ausbildung oder zu Beginn meiner Ausbildung gesehen haben zu dürfen. Da man als angehender Software Entwickler während seiner beruflichen Ausbildung, also seinem Studium oder betrieb. Ausbildung oft daheim schon aus Interesse und Leidenschaft sich viel mit der Technik/Technologien auseinander gesetzt hat. Hat man sich meistens gar nicht oder eher weniger mit dem Software Engineering beschäftigt, also dem professionellen Entwickeln von Software. Aber gerade das ist unglaublich wichtig um ein guter Software Entwickler sein zu können, der dann auch gute Software liefern kann. Danke David! 👍
Hallo David, vielen Dank für Deinen großartigen Kanal. Dieses Video ist, gerade weil es High-Level ist, ein super Einstieg in Deinen Kanal. Das größte Probleme in der Prozesskette in meinem Unternehmen ist definitiv das Testen. Aber eigentlich gibt es keinen Prozessschritt mit großen Problemen. Das liegt an vielen Umständen, die ich hier nicht alle offen darstellen kann. Der wesentliche Aspekt ist aber die verfügbare Manpower. Heutzutage ist es halt schwer an Leute zu kommen. Und dann muss man sehen, wie trotzdem die anfallende Arbeit erledigt wird. Auch wenn es falsch ist, intuitiv spart man dann an den gefühlt "unproduktiven" Arbeiten. Bzw. ich als Entwickler habe dann Verständnis dafür, dass die Prozesse vernachlässigt werden, oder mache da sogar mit ... .
Hey Simon, danke für das Feedback, schön das es Dir gefällt. Ja das Testen ist leider immer so eine Sache und vor allem wann man damit anfängt. Testet ihr Eure Software? Gruß David
Hallo David, vielen Dank für das Video! Bei uns im Unternehmen sehe ich tatsächlich die Anforderungsanalyse als einen schwierigen Punkt. Ein spezielles Team gibt es dafür natürlich nicht. Gerne werden "Aufträge" mal schnell in wenigen Sätzen (am besten in der Küche oder gar im Fahrstuhl, im Optimalfall eine 10-zeilige Email) rübergereicht. Das Business vermutet dann, mit diesen paar Worten sei doch alles hinreichend beschrieben; Zeit für eine detaillierte Analyse hat kaum jemand. Die Folgen kannst du dir natürlich sehr gut vorstellen. Wir versuchen nun konsequent mit agilen Methoden dieser Situation zu begegnen. Ein schwieriger Weg, aber der erste Schritt ist gemacht. Bleiben wir optimistisch. VG, Frank
Hallo Frank, sehr gerne, schön wenn es Dir gefällt. Genau solche Antworten wie Deine hatte ich erwartet, leider ist das der standardmäßige Umgang mit Anforderungen - finde das selber total grenzwertig und verstehe nicht, warum das Problem so selten angegangen wird. Gruß David
Als Top-Down-Lerner muss ich sagen: Top! Ein guter Überblick über Software-Entwicklung als Ganzes! Auch gut gestaltete Folien! An die Schnitttechnik, die Atempausen und damit die Zeit, um den Satz zuvor sacken lassen zu können, wegzuschneiden, muss ich noch gewöhnen. Andererseits bleibt die Aufmerksamkeit hoch. "Testen" ist bei uns noch der ausbaufähigste Aspekt. Im Gegenzug zu anderen Kommentaren maintainen wir seit Jahrzehnten dasselbe Produkte in derselben Branche; die Anforderungen von Kundenseite sind daher meist offensichtlich und werden nur als Features an die bestehende Software gestückelt, allerdings: meist schlecht getestet. :-)
Hallo Martin, vielen Dank, freut mich sehr das es Dir gefällt. Ja, die Schnitte sind schon brutal teilweise, aber ich habe bei vielen Videos festgestellt, das die Aufmerksamkeit der Leute schnell abfällt und diese Schnitte halten sie tatsächlich oben :) Ich experimentiere noch etwas damit, mal gucken ob es so bleibt - trotzdem danke das Du es ansprichst :) Hehe, dann klingt es aber ganz so, als hättet ihr wesentlich mehr Probleme, wenn es kein Bestandsprojekt wäre und ihr die Anforderungen immer neu aufnehmen müsstet, oder? Gruß David
Vielen Dank für das Video. :) Das macht halt einfach Sinn, was ihr macht. Ich mache eine Ausbildung zur Technischen Systemplanerin und unsere Leistungsphasen, die wir durchlaufen, sind übelst bescheuert und längst überholt. Und wir sind dann die, die in den ineffektivsten, schrottigsten CAD-Zeichenprogrammen alles händisch und manuell zeichnen und rechnen dürfen. Jeder Zeichner regt sich über das Programm auf. Also falls du mal Lust hast, dafür etwas Sinnvolles zu entwickeln, dann sehr gerne. Damit kannst du sicher viel Geld machen. Das fängt schon damit an, dass wir für die Heizlastberechnung in den Grundrissen von den Architektenplänen die ganzen Wände nachskizzieren und nachzeichnen dürfen, mit Türen, Decken, Fenstern... . Und wenn sich der Plan dann nochmals ändert, die Wände verschieben und neu zeichnen müssen. Kein normaler Mensch tut sich das an. 😅 (ist im Bereich TGA (SHKL)).
Mehr Clean Code bitte ! :) P. S. wegen der Verlosung: In unserem Betrieb gibt es quasi keine Entwurfsphase und damit keinen Architekten. Es wird von Anforderungsanalyse direkt in die Implementierung gegangen, damit sind die Grenzen fließend und Architekturentscheidungen bezüglich eingesetzter Technologien oder Entwurfsprinzipien und -muster werden von jedem Programmierer selbst getroffen... Als ich nach eingesetzten Entwurfsmustern gefragt habe wurde ich belächelt und erhielt die Antwort: "Joa, hier programmiert jeder eher so der Nase nach."
Hallo David, wie immer - tolles, leicht verständliches Video... Was bei uns falsch läuft ... kurz gesagt das Anforderungsmanagement. Wir schreiben am Anfang jedes Projektes zwar die User-Stories auf, leiten davon Spezifikationen ab und entwicklen danach die gewünschte Software. Dies betreiben wir agil, mit regelmässigen Scrum-Meetings, entsprechenden Tools, usw. Leider verpassen wir es dabei immer wieder geänderte Anforderungen in den ursprünglichen User-Stories und Spezifikationen nachzupflegen. Im ersten Moment ist dies auch noch kein Problem, die Entwickler kennen die geänderten Wünsche und implementieren diese meist auch richtig. Das Problem entsteht erst am Ende der Projekte, wenn der Tester (das bin ich) die Software im Rahmen eines Alpha- bzw. Beta-Test mit den ursprünglichen Spezifikationen vergleicht => Diskrepanz vorprogrammiert.
Hallo Ramon, vielen Dank, schön das Dir das Video gefällt. Was genau läuft denn dabei falsch? Klingt doch nach Deiner Beschreibung gar nicht so verkehrt. Gruß David
Wie immer erstklassiger Content kurz und verständlich vorgetragen. Wäre meine Lehrer so, wäre vielleicht auch vielleicht mehr aus mir geworden. Gruß Leschek 😉
Danke für diesen tollen Inhalt! Du vermittelst die Themen sehr spannend und hast zusätzlich eine sehr angenehme Stimme und eine ruhige, professionelle Art. Habe dich direkt abonniert lieber David.
Moin David. Mal wieder danke für ein gutes Video. Bei uns sehe ich die Probleme am meisten beim Aufbauen von technischen Schulden und die daraus resultierende Bugwelle im Laufe der Zeit.. Als zweiten Punkt sehe ich noch das saubere Testen, dass keine Akzeptanzkriterien vergessen oder falsch verstanden werden.
Ja, die Anforderungen zu schreiben und zu verstehen ist es manchmal schwierig. Die Architektur ist ok. Es liegt - glaube ich - eher an der Umsetzung in der Entwicklungsphase.
Ja, das vermute ich. Als Beispiel: Wir arbeiten mit React und einige Entwickler bauen ungemein riesige Komponenten. Irgendwann sieht man da unweigerlich nicht mehr durch. Manchmal rutscht sowas im Review durch und schon hat man diese Komponente ewig in seinem Projekt. Du kennst doch das Problem: Features sind immer wichtiger als Qualität :-D
Hallo David, die Wochen sind sicher vorbei ;-) Bei 16:55 sprichst Du ein Video zum Thema DevOps an, das Du in den nächsten Wochen erstellen willst und dann in der Videobeschreibung (und oben Rechts) verlinken möchtest. Gibt es das Video oder ist es vielleicht in Vergessenheit geraden? Gruß, Carsten
Hallo Carsten, das zwar nicht in Vergessenheit geraten, allerdings habe ich erstmal andere Videoideen vorgezogen. Im Moment mache ich mangels Zeit und Projekten eher kürzere Videos und die vor allem nach Möglichkeit draußen in der Natur - das ist mit diesem Video leider nicht möglich. Sobald das Wetter aber wieder schlechter wird, werde ich das als erstes machen :) Gruß David
Cooles Video, von der Thematik perfekt getroffen mit dem SDLC. In vielen mir bekannten Projekten wird viel zu wenig getestet. Also hier fehlt zum Beispiel der einfache Unit-Test. TDD auf einfache Units und Komponenten wäre mal was schönes. Schöne Grüße aus Ingolstadt! :)
Moin Bastian, vielen Dank, schön das Dir das Video gefällt! Testen und Anforderung wären auch mein Tipp für die meisten Nennungen gewesen ;) Schöne Grüße nach Ingolstadt! Gruß David
Moin David. Was weißt du über ein Software Entwicklung Studium? Ich möchte anstatt Informatik ein Software Entwicklung Studium machen an der IU. Ich finde allerdings keine andere Uni die so etwas anbietet. Habe ich nicht richtig gesucht oder gibt es sowas in Deutschland noch nicht?
Bei uns gibt es im Bereich der Anforderungen Nachholbedarf. Dort werden die "Ideen" direkt an die Entwicklung weitergegeben ohne das eine Anforderungsanalyse stattfindet. Man kann als Entwicklungsteam so oft darauf Hinweisen wie man möchte, jedoch wird man nicht wirklich ernst genommen.
Ganz klarer Favorit für Verbesserung: Anforderungsanalyse.. Ich habe leider schon mehrmals gehört: Ja wenn du das nicht verstehst musst du beim Autor nachfragen. Aus meiner Sicht eine sehr sehr teure Kultur, weil nicht nur ich ewig los laufen muss sondern auch der Autor aus seinem Kontext gerissen wird.. Hast du in deinem Video zu den Anforderungen vor den Prozess vom Kopf des Kunden bis zum Entwicklerschreibtisch zu behandeln? Meist liegen da ja viele Ebenen zwischen; Last zu Pflicht zu Epic/Epos Usw bis runter zum einzelnen Task. Ich habe nämlich oft das Gefühl, dass ein Verständnis fehlt was "ready" für die nächste Schicht ist.
Hey, ja das ist (leider) bei vielen der Favorit. Genau das habe ich vor - es geht vor allem um pragmatische Lösungen und Tipps für alle Ebenen. Gruß David
Ich bin immer wieder amüsiert bezogen auf den Begriff ‚agil‘ und behaupte mal ganz frech, dass die kleinen mittelständischen Software-Unternehmen - ironisch formuliert - eigentlich ‚hyperagil‘ unterwegs sind 😂 und dabei jede Form der Organisation verlieren. Während das Scrum Modell ursprünglich entwickelt wurde, um riesige Softwareprojekte handhabbar zu gestalten, die regelmässig mit Wasserfallmodell scheiterten, wird Scrum in den kleinen Unternehmen verwendet, um ein Mindestmass an Organisation zu entwickeln - aber eigentlich war es so, wenn ich es historisch richtig in Erinnerung habe, nicht gedacht.
Wiedermal ein sehr informatives Video :) Was definitiv häufig zu kurz kommt ist das Testen. Meist wird die Software nur ein paar mal angestoßen und überprüft, ob die umgesetzte Funktion wie erwartet arbeitet. Fehlerfälle werden dabei häufig erst behandelt, wenn Sie auftreten. Das kostet natürlich viel Zeit. Die resultierenden Effekte sind aber im Buch "Langlebige Softwarearchitekturen" von der Frau Lilienthal bereits schön beschreiben.
Hallo Martin, schön das Dir das Video gefällt - danke für das Feedback. Ja, Testen in der Softwareentwicklung ist in der Tat schwierig und wird vernachlässigt - das sehe ich jeden Tag. Aber meist ist es dann schon so, das die Anforderungen so schlecht sind, das ein Testen gar nicht möglich ist. Sind die bei Euch gut genug? Ja, ich liebe das Buch :D Gruß David
Hey@@DavidTielke. Ja die Projekte sind eher forschender Natur, Anforderungen entstehen da eher durch plötzlich auftretende Bedarfe. Es gibt meist nur ein grobes Konzept und dann heißt es erstmal "In alle Richtungen gucken; Was existiert vielleicht schon; Was kann man übernehmen; ...[getestet werden kann später^^]". Ich selbst habe erst meine Abschlussarbeit über den Entwurf einer Softwarearchitektur geschrieben und habe daher sehr viel Literatur gewälzt, genauso eben dieses Buch verwendet. Es war schön zu sehen, dass du selbst vor ein paar Monaten ein Interview mit Frau Lilienthal in einem deiner Videos veröffentlicht hast. Gerne mehr davon! Es gibt nichts besseres als Lernen aus Erfahrung und vor allem aus Erfahrung anderer. LG
Hallo Martin, ja ok, dann bist Du schon in einem speziellen Bereich der Softwareentwicklung unterwegs. Ja, diese Reihe mit anderen Experten hat mir auch sehr viel Spaß gemacht aber aufgrund der Masterarbeit habe ich es erst einmal pausiert - aber ich hoffe das ich bald mal wieder (dann aber unregelmäßig) dazu etwas starten kann :) So etwas zum Thema Testen wäre auch nicht so schlecht. Testet Ihr denn überhaupt? Gruß David
Also der Vorteil in diesem Bereich ist , dass man da schon sehr viel Freiheiten hat und sich auch viel mit neuen Technologien auseinandersetzen kann. Dadurch ist man stetig am Lernen, was in unserer Branche natürlich überlebenswichtig ist! Ach, auch eine Masterarbeit. Sehr gut, dann wünsche ich dafür viel Erfolg! Ich habe es ja nun endlich geschafft aber merke halt, dass ich noch viel Erfahrung sammeln muss und noch viele Bücher zu wälzen habe^^ Ja wir testen schon, aber nicht so ausführlich, wie ich es mir manchmal wünschen würde. Meist haben die Projekte zunächst eine sehr kurze Lebensdauer, bis sie verlängert werden. Daher müssen immer recht schnell vorzeigbare Ergebnisse geliefert werden. Findet eine letztlich Verlängerung statt, fehlen natürlich die Testszenarien (Tests kosten wertvolle Zeit). Daher ist die Idee mit dem Thema "Testen" natürlich super. Vor allem wie man effizient Testet. Ich denke man muss auch eine "Testen tut nicht weh"-Kultur etablieren und diese im gesamten Team verbreiten. Es muss nur anklang finden. Ich freu mich schon auf deine Videos dazu ;) Gruß Martin
Ja, auch eine Masterarbeit - aber ich habe sie halt nach 15 Jahren Selbstständigkeit gemacht. Bücher sind ohne Zweifel sehr gut aber reichen alleine auch nicht, ich denke wenn man selbst die Motivation hat, jeden Tag irgendwie ein kleines Stückchen besser zu werden - das ist der Schlüsse. Und in der Forschung ist die Softwareentwicklung in der Tat schwierig und in großen Teilen komplett anders als in der Industrie - viele der Dinge auf die es hier ankommt, was gute Softwarequalität angeht, ist in anderen Bereichen total unnütz :) Arbeitest Du denn als Wissenschaftlicher Mitarbeiter? Gruß David
#FragDavid Hattest Du schon Mal etwas dazu gemacht, wie ein fertiger Architektur-Entwurf aussehen kann oder sollte und wo die Architektur aufhört? Ich kann natürlich Quellcode schreiben (würde ich mit Contract-Assemblies machen) und dazu alles mit Diagrammen verdeutlichen. Und wo ist die Grenze zwischen Software-Architektur und Quellcode-Design? Je kleinteiliger ich plane, desto größer das Risiko, zu "overengeneeren". Verstehst Du, was ich meine?
Hey, so eine Serie ist in Arbeit - habe erstmal noch ein paar andere Ideen für Lernvideos und ein neues Format, was ich mal testen möchte, aber dann geht es mit Architektur los :) Gruß David
Wir haben derzeit Probleme bei der Bereitstellung. Und das hat diesmal gar nichts mit Softwareentwicklung zu tun. Wir liefern die Software aber die Stakeholder liefern keine angepassten Nutzungsbedingungen/AGBs, Verträge und andere Informationen. Wir haben jetzt seit einem Jahr ein Feature fertig und können es nicht bereitstellen, da rechtlichen oder kaufmännische Themen fehlen.
Hey Andre :) Okay, das ist mal Strange - ist aber mehr oder weniger ein Anforderungs oder gar Projektmanagement-Problem, weil da kann die Softwareentwicklung ja nicht wirklich was zu, oder? Gruß David
Die meisten Mankos bestanden stets in Anforderungserfassung (konkret Tickets) und der Architektur. Bei ersterem oft schlicht, weil die Verantwortlichen schwach im schriftlichen Ausdruck sind und schlecht gliedern können. Oft habe ich die Spezifikation übernommen oder diue Tickets direkt selber verfasst. Zum zweiten: Verständnisss von Architektur besteht oft fast gar nicht oder es bestehen viele Missverständnisse (ich schließe mich selber nicht aus). Zum Teil auch bedingt duch überlappende Terminologien. (Warum müssen PHP-MVC-Frameworks ihren DI-Container "Service Container" nennen? Was ist denn nun ein Service? Und schon hat man unproduktive Diskussionen.) Konkret habe ich erlebt, dass dieselbe Anwendung mit abweichenden Zusatzanforderuingen zwei mal komplett neu geschrieben wurde und man das als eine gute Lösung angesehen hat.
Hey Guido, ja, Anforderungen werden leider immer so ein bisschen "nebenbei" gemacht und kaum jemand erkennt wie wichtig diese im Endeffekt sind. Bzgl. Eurem Kommunikationsproblem in der Architektur, habt ihr Codierrichtlinien und Architekturrichtlinien? Klingt ganz danach, als würden diese fehlen.... @zwei doppelt implementierte Lösungen: Ernsthaft?!?! :D Gruß David
@@DavidTielke Bezüglich Architekturrichtlinien: Bei der einen Firma: nein (deshalb auch die zwei Implementierungen). Das ist das Missverständniss, dass sich aus den MVC-Frameworks ergibt. Die sind so umfänglich und beschäftigen die Teams dermaßen, dass die Teams meinen, dies sei schon die Architektur. Dann hatten wir noch einen externen Dienstleister, den ich frühzeitig auf "generalistischen Ansatz für sich wiederholende Anforderungen" angesprochen habe. Und da kam die Antwort: " Bei sowas machen wir lieber Copy & Paste. (Und der hatte "Architekt" auf der Visitenkarte stehen.) Die machen halt "flotte Kundenwunscherfüllung" und dann tschüß. Ausbaden dürfen den Kuddelmuddel dann die Festangestellten. Bei einer anderen Firma gab es sehr wohl einen Domain-getriebenen Komponenten-Ansatz. Allerdings irgenwie out of Control. (Fassaden mit was-weiß-ich-wie-vielen public-Methoden.) Copy & Paste, willkürliche Vererbungen ... Und die Terminologie war keinesfalls klar. Was nun Code-Design und was Architektur ist ... und wenn man präzise werden wollte, dann war das "zu wissenschaftlich" oder "zu philosophisch". Aber Coderichtlinien bis auf den letzten Whitespace. (Buhuuh, eine Leerzeile zu viel!) Ja, zwei Implementierungen auch, weil ja Laravel viel cooler ist als Symfony. Und mein whiltelabel DB-Entwurf war ja viel zu komplex. Und Agiles Entwickeln heißt, dass man von Höckchen auf Stöckchen den Kundenanforderungen hinterherdackelt, Vorplanungen sind eh für die Katz, und immer schön am MVC entlang, denn das MVC das rettet einen ja.
@@DavidTielke das geht bei den ungenauen Anforderungen los, aus denen ein Nicht-Architekt eine passende Architektur zaubern muss, und geht dann weiter mit der Entwicklung wo man hoffen muss, dass die gewählten Technologien und Frameworks am Ende immer noch die richtige Wahl sind. Insofern ist CoCo 2.0 ne feine Sache, weil das Änderungen im letztgenannten Kontext leichter macht. Gruß Heiko
Schöne einfache Erläuterung des ganzen Prozesses. Aus eigenen Erfahrungen würde ich sagen, dass der Test oft zu kurz kommt. Zum einen weil es keinen definierten Prozess gab/gibt; zum anderen aber auch aufgrund von vorherigen Fehlern. Falsch verstanden oder unvollständige Anforderungen. Dadurch kann eine komplett verzogene Architektur entstehen, die die Entwicklung dann erschwert.
Sehr cool, super spannende und tolle Aufgabe... Wir sollten mal ein Video zu Cypress.io hier machen :D Schon konkrete Ideen für den Prozess? Gruß David
Hallo David, sehr interessantes Video, vielen Dank. Bei uns sind die Test leider noch nicht so gut. Bei einer Änderung schaut der Entwickler über die Anwendungen und vergleicht mal die Werte mit der alten Version. Wenn da soweit alles gleich ist, gehts in das Produktivsystem. Ohne zu Wissen, ob nicht doch irgendwelche Seiteneffekte durch die Änderung aufgetreten ist. Bei jeder Änderung hat man ein bisschen Angst. ;-)
Moin, sehr gerne, schön das es Dir gefällt. Ok... Noch ein Punkt für die Tests :) Wären denn Eure Anforderungen gut genug, dass man wirklich gut und sinnvoll testen könnte? Weil das meist das nächste Problem ist, was damit einher geht... Gruß David
@@DavidTielke das kommt noch dazu. Die Entwickler wissen nicht, wie richtige Tests geschrieben werden und die Anforderung vom Fachbereich sind auch eher knapp...
Das dachte ich mir schon. Ohne solche ist es halt unfassbar schwer zu testen - besonders wenn man es dann im Nachgang machen muss. Da würde ich sogar so weit gehen zu sagen, dass es ab einer gewissen Größe unmöglich ist. Gruß David
Hey, wenn Du genug Interesse hast und schon privat ein bisschen in dem Bereich gemacht hast bestimmt - bei dem Personalmangel im Moment werden in der Softwareentwicklung auch viele andere Tätigkeiten gesucht, für die Du nicht unbedingt eine IT-Ausbildung braucht, z.B. Tester, Dokumentatoren, Supportler usw. Gruß David
Hallo David, in unserem Unternehmen gibt es leider nur drei Entwickler, die jeweils mit verschiedenen Projekten beschäftigt sind. Somit gibt es leider keine Redundanzen (Krankheit/Vertretung) und auch keinerlei Rollen wie Architekten etc. Jeder Kollege ist im Prinzip eine One-Man-Army
Sehr informativ. Bei uns ist das Requirements Engineering oft vernachlässigt. Nach dem Prinzip SHISHO kann man sich vorstellen was dabei rumkommt. Ich finde nicht nur das Management sondern and alle bis runter zum Programmierer sollte diese Disziplin beherrschen. Denn Anforderungen sollten nicht nur richtig geschrieben sondern auch richtig gelesen werden können. (Wenn man es dann ändern muss: "Wir sind ja so agile") Diesen Prozess zu optimieren dauert lange und ist teuer. Kannst du mal ein Video machen über Requirements Engineering über die Grenzen der Zuständigkeiten machen (Definition of Ready, Definition of Done .... )?
Hey, schön das Dir das Video gefällt. Ja, solche Antworten hatte ich schon vermutet :) Ob es alle beherrschen sollten weiß ich nicht, da es mitunter ganz schön schwer sein kann gute Anforderungen in der Softwareentwicklung zu ermitteln. Wobei dein Argument mit dem "müssen alle lesen können" schon zutreffend ist. Genau so ein Video kommt in den nächsten Wochen :) Spezielle Wünsche? Gruß David
Übrigens Pro Tip ;-) Acceptance Kriterien in Gherkin Style ist auch mal ein Video Wert. Es gibt gute Tools Unterstützung (SpecFlow, Cucumber etc) so das man diese direkt in Test überführen kann.
Gherkin für Akzeptanzkriterien ist in der Tat sehr sehr cool und nutze ich in vielen Projekten, allerdings für Anforderungen leider nicht ausdrucksstark genug :) Pro-Tipp habe ich schon was anderes im Sinn ;) Gruß David
Arbeiten wir zufällig in der selben Firma? 😃 Das, was Du genannt hast, hat nur knapp gegen unser Test-Chaos verloren. Und "SHISHO" gefällt mir, die Abkürzung kannte ich noch nicht ^^
Hallo David, Schöne heile Welt. Aber exzellent erklärt, ich finds großartig. Fehler? Ich weiß gar nicht wo ich anfangen soll. Selbst auferlegte Dogmas werden wiederholt verletzt. Künstlicher Zeitdruck. Keine gemeinsamen Definitionen für unterschiedliche Teams. Man baut das Dach, ohne ein Gerüst. Usw. Leider🙁 Danke Dir, für diesen Eindruck wie es theoretisch laufen sollte. Gruß Marcus
#FragDavid Hey David, deine Videos sind super! Vielen Dank erstmal dafür! Ich hätte nie gedacht, dass ich mich mal für Softwareentwicklung interessieren würde, bis ich mich vor ein paar Jahren intensiv mit dem Bitcoin und seiner gesellschaftlichen Idee auseinandergesetzt habe. Hast du Bezug zum Bitcoin? Was denkst du über dieses spezielle verteilte System und die Idee Wert im Netz durch unkopierbare Werte zu erschaffen? Meinst du es lohnt sich für eine Karriere in diesem Bereich das Coden zu lernen? Liebe Grüße F.
Nachholbedarf unbedingt bei den Anforderungen. Ein guter Product Owner sorgt für den Erfolg des gesamten Projekts. Und wenn der fehlt, wird es schwierig - und meist teuer.
@@DavidTielke Derzeit leider nicht mehr. Es steht ein Wechsel bevor. Ich bin gespannt. Danke für deine Videos. (auch wenn sie mir ohne Hintergrundmusik noch besser gefallen ;-) Aber das ist vielleicht Geschmackssache.)
Hey Markus, ist auch schwer zu finden so eine Person. Sehr gerne, schön das Sie dir gefallen - ich bin hin und her gerissen was die Musik angeht, mal schauen :) Gruß David
Wir entwickeln tatsächlich noch in schönster Wildwest-Manier. Insbesondere die Anforderungen und die Unit Tests werden gerne mal ignoriert. Für die Anforderungen wünsche ich mir ein nettes Tool, um den entstandenen Code den ursprünglichen Anforderungen zuzuordnen. Von Hand wird nie was draus. Oder es artet in so viel Papierkram aus, dass es niemand schreiben und schon gar nicht lesen will. Ansonsten nettes Video, in kompakter Form alles Wichtige präsentiert!
Hey Alex, das ist halt oft nicht so einfach, dem Quellcode eine Anforderung zuzuordnen, da der Quellcode oft von mehreren Anforderungen betroffen ist. Mit integrierten ALM Tools wie Azure DevOps kannst Du das aber quasi for-free im vorbeigehen bekommen - da wird jede Quellcodezeile mit der entsprechenden Anforderung verknüpft, wenn Du es beim Checkin angibst. Gruß David
Bald starte ich meine erste Tätigkeit im Bereich der Softwareentwicklung und das Video fasst die Inhalte aus dem Studium nochmal super zusammen. Habe schon Bammel aber das wird schon. Vielen Dank!
Wir haben eine sehr guten Draht zu unseren Kunden und das DevOps Prinzip wird sehr gut umgesetzt/gelebt, wenn ich etwas verbessern würde, ist es die Architektur, wobei dieser Punkt auch der undankbarste ist, weil sobald mögliche Konkurrenz auf der Bildfläche erscheint und dem Kunden vermeidlich das „Startgeld“ für ein Projekt wichtiger ist als die Qualität (und die möglichen Einsparungen in der Zukunft), so wird auch die Architektur darunter leiden… schade das.
Vorbildlich - ja das ist leider so, vor allem Kunden die wenig Erfahrung in dem Bereich haben, lassen sich oft von diesen - vermeintlich günstigen Projekten - blenden und zahlen nachher doppelt. Schafft Ihr es trotzdem das umzusetzen? Gruß David
@@DavidTielke Ja, wir verkaufen uns natürlich trotzdem nicht unter Wert, aber gewisse Kunden ziehen viele Konkurrenz Firmen an… mit teils sehr unseriösen Angeboten^^ Am Ende ist es wirklich Gold wert, wenn man jemanden in der Firma zu hat, der viel Erfahrung mitbringt und all diese Faktoren die bei Preisbildung etc. eine Rolle spielen im Auge hat. Grüße
Ja, total - das Problem ist, dass solche Leute einen guten Überblick und viel Erfahrung haben müssen. Das ist in der Praxis oft nicht einfach solche Leute zu bekommen :) Gruß David
Das Buch wird verlost? Schade eigentlich, wenn es am der schlimmsten Geschichte festgemacht wäre, hätte ich gute Chancen 😃 Und ich würde sagen, das größte Problem sind Tests. Die Anforderungen sind zwar auch ein einziges Chaos, aber Tests sind derzeit quasi nicht existent. Konkret schreibt meist der Entwickler die Test-Beschreibungen, die der Tester dann Schritt für Schritt ausführen muss. UnitTests gibt es nicht, Akzeptanzkriterien auch nicht. Die Test-Beschreibungen sind also meist auf das bezogen, was der Entwickler gemacht und sowieso schon getestet hat (wenn nicht, hätte er was falsch gemacht), daneben fallen viele Punkte unter den Tisch. Außerdem werden alte Funktion meist gar nicht getestet. Am Ende heißt das, dass der Test sehr viel Zeit für eine mMn. eher stumpfsinnige Arbeit braucht, die der Entwickler sowieso schon gemacht haben sollte. Oft muss sogar noch der Entwickler daneben sitzen, z.B. bei sehr technischen Aufgaben, die man aus Nutzer-Sicht nur schwer nachvollziehen kann.
PS: Der Grund, warum die Anforderungen nicht top 1 sind, ist einfach: Der Chef weiß meist sehr genau, was gewünscht ist. Er teilt es niemandem mit, man muss alles erfragen (auch wenn man nichts davon weiß "hättest ja Mal fragen können"), aber irgendwo vorhanden und erreichbar sind die Anforderungen schon. Die Tests bzw. das fehlen einer vernünftigen Teststrategie hat die weitreichenden Folgen, daher sind die mein Platz 1.
Hey, ja - ich lose das aus. Aber Du hast recht, mit der Story hättest Du gute chancen... Aber sei beruhigt, genau solche Szenarien habe ich bei meinen Kunden ständig :D Wie viel Zeit entwickelt ein Entwickler dann noch? 30 Minuten? :D Gruß David
@@DavidTielke Was meinst Du? Die meiste Zeit nimmt die Entwicklung in Anspruch, der Test geht meist ziemlich schnell, weil nur oberflächlich getestet wird. Es hängt aber auch vom Projekt an, z.B. mein aktuelles Projekt läuft seit Monaten und ist das erste mit UnitTests, weil der Kunde das wollte. Und die menschlichen Tests werden sehr viel Zeit in Anspruch nehmen, weil es ein neues Programm ist und vollständig im Hintergrund ohne UI und mit sehr großen XML-Daten arbeitet. Die Zeit ist natürlich nicht da, also wird wieder die Deadline gerissen.
@@DavidTielke Achso - in dem Fall bereiten wir vor, in der Hoffnung, so Zeit zu sparen. Wenn wir falsch vermutet haben, war das natürlich für die Katz, aber naja. Oder wir arbeiten an anderen Projekten weiter, meistens hat jeder mehrere Projekte am laufen und muss mit den Prioritäten jonglieren. Warten ist also eher selten das Problem, es gibt immer was zu tun.
Moin Sven, ihr lasst Architektur und die Anforderungen aus? Wie viel langlaufende Projekte habt ihr denn? Die müssten potenziell ja alle in einem furchtbaren Zustand sein!?!? Gruß David
Ich werde nicht müde, den meiner Meinung nach grossen Unterschied zwischen Produkt- und Projektentwicklung zu betonen. Er ist vergleichbar mit dem Unterschied zwischen der Erreichung von strategischen und taktischen Zielen. Das strategische Ziel ist die Erstellung eines Hauses. Ein taktisches Ziel bei der Erstellung eines Hauses ist z.B. die Erstellung eines Bauplans. Software-Produkte berücksichtigen meiner Meinung nach strategische Ziele, Software-Projekte dienen eher der Erreichung taktischer Ziele. Das Instrumentarium der Softwareentwicklung ist auf die Projektentwicklung ausgerichtet und leider kaum auf die Entwicklung von Produkten. Dazu reichen die Scrum Rollen meines Erschtens nach nicht aus.
![Scrum - Von A bis Z [Mit Profi-Tipps]](http://i.ytimg.com/vi/QtTH3m8GfN0/mqdefault.jpg)
![Scrum - Von A bis Z [Mit Profi-Tipps]](/img/tr.png)
Wie immer interessiert mich: Wie steht Ihr zum Thema Softwareentwicklung? Wie geht ihr da ran? Was ist bei Euch der problematischste Schritt in dem Prozess selbst? Was vermeidet ihr und welche Erfahrungen habt ihr damit gemacht? Und wie immer: wenn Euch das Thema interessiert, helft mir und unterstützt den Kanal mit Likes und einem *Abo* - Danke!
Ich habe angefangen, mir Deine Videos der Reihe nach anzusehen - ausgehend von Deinem Video bezüglich der Standard-Fehler in einer Software-Firma (fehlende Besetzung aller Rollen). Mir Deine Videos vorzustellen war eine Idee von UA-cam - es war eine gute :-)!
Hey und herzlich willkommen,
schön das Dir die Videos gefallen!
Gruß David
Endlich wieder Zeit, für etwas lernen mit David Tielke :D
Danke für deine wundervolle Arbeit.
Sehr sehr gerne - Willkommen zurück :)
Gruß David
Spitze! Ich hätte mir nur gewünscht dieses Video schon während meiner Ausbildung oder zu Beginn meiner Ausbildung gesehen haben zu dürfen. Da man als angehender Software Entwickler während seiner beruflichen Ausbildung, also seinem Studium oder betrieb. Ausbildung oft daheim schon aus Interesse und Leidenschaft sich viel mit der Technik/Technologien auseinander gesetzt hat. Hat man sich meistens gar nicht oder eher weniger mit dem Software Engineering beschäftigt, also dem professionellen Entwickeln von Software. Aber gerade das ist unglaublich wichtig um ein guter Software Entwickler sein zu können, der dann auch gute Software liefern kann. Danke David! 👍
Hallo David,
vielen Dank für Deinen großartigen Kanal. Dieses Video ist, gerade weil es High-Level ist, ein super Einstieg in Deinen Kanal.
Das größte Probleme in der Prozesskette in meinem Unternehmen ist definitiv das Testen.
Aber eigentlich gibt es keinen Prozessschritt mit großen Problemen. Das liegt an vielen Umständen, die ich hier nicht alle offen darstellen kann. Der wesentliche Aspekt ist aber die verfügbare Manpower. Heutzutage ist es halt schwer an Leute zu kommen. Und dann muss man sehen, wie trotzdem die anfallende Arbeit erledigt wird. Auch wenn es falsch ist, intuitiv spart man dann an den gefühlt "unproduktiven" Arbeiten. Bzw. ich als Entwickler habe dann Verständnis dafür, dass die Prozesse vernachlässigt werden, oder mache da sogar mit ... .
Hey Simon,
danke für das Feedback, schön das es Dir gefällt.
Ja das Testen ist leider immer so eine Sache und vor allem wann man damit anfängt. Testet ihr Eure Software?
Gruß David
Hallo David,
vielen Dank für das Video!
Bei uns im Unternehmen sehe ich tatsächlich die Anforderungsanalyse als einen schwierigen Punkt. Ein spezielles Team gibt es dafür natürlich nicht. Gerne werden "Aufträge" mal schnell in wenigen Sätzen (am besten in der Küche oder gar im Fahrstuhl, im Optimalfall eine 10-zeilige Email) rübergereicht. Das Business vermutet dann, mit diesen paar Worten sei doch alles hinreichend beschrieben; Zeit für eine detaillierte Analyse hat kaum jemand. Die Folgen kannst du dir natürlich sehr gut vorstellen. Wir versuchen nun konsequent mit agilen Methoden dieser Situation zu begegnen. Ein schwieriger Weg, aber der erste Schritt ist gemacht. Bleiben wir optimistisch.
VG, Frank
Hallo Frank,
sehr gerne, schön wenn es Dir gefällt.
Genau solche Antworten wie Deine hatte ich erwartet, leider ist das der standardmäßige Umgang mit Anforderungen - finde das selber total grenzwertig und verstehe nicht, warum das Problem so selten angegangen wird.
Gruß David
Als Top-Down-Lerner muss ich sagen: Top! Ein guter Überblick über Software-Entwicklung als Ganzes! Auch gut gestaltete Folien! An die Schnitttechnik, die Atempausen und damit die Zeit, um den Satz zuvor sacken lassen zu können, wegzuschneiden, muss ich noch gewöhnen. Andererseits bleibt die Aufmerksamkeit hoch.
"Testen" ist bei uns noch der ausbaufähigste Aspekt. Im Gegenzug zu anderen Kommentaren maintainen wir seit Jahrzehnten dasselbe Produkte in derselben Branche; die Anforderungen von Kundenseite sind daher meist offensichtlich und werden nur als Features an die bestehende Software gestückelt, allerdings: meist schlecht getestet. :-)
Hallo Martin,
vielen Dank, freut mich sehr das es Dir gefällt. Ja, die Schnitte sind schon brutal teilweise, aber ich habe bei vielen Videos festgestellt, das die Aufmerksamkeit der Leute schnell abfällt und diese Schnitte halten sie tatsächlich oben :) Ich experimentiere noch etwas damit, mal gucken ob es so bleibt - trotzdem danke das Du es ansprichst :)
Hehe, dann klingt es aber ganz so, als hättet ihr wesentlich mehr Probleme, wenn es kein Bestandsprojekt wäre und ihr die Anforderungen immer neu aufnehmen müsstet, oder?
Gruß David
Vielen Dank für das Video. :)
Das macht halt einfach Sinn, was ihr macht.
Ich mache eine Ausbildung zur Technischen Systemplanerin und unsere Leistungsphasen, die wir durchlaufen, sind übelst bescheuert und längst überholt. Und wir sind dann die, die in den ineffektivsten, schrottigsten CAD-Zeichenprogrammen alles händisch und manuell zeichnen und rechnen dürfen. Jeder Zeichner regt sich über das Programm auf. Also falls du mal Lust hast, dafür etwas Sinnvolles zu entwickeln, dann sehr gerne. Damit kannst du sicher viel Geld machen. Das fängt schon damit an, dass wir für die Heizlastberechnung in den Grundrissen von den Architektenplänen die ganzen Wände nachskizzieren und nachzeichnen dürfen, mit Türen, Decken, Fenstern... . Und wenn sich der Plan dann nochmals ändert, die Wände verschieben und neu zeichnen müssen.
Kein normaler Mensch tut sich das an. 😅
(ist im Bereich TGA (SHKL)).
Hey Caro,
sehr gerne - schön das Dir das Video gefällt!
Gruß David
Mehr Clean Code bitte ! :) P. S. wegen der Verlosung: In unserem Betrieb gibt es quasi keine Entwurfsphase und damit keinen Architekten. Es wird von Anforderungsanalyse direkt in die Implementierung gegangen, damit sind die Grenzen fließend und Architekturentscheidungen bezüglich eingesetzter Technologien oder Entwurfsprinzipien und -muster werden von jedem Programmierer selbst getroffen... Als ich nach eingesetzten Entwurfsmustern gefragt habe wurde ich belächelt und erhielt die Antwort: "Joa, hier programmiert jeder eher so der Nase nach."
Ist in Arbeit :)
Hier hast Du mir Softwareentwichlung schon mal die Basics ;)
Gruß David
Hallo David,
wie immer - tolles, leicht verständliches Video...
Was bei uns falsch läuft ... kurz gesagt das Anforderungsmanagement. Wir schreiben am Anfang jedes Projektes zwar die User-Stories auf, leiten davon Spezifikationen ab und entwicklen danach die gewünschte Software. Dies betreiben wir agil, mit regelmässigen Scrum-Meetings, entsprechenden Tools, usw.
Leider verpassen wir es dabei immer wieder geänderte Anforderungen in den ursprünglichen User-Stories und Spezifikationen nachzupflegen. Im ersten Moment ist dies auch noch kein Problem, die Entwickler kennen die geänderten Wünsche und implementieren diese meist auch richtig. Das Problem entsteht erst am Ende der Projekte, wenn der Tester (das bin ich) die Software im Rahmen eines Alpha- bzw. Beta-Test mit den ursprünglichen Spezifikationen vergleicht => Diskrepanz vorprogrammiert.
Hallo Ramon,
vielen Dank, schön das Dir das Video gefällt.
Was genau läuft denn dabei falsch? Klingt doch nach Deiner Beschreibung gar nicht so verkehrt.
Gruß David
Wie immer erstklassiger Content kurz und verständlich vorgetragen. Wäre meine Lehrer so, wäre vielleicht auch vielleicht mehr aus mir geworden.
Gruß Leschek 😉
Hey Leschek,
vielen Dank - ich glaub Du hast es auch mit den Lehrern ganz gut zu etwas gebracht ;)
Gruß David
Danke für diesen tollen Inhalt! Du vermittelst die Themen sehr spannend und hast zusätzlich eine sehr angenehme Stimme und eine ruhige, professionelle Art. Habe dich direkt abonniert lieber David.
Hey Christian,
vielen Dank, es freut mich sehr das Dir meine Videos gefallen!
Gruß David
Moin David. Mal wieder danke für ein gutes Video. Bei uns sehe ich die Probleme am meisten beim Aufbauen von technischen Schulden und die daraus resultierende Bugwelle im Laufe der Zeit.. Als zweiten Punkt sehe ich noch das saubere Testen, dass keine Akzeptanzkriterien vergessen oder falsch verstanden werden.
Hallo Max,
sehr gerne, schön das es Dir gefällt! Also Architektur und Anforderungen?
Gruß David
Ja, die Anforderungen zu schreiben und zu verstehen ist es manchmal schwierig. Die Architektur ist ok. Es liegt - glaube ich - eher an der Umsetzung in der Entwicklungsphase.
OK, verstehe. Weil die Qualität nicht ausreichend ist?
Gruß David
Ja, das vermute ich. Als Beispiel: Wir arbeiten mit React und einige Entwickler bauen ungemein riesige Komponenten. Irgendwann sieht man da unweigerlich nicht mehr durch. Manchmal rutscht sowas im Review durch und schon hat man diese Komponente ewig in seinem Projekt.
Du kennst doch das Problem: Features sind immer wichtiger als Qualität :-D
Ja, das kenne ich leider in der Tat :) Aber sowas ist bei mir in der Retro immer Gesprächspunkt Nr. weil sowas nur einmal passieren darf :)
Gruß David
Hallo David,
die Wochen sind sicher vorbei ;-)
Bei 16:55 sprichst Du ein Video zum Thema DevOps an, das Du in den nächsten Wochen erstellen willst und dann in der Videobeschreibung (und oben Rechts) verlinken möchtest.
Gibt es das Video oder ist es vielleicht in Vergessenheit geraden?
Gruß,
Carsten
Hallo Carsten,
das zwar nicht in Vergessenheit geraten, allerdings habe ich erstmal andere Videoideen vorgezogen. Im Moment mache ich mangels Zeit und Projekten eher kürzere Videos und die vor allem nach Möglichkeit draußen in der Natur - das ist mit diesem Video leider nicht möglich. Sobald das Wetter aber wieder schlechter wird, werde ich das als erstes machen :)
Gruß David
Herzlichen Dank!
Sehr gerne :)
Gruß David
Sehr Hilfreiches Video. Ich hab eine kurze Frage und zwar wie sind eigentlich die Kurze von alnafi.
Hey,
vielen Dank aber verstehe Deine Frage nicht ganz. Was genau meinst Du?
Gruß David
Cooles Video, von der Thematik perfekt getroffen mit dem SDLC. In vielen mir bekannten Projekten wird viel zu wenig getestet. Also hier fehlt zum Beispiel der einfache Unit-Test. TDD auf einfache Units und Komponenten wäre mal was schönes.
Schöne Grüße aus Ingolstadt! :)
Moin Bastian,
vielen Dank, schön das Dir das Video gefällt! Testen und Anforderung wären auch mein Tipp für die meisten Nennungen gewesen ;)
Schöne Grüße nach Ingolstadt!
Gruß David
Moin David. Was weißt du über ein Software Entwicklung Studium? Ich möchte anstatt Informatik ein Software Entwicklung Studium machen an der IU. Ich finde allerdings keine andere Uni die so etwas anbietet. Habe ich nicht richtig gesucht oder gibt es sowas in Deutschland noch nicht?
Bei uns gibt es im Bereich der Anforderungen Nachholbedarf. Dort werden die "Ideen" direkt an die Entwicklung weitergegeben ohne das eine Anforderungsanalyse stattfindet. Man kann als Entwicklungsteam so oft darauf Hinweisen wie man möchte, jedoch wird man nicht wirklich ernst genommen.
Hey Stefan,
urgs, daran solltet ihr aber schleunigst arbeiten ;)
Gruß David
Ganz klarer Favorit für Verbesserung: Anforderungsanalyse..
Ich habe leider schon mehrmals gehört: Ja wenn du das nicht verstehst musst du beim Autor nachfragen. Aus meiner Sicht eine sehr sehr teure Kultur, weil nicht nur ich ewig los laufen muss sondern auch der Autor aus seinem Kontext gerissen wird..
Hast du in deinem Video zu den Anforderungen vor den Prozess vom Kopf des Kunden bis zum Entwicklerschreibtisch zu behandeln? Meist liegen da ja viele Ebenen zwischen; Last zu Pflicht zu Epic/Epos Usw bis runter zum einzelnen Task. Ich habe nämlich oft das Gefühl, dass ein Verständnis fehlt was "ready" für die nächste Schicht ist.
Hey,
ja das ist (leider) bei vielen der Favorit.
Genau das habe ich vor - es geht vor allem um pragmatische Lösungen und Tipps für alle Ebenen.
Gruß David
Ich bin immer wieder amüsiert bezogen auf den Begriff ‚agil‘ und behaupte mal ganz frech, dass die kleinen mittelständischen Software-Unternehmen - ironisch formuliert - eigentlich ‚hyperagil‘ unterwegs sind 😂 und dabei jede Form der Organisation verlieren. Während das Scrum Modell ursprünglich entwickelt wurde, um riesige Softwareprojekte handhabbar zu gestalten, die regelmässig mit Wasserfallmodell scheiterten, wird Scrum in den kleinen Unternehmen verwendet, um ein Mindestmass an Organisation zu entwickeln - aber eigentlich war es so, wenn ich es historisch richtig in Erinnerung habe, nicht gedacht.
#fragdavid Ist while(true) böse oder nicht? Ich persönlich mag es nicht, da die Abbruchbedingung nicht direkt erkennen kann.
Dein Berater würde darauf die typische Antwort geben: it depends :)
Wiedermal ein sehr informatives Video :) Was definitiv häufig zu kurz kommt ist das Testen. Meist wird die Software nur ein paar mal angestoßen und überprüft, ob die umgesetzte Funktion wie erwartet arbeitet. Fehlerfälle werden dabei häufig erst behandelt, wenn Sie auftreten. Das kostet natürlich viel Zeit. Die resultierenden Effekte sind aber im Buch "Langlebige Softwarearchitekturen" von der Frau Lilienthal bereits schön beschreiben.
Hallo Martin,
schön das Dir das Video gefällt - danke für das Feedback. Ja, Testen in der Softwareentwicklung ist in der Tat schwierig und wird vernachlässigt - das sehe ich jeden Tag. Aber meist ist es dann schon so, das die Anforderungen so schlecht sind, das ein Testen gar nicht möglich ist. Sind die bei Euch gut genug? Ja, ich liebe das Buch :D
Gruß David
Hey@@DavidTielke. Ja die Projekte sind eher forschender Natur, Anforderungen entstehen da eher durch plötzlich auftretende Bedarfe. Es gibt meist nur ein grobes Konzept und dann heißt es erstmal "In alle Richtungen gucken; Was existiert vielleicht schon; Was kann man übernehmen; ...[getestet werden kann später^^]". Ich selbst habe erst meine Abschlussarbeit über den Entwurf einer Softwarearchitektur geschrieben und habe daher sehr viel Literatur gewälzt, genauso eben dieses Buch verwendet. Es war schön zu sehen, dass du selbst vor ein paar Monaten ein Interview mit Frau Lilienthal in einem deiner Videos veröffentlicht hast. Gerne mehr davon! Es gibt nichts besseres als Lernen aus Erfahrung und vor allem aus Erfahrung anderer.
LG
Hallo Martin,
ja ok, dann bist Du schon in einem speziellen Bereich der Softwareentwicklung unterwegs. Ja, diese Reihe mit anderen Experten hat mir auch sehr viel Spaß gemacht aber aufgrund der Masterarbeit habe ich es erst einmal pausiert - aber ich hoffe das ich bald mal wieder (dann aber unregelmäßig) dazu etwas starten kann :) So etwas zum Thema Testen wäre auch nicht so schlecht. Testet Ihr denn überhaupt?
Gruß David
Also der Vorteil in diesem Bereich ist , dass man da schon sehr viel Freiheiten hat und sich auch viel mit neuen Technologien auseinandersetzen kann. Dadurch ist man stetig am Lernen, was in unserer Branche natürlich überlebenswichtig ist! Ach, auch eine Masterarbeit. Sehr gut, dann wünsche ich dafür viel Erfolg! Ich habe es ja nun endlich geschafft aber merke halt, dass ich noch viel Erfahrung sammeln muss und noch viele Bücher zu wälzen habe^^
Ja wir testen schon, aber nicht so ausführlich, wie ich es mir manchmal wünschen würde. Meist haben die Projekte zunächst eine sehr kurze Lebensdauer, bis sie verlängert werden. Daher müssen immer recht schnell vorzeigbare Ergebnisse geliefert werden. Findet eine letztlich Verlängerung statt, fehlen natürlich die Testszenarien (Tests kosten wertvolle Zeit). Daher ist die Idee mit dem Thema "Testen" natürlich super. Vor allem wie man effizient Testet. Ich denke man muss auch eine "Testen tut nicht weh"-Kultur etablieren und diese im gesamten Team verbreiten. Es muss nur anklang finden. Ich freu mich schon auf deine Videos dazu ;)
Gruß Martin
Ja, auch eine Masterarbeit - aber ich habe sie halt nach 15 Jahren Selbstständigkeit gemacht. Bücher sind ohne Zweifel sehr gut aber reichen alleine auch nicht, ich denke wenn man selbst die Motivation hat, jeden Tag irgendwie ein kleines Stückchen besser zu werden - das ist der Schlüsse. Und in der Forschung ist die Softwareentwicklung in der Tat schwierig und in großen Teilen komplett anders als in der Industrie - viele der Dinge auf die es hier ankommt, was gute Softwarequalität angeht, ist in anderen Bereichen total unnütz :) Arbeitest Du denn als Wissenschaftlicher Mitarbeiter?
Gruß David
Können Sie ein Video machen, wie kann ein Softwareentwickler sich vorstellen bei dem Vorstellungsgespräch. Vielen Dank
Hallo,
wenn ich Zeit habe, kann ich diese Idee von Ihnen gerne einmal umsetzen.
Gruß David
Wie sieht es denn mit der Wiederverwendbarkeit von Software (Komponenten) aus?
Hey David..wann kommt dein Video zu DevOps.:)
Hey,
ich vermute in zwei Wochen :)
Gruß David
@@DavidTielke Superkühl :D
#FragDavid
Hattest Du schon Mal etwas dazu gemacht, wie ein fertiger Architektur-Entwurf aussehen kann oder sollte und wo die Architektur aufhört?
Ich kann natürlich Quellcode schreiben (würde ich mit Contract-Assemblies machen) und dazu alles mit Diagrammen verdeutlichen.
Und wo ist die Grenze zwischen Software-Architektur und Quellcode-Design? Je kleinteiliger ich plane, desto größer das Risiko, zu "overengeneeren".
Verstehst Du, was ich meine?
Hey,
so eine Serie ist in Arbeit - habe erstmal noch ein paar andere Ideen für Lernvideos und ein neues Format, was ich mal testen möchte, aber dann geht es mit Architektur los :)
Gruß David
Wir haben derzeit Probleme bei der Bereitstellung. Und das hat diesmal gar nichts mit Softwareentwicklung zu tun. Wir liefern die Software aber die Stakeholder liefern keine angepassten Nutzungsbedingungen/AGBs, Verträge und andere Informationen.
Wir haben jetzt seit einem Jahr ein Feature fertig und können es nicht bereitstellen, da rechtlichen oder kaufmännische Themen fehlen.
Hey Andre :)
Okay, das ist mal Strange - ist aber mehr oder weniger ein Anforderungs oder gar Projektmanagement-Problem, weil da kann die Softwareentwicklung ja nicht wirklich was zu, oder?
Gruß David
@@DavidTielke Mehr als die Dinge einfordern und ständig darauf hinweisen, können wir leider nicht. Aber es ist recht frustrierend.
Die meisten Mankos bestanden stets in Anforderungserfassung (konkret Tickets) und der Architektur.
Bei ersterem oft schlicht, weil die Verantwortlichen schwach im schriftlichen Ausdruck sind und schlecht gliedern können. Oft habe ich die Spezifikation übernommen oder diue Tickets direkt selber verfasst.
Zum zweiten: Verständnisss von Architektur besteht oft fast gar nicht oder es bestehen viele Missverständnisse (ich schließe mich selber nicht aus). Zum Teil auch bedingt duch überlappende Terminologien. (Warum müssen PHP-MVC-Frameworks ihren DI-Container "Service Container" nennen? Was ist denn nun ein Service? Und schon hat man unproduktive Diskussionen.)
Konkret habe ich erlebt, dass dieselbe Anwendung mit abweichenden Zusatzanforderuingen zwei mal komplett neu geschrieben wurde und man das als eine gute Lösung angesehen hat.
Hey Guido,
ja, Anforderungen werden leider immer so ein bisschen "nebenbei" gemacht und kaum jemand erkennt wie wichtig diese im Endeffekt sind.
Bzgl. Eurem Kommunikationsproblem in der Architektur, habt ihr Codierrichtlinien und Architekturrichtlinien? Klingt ganz danach, als würden diese fehlen....
@zwei doppelt implementierte Lösungen: Ernsthaft?!?! :D
Gruß David
@@DavidTielke Bezüglich Architekturrichtlinien: Bei der einen Firma: nein (deshalb auch die zwei Implementierungen). Das ist das Missverständniss, dass sich aus den MVC-Frameworks ergibt. Die sind so umfänglich und beschäftigen die Teams dermaßen, dass die Teams meinen, dies sei schon die Architektur. Dann hatten wir noch einen externen Dienstleister, den ich frühzeitig auf "generalistischen Ansatz für sich wiederholende Anforderungen" angesprochen habe. Und da kam die Antwort: " Bei sowas machen wir lieber Copy & Paste. (Und der hatte "Architekt" auf der Visitenkarte stehen.) Die machen halt "flotte Kundenwunscherfüllung" und dann tschüß. Ausbaden dürfen den Kuddelmuddel dann die Festangestellten.
Bei einer anderen Firma gab es sehr wohl einen Domain-getriebenen Komponenten-Ansatz. Allerdings irgenwie out of Control. (Fassaden mit was-weiß-ich-wie-vielen public-Methoden.) Copy & Paste, willkürliche Vererbungen ... Und die Terminologie war keinesfalls klar. Was nun Code-Design und was Architektur ist ... und wenn man präzise werden wollte, dann war das "zu wissenschaftlich" oder "zu philosophisch". Aber Coderichtlinien bis auf den letzten Whitespace. (Buhuuh, eine Leerzeile zu viel!)
Ja, zwei Implementierungen auch, weil ja Laravel viel cooler ist als Symfony. Und mein whiltelabel DB-Entwurf war ja viel zu komplex. Und Agiles Entwickeln heißt, dass man von Höckchen auf Stöckchen den Kundenanforderungen hinterherdackelt, Vorplanungen sind eh für die Katz, und immer schön am MVC entlang, denn das MVC das rettet einen ja.
Nachholbedarf besteht bei uns in der Entwurfsphase, hauptsächlich bei kleineren Projekten.
Hey,
Entwurf seitens der Architektur oder der Entwickler?
Gruß David
@@DavidTielke das geht bei den ungenauen Anforderungen los, aus denen ein Nicht-Architekt eine passende Architektur zaubern muss, und geht dann weiter mit der Entwicklung wo man hoffen muss, dass die gewählten Technologien und Frameworks am Ende immer noch die richtige Wahl sind. Insofern ist CoCo 2.0 ne feine Sache, weil das Änderungen im letztgenannten Kontext leichter macht.
Gruß Heiko
Schöne einfache Erläuterung des ganzen Prozesses. Aus eigenen Erfahrungen würde ich sagen, dass der Test oft zu kurz kommt. Zum einen weil es keinen definierten Prozess gab/gibt; zum anderen aber auch aufgrund von vorherigen Fehlern. Falsch verstanden oder unvollständige Anforderungen. Dadurch kann eine komplett verzogene Architektur entstehen, die die Entwicklung dann erschwert.
Hallo Torben,
schön, dass Dir das Video gefällt.
Was ist denn bei Euch problematischer, Anforderungen oder das Testen?
Gruß David
@@DavidTielke Stand jetzt: das Testen; ist aber auch mit einer meiner neuen Aufgaben, den Prozess zu kreieren. 😊
Sehr cool, super spannende und tolle Aufgabe... Wir sollten mal ein Video zu Cypress.io hier machen :D Schon konkrete Ideen für den Prozess?
Gruß David
@@DavidTielke im Moment bei der Evaluierung von Testtools. Liegt aber wegen Release auf Eis 😂
Tolles Video!!! Bei der Entwicklung, Programmiersprachen kommen und gehen, uns somit viele Mitarbeiter (VBScript).
Hey Toni,
Danke für Dein Feedback! ich kann mir vorstellen, dass VBScript Entwickler nicht mehr so einfach zu finden sind, stimmts?
Gruß David
Hallo David,
sehr interessantes Video, vielen Dank.
Bei uns sind die Test leider noch nicht so gut. Bei einer Änderung schaut der Entwickler über die Anwendungen und vergleicht mal die Werte mit der alten Version. Wenn da soweit alles gleich ist, gehts in das Produktivsystem. Ohne zu Wissen, ob nicht doch irgendwelche Seiteneffekte durch die Änderung aufgetreten ist. Bei jeder Änderung hat man ein bisschen Angst. ;-)
Moin,
sehr gerne, schön das es Dir gefällt. Ok... Noch ein Punkt für die Tests :) Wären denn Eure Anforderungen gut genug, dass man wirklich gut und sinnvoll testen könnte? Weil das meist das nächste Problem ist, was damit einher geht...
Gruß David
@@DavidTielke das kommt noch dazu. Die Entwickler wissen nicht, wie richtige Tests geschrieben werden und die Anforderung vom Fachbereich sind auch eher knapp...
Habt ihr denn Akzeptanzkriterien in Euren Anforderungen nach denen Ihr entwickelt und nach denen die Tester testen könnten?
Gruß David
@@DavidTielke das passiert dann eher auf Nachfrage. Aber in den Anforderung geschrieben, gibt es sowas meistens nicht.
Das dachte ich mir schon. Ohne solche ist es halt unfassbar schwer zu testen - besonders wenn man es dann im Nachgang machen muss. Da würde ich sogar so weit gehen zu sagen, dass es ab einer gewissen Größe unmöglich ist.
Gruß David
danke!
Bitte sehr!
kann ich ohne erfahrung ein Praktikum als Softwareenteicklung ode Sicherheit machen ?
Hey,
wenn Du genug Interesse hast und schon privat ein bisschen in dem Bereich gemacht hast bestimmt - bei dem Personalmangel im Moment werden in der Softwareentwicklung auch viele andere Tätigkeiten gesucht, für die Du nicht unbedingt eine IT-Ausbildung braucht, z.B. Tester, Dokumentatoren, Supportler usw.
Gruß David
Hallo David,
in unserem Unternehmen gibt es leider nur drei Entwickler, die jeweils mit verschiedenen Projekten beschäftigt sind. Somit gibt es leider keine Redundanzen (Krankheit/Vertretung) und auch keinerlei Rollen wie Architekten etc.
Jeder Kollege ist im Prinzip eine One-Man-Army
Same here. Das will ich gerade ändern😅
Sehr informativ. Bei uns ist das Requirements Engineering oft vernachlässigt. Nach dem Prinzip SHISHO kann man sich vorstellen was dabei rumkommt. Ich finde nicht nur das Management sondern and alle bis runter zum Programmierer sollte diese Disziplin beherrschen. Denn Anforderungen sollten nicht nur richtig geschrieben sondern auch richtig gelesen werden können. (Wenn man es dann ändern muss: "Wir sind ja so agile") Diesen Prozess zu optimieren dauert lange und ist teuer. Kannst du mal ein Video machen über Requirements Engineering über die Grenzen der Zuständigkeiten machen (Definition of Ready, Definition of Done .... )?
Hey,
schön das Dir das Video gefällt. Ja, solche Antworten hatte ich schon vermutet :) Ob es alle beherrschen sollten weiß ich nicht, da es mitunter ganz schön schwer sein kann gute Anforderungen in der Softwareentwicklung zu ermitteln. Wobei dein Argument mit dem "müssen alle lesen können" schon zutreffend ist. Genau so ein Video kommt in den nächsten Wochen :) Spezielle Wünsche?
Gruß David
Übrigens Pro Tip ;-) Acceptance Kriterien in Gherkin Style ist auch mal ein Video Wert. Es gibt gute Tools Unterstützung (SpecFlow, Cucumber etc) so das man diese direkt in Test überführen kann.
Gherkin für Akzeptanzkriterien ist in der Tat sehr sehr cool und nutze ich in vielen Projekten, allerdings für Anforderungen leider nicht ausdrucksstark genug :) Pro-Tipp habe ich schon was anderes im Sinn ;)
Gruß David
Arbeiten wir zufällig in der selben Firma? 😃
Das, was Du genannt hast, hat nur knapp gegen unser Test-Chaos verloren.
Und "SHISHO" gefällt mir, die Abkürzung kannte ich noch nicht ^^
Bei meinem aktuellen Projekt sind es die Anforderungen auszuarbeiten. Die verantwortlichen Kollegen machen das mit sich selbst.
Hey,
jaja, die Anforderungen :) Habt ihr ein Produktmanagement?
Gruß David
@@DavidTielke Wir haben ein Manager, der sich aber mit Agil noch nicht so gut auskennt und lieber das
Wassermodell anwendet.
Ich halte den Kollegen den Rücken frei als Freiberufler und merke das einiges schiefgeht wegen Zeitmangel
Hallo David,
Schöne heile Welt.
Aber exzellent erklärt, ich finds großartig.
Fehler? Ich weiß gar nicht wo ich anfangen soll.
Selbst auferlegte Dogmas werden wiederholt verletzt.
Künstlicher Zeitdruck.
Keine gemeinsamen Definitionen für unterschiedliche Teams.
Man baut das Dach, ohne ein Gerüst.
Usw. Leider🙁
Danke Dir, für diesen Eindruck wie es theoretisch laufen sollte.
Gruß Marcus
Hallo Marcus,
schön wenn Dir die Erklärung gefällt. Ist sie bei Dir nicht so "heile"? Wie schaut es bei Euch aus?
Gruß David
#FragDavid
Hey David, deine Videos sind super! Vielen Dank erstmal dafür!
Ich hätte nie gedacht, dass ich mich mal für Softwareentwicklung interessieren würde, bis ich mich vor ein paar Jahren intensiv mit dem Bitcoin und seiner gesellschaftlichen Idee auseinandergesetzt habe. Hast du Bezug zum Bitcoin? Was denkst du über dieses spezielle verteilte System und die Idee Wert im Netz durch unkopierbare Werte zu erschaffen?
Meinst du es lohnt sich für eine Karriere in diesem Bereich das Coden zu lernen?
Liebe Grüße
F.
Sehr gerne, schön das dir die Videos gefallen. Beim Thema Bitcoin bin ich leider raus, sorry!
Nachholbedarf unbedingt bei den Anforderungen. Ein guter Product Owner sorgt für den Erfolg des gesamten Projekts. Und wenn der fehlt, wird es schwierig - und meist teuer.
Hey Markus,
Amen !!! Sehr gut ausgedrückt :) Habt ihr so einen? :D
Gruß David
@@DavidTielke Derzeit leider nicht mehr. Es steht ein Wechsel bevor. Ich bin gespannt. Danke für deine Videos. (auch wenn sie mir ohne Hintergrundmusik noch besser gefallen ;-) Aber das ist vielleicht Geschmackssache.)
Hey Markus,
ist auch schwer zu finden so eine Person. Sehr gerne, schön das Sie dir gefallen - ich bin hin und her gerissen was die Musik angeht, mal schauen :)
Gruß David
Wir entwickeln tatsächlich noch in schönster Wildwest-Manier. Insbesondere die Anforderungen und die Unit Tests werden gerne mal ignoriert. Für die Anforderungen wünsche ich mir ein nettes Tool, um den entstandenen Code den ursprünglichen Anforderungen zuzuordnen. Von Hand wird nie was draus. Oder es artet in so viel Papierkram aus, dass es niemand schreiben und schon gar nicht lesen will. Ansonsten nettes Video, in kompakter Form alles Wichtige präsentiert!
Hey Alex,
das ist halt oft nicht so einfach, dem Quellcode eine Anforderung zuzuordnen, da der Quellcode oft von mehreren Anforderungen betroffen ist. Mit integrierten ALM Tools wie Azure DevOps kannst Du das aber quasi for-free im vorbeigehen bekommen - da wird jede Quellcodezeile mit der entsprechenden Anforderung verknüpft, wenn Du es beim Checkin angibst.
Gruß David
Bald starte ich meine erste Tätigkeit im Bereich der Softwareentwicklung und das Video fasst die Inhalte aus dem Studium nochmal super zusammen.
Habe schon Bammel aber das wird schon.
Vielen Dank!
Wir haben eine sehr guten Draht zu unseren Kunden und das DevOps Prinzip wird sehr gut umgesetzt/gelebt, wenn ich etwas verbessern würde, ist es die Architektur, wobei dieser Punkt auch der undankbarste ist, weil sobald mögliche Konkurrenz auf der Bildfläche erscheint und dem Kunden vermeidlich das „Startgeld“ für ein Projekt wichtiger ist als die Qualität (und die möglichen Einsparungen in der Zukunft), so wird auch die Architektur darunter leiden… schade das.
Vorbildlich - ja das ist leider so, vor allem Kunden die wenig Erfahrung in dem Bereich haben, lassen sich oft von diesen - vermeintlich günstigen Projekten - blenden und zahlen nachher doppelt. Schafft Ihr es trotzdem das umzusetzen?
Gruß David
@@DavidTielke
Ja, wir verkaufen uns natürlich trotzdem nicht unter Wert, aber gewisse Kunden ziehen viele Konkurrenz Firmen an… mit teils sehr unseriösen Angeboten^^
Am Ende ist es wirklich Gold wert, wenn man jemanden in der Firma zu hat, der viel Erfahrung mitbringt und all diese Faktoren die bei Preisbildung etc. eine Rolle spielen im Auge hat.
Grüße
Ja, total - das Problem ist, dass solche Leute einen guten Überblick und viel Erfahrung haben müssen. Das ist in der Praxis oft nicht einfach solche Leute zu bekommen :)
Gruß David
Das Buch wird verlost?
Schade eigentlich, wenn es am der schlimmsten Geschichte festgemacht wäre, hätte ich gute Chancen 😃
Und ich würde sagen, das größte Problem sind Tests.
Die Anforderungen sind zwar auch ein einziges Chaos, aber Tests sind derzeit quasi nicht existent.
Konkret schreibt meist der Entwickler die Test-Beschreibungen, die der Tester dann Schritt für Schritt ausführen muss. UnitTests gibt es nicht, Akzeptanzkriterien auch nicht.
Die Test-Beschreibungen sind also meist auf das bezogen, was der Entwickler gemacht und sowieso schon getestet hat (wenn nicht, hätte er was falsch gemacht), daneben fallen viele Punkte unter den Tisch.
Außerdem werden alte Funktion meist gar nicht getestet.
Am Ende heißt das, dass der Test sehr viel Zeit für eine mMn. eher stumpfsinnige Arbeit braucht, die der Entwickler sowieso schon gemacht haben sollte.
Oft muss sogar noch der Entwickler daneben sitzen, z.B. bei sehr technischen Aufgaben, die man aus Nutzer-Sicht nur schwer nachvollziehen kann.
PS: Der Grund, warum die Anforderungen nicht top 1 sind, ist einfach:
Der Chef weiß meist sehr genau, was gewünscht ist. Er teilt es niemandem mit, man muss alles erfragen (auch wenn man nichts davon weiß "hättest ja Mal fragen können"), aber irgendwo vorhanden und erreichbar sind die Anforderungen schon.
Die Tests bzw. das fehlen einer vernünftigen Teststrategie hat die weitreichenden Folgen, daher sind die mein Platz 1.
Hey,
ja - ich lose das aus. Aber Du hast recht, mit der Story hättest Du gute chancen... Aber sei beruhigt, genau solche Szenarien habe ich bei meinen Kunden ständig :D Wie viel Zeit entwickelt ein Entwickler dann noch? 30 Minuten? :D
Gruß David
@@DavidTielke Was meinst Du?
Die meiste Zeit nimmt die Entwicklung in Anspruch, der Test geht meist ziemlich schnell, weil nur oberflächlich getestet wird.
Es hängt aber auch vom Projekt an, z.B. mein aktuelles Projekt läuft seit Monaten und ist das erste mit UnitTests, weil der Kunde das wollte. Und die menschlichen Tests werden sehr viel Zeit in Anspruch nehmen, weil es ein neues Programm ist und vollständig im Hintergrund ohne UI und mit sehr großen XML-Daten arbeitet.
Die Zeit ist natürlich nicht da, also wird wieder die Deadline gerissen.
Ich meinte weil ihr so viel Zeit mit dem Erfragen der Anforderungen verbringt :)
Gruß David
@@DavidTielke Achso - in dem Fall bereiten wir vor, in der Hoffnung, so Zeit zu sparen. Wenn wir falsch vermutet haben, war das natürlich für die Katz, aber naja.
Oder wir arbeiten an anderen Projekten weiter, meistens hat jeder mehrere Projekte am laufen und muss mit den Prioritäten jonglieren.
Warten ist also eher selten das Problem, es gibt immer was zu tun.
👍
👍
Anforderungen und Architektur werden teilweise komplett ausgelassen. Jemand hat eine Idee, jemand Anderes fängt an etwas umzusetzen.
Moin Sven,
ihr lasst Architektur und die Anforderungen aus? Wie viel langlaufende Projekte habt ihr denn? Die müssten potenziell ja alle in einem furchtbaren Zustand sein!?!?
Gruß David
Anforderungsanalyse
Ich werde nicht müde, den meiner Meinung nach grossen Unterschied zwischen Produkt- und Projektentwicklung zu betonen. Er ist vergleichbar mit dem Unterschied zwischen der Erreichung von strategischen und taktischen Zielen. Das strategische Ziel ist die Erstellung eines Hauses. Ein taktisches Ziel bei der Erstellung eines Hauses ist z.B. die Erstellung eines Bauplans. Software-Produkte berücksichtigen meiner Meinung nach strategische Ziele, Software-Projekte dienen eher der Erreichung taktischer Ziele. Das Instrumentarium der Softwareentwicklung ist auf die Projektentwicklung ausgerichtet und leider kaum auf die Entwicklung von Produkten. Dazu reichen die Scrum Rollen meines Erschtens nach nicht aus.
Zu wenig Zeit für betriebswirtschaftlich unsichtbare Aufgaben
#FragDavid
Hi David, kannst du mal etwas zu Domain Driven Design machen?
Hey Kevin,
hab es auf die Liste gepackt - danke!
Gruß David