@vogtsburger  schrieb:   @latti schrieb: ... Man kann auch nur einzelne Sessions besuchen ...   ... erfahrungsgemäß gibt es fast nichts, was man nicht auch falsch verstehen könnte 😉   ... ich nehme jetzt einfach mal an, dass Folgendes gemeint ist:   "... man muss nicht mehrere Sessions besuchen. Man könnte sich auch auf diese eine Session beschränken" 😉   Exakt auch das ist möglich. Jede mathematisch denkbare Form des Besuches ist möglich: von 0 (= kein Besuch 😉) bis 20 (= in jede Session kurz reinschauen und alle gemeinsamen Sessions besuchen). ... Mehr anzeigen

@m_brunzendorf schrieb:   @Fischermaen  schrieb: @m_brunzendorf Auf eine DATEV Software strömen von vielen Seiten Änderungswünsche zu: Natürlich von den Kunden, dann vom Gesetzgeber und vom Einsatz-Umfeld (Eine verwendete Fremd-Software hat ein Sicherheitsproblem, oder wird nicht mehr weitergepflegt, usw.) Alle diese Anforderungen müssen gemäß ihrer Wichtigkeit priorisiert werden. Da kann dann ein Kunden-Wunsch auch einmal "weiter hinten" landen. Das ist einerseits verständlich und andererseits, wenn es sich um Jahre handelt, leider sehr ärgerlich. Da bin ich völlig bei Dir!    @m_brunzendorf  schrieb: @Fischermaen  schrieb: Und dann noch der Klassiker: Zwei Kunden äußern konträre Wünsche. Wie geht man damit um... Da will ich nicht in der Haut der Person stecken, die das dann entscheiden muss.   Je nach dem, was das eventuell für Wünsche wären und wie weit dort die Eingriffe in die Software sind und wieviele Anwender sich dies oder jenes wünschen:   Lösung: beides einbauen mit einem "Haken" innerhalb des Programms für den Anwender:   Du willst die Funktion: Bitte Häkchen setzen. Die willst die Funktion nicht: Bitte Häkchen weglassen bzw. nicht setzen.   Ich vermute, das ist niemals eine Option? Das ist in der Software-Entwicklung der Vorhof zur Hölle. Mit einer solchen Stelle mag das noch gehen, aber sobald das öfters vorkommt, vielleicht auch noch mit gegenseitigen Abhängigkeiten, dann kann das sehr schnell eine Software unwartbar machen.   ... Mehr anzeigen

@m_brunzendorf Ja, das kann ich verstehen. Manchmal entsteht bestimmt dieser Eindruck. Auf eine DATEV Software strömen von vielen Seiten Änderungswünsche zu: Natürlich von den Kunden, dann vom Gesetzgeber und vom Einsatz-Umfeld (Eine verwendete Fremd-Software hat ein Sicherheitsproblem, oder wird nicht mehr weitergepflegt, usw.) Alle diese Anforderungen müssen gemäß ihrer Wichtigkeit priorisiert werden. Da kann dann ein Kunden-Wunsch auch einmal "weiter hinten" landen.   Und dann noch der Klassiker: Zwei Kunden äußern konträre Wünsche. Wie geht man damit um... ... Mehr anzeigen

@vogtsburger schrieb:   ... man gewinnt den Eindruck, dass jeder unser Wünsche als Datev-Anwender, und sei er auch noch so klein, eine große Maschinerie bzw. eine ganze Mann- und Frauschaft an Software-Spezialisten in Bewegung setzt, die jeweils eigentlich einen Berg von anderen dringenden Entwicklungs-Themen auf dem Tisch liegen haben und die vor jeder (agilen ?) Besprechung oder (Scrum ?) Session in Panik geraten, welche neuen Anforderungen jetzt wohl wieder auf sie zukommen. Ein Kunden-Wunsch wird ebenfalls. Durch Scrum ist eben nicht mehr ein "Berg" von Anforderungen, die vor dem Entwicklungsteam liegen, sondern genau so viele Anforderungen, wie das Team im "Sprint" (so nennt sich ein Entwicklungs-Zyklus = ca. 2 bis 4 Wochen) abarbeiten kann. Jedes Anforderungspaket wird vor der Priorisierung vom Entwicklungsteam geschätzt. So kann dann im Laufe der Zeit ziemlich genau festgelegt werden, wie viele Anforderungen in einem Sprint umgesetzt werden können. Das Team hat somit keine Angst vor Besprechungen, weil ein Kunden-Wunsch nicht einfach sofort dem Team zur Umsetzung "vorgeworfen" wird, sondern vom Product Owner anhand seiner Entscheidungskriterien priorisiert wird.   Software-Entwicklung ist ja vielleicht nicht nur ein Handwerk, sondern auch ein kreativer Akt.  ... und Kreativität lässt sich eben nicht (immer) auf Kommando herausprügeln oder -kitzeln. Ja, das ist richtig. Man braucht aber nicht für jede Zeile Source-Code Kreativität. Diese wird vielmehr bei Problemlösungen oder Fehlersuche benötigt. Viel Zeit in geht in der Programmierung mit handwerklich guter Abarbeitung der Aufgaben auf. Deshalb ist das Üben (natürlich auch einmal während der Arbeitszeit oder auf einem Code Retreat am Wochenende) auch so wichtig. Software-Entwickler müssen ihr Handwerk beherrschen und immer wieder verbessern und dazu lernen. Ich bin seit 33+ Software-Entwickler bei DATEV und die Veränderungsgeschwindigkeit in der Software Entwicklung wird immer größer. Daher ist permanentes Lernen immer wichtiger geworden. ... Mehr anzeigen

... ich finde es sehr schön und hilfreich, dass ein Insider (ein '@Fischermaen 's Friend') uns ein wenig 'an die Hand nimmt' und uns durch ein Kaleidoskop in die Datev-Entwicklung schauen lässt   Danke ! Das freut mich sehr. Ich denke Transparenz hilft gegen Missverständnisse und falsche Vorstellungen.        OT (= Off topic): "Fischermän's Friends" hieß meine Band zu Beginn, in der ich 32 Jahre Rock- und Pop-Musik gemacht habe. 😎 ... Mehr anzeigen

@jjunker schrieb   Erstmal Respekt, dass Sie nach meiner "verbalen" Ohrfeige, Entschuldigung dafür hier weiter mitmachen. Ich habe es nicht als Ohrfeige empfunden. Man muss Dinge klar ansprechen können und nichts anderes haben Sie gemacht.     Der Mahagonischrank war aber auch ein Ball auf dem 11 Meter Punkt vor dem leer Tor.  Ein sehenswerter Torschuss, über den ich sehr geschmunzelt habe, vor allem, weil er auch (manche Dinge betreffend) stimmt.   Das mit dem drüber gucken sollte auch bei Software und der Kommunikation zur selbige Standard sein.@metalposaunist findet ja gefühlt jedem Tag irgendeine kleine oder große Inkonsistenz....  DATEV befindet sich gerade in einem großen Wandel. Die Strategie, alles auf Online-Produkte umzustellen, bedeutet auch für die Mitarbeiter eine große Herausforderung. Zudem haben wir auch festgestellt, dass es Dinge gibt, die wir verbessern können. Das geht allerdings nicht von "jetzt auf gleich" - gerade grundlegende Änderungen bringen ja auch erst einmal alles durcheinander.   Nachdem (in meinen Augen) vielleicht noch ein falsches Bild des Software Entwicklers existiert, würde ich gerne einmal kurz beschreiben, welche Rollen es in einem Software-Entwicklungs-Team (für Online-Programme) gibt und was deren Aufgabe ist:   Product Owner: Verantwortet das Produkt. Bringt die Anforderungen (= Aufgabenpakete für das Entwicklungsteam) in eine Reihenfolge. Requirements Engineer: Ermittelt die Anforderungen an das Produkt. Hat das fachliche Know-How und kennt die Kunden. Dabei werden auch sogenannte "nicht-funktionale" Anforderungen ermitteln. Das sind Dinge, wie gewünschte Performance, maximaler Speicherverbrauch, Sicherheitsanforderungen etc... Software Architect: Legt die technischen Rahmenbedingungen für die Software fest. Dazu zählen Schnittstellen zu anderen Programmen und auch der Aufbau der Software. Software Engineer: (Der "Software Entwickler" über den in diesem Thread oft gesprochen wurde): Setzt die Aufgabenpakete unter Beachtung aller Rahmenbedingungen technisch um. Ein fachliches Know-How ist dabei nicht erforderlich. Vielmehr ist die technische Exzellenz hier sehr wichtig, damit die Software auch sicher, schnell und robust funktioniert. Test Engineer: Schafft die Rahmenbedingungen, damit die automatisierten Tests der Software laufen können.   Das ist nur eine grobe Beschreibung, die aber hoffentlich für etwas mehr Klarheit sorgt. Bestimmt sind aber auch wieder ein paar Chancen für "Elfmeter" dabei. 😉 ... Mehr anzeigen

@Fischermaen  schrieb Genau der fehlende Bezug zur Fachlichkeit ermöglicht erst den offenen Blick. Das Lernen von neuen Dingen wird in keinem Job der Welt direkt am Kunden-Objekt durchgeführt. Kein Schreinermeister wird seinen Lehrling das Hobeln am Mahagonie-Schrank seines Kunden üben lassen. Das ist in der Software-Entwicklung nicht anders.  Wie ist diese Aussage mit der MVP~Strategie der Datev vereinbar? Das eine hat mit dem anderen nichts zu tun. Seine Fertigkeiten im Handwerk (= Üben als Software Entwickler) zu verbessern, bedeutet nicht, dass man keine MVPs erstellt. Man übt ja nicht 40 Stunden in Vollzeit...   PS Ich muss dich leider korrigieren, in unserer Branche ist es üblich, direkt am ‚Kunden-Objekt“ zu arbeiten. Aber, dann schaut mit Sicherheit noch einmal eine erfahrene Person über das "Kunden-Objekt", bevor es dieser bekommt.    ... Mehr anzeigen

... dieses Schlüsselloch zu einer Datev-Parallelwelt kannte ich noch nicht   ... keine Ahnung, ob es nur eine Fata Morgana ist oder sie tatsächlich existiert Keine Fata Morgana, existiert wirklich. "Global Day of Code Retreat (GDCR)" wurde schon 3 Mal von Mitarbeitern der DATEV organisiert.    Mich würde interessieren, was da so 'gecodet' wird beim "Global Day of Code Retreat" (GDCR)  Übungsaufgaben. Nur damit ist man frei von fachlichen Zwängen und kann neue Dinge üben.   ... könnte man nicht den hochbegabten, jungen Codern mal ein paar kleine, nervende Datev-Software-Problemchen als eine Art Prüfungs-Aufgabe auf den Tisch legen ? Nicht nur "junge" Coder. Das Alter hat nichts mit Begabung oder Fähigkeiten zu tun. Leidenschaft für den Beruf und Fachwissen ist vom Alter völlig unabhängig. Genau der fehlende Bezug zur Fachlichkeit ermöglicht erst den offenen Blick. Das Lernen von neuen Dingen wird in keinem Job der Welt direkt am Kunden-Objekt durchgeführt. Kein Schreinermeister wird seinen Lehrling das Hobeln am Mahagonie-Schrank seines Kunden üben lassen. Das ist in der Software-Entwicklung nicht anders.  Die nervenden DATEV-Software-Probleme werden im Nachgang zu einem solchen Code Retreat von hochmotivierten Codern angegangen, die freiwillig an einem Samstag zum Lernen in der DATEV waren. 😉 ... Mehr anzeigen

Der "Fullstack"-Entwickler kennt den kompletten "Stack" der Entwicklung. Mit einem Stack bezeichnen wir die Gesamtheit an Tools (Entwicklungsumgebung, Bau- und Verteilungstools), Programmiersprache und verwendete Bibliotheken (Funktionalitäten, die entweder gekauft oder aus dem Open Source Bereich genutzt werden). In der Online (korrekter Cloud Native) Entwicklung unterscheiden wir 2 Stacks: Frontend und Backend. Grob gesagt ist das Frontend die Software, die der Kunde sieht und das Backend die Server im Hintergrund, die die Funktionalität erbringen. Beide Stacks unterscheiden sich in Anforderungen und Tools (können aber auch ziemlich identisch sein).    Ein "Fullstack"-Entwickler ist jemand, der sowohl Frontend als auch Backend programmieren kann.   Von jedem erfahrenen Entwickler erwarten wir, dass er Wissen weitergibt, und somit als Schnittstelle fungiert. ... Mehr anzeigen

@jjunker Auch wenn der Kunde (meist) nichts von der Code-Qualität sieht, ist diese dennoch sehr wichtig für ihn. Die Code-Qualität hat z.B. Auswirkungen auf die Performance, Stabilität, Robustheit (u.v.m.) der Software. Es ist mir natürlich völlig klar, dass Features das sind, was der Kunde braucht, aber diese müssen - neben der fehlerfreien Funktionalität - auch technisch gut umgesetzt sein, damit der Kunde seine echte Freude daran hat.   Aber ich bin auch völlig bei Ihnen (oder wäre das Du auch in Ordnung?), dass die Verzahnung der Funktionen zu einem guten Workflow die Königs-Disziplin und auch unser Ziel ist.     ... Mehr anzeigen

@jjunker Ich habe diesen Thread leider übersehen. Nun liest einer der (inzwischen 1.100 😄) aktiven Entwickler. Ich oute mich auch gleich einmal als der Gründer dieser Community. ... Mehr anzeigen