1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Agile…

Die Probleme sind andere

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Die Probleme sind andere

    Autor: egal1234 23.05.22 - 15:05

    Der Vorteil von Scrum + agil ist natürlich, dass man kurzfristig reagieren kann. Kein Mensch braucht detailierte Klassendiagramme aus nem V-Modell wo man erstmal Monate nichts anderes macht.
    Zumal man viele Sachen ja auch erst oft beim Implementieren merkt.
    Ich sehe die meisten Probleme aber woanders:

    Architektur. Scrum macht man ja auch über mehrere Teams hinweg. Die einzelnen Teams wissen dann ja nicht wer die Schnittstellen nutzt und wie. Wie die Schnittstellen aussehen ist ja egal. Scrum sagt ja explizit: das Regelt das Team. D.h. es kann schnell ein Wildwuchs entstehen. CamelCase, pascal case, snake case? Und das sind nur die offensichtlichen Sachen. Von Datenstrukturen, etc. mal gar nicht erst zu reden.
    Theoretisch könnte der PO dafür verantwortlich sein. Der soll aber ja nichts von der Implementierung wissen und hat meistens ja eh die Hände voll von den Stakeholdern überhaupt zu erfahren was gewollt ist.

    Tests&QA. Wenn ich PO bin, kann ich das ja venachlässigen, solange das Team features liefert. Unittests mach ich ja als Entwickler. System + Integrationstest bringen erstmal keinen business value. Das Thema fehlt mir halt auch komplett. Zumal sich das Verhalten der software ja dank Agilität schnell ändern kann ist das fürs nicht-manuelle Testen natürlich eine Katastrophe.
    Ich kann als Entwickler ja sagen, ich schreibe keine Systemtests und komme damit in Scrum leicht damit durch.

    Das Team wird informationstechnisch ziemlich kurz gehalten. "Wofür brauchen wir das?" ist nicht wichtig. Wissen wir selbst noch nicht. Mach erstmal ne Version. D.h. man implementiert immer mit sehr wenig Wissen. Dementsprechend schlecht kann die Implementierung sein. Oft gibts dann hinterher PBIs wie "mach xyz schneller"

    DevOps , Tests , Dokumentation , etc wird meistens relativ ungern gesehen. Der PO drückt ja features rein und je eher die fertig sind desto besser. Das wird auch lieber gesehen als die anderen Aufgaben, die ja keinen business value bringen. Als Entwickler ist das daher besser sich auf sowas zu konzentrieren. "Tests machen wir hinterher"

    Verantwortung: meistens heißt es "das Team ist dafür als Ganzes verantwortlich" und damit im Endeffekt niemand. Zudem gibt es auch viele Aufgaben, gearde bei mehreren Scrum-Teams ergäben sich da ja Synergien: Tests, Dokumentation, CI + DevOps, etc. Fehlt komplett die Rolle, da ja jedes Team selbstorganisierend arbeitet.

  2. Re: Die Probleme sind andere

    Autor: supersux 23.05.22 - 15:47

    egal1234 schrieb:
    --------------------------------------------------------------------------------
    > Ich sehe die meisten Probleme aber woanders:
    >
    > Architektur. Scrum macht man ja auch über mehrere Teams hinweg. Die
    > einzelnen Teams wissen dann ja nicht wer die Schnittstellen nutzt und wie.

    Eure Teams reden nicht miteinander und es gibt nur friss-order-stirb?

    > Wie die Schnittstellen aussehen ist ja egal.

    Warum ist das egal? Wofür macht man denn überhaupt Schnittstellen, wenn sie nicht genutzt werden sollen?

    > Scrum sagt ja explizit: das
    > Regelt das Team. D.h. es kann schnell ein Wildwuchs entstehen. CamelCase,
    > pascal case, snake case? Und das sind nur die offensichtlichen Sachen. Von
    > Datenstrukturen, etc. mal gar nicht erst zu reden.

    Wer sonst wäre besser geeignet die detaillierten Vorgaben zu machen?

    > Theoretisch könnte der PO dafür verantwortlich sein. Der soll aber ja
    > nichts von der Implementierung wissen und hat meistens ja eh die Hände voll
    > von den Stakeholdern überhaupt zu erfahren was gewollt ist.

    Wieso sollte ein PO auch dem Team beispielsweise vorschreiben, welche Codeformatierung genutzt wird?


    > Tests&QA. Wenn ich PO bin, kann ich das ja venachlässigen, solange das Team
    > features liefert. Unittests mach ich ja als Entwickler. System +
    > Integrationstest bringen erstmal keinen business value. Das Thema fehlt mir
    > halt auch komplett.

    Warum sollte ein PO das vernachlässigen können? Er steht ja letztlich in der Verantwortung.
    Wieso sollte ein Methodenframework hierauf überhaupt detailliert eingehen?


    > Zumal sich das Verhalten der software ja dank Agilität
    > schnell ändern kann ist das fürs nicht-manuelle Testen natürlich eine
    > Katastrophe.
    > Ich kann als Entwickler ja sagen, ich schreibe keine Systemtests und komme
    > damit in Scrum leicht damit durch.

    Wenn Systemtests für euch keinen Wert haben, warum ist dies ein Problem des Methodenframeworks?


    > Das Team wird informationstechnisch ziemlich kurz gehalten. "Wofür brauchen
    > wir das?" ist nicht wichtig.

    Ganz im Gegenteil, sämtliche Rituale & Co. des Frameworks zielen genau darauf ab, hier ein entsprechendes Verständnis zu schaffen.

    > Wissen wir selbst noch nicht. Mach erstmal ne
    > Version. D.h. man implementiert immer mit sehr wenig Wissen.
    > Dementsprechend schlecht kann die Implementierung sein. Oft gibts dann
    > hinterher PBIs wie "mach xyz schneller"

    Ohne Quantifizierung, was genau "mach schneller" bedeuten soll? Und auch hier wieder: mit welcher Methode würde sowas verhindert?

    > DevOps , Tests , Dokumentation , etc wird meistens relativ ungern gesehen.

    ist auch dies wirklich ein Problem der Methode oder nicht eher doch ein generelles Kulturproblem des Unternehmens ?

    > Der PO drückt ja features rein und je eher die fertig sind desto besser.
    > Das wird auch lieber gesehen als die anderen Aufgaben, die ja keinen
    > business value bringen. Als Entwickler ist das daher besser sich auf sowas
    > zu konzentrieren. "Tests machen wir hinterher"

    warum sollte man auch etwas machen, was keinen business value bringt?
    Ich weiß, worauf du hinauswillst und auch hier ist es kein direktes Problem der Methode. Ein guter Einstieg in solche Diskussionen um "langweilige, nicht feature getriebene oder Querschnittsthemen" fand ich immer: "wenn Stabilität, Security <insert Thema here> keinen Wert hat, dann lassen wir es einfach weg".


    > Verantwortung: meistens heißt es "das Team ist dafür als Ganzes
    > verantwortlich" und damit im Endeffekt niemand.
    Das wäre einen eigenen Aufsatz wert, warum es eine gute Sache ist, ein gut geformtes Team in eine Verantwortung zu nehmen, statt Fingerpointing auf einzelne Entwickler zu betreiben...

    > Zudem gibt es auch viele
    > Aufgaben, gearde bei mehreren Scrum-Teams ergäben sich da ja Synergien:
    > Tests, Dokumentation, CI + DevOps, etc. Fehlt komplett die Rolle, da ja
    > jedes Team selbstorganisierend arbeitet.
    und auch hier wieder: warum sollte eine Methode vorschreiben, was wann wie wo und in welchem Umfang getestet oder dokumentiert wird?

  3. Re: Die Probleme sind andere

    Autor: egal1234 23.05.22 - 15:55

    supersux schrieb:
    --------------------------------------------------------------------------------
    > Eure Teams reden nicht miteinander und es gibt nur friss-order-stirb?

    nö. Natürlich redet man miteinander. Aber eben nur oberflächlich. was heißt hier friss-oder-stirb?
    teilweise definiert der das interface, der zu erst kommt.

    > Warum ist das egal? Wofür macht man denn überhaupt Schnittstellen, wenn sie
    > nicht genutzt werden sollen?

    man kann sie ja nutzen. Aber man müsste dann ja auch Kenntnis über alle Schnittstellen haben und das ist nicht immer der Fall, weil man sich ja nur auf seine aktuelle Teilaufgabe konzentrieren soll

    > Wer sonst wäre besser geeignet die detaillierten Vorgaben zu machen?

    ist natürlich toll, wenn es dann n-Vorgaben gibt, weil jeder Entwickler das anders macht.

    > Wieso sollte ein PO auch dem Team beispielsweise vorschreiben, welche
    > Codeformatierung genutzt wird?

    damit das unternehmensweit einheitlich ist?

    > Warum sollte ein PO das vernachlässigen können? Er steht ja letztlich in
    > der Verantwortung.
    > Wieso sollte ein Methodenframework hierauf überhaupt detailliert eingehen?

    eigentlich ist das Team verantwortlich...

    > Wenn Systemtests für euch keinen Wert haben, warum ist dies ein Problem des
    > Methodenframeworks?

    weil das in anderen Frameworks explit vorgegeben wird.


    > Ganz im Gegenteil, sämtliche Rituale & Co. des Frameworks zielen genau
    > darauf ab, hier ein entsprechendes Verständnis zu schaffen.

    das ist eine komplette Phrase ohne Inhalt.


    > Ohne Quantifizierung, was genau "mach schneller" bedeuten soll? Und auch
    > hier wieder: mit welcher Methode würde sowas verhindert?

    wenn man z.B. vorher weiß wofür man das braucht, wenn sich um solche Anforderungen z.B. ein Architekt kümmert.

    > ist auch dies wirklich ein Problem der Methode oder nicht eher doch ein
    > generelles Kulturproblem des Unternehmens ?

    ich dachte Scrum bringt die Kultur mit ...

    > warum sollte man auch etwas machen, was keinen business value bringt?
    > Ich weiß, worauf du hinauswillst und auch hier ist es kein direktes Problem
    > der Methode. Ein guter Einstieg in solche Diskussionen um "langweilige,
    > nicht feature getriebene oder Querschnittsthemen" fand ich immer: "wenn
    > Stabilität, Security keinen Wert hat, dann lassen wir es einfach weg".

    nochmal. Bei anderen Methoden wird das ja explizit erwähnt.
    Wenn du sagst, das liegt in der Verantwortung des Entwicklers, bzw. in der Unternehmenskultur, während das beim vorigen Konzept mit eingeplant ist, dann fehlt da im Scrum halt etwas.

    > Das wäre einen eigenen Aufsatz wert, warum es eine gute Sache ist, ein gut
    > geformtes Team in eine Verantwortung zu nehmen, statt Fingerpointing auf
    > einzelne Entwickler zu betreiben...

    Ich rede ja nicht von Fingerpoiting sondern von Zuständigkeit

    > und auch hier wieder: warum sollte eine Methode vorschreiben, was wann wie
    > wo und in welchem Umfang getestet oder dokumentiert wird?

    weil es integraler Bestandteil von Softwareentwicklung ist. Wozu ein Framework, wenn alles darin wischi-Waschi ist?

  4. Re: Die Probleme sind andere

    Autor: chseidel 23.05.22 - 21:18

    Dazu gibt es - auch seit Jahrzehnten - erfolgreich genutzte Ansätze. Stichworte sind LeSS und Spotify.

    Wichtig bezüglich Architektur sind eine vernünftige Kleinteiligkeit (Microservices).
    Bei Abhängigkeiten zu anderen Teams und zur Langfristabstimmung eventuell Big Room Planning.

  5. Re: Die Probleme sind andere

    Autor: supersux 23.05.22 - 21:26

    egal1234 schrieb:
    --------------------------------------------------------------------------------
    > supersux schrieb:
    > ---------------------------------------------------------------------------

    > > ist auch dies wirklich ein Problem der Methode oder nicht eher doch ein
    > > generelles Kulturproblem des Unternehmens ?
    >
    > ich dachte Scrum bringt die Kultur mit ...
    >

    Die Aussage ist so wichtig, dass ich mir erlaube, sie mal ganz nach vorne zu stellen.
    Dies ist genau der Kardinalfehler, der leider in vielen Unternehmen gemacht wird.
    Es wird einfach eine neue Arbeitsmethodik übergestülpt, ohne überhaupt am Mindset zu arbeiten.
    Wie ich an anderer Stelle hier schon schrieb, ist diese Denkweise leider viel zu oft anzutreffen:
    "3 Tage Scrum-Schulung, jetzt bist du ScrumMaster, du arbeitest jetzt in diesem Team" und das noch möglichst nicht in Vollzeit sondern es wird noch erwartet die Rolle nebenher auszufüllen...und am Ende wird sich gewundert, warum nicht das erhoffte Ergebnis erzielt wird und die Methode ist grade bei den direkt betroffenen schlicht verbrannt.


    > -----
    > > Eure Teams reden nicht miteinander und es gibt nur friss-order-stirb?
    >
    > nö. Natürlich redet man miteinander. Aber eben nur oberflächlich. was heißt
    > hier friss-oder-stirb?
    > teilweise definiert der das interface, der zu erst kommt.

    Und wer hindert euch in Scrum daran, mit allen schon bekannten Clients eine Schnittstelle zu designen?

    > > Warum ist das egal? Wofür macht man denn überhaupt Schnittstellen, wenn
    > sie
    > > nicht genutzt werden sollen?
    > man kann sie ja nutzen. Aber man müsste dann ja auch Kenntnis über alle
    > Schnittstellen haben und das ist nicht immer der Fall, weil man sich ja nur
    > auf seine aktuelle Teilaufgabe konzentrieren soll

    Wer sagt das man sich nur stur auf seine Teilaufgabe fokussieren soll? Ganz im Gegenteil, das Ziel ist, dass das Team Gesamtverantwortung für sein Ergebnis übernimmt.

    > > Wer sonst wäre besser geeignet die detaillierten Vorgaben zu machen?
    >
    > ist natürlich toll, wenn es dann n-Vorgaben gibt, weil jeder Entwickler das
    > anders macht.

    Du hattest es doch schon selbst geschrieben: "das Team regelt das". Bist du denn wirklich der Meinung, das euer Team sich nicht einigen könnte und sich die einzelnen Entwickler nicht dran halten? Und wenn sie dies bei gemeinsam erarbeiteten Regeln nicht tun, warum sollten sie dies dann bei Regeln, welche ihnen vom Elfenbeinturm vorgesetzt werden?

    > > Wieso sollte ein PO auch dem Team beispielsweise vorschreiben, welche
    > > Codeformatierung genutzt wird?
    >
    > damit das unternehmensweit einheitlich ist?

    Unternehmensregeln gelten doch auch weiterhin und sind ebenfalls unabhängig von der jeweiligen Arbeitsmethodik in einem Team? Wenn die Unternehmensregeln z.B. eine bestimmte Programmiersprache vorschreibt, dann kann das Team natürlich nicht (so einfach) auf was anderes wechseln. Auch wenn aufsichtsrechtliche Hindernisse im Weg stehen, sind bestimmte Praktiken a la Continuous Deployment eher nicht umzusetzen und enden dann z.B. beim c-Delivery. Und wenn die Unternehmensvorschriften bis auf die Codeformatierung runtergehen, dann ist das nun mal auch so.

    (Aber um auch nochmal zurückzukommen: der PO ist dennoch schlicht die falsche Rolle zur Ausarbeitung dieser unternehmensweiten Regeln.)

    > > Warum sollte ein PO das vernachlässigen können? Er steht ja letztlich in
    > > der Verantwortung.
    > > Wieso sollte ein Methodenframework hierauf überhaupt detailliert
    > eingehen?
    >
    > eigentlich ist das Team verantwortlich...

    In diesem Kontext ist der PO ist verantwortlich (für den Value des Products)

    > > Wenn Systemtests für euch keinen Wert haben, warum ist dies ein Problem
    > des
    > > Methodenframeworks?
    > weil das in anderen Frameworks explit vorgegeben wird.

    Bewusst etwas polemisch gefragt:
    D.h. ihr erstellt unnütze Dinge, weil euch ein Methodenframework das sagt? Was ist wenn, Dinge gefordert werden, die in euerem Methodenframework nicht explizit vorkommen? Lasst ihr die dann weg?

    Oder etwas weniger polemisch: Wer oder was hindert euch daran, Systemtests aufzunehmen?

    > > Ganz im Gegenteil, sämtliche Rituale & Co. des Frameworks zielen genau
    > > darauf ab, hier ein entsprechendes Verständnis zu schaffen.
    >
    > das ist eine komplette Phrase ohne Inhalt.

    Definition of Ready, Sprint Goal, Product Goal, Planning, Review, Backlog Refinement...jedes Einzelne dient auch zum Verständnis von Team<>Business(verstreten durch PO bzw. im Review auch direkt vom "Kunden")

    > > Ohne Quantifizierung, was genau "mach schneller" bedeuten soll? Und auch
    > > hier wieder: mit welcher Methode würde sowas verhindert?
    >
    > wenn man z.B. vorher weiß wofür man das braucht, wenn sich um solche
    > Anforderungen z.B. ein Architekt kümmert.

    Kann leider nicht ganz nachvollziehen, was du meinst. Entweder ist der Architekt Teil des Teams oder nicht. Im letzteren Fall verhindert aber doch das Methodenframework auch nicht die Einbeziehung desselbigen?



    > > warum sollte man auch etwas machen, was keinen business value bringt?
    > > Ich weiß, worauf du hinauswillst und auch hier ist es kein direktes
    > Problem
    > > der Methode. Ein guter Einstieg in solche Diskussionen um "langweilige,
    > > nicht feature getriebene oder Querschnittsthemen" fand ich immer: "wenn
    > > Stabilität, Security keinen Wert hat, dann lassen wir es einfach weg".
    >
    > nochmal. Bei anderen Methoden wird das ja explizit erwähnt.
    > Wenn du sagst, das liegt in der Verantwortung des Entwicklers, bzw. in der
    > Unternehmenskultur, während das beim vorigen Konzept mit eingeplant ist,
    > dann fehlt da im Scrum halt etwas.

    Nicht wirklich, Scrum macht (wie viele andere Frameworks übrigens auch) nur keine expliziten Vorgaben über konkret zu erledigende Arbeit. (Siehe auch die Antwort zu den "Systemtests")


    > > Das wäre einen eigenen Aufsatz wert, warum es eine gute Sache ist, ein
    > gut
    > > geformtes Team in eine Verantwortung zu nehmen, statt Fingerpointing auf
    > > einzelne Entwickler zu betreiben...
    >
    > Ich rede ja nicht von Fingerpoiting sondern von Zuständigkeit

    D.h. bei euch sind wirklich einzelne Entwickler alleine für ein Produkt zuständig? O_o

    > > und auch hier wieder: warum sollte eine Methode vorschreiben, was wann
    > wie
    > > wo und in welchem Umfang getestet oder dokumentiert wird?
    >
    > weil es integraler Bestandteil von Softwareentwicklung ist. Wozu ein
    > Framework, wenn alles darin wischi-Waschi ist?

    Weil es ein Methodenframework für Agile Entwicklung (vornehmlich, aber eben nicht nur Softwareentwicklung) ist. Es macht dazu eben bewusst keine strikten Vorgaben, wann was wie in welcher Form zu erledigen ist. Das ist Sache des jeweiligen Teams, wenn dies z.B. bestimmt, dass für jedes PBI Unit- & Integrationstests zu schreiben sind, dann ist das so...wenn es bestimmt, das auch bestimmte QualityGates im CodeAnalysetool der Wahl zu durchlaufen sind, dann ist das so...wenn es bestimmt, das technische Entwurfsentscheidungen direkt begleitend im Tech-Wiki zu dokumentieren sind, während das Nutzerhandbuch in Abstimmung mit dem PO besser als eigenes Item noch etwas weiter hinten im Backlog liegt...alles vollkommen okay.


    Darf ich fragen, in welchem fachlichen Umfeld du dich bewegst und nach welcher Methode entwickelt wird?

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Informatiker*in Entwicklung von Simulationssoftware
    Fraunhofer-Institut für Kurzzeitdynamik, Ernst-Mach-Institut EMI, Efringen-Kirchen, Freiburg
  2. DevOps Software Engineer im Bereich "Software Factory" (m/w / divers)
    Continental AG, Frankfurt
  3. C# / .NET Softwareentwickler / Programmierer (m/w/d)
    PM-International AG', Speyer
  4. SAP Basis Administrator (m/w/x)
    über duerenhoff GmbH, Raum Karlsruhe, Remote

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. SilentiumPC Navis F240 ARGB 240 für 79,90€ + 6,99€ Versand und Cooler Master SK620 für...
  2. 5€ inkl. Versand (Vergleichspreis 10,98€)
  3. 149€ + Cashback-Aktion von Acer (Bestpreis!)
  4. 39€ (Vergleichspreis 47€)


Haben wir etwas übersehen?

E-Mail an news@golem.de