Auch von mit vielen Dank für deine Videos. Sie haben nicht nur meine Softwarequalität und Entwicklungsprozess verbesser, sondern trage es auch an meine Kollegen und Freunde weiter. 👍
Ich weiß gar nicht wann das war, aber vor einigen Jahren bin ich zu einer Gruppe gestoßen, die an ein Projet realisieren sollten und die arc42 als Template für ihre Dokumentationen nutzten. Danach hatte ich zwei kleinere Projekte und habe dieses Template übernommen. "Schema F" funktioniert ja nicht überall so das ich das Template für meine Bedürfnisse leicht angepasst habe. Seid mittlerweile 6 Jahren arbeite ich mit 4 Entwicklern an einer Software für eine dänische Zeitung in Flensburg und ich habe auch hier von Anfang an mit arc42 gearbeitet (wieder leicht angepasst). Zusammen mit AsciiDoc lässt es sich dann auch schön mit GIT versionieren. AsciiDoc verwende ich auch für meine Anforderungsdokumentation. Das funzt echt gut. Ansonsten hab ich mein Draw.io für die Diagramme, Pencil für die Mockups und OneNote auf dem Surface für Meetings (und auch manchmal für Mocklups)
Hi, sorry, ich glaube du hast das Dokumentieren der Tests für alle Dinger die du dokumentieren möchtest vergessen. Würde mich sehr freuen, deine Meinung dazu zu hören. LG
Hey, das dokumentieren von Tests ist schwierig - welche Art von Tests meinst du? Unit-Tests? Service-Tests? Systemtest? Außer letzeres fällt mir da zum Thema dokumentieren nicht viel ein wenn ich ehrlich bin und selbst da ist es meinst so, das die Testlisten selbst schon Dokumentation genug ist. Also erklär mal genauer was Du meinst :) Gruß David
@@DavidTielke Die Dokumentation, die du beschreibst sagt aus: So ist es, sei es Architektur oder Funktion oder Schnittstelle... Wenn du jetzt testest, sollte hoffentlich dabei rauskommen, dass das was du getestet hast, nicht dem Dokumentierten widerspricht, sei es weil es nicht die passende Form hat oder anderes Verhalten zeigt oder weil du gar nicht Testest und nie einen Widerspruch feststellen würdest... Jetzt steckt ja in den Überlegungen beim Testdesign doch einiges an Effort (z.B. Validieren/Opimieren der Architektur oder Überlegungen beim Testen von Schnittstellen zu Objekten und in der Interaktion von Objekten in der dazugehörigen Umgebung, so dass das robust ist). Die Belohnung ist ja dann das "Fallnetz, ohne allzugrosse Löcher". Irgendwie muss es doch dann möglich sein "das Programm", welches dem Testen zu Gunde liegt, zu dokumentieren. Also sozusagen gehört ja das "Fallnetz" selber auch dazu. Ich hoffe, ich habe mich einigermassen verständlich ausgedrückt. In gewisser Weise, sagt ein Test ja auch aus, was nicht passieren darf oder wovon du dich schützen willst...um zu diesem Schluss zu kommen, bedarf es in der Regel gewisse Anstrengungen, weil nicht von Anfang ersichtlich (sondern erst durch Fehler, TDD), das sollte doch dann festgehalten werden, warum es diesen Test braucht und was er sicherstellt.
Das ist schon ne sehr beschränkte "enterprisy" Sicht, die hier präsentiert wird. Also kann man so machen, aber dann geht ungefähr jegliche Agilität dabei verloren 🤔😂
Hey, ist mir unverständlich, was daran "enterprisy" ist und wo genau das jetzt kontra der Agilität ist. Was bitte haben die beiden Punkte mit der Dokumentation zu tun? Gruß David
@@DavidTielke Du hast das wichtigste vergessen. In jedem Fall sollte die Software mit den Kommandos aus dem Readme bauen und anstarten, sonst hat man keine funktionierende Software. Und ein Projekt, dessen Release Prozedur nicht funktioniert, ist tot. Naja alleine schon dass SCRUM als Prozess gesetzt ist, man JIRA nutzt, in Sprints arbeitet, ein Backlog pflegt und es einen SM / PO / SWA als Rolle gibt, finde ich schwierig. Am Ende des Tages zählt eben nur Code, egal wie viele schöne Tickets, Meetings und Diagramme es gibt und da kann man niemanden brauchen, der nix dazu beiträgt bzw. den Prozess aktiv behindert. Für mich ist es nur agil, wenn Entwickler direkt mit dem Benutzer reden, ansonsten spielt man Flaschenpost. Also bei der Doku vom Code und dem Handbuch für den Kunde stimme ich überein. Meine Sicht ist aber, dass man die Stories, die einem ein echter Benutzer (kein PO) erzählt, in Form von Tests niederschreiben sollte und die Tests somit zur Spezifikation werden, was die Software macht. Und natürlich ist der Code die einzige valide und wertvollste Doku. Bei einem Open Source Projekt würde ich es meistens bei Code + Tests + Readme belassen. Bei Closed Source muss man natürlich mehr Wert auf die Doku der Schnittstellen legen, weil ja niemand von außen reinschauen kann. Und ja, ich hab ein paar "extreme" Ansichten, die nicht Mainstream sind und ich hab kein Problem, wenn man anderer Ansicht ist. Bisher bin ich gut damit gefahren, vor allem als Solo-Selbständiger und in kleinen Teams.
Finde es großartig, wie du die verschiedenen Arten an Dokumentation so kompakt und HandsOn ausarbeitest.
Danke für das tolle Video 👍
Hey,
vielen Dank für das Feedback - sehr gerne :)
Gruß David
Auch von mit vielen Dank für deine Videos. Sie haben nicht nur meine Softwarequalität und Entwicklungsprozess verbesser, sondern trage es auch an meine Kollegen und Freunde weiter. 👍
Sehr gute Übersicht.. Top 👍
Danke, sehr gerne!
Gruß David
Architekturdoku mit Asciidoc mit arc42. Das mach ich seid jahren und ist genau richtig für mich.....
Hey,
ja Arc42 ist ein guter Start - aber auch kein Allheilmittel :) Wie lang ist deine Doku und wie viel Jahre führst Du sie schon?
Gruß David
Ich weiß gar nicht wann das war, aber vor einigen Jahren bin ich zu einer Gruppe gestoßen, die an ein Projet realisieren sollten und die arc42 als Template für ihre Dokumentationen nutzten. Danach hatte ich zwei kleinere Projekte und habe dieses Template übernommen. "Schema F" funktioniert ja nicht überall so das ich das Template für meine Bedürfnisse leicht angepasst habe. Seid mittlerweile 6 Jahren arbeite ich mit 4 Entwicklern an einer Software für eine dänische Zeitung in Flensburg und ich habe auch hier von Anfang an mit arc42 gearbeitet (wieder leicht angepasst). Zusammen mit AsciiDoc lässt es sich dann auch schön mit GIT versionieren. AsciiDoc verwende ich auch für meine Anforderungsdokumentation. Das funzt echt gut. Ansonsten hab ich mein Draw.io für die Diagramme, Pencil für die Mockups und OneNote auf dem Surface für Meetings (und auch manchmal für Mocklups)
Asciidoc ist soviel besser als Markdown.
Was sind PWIs?
Hi, sorry, ich glaube du hast das Dokumentieren der Tests für alle Dinger die du dokumentieren möchtest vergessen. Würde mich sehr freuen, deine Meinung dazu zu hören. LG
Hey,
das dokumentieren von Tests ist schwierig - welche Art von Tests meinst du? Unit-Tests? Service-Tests? Systemtest? Außer letzeres fällt mir da zum Thema dokumentieren nicht viel ein wenn ich ehrlich bin und selbst da ist es meinst so, das die Testlisten selbst schon Dokumentation genug ist. Also erklär mal genauer was Du meinst :)
Gruß David
@@DavidTielke Die Dokumentation, die du beschreibst sagt aus: So ist es, sei es Architektur oder Funktion oder Schnittstelle... Wenn du jetzt testest, sollte hoffentlich dabei rauskommen, dass das was du getestet hast, nicht dem Dokumentierten widerspricht, sei es weil es nicht die passende Form hat oder anderes Verhalten zeigt oder weil du gar nicht Testest und nie einen Widerspruch feststellen würdest... Jetzt steckt ja in den Überlegungen beim Testdesign doch einiges an Effort (z.B. Validieren/Opimieren der Architektur oder Überlegungen beim Testen von Schnittstellen zu Objekten und in der Interaktion von Objekten in der dazugehörigen Umgebung, so dass das robust ist). Die Belohnung ist ja dann das "Fallnetz, ohne allzugrosse Löcher". Irgendwie muss es doch dann möglich sein "das Programm", welches dem Testen zu Gunde liegt, zu dokumentieren. Also sozusagen gehört ja das "Fallnetz" selber auch dazu. Ich hoffe, ich habe mich einigermassen verständlich ausgedrückt. In gewisser Weise, sagt ein Test ja auch aus, was nicht passieren darf oder wovon du dich schützen willst...um zu diesem Schluss zu kommen, bedarf es in der Regel gewisse Anstrengungen, weil nicht von Anfang ersichtlich (sondern erst durch Fehler, TDD), das sollte doch dann festgehalten werden, warum es diesen Test braucht und was er sicherstellt.
Spoiler .. DWX22Tielke100 funktioniert nicht 😂
Hey Jonas,
netter Versuch - so einfach machen die bei der DWX es uns aber nicht.... ;)
Gruß David
Golive klang fuer mich irgendwie nach Goliath ^^ Hat was.
Das ist schon ne sehr beschränkte "enterprisy" Sicht, die hier präsentiert wird. Also kann man so machen, aber dann geht ungefähr jegliche Agilität dabei verloren 🤔😂
Hey,
ist mir unverständlich, was daran "enterprisy" ist und wo genau das jetzt kontra der Agilität ist. Was bitte haben die beiden Punkte mit der Dokumentation zu tun?
Gruß David
@@DavidTielke Du hast das wichtigste vergessen. In jedem Fall sollte die Software mit den Kommandos aus dem Readme bauen und anstarten, sonst hat man keine funktionierende Software. Und ein Projekt, dessen Release Prozedur nicht funktioniert, ist tot.
Naja alleine schon dass SCRUM als Prozess gesetzt ist, man JIRA nutzt, in Sprints arbeitet, ein Backlog pflegt und es einen SM / PO / SWA als Rolle gibt, finde ich schwierig. Am Ende des Tages zählt eben nur Code, egal wie viele schöne Tickets, Meetings und Diagramme es gibt und da kann man niemanden brauchen, der nix dazu beiträgt bzw. den Prozess aktiv behindert. Für mich ist es nur agil, wenn Entwickler direkt mit dem Benutzer reden, ansonsten spielt man Flaschenpost.
Also bei der Doku vom Code und dem Handbuch für den Kunde stimme ich überein. Meine Sicht ist aber, dass man die Stories, die einem ein echter Benutzer (kein PO) erzählt, in Form von Tests niederschreiben sollte und die Tests somit zur Spezifikation werden, was die Software macht. Und natürlich ist der Code die einzige valide und wertvollste Doku. Bei einem Open Source Projekt würde ich es meistens bei Code + Tests + Readme belassen. Bei Closed Source muss man natürlich mehr Wert auf die Doku der Schnittstellen legen, weil ja niemand von außen reinschauen kann.
Und ja, ich hab ein paar "extreme" Ansichten, die nicht Mainstream sind und ich hab kein Problem, wenn man anderer Ansicht ist. Bisher bin ich gut damit gefahren, vor allem als Solo-Selbständiger und in kleinen Teams.