Ich finde einfache Lösungen auch besser. Wir nutzen allerdings für unsere Projekte Jira, was eher in die Kategorie "überfrachtet" fällt. Mit GitHub Issues habe ich in privaten Projekten gute Erfahrungen gemacht. Für Anforderungen gibt es übrigens - genau wie für Software selbst - Qualitätskriterien. Diese sollten auch bei einfachen Tools berücksichtigt werden. Besonders wichtig sind mir die Kriterien Vollständigkeit, Eindeutigkeit und Verständlichkeit. Ansonsten ist das Ergebnis der Entwicklung möglicherweise nicht, was der Kunde sich vorgestellt hat. Diese Kriterien zu prüfen und die Formulierung von Anforderungen nachzuschärfen ist Gegenstand von regelmäßigen Meetings mit Kunden, die wir Refinement nennen.
[gr] Ja, das stimmt - genauso wie man eine "Definition of Done" für den Code / die Entwicklung haben sollte, kann es beispielsweise eine gute Idee sein, eine "Definition of Ready" für das Schreiben von Anforderungen zu haben. Die Kriterien, die Du genannt hast, sind da gute Stichworte 👍
Hallo Golo, mit viel Interesse verfolge ich aus dem Markgräfler Land deine spannenden Erklärungen rund um das Thema "Softwareentwicklung". Ich wollte Fragen, ob du mal ein Video zum Thema "use cases" machen könntest? Vielen Dank, Pierre
[gr] Vielen Dank für das tolle Feedback, das freut mich 😊 Was das Thema „use cases“ angeht - magst Du das noch ein bisschen ausführen, was Du Dir da genau wünschen würdest?
Ich bin über 20 Jahre als klinischer Mediziner in der Anästhesie und Intensivmedizin tätig gewesen. Vor 13 Jahren habe ich einen Master für IT im Gesundheitswesen erworben und arbeite seit 2 Jahren im Bereich der Softwareentwicklung für Dokumentationssoftware auf Intensiv und in der Anästhesie. Dabei kommt immer wieder die Frage nach den "use cases" auf, aus denen dann der "bussiness value" abgeleitet werden soll. Regelmäßig stehen ich und selbst meine ärztlichen Kollegen (Kundenbefragungen) da regelmäßig auf dem Schlauch, weil wir mit diesen Managementbegriffen nicht immer sehr viel anfangen können und weil uns hier eventuell die Grundlagen fehlen. Was ist ein "use case"? Wie beschreibe ich die Inhalte so, daß eine gute Anforderung für den Entwickler daraus abgeleitet werden kann? Ist ein "use case" bereits eine Anforderung? Liegt in der sauberen Dokumentation von klinischen Inhalten, der standardisierten Datenausleitung nicht selbst schon ein Wert? Oft interessiert den Geldgeber dann in diesem Zusammenhang natürlich auch: "Was ist der Kunde bereit, dafür zu zahlen?" Gelegentlich ist es schwierig, hier die Welt des Spezialisten mit der Welt des Entwicklers in Einklang zu bringen. Da tauchen dann ebenso oft Kommunikationsbrüche auf, wie es Medienbrüche in der Dokumentationslandschaft der Kliniken gibt... Danke für deine nette und hilfreiche Art. Wenn das Thema für dich nicht passt oder den Rahmen sprengt, dann fühle dich nicht genötigt, noch mehr Zeit zu investieren, als du ohnehin schon durch das Lesen und Beantworten meiner Kommentare getan hast... 😉 Es soll ja auch vielen durch diese Videotutorials geholfen werden! Auf jeden Fall habe ich mich sehr über eine superschnelle Antwort von dir gefreut. DANKE!
[gr] Danke für die ausführliche Erklärung, jetzt habe ich eine gute Vorstellung davon, was Du meinst - und ja, ich kann absolut nachvollziehen, dass das oftmals mehr Fragen hinterlässt als es klärt 😉 Das Thema ist super, und es passt auch gut mit dem von Dir angesprochenen Kommunikationsbruch zusammen, dazu machen wir sehr gerne etwas. Ob das schon direkt kommende Woche sein wird, kann ich Dir nicht versprechen, aber in den nächsten zwei, drei Wochen sollte es machbar sein 😊 Und ich denke, dass das Thema auch so wichtig ist, dass es möglichst viele Entwicklerinnen und Entwickler (und natürlich auch andere Rollen!) auf dem Schirm haben sollten, insofern - vielen Dank für die Anregung 😊
@@thenativewebhi eine frage ich muss Anforderungen nicht nachgekommen bist . Bitte stelle sicher alle Anforderungen zu erfüllen . Bin bi & muss in Romeo App das machen Aber was bedeutet es Könntest du mir bitte Hilfen danke .
Wir benutzen bei uns in der Firma Jira, mit mehreren Boards und gefühlt mehr mal als 20 (optionale) Felder im Ticket. Dabei sind wir keine große Firma... Ich bin ein Freund von einfachen Strukturen. Wir hatten am Anfang die Issue Verwaltung von Gitlab benutzte, haben dann aber Jira vorgesetzt bekommen mit der Anweisung es zu benutzen. Ähnlich sieht es mit der Dokumentation aus. Ich finde, dass die Dokumentation nah dem Code stehen soll (also im bestenfalls im repo), jetzt benutzen wir Confluence. Du hast von den Issue Template von Wolkenkit geredet, darf man sie für eigene Projekte übernehmen?
[gr] Das klingt nach der leider durchaus gängigen Vorgehensweise, dass nicht die die Werkzeuge entscheiden, die tagtäglich damit arbeiten, sondern jemand anderes … dass nicht nur die Issues, sondern auch die Dokumentation nah am Code sein sollte, da bin ich ganz bei Dir - alles andere macht es letztlich nur umständlicher, und damit leider auch fehleranfälliger. Wegen der Templates, die wir für wolkenkit verwenden: Das ist sehr lieb, dass Du fragst, und die könnt Ihr auf jeden Fall sehr gerne verwenden. Freut mich, wenn sie Euch helfen 😊 Die Vorlagen findest Du unter github.com/thenativeweb/wolkenkit/tree/main/.github/ISSUE_TEMPLATE
Ich arbeite aktuell mit Doors und bin auf der Suche nach Tools mit mehr Zukunftssicherheit und Progressivität. Ich finde den Ansatz mit Git Issues sehr interessant. Vor allem, weil man dort glaube ich auch Requirements kommentieren könnte, nachdem sie verfasst wurden. In meinem Kontext ist das System und die SW sehr komplex, alt, groß, monolithisch und verteilt. In größeren Systemen unterteilt man i.d.R. zwischen System- und Software-Requirements, die miteinander verlinkt werden (Traceability). Siehst du eine Möglichkeit, Beziehungen/Verlinkungen mit Git Issues zu realisieren? Nächste Frage: Gibt es Git Issues auch als standalone package zur lokalen Installation?
[gr] Ja, Du kannst die Issues auf GitHub / GitLab untereinander verlinken. Das einfachste ist, in einem Issue die ID des anderen mit einem Hash zu erwähnen (also zB so was wie #123). Das wandeln die beiden Systeme dann jeweils in einen Link um. Die Issues sind aber kein Feature von Git, sondern wie gesagt von GitHub und GitLab. Die kann man jeweils in einer Enterprise-Edition bekommen, die sich dann auch lokal installieren lässt.
Bei meinen Kunden kommt vor der Besprechung von Anforderungen immer noch eine Einleitung über Kommunikation und Sprache. Viele Missverständnisse und Rückfrageorgien lassen sich durch den klugen Einsatz von Sprache vermeiden. Bei der Vorbereitung eines solchen Vortrags bei einem Kunden vor Ort Abends im Hotelrestaurant stieß ich in der Speisekarte auf den Satz "Salat oder Suppe mit Brot". Dieser findet sich noch heute in meinen Slides. Im schlimmsten Fall wird hier nicht erkannt, dass dieser Satz unterschiedlich aufgefasst werden kann. Im besten Fall liefert der Kontext eine Konkretisierung (Brot steht schon auf den Tisch). Im mittleren Fall muss jemand Fragen "Gibt es Brot nur zur Suppe oder auch zum Salat?". Egal welches Tool: Sprache ist sehr entscheidend und man kann dies gut trainieren und selbst die Qualität der Prosaanforderungen steigen, so dass weniger Zeit mit dem "Verstehen" vergeht.
[gr] Das ist ein spannender Ansatz (und das Beispiel mit der Speisekarte ist super, btw!), und man kann den Wert und die Relevanz einer gemeinsamen Sprache letztlich nicht genug betonen. Das wird zu oft unterschätzt und kommt daher in aller Regel viel zu kurz … und das rächt sich über kurz oder lang.
Es wäre manchmal hilfreich, wenn ihr Beispiele eingeblendet hättet statt nur trocken darüber zu sprechen. Dann könnte man sich das wesentlich besser vorstellen, worüber gerade gesprochen wird.
Ich finde einfache Lösungen auch besser. Wir nutzen allerdings für unsere Projekte Jira, was eher in die Kategorie "überfrachtet" fällt. Mit GitHub Issues habe ich in privaten Projekten gute Erfahrungen gemacht.
Für Anforderungen gibt es übrigens - genau wie für Software selbst - Qualitätskriterien. Diese sollten auch bei einfachen Tools berücksichtigt werden. Besonders wichtig sind mir die Kriterien Vollständigkeit, Eindeutigkeit und Verständlichkeit. Ansonsten ist das Ergebnis der Entwicklung möglicherweise nicht, was der Kunde sich vorgestellt hat. Diese Kriterien zu prüfen und die Formulierung von Anforderungen nachzuschärfen ist Gegenstand von regelmäßigen Meetings mit Kunden, die wir Refinement nennen.
[gr] Ja, das stimmt - genauso wie man eine "Definition of Done" für den Code / die Entwicklung haben sollte, kann es beispielsweise eine gute Idee sein, eine "Definition of Ready" für das Schreiben von Anforderungen zu haben. Die Kriterien, die Du genannt hast, sind da gute Stichworte 👍
Hallo Golo,
mit viel Interesse verfolge ich aus dem Markgräfler Land deine spannenden Erklärungen rund um das Thema "Softwareentwicklung". Ich wollte Fragen, ob du mal ein Video zum Thema "use cases" machen könntest?
Vielen Dank, Pierre
[gr] Vielen Dank für das tolle Feedback, das freut mich 😊
Was das Thema „use cases“ angeht - magst Du das noch ein bisschen ausführen, was Du Dir da genau wünschen würdest?
Ich bin über 20 Jahre als klinischer Mediziner in der Anästhesie und Intensivmedizin tätig gewesen. Vor 13 Jahren habe ich einen Master für IT im Gesundheitswesen erworben und arbeite seit 2 Jahren im Bereich der Softwareentwicklung für Dokumentationssoftware auf Intensiv und in der Anästhesie. Dabei kommt immer wieder die Frage nach den "use cases" auf, aus denen dann der "bussiness value" abgeleitet werden soll. Regelmäßig stehen ich und selbst meine ärztlichen Kollegen (Kundenbefragungen) da regelmäßig auf dem Schlauch, weil wir mit diesen Managementbegriffen nicht immer sehr viel anfangen können und weil uns hier eventuell die Grundlagen fehlen. Was ist ein "use case"? Wie beschreibe ich die Inhalte so, daß eine gute Anforderung für den Entwickler daraus abgeleitet werden kann? Ist ein "use case" bereits eine Anforderung? Liegt in der sauberen Dokumentation von klinischen Inhalten, der standardisierten Datenausleitung nicht selbst schon ein Wert? Oft interessiert den Geldgeber dann in diesem Zusammenhang natürlich auch: "Was ist der Kunde bereit, dafür zu zahlen?" Gelegentlich ist es schwierig, hier die Welt des Spezialisten mit der Welt des Entwicklers in Einklang zu bringen. Da tauchen dann ebenso oft Kommunikationsbrüche auf, wie es Medienbrüche in der Dokumentationslandschaft der Kliniken gibt...
Danke für deine nette und hilfreiche Art. Wenn das Thema für dich nicht passt oder den Rahmen sprengt, dann fühle dich nicht genötigt, noch mehr Zeit zu investieren, als du ohnehin schon durch das Lesen und Beantworten meiner Kommentare getan hast... 😉 Es soll ja auch vielen durch diese Videotutorials geholfen werden! Auf jeden Fall habe ich mich sehr über eine superschnelle Antwort von dir gefreut. DANKE!
[gr] Danke für die ausführliche Erklärung, jetzt habe ich eine gute Vorstellung davon, was Du meinst - und ja, ich kann absolut nachvollziehen, dass das oftmals mehr Fragen hinterlässt als es klärt 😉
Das Thema ist super, und es passt auch gut mit dem von Dir angesprochenen Kommunikationsbruch zusammen, dazu machen wir sehr gerne etwas. Ob das schon direkt kommende Woche sein wird, kann ich Dir nicht versprechen, aber in den nächsten zwei, drei Wochen sollte es machbar sein 😊
Und ich denke, dass das Thema auch so wichtig ist, dass es möglichst viele Entwicklerinnen und Entwickler (und natürlich auch andere Rollen!) auf dem Schirm haben sollten, insofern - vielen Dank für die Anregung 😊
@@thenativewebhi eine frage ich muss
Anforderungen nicht nachgekommen bist .
Bitte stelle sicher alle Anforderungen zu erfüllen .
Bin bi & muss in Romeo App das machen
Aber was bedeutet es
Könntest du mir bitte Hilfen danke .
Wir benutzen bei uns in der Firma Jira, mit mehreren Boards und gefühlt mehr mal als 20 (optionale) Felder im Ticket. Dabei sind wir keine große Firma... Ich bin ein Freund von einfachen Strukturen. Wir hatten am Anfang die Issue Verwaltung von Gitlab benutzte, haben dann aber Jira vorgesetzt bekommen mit der Anweisung es zu benutzen. Ähnlich sieht es mit der Dokumentation aus. Ich finde, dass die Dokumentation nah dem Code stehen soll (also im bestenfalls im repo), jetzt benutzen wir Confluence.
Du hast von den Issue Template von Wolkenkit geredet, darf man sie für eigene Projekte übernehmen?
[gr] Das klingt nach der leider durchaus gängigen Vorgehensweise, dass nicht die die Werkzeuge entscheiden, die tagtäglich damit arbeiten, sondern jemand anderes … dass nicht nur die Issues, sondern auch die Dokumentation nah am Code sein sollte, da bin ich ganz bei Dir - alles andere macht es letztlich nur umständlicher, und damit leider auch fehleranfälliger.
Wegen der Templates, die wir für wolkenkit verwenden: Das ist sehr lieb, dass Du fragst, und die könnt Ihr auf jeden Fall sehr gerne verwenden. Freut mich, wenn sie Euch helfen 😊
Die Vorlagen findest Du unter github.com/thenativeweb/wolkenkit/tree/main/.github/ISSUE_TEMPLATE
Ich arbeite aktuell mit Doors und bin auf der Suche nach Tools mit mehr Zukunftssicherheit und Progressivität. Ich finde den Ansatz mit Git Issues sehr interessant. Vor allem, weil man dort glaube ich auch Requirements kommentieren könnte, nachdem sie verfasst wurden. In meinem Kontext ist das System und die SW sehr komplex, alt, groß, monolithisch und verteilt. In größeren Systemen unterteilt man i.d.R. zwischen System- und Software-Requirements, die miteinander verlinkt werden (Traceability). Siehst du eine Möglichkeit, Beziehungen/Verlinkungen mit Git Issues zu realisieren? Nächste Frage: Gibt es Git Issues auch als standalone package zur lokalen Installation?
[gr] Ja, Du kannst die Issues auf GitHub / GitLab untereinander verlinken. Das einfachste ist, in einem Issue die ID des anderen mit einem Hash zu erwähnen (also zB so was wie #123). Das wandeln die beiden Systeme dann jeweils in einen Link um.
Die Issues sind aber kein Feature von Git, sondern wie gesagt von GitHub und GitLab. Die kann man jeweils in einer Enterprise-Edition bekommen, die sich dann auch lokal installieren lässt.
Bei meinen Kunden kommt vor der Besprechung von Anforderungen immer noch eine Einleitung über Kommunikation und Sprache. Viele Missverständnisse und Rückfrageorgien lassen sich durch den klugen Einsatz von Sprache vermeiden. Bei der Vorbereitung eines solchen Vortrags bei einem Kunden vor Ort Abends im Hotelrestaurant stieß ich in der Speisekarte auf den Satz "Salat oder Suppe mit Brot". Dieser findet sich noch heute in meinen Slides. Im schlimmsten Fall wird hier nicht erkannt, dass dieser Satz unterschiedlich aufgefasst werden kann. Im besten Fall liefert der Kontext eine Konkretisierung (Brot steht schon auf den Tisch). Im mittleren Fall muss jemand Fragen "Gibt es Brot nur zur Suppe oder auch zum Salat?". Egal welches Tool: Sprache ist sehr entscheidend und man kann dies gut trainieren und selbst die Qualität der Prosaanforderungen steigen, so dass weniger Zeit mit dem "Verstehen" vergeht.
[gr] Das ist ein spannender Ansatz (und das Beispiel mit der Speisekarte ist super, btw!), und man kann den Wert und die Relevanz einer gemeinsamen Sprache letztlich nicht genug betonen. Das wird zu oft unterschätzt und kommt daher in aller Regel viel zu kurz … und das rächt sich über kurz oder lang.
Es wäre manchmal hilfreich, wenn ihr Beispiele eingeblendet hättet statt nur trocken darüber zu sprechen. Dann könnte man sich das wesentlich besser vorstellen, worüber gerade gesprochen wird.
[gr] Danke für Dein Feedback 😊