Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Mitarbeiterführung: Fünf Faktoren…

Was an SCRUM kaputt ist

  1. Thema

Neues Thema Ansicht wechseln


  1. Was an SCRUM kaputt ist

    Autor: ubuntu_user 23.08.19 - 10:05

    Generell ist scrum/agiles manifest/usw. ja eine Geschichte, die von Entwicklern kam.
    SCRUM hat ja eine Menge positive Sachen:
    - CI ist unheimlich wichtig
    - kurze Sprints mit jeweils shippable Ergebnissen
    - wenig "oh das wollte ich ja gar nicht" Ergebnisse

    Was unheimlich negativ ist:
    - Teamleiter macht den SCRUM Master. Wenn man sich die Aufgaben anguckt (https://www.it-agile.de/fileadmin/agile_review/einzelartikel/Was_MachtDerScrumMasterDenGanzenTagArtikelagilereview201501hw.pdf) dann ist ein voriger Teamleiter eine absolute Fehlbesetzung. Der wäre dann eher PO. Aber selbst wenn der SCRUM Master so agiert wie erwartet, besteht immer die Gefahr, dass der SCRUM Master keine Ahnung hat was eigentlich das Problem ist.

    - Das Team bekommt eigentlich immer nur kurze Informationen was gemacht wird. Längerfristige Planungen sind so eigentlich nicht vorgesehen. Gearde da das Backlog ja eher vom PO betreut wird und auch nicht alles bearbeitet werden muss, häuft sich da viel Müll an und der Entwickler braucht sich das ja nicht anschauen, weil das ja vllt eh nicht genutzt wird. Dann heißt es auf einmal die Software soll auch auf Linux-Servern/WindowsDesktop/Android laufen. In den bisherigen Anforderungen war das aber nie vorgesehen.

    - "Das Team organisiert sich selbst" ist die ideale Ausrede für "Führungskräfte" einfach gar nichts mehr zu machen und jegliche Probleme komplett zu leugnen.

    - Es wird noch viel mehr dazu tendiert nur noch business value Sachen zu machen. Entwickler werden meistens dazu gedrängt die "schnelle" Lösung zu machen, damit man was zeigen kann im Review. Eigentlich muss der Entwickler sehr viel mehr Selbstdisziplin haben als bei anderen Arbeitsweisen und weniger Wert auf Fortschritt als auf Qualität legen.

    - Arbeitspakete werden ja vom PO geschrieben. Der ist natürlich immer weiter weg vom Entwicklungsprozess, da er ja nur die Anforderungen schreibt und die Implementierungen nicht kennt und auch nicht Vorgeben soll.

    - Aus genannten Punkten leidet die Architektur. Niemand ist da wirklich für verantwortlich, außer "dem Team". Die Arbeit vom Team sieht man aber nur wenn man im Review Ergebnisse zeigt. Da wird dann der Entwickler belohnt, der schnell was zusammenfrickelt. Der Entwickler, der Infrastruktur (wo wenig Ergebnisse bei raus kommen) macht oder gründlich arbeitet zeigt dann im Review weniger. Tests sind dafür ja auch weniger wichtig, denn die verhindern ja ggf. das Sprintgoal

  2. Re: Was an SCRUM kaputt ist

    Autor: Serenity 23.08.19 - 13:11

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > - Teamleiter macht den SCRUM Master. Wenn man sich die Aufgaben anguckt
    > (www.it-agile.de dann ist ein voriger Teamleiter eine absolute
    > Fehlbesetzung. Der wäre dann eher PO. Aber selbst wenn der SCRUM Master so
    > agiert wie erwartet, besteht immer die Gefahr, dass der SCRUM Master keine
    > Ahnung hat was eigentlich das Problem ist.

    Der Scrum-Master ist eine neue Position, die normalerweise nicht der Teamleiter macht. Seine Aufgaben bestehen daran, das Scrum Framework bzw. die agile Sichtweise in das Unternehmen einzubringen und dem Team (PO, DevTeam) dabei zu helfen, Scrum zu verwenden. Dazu gilt er auch noch als "Severant Leader", also jemand, der mehr dem Team dient als dieses anführt. So sorgt er sich unter anderem darum, Hindernisse abzuschaffen. Das ist, gerade am Anfang einer agilen Transformation ein Full-Time-job.
    Ein Teamleiter mit Führungsverantwortlichkeiten hat meist vollkommen andere Aufgaben.

    > - Das Team bekommt eigentlich immer nur kurze Informationen was gemacht
    > wird. Längerfristige Planungen sind so eigentlich nicht vorgesehen. Gearde
    > da das Backlog ja eher vom PO betreut wird und auch nicht alles bearbeitet
    > werden muss, häuft sich da viel Müll an und der Entwickler braucht sich das
    > ja nicht anschauen, weil das ja vllt eh nicht genutzt wird. Dann heißt es
    > auf einmal die Software soll auch auf Linux-Servern/WindowsDesktop/Android
    > laufen. In den bisherigen Anforderungen war das aber nie vorgesehen.

    Der PO ist wie der Name schon sagt, der Produkt Owner und kümmert sich (im Grunde) um das Verwalten der Anforderungen. Der ganze "Müll" wird meist auch vom Produkt Owner nicht näher spezifiziert, weil das meist ganz unten im Backlog landet. Ein guter Product Owner würde allerdings nicht den Müll aufnehmen, sondern mehr nach dem "Pull-Prinzip" arbeiten, indem er zu den Stakeholdern selber geht und sich die Anforderungen abholt. Gutes Stakeholder-Management ist da Pflicht. Ich kenne POs, die nach dem "wer am lautesten schreit, gewinnt"-Prinzip arbeiten. Das widerspricht aber die Aufgabe des POs als "Product Maximizer".

    Randbedienungen wie die Systemwahl sollten (egal ob Agil oder klassisch) direkt am Anfang festgelegt werden. Soll eine Software plötzlich auf Linux portiert werden, auch wenn sie dafür nicht ausgelegt ist, kann das ein Problem darstellen. Ein guter PO sollte solche Randbedingungen mit den Stakeholder direkt ansprechen und aufnehmen.

    Ansonsten sollte der PO die Vision des Produktes auch mit dem Entwickler teilen. Ein gute Praxis ist es, ein "Release Planning" durchzuführen, aber in Scrum kein Muss.

    > - "Das Team organisiert sich selbst" ist die ideale Ausrede für
    > "Führungskräfte" einfach gar nichts mehr zu machen und jegliche Probleme
    > komplett zu leugnen.

    Führungskräfte haben nicht nur die Aufgabe, Arbeitspakete an Mitarbeiter zu adressieren und diese zu bewerten. Probleme können auch angesprochen werden und werden dann vom Scrum-Master an den Personalverantwortlichen weitergegeben (Hinweis: Good Practice ist es, dass der Personalverantwortliche kein Teil vom Scrum-Team ist). Wenn also Streitigkeiten und Probleme innerhalb des Teams (z.b. persönliche Differenzen, "Rebellen") nicht durch den Scrum-Master gelöst werden können, dann wird er diese an den Personalverantwortlichen gelöst. Probleme mit Produkten und der Umsetzung sind eher Aufgaben vom PO und Scrum-Master.

    > - Es wird noch viel mehr dazu tendiert nur noch business value Sachen zu
    > machen. Entwickler werden meistens dazu gedrängt die "schnelle" Lösung zu
    > machen, damit man was zeigen kann im Review. Eigentlich muss der Entwickler
    > sehr viel mehr Selbstdisziplin haben als bei anderen Arbeitsweisen und
    > weniger Wert auf Fortschritt als auf Qualität legen.

    Falsch, es ist eher der Fall, dass durch Scrum die Qualität im Gegensatz zum klassischen PjM steigt. Das liegt daran, dass man im Team eine sogenannte DoD definiert, die viele Qualitätsanforderungen enthält. Ein PBI ist somit erst dann fertig, wenn alle Aspekte vom DoD erfüllt werden.
    Im klassischen PjM ist das doch eher der Fall: Schnell alle Anforderungen durcharbeiten, Unit-Test und andere Tests machen wir dann, wenn wir alles fertig haben und noch Zeit übrig bleibt (also nie ;) )

    > - Arbeitspakete werden ja vom PO geschrieben. Der ist natürlich immer
    > weiter weg vom Entwicklungsprozess, da er ja nur die Anforderungen schreibt
    > und die Implementierungen nicht kennt und auch nicht Vorgeben soll.

    Naja, er ist die Schnittstelle von den Entwicklern und den Stakeholdern und der PO beteiligt sich fast immer am Sprint Planning. Dahingehend ist er zum einen sehr gut mit den Entwicklungen des Teams vertraut und kennt die einzelnen Schritte. Ein guter PO geht auch mal als stiller Beobachter zum Daily und wirft des öfteren einen Blick auf das Sprint Backlog.
    Selten ist ein PO irgendeiner, der BWL studiert hat. Ein PO muss Ahnung von der Materie haben, ansonsten hättest du recht: Er kennt dann die Implementierung nicht. Aber dann ist er als PO ungeeignet.
    Der PO ist übrigens für das Produkt-Inkrement haftbar ("accountable"), dementsprechend ist es sehr blöd, wenn er nicht weiß, was das DevTeam macht.

    > - Aus genannten Punkten leidet die Architektur. Niemand ist da wirklich für
    > verantwortlich, außer "dem Team". Die Arbeit vom Team sieht man aber nur
    > wenn man im Review Ergebnisse zeigt. Da wird dann der Entwickler belohnt,
    > der schnell was zusammenfrickelt. Der Entwickler, der Infrastruktur (wo
    > wenig Ergebnisse bei raus kommen) macht oder gründlich arbeitet zeigt dann
    > im Review weniger. Tests sind dafür ja auch weniger wichtig, denn die
    > verhindern ja ggf. das Sprintgoal

    Moment: Das DevTeam zeigt ihre Ergebnisse, nicht jeder Entwickler. Die Arbeit wird immer vom gesamten Team bearbeitet, es findet da keine "PBI-Zuweisung an einzelne Mitarbeiter" statt.
    Im Planning II / Daily werden allerdings die Tasks der jeweiligen PBIs definiert, wo auch Entwickler "Besitzer" der Task sind (sie schieben die Tasks ja in den "In Progress" Bereich und bearbeiten diese). Ein Task sollte in der Regel maximal 1 Tag dauern. Daran kann man sehen, wer mehr oder wer weniger Arbeit macht. Auch ein Architekt sollte tasks definieren, häufig kann man auch in der DoD aufnehmen, dass die Architekturdokumentation aktualisiert wurde.

    Wenn Tests zum Sprintziel nicht fertig werden, dann hat das Team sich verschätzt und das PBI (mit den fehlenden Tests) wird im nächsten Sprint behandelt. Klar, so kann man (mit minderer Qualitätsanforderungen) das Sprintziel erreichen, aber das PBI wandert dann in den nächsten Sprint und dort wird dann weniger behandelt und das Sprintziel "verringert". Dem PO bringt das nichts, denn er legt nicht den Umfang fest, was im nächsten Sprint gemacht wird, sondern nur die Reihenfolge.

  3. Re: Was an SCRUM kaputt ist

    Autor: ubuntu_user 23.08.19 - 13:46

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Der Scrum-Master ist eine neue Position, die normalerweise nicht der
    > Teamleiter macht.

    ach ne.
    ich zitiere mal aus dem Text:
    >Die Teamleiter wurden in diesem Sprint zu Scrum Mastern, die für flüssige Arbeitsabläufe und die Problembehebung innerhalb der Teams verantwortlich waren.


    > Ein guter Product Owner würde allerdings nicht den Müll
    > aufnehmen, sondern mehr nach dem "Pull-Prinzip" arbeiten, indem er zu den
    > Stakeholdern selber geht und sich die Anforderungen abholt. Gutes
    > Stakeholder-Management ist da Pflicht. Ich kenne POs, die nach dem "wer am
    > lautesten schreit, gewinnt"-Prinzip arbeiten. Das widerspricht aber die
    > Aufgabe des POs als "Product Maximizer".

    natürlich. Wenn alle sich vorbildlich verhalten klappt auch Wasserfall.
    Ich finde das eher schwammig formuliert, wie der PO mit dem Backlog umgehen soll.

    > Randbedienungen wie die Systemwahl sollten (egal ob Agil oder klassisch)
    > direkt am Anfang festgelegt werden. Soll eine Software plötzlich auf Linux
    > portiert werden, auch wenn sie dafür nicht ausgelegt ist, kann das ein
    > Problem darstellen. Ein guter PO sollte solche Randbedingungen mit den
    > Stakeholder direkt ansprechen und aufnehmen.

    Wenn die Stakeholder aber dann z.B. Chefs sind wird das schwer.

    > Führungskräfte haben nicht nur die Aufgabe, Arbeitspakete an Mitarbeiter zu
    > adressieren und diese zu bewerten. Probleme können auch angesprochen werden
    > und werden dann vom Scrum-Master an den Personalverantwortlichen
    > weitergegeben (Hinweis: Good Practice ist es, dass der
    > Personalverantwortliche kein Teil vom Scrum-Team ist). Wenn also
    > Streitigkeiten und Probleme innerhalb des Teams (z.b. persönliche
    > Differenzen, "Rebellen") nicht durch den Scrum-Master gelöst werden können,
    > dann wird er diese an den Personalverantwortlichen gelöst. Probleme mit
    > Produkten und der Umsetzung sind eher Aufgaben vom PO und Scrum-Master.

    Wenn aber das Mantra ist "Das Team organisiert sich selbst", dann hat man das als Personalverantwortlicher unheimlich einfach alles zu ignorieren.

    > Falsch, es ist eher der Fall, dass durch Scrum die Qualität im Gegensatz
    > zum klassischen PjM steigt. Das liegt daran, dass man im Team eine
    > sogenannte DoD definiert, die viele Qualitätsanforderungen enthält. Ein PBI
    > ist somit erst dann fertig, wenn alle Aspekte vom DoD erfüllt werden.
    > Im klassischen PjM ist das doch eher der Fall: Schnell alle Anforderungen
    > durcharbeiten, Unit-Test und andere Tests machen wir dann, wenn wir alles
    > fertig haben und noch Zeit übrig bleibt (also nie ;) )

    als ob Entwickler Interesse an UnitTests hätten.
    Das Szenario was du beschrieben hast, trifft ja genauso zu. Wenn alles fertig ist, kommt das nächste PBI und dann brauchen wir die Unittests ja nicht mehr nachziehen. Funktioniert ja.

    > wenn wir alles fertig haben und noch Zeit übrig bleibt (also nie ;) )

    das ist ja bei SCRUM genauso. Ob du jetzt ein Release oder Sprint abnimmst ist ja egal.

    > Moment: Das DevTeam zeigt ihre Ergebnisse, nicht jeder Entwickler. Die
    > Arbeit wird immer vom gesamten Team bearbeitet, es findet da keine
    > "PBI-Zuweisung an einzelne Mitarbeiter" statt.

    irgend jemand stellt das ja vor. in der Regel der, der am Meisten daran gemacht hat.

    > Im Planning II / Daily werden allerdings die Tasks der jeweiligen PBIs
    > definiert, wo auch Entwickler "Besitzer" der Task sind (sie schieben die
    > Tasks ja in den "In Progress" Bereich und bearbeiten diese). Ein Task
    > sollte in der Regel maximal 1 Tag dauern. Daran kann man sehen, wer mehr
    > oder wer weniger Arbeit macht. Auch ein Architekt sollte tasks definieren,
    > häufig kann man auch in der DoD aufnehmen, dass die
    > Architekturdokumentation aktualisiert wurde.

    Architekten sind in SCRUM nicht vorgesehen. Die Architektur macht das Team

    > Wenn Tests zum Sprintziel nicht fertig werden, dann hat das Team sich
    > verschätzt und das PBI (mit den fehlenden Tests) wird im nächsten Sprint
    > behandelt. Klar, so kann man (mit minderer Qualitätsanforderungen) das
    > Sprintziel erreichen, aber das PBI wandert dann in den nächsten Sprint und
    > dort wird dann weniger behandelt und das Sprintziel "verringert". Dem PO
    > bringt das nichts, denn er legt nicht den Umfang fest, was im nächsten
    > Sprint gemacht wird, sondern nur die Reihenfolge.

    Wenn das funktioniert, aber Tests fehlen oder DoD nicht erfüllt ist, dann wird das trotzdem abgenommen, weil das ggf. ein anderes team benötigt.

  4. Re: Was an SCRUM kaputt ist

    Autor: Serenity 23.08.19 - 14:41

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Der Scrum-Master ist eine neue Position, die normalerweise nicht der
    > > Teamleiter macht.
    >
    > ach ne.
    > ich zitiere mal aus dem Text:
    > >Die Teamleiter wurden in diesem Sprint zu Scrum Mastern, die für flüssige
    > Arbeitsabläufe und die Problembehebung innerhalb der Teams verantwortlich
    > waren.

    Teamleiter ist nicht das gleiche wie ein Leiter eines Teams mit Führungsverantwortung. Das ist der unterschied.

    >
    > > Ein guter Product Owner würde allerdings nicht den Müll
    > > aufnehmen, sondern mehr nach dem "Pull-Prinzip" arbeiten, indem er zu
    > den
    > > Stakeholdern selber geht und sich die Anforderungen abholt. Gutes
    > > Stakeholder-Management ist da Pflicht. Ich kenne POs, die nach dem "wer
    > am
    > > lautesten schreit, gewinnt"-Prinzip arbeiten. Das widerspricht aber die
    > > Aufgabe des POs als "Product Maximizer".
    >
    > natürlich. Wenn alle sich vorbildlich verhalten klappt auch Wasserfall.
    > Ich finde das eher schwammig formuliert, wie der PO mit dem Backlog umgehen
    > soll.

    Wasserfall klappt auch, aber es ist einfacher, sich vorbildlich an Scrum zu halten als an Wasserfall. Oder kennst du einen Projektleiter, der sagt "Nö, wir sind mitten in der Entwicklung. Anpassungen an den Anforderungen gibt es somit nicht mehr"?

    > > Randbedienungen wie die Systemwahl sollten (egal ob Agil oder klassisch)
    > > direkt am Anfang festgelegt werden. Soll eine Software plötzlich auf
    > Linux
    > > portiert werden, auch wenn sie dafür nicht ausgelegt ist, kann das ein
    > > Problem darstellen. Ein guter PO sollte solche Randbedingungen mit den
    > > Stakeholder direkt ansprechen und aufnehmen.
    >
    > Wenn die Stakeholder aber dann z.B. Chefs sind wird das schwer.

    Und warum kann man mit dem Chefs Randbedingungen nicht direkt absprechen? Verstehe da das Problem nicht.

    > > Führungskräfte haben nicht nur die Aufgabe, Arbeitspakete an Mitarbeiter
    > zu
    > > adressieren und diese zu bewerten. Probleme können auch angesprochen
    > werden
    > > und werden dann vom Scrum-Master an den Personalverantwortlichen
    > > weitergegeben (Hinweis: Good Practice ist es, dass der
    > > Personalverantwortliche kein Teil vom Scrum-Team ist). Wenn also
    > > Streitigkeiten und Probleme innerhalb des Teams (z.b. persönliche
    > > Differenzen, "Rebellen") nicht durch den Scrum-Master gelöst werden
    > können,
    > > dann wird er diese an den Personalverantwortlichen gelöst. Probleme mit
    > > Produkten und der Umsetzung sind eher Aufgaben vom PO und Scrum-Master.
    >
    > Wenn aber das Mantra ist "Das Team organisiert sich selbst", dann hat man
    > das als Personalverantwortlicher unheimlich einfach alles zu ignorieren.

    Dann hat der Personalverantwortliche seinen Job nicht verstanden. Das hat aber dann nichts mit Scrum zu tun, sondern mit deinem Chef. Bei so einem Chef buche ich dann eine 2-wöchigen "Workshop" auf den Malediven, weil wir das so in der Scrum Retrospektive als PBI in unserem Sprint aufgenommen haben ;) Wir sind ja "selbst-organisierend" :-D


    > > Falsch, es ist eher der Fall, dass durch Scrum die Qualität im Gegensatz
    > > zum klassischen PjM steigt. Das liegt daran, dass man im Team eine
    > > sogenannte DoD definiert, die viele Qualitätsanforderungen enthält. Ein
    > PBI
    > > ist somit erst dann fertig, wenn alle Aspekte vom DoD erfüllt werden.
    > > Im klassischen PjM ist das doch eher der Fall: Schnell alle
    > Anforderungen
    > > durcharbeiten, Unit-Test und andere Tests machen wir dann, wenn wir
    > alles
    > > fertig haben und noch Zeit übrig bleibt (also nie ;) )
    >
    > als ob Entwickler Interesse an UnitTests hätten.
    > Das Szenario was du beschrieben hast, trifft ja genauso zu. Wenn alles
    > fertig ist, kommt das nächste PBI und dann brauchen wir die Unittests ja
    > nicht mehr nachziehen. Funktioniert ja.

    Du glaubst es nicht, aber Ja, die haben Interesse an Unittest.
    Außerdem wird diese der PO auf jeden Fall haben wollen und der ist derjenige, der für das Inkrement haftbar ist. Dieser definiert auch mit dem DevTeam die DoD und nimmt im Zweifel das PBI ohne Tests nicht ab. Und das PBI landet wieder oben im Product backlog, wird in der Velocity nicht mit eingerechnet und diese nimmt dann für das gesamte Team ab. D.h. das Team muss wieder mit dem gleichen PBI anfangen und im schlimmsten Fall haben sie das gleiche Sprint Ziel.
    Sorry, aber als PO bist du für die Entwicklung des Teams haftbar. Natürlich willst du dann auch die Qualitätsziele die du dir gesetzt hast, erreichen.

    > > wenn wir alles fertig haben und noch Zeit übrig bleibt (also nie ;) )
    >
    > das ist ja bei SCRUM genauso. Ob du jetzt ein Release oder Sprint abnimmst
    > ist ja egal.

    Nein, denn bei Scrum nimmt ein guter PO den Sprint nicht ab und schiebt das PBI wieder in den nächsten Sprint.
    Natürlich gibt es auch PO, die keine Lust auf Qualität haben und denken, dass ein Feature nach dem anderen ohne Qualitätsnachweis das Produkt verbessert. Dann hast du aber keinen guten PO.

    > > Moment: Das DevTeam zeigt ihre Ergebnisse, nicht jeder Entwickler. Die
    > > Arbeit wird immer vom gesamten Team bearbeitet, es findet da keine
    > > "PBI-Zuweisung an einzelne Mitarbeiter" statt.
    >
    > irgend jemand stellt das ja vor. in der Regel der, der am Meisten daran
    > gemacht hat.

    Ja und? Ist trotzdem die Teamleistung. Nur weil Person X das vorstellt, heißt das nie(!) dass er das nur alleine gemacht hat.

    > > Im Planning II / Daily werden allerdings die Tasks der jeweiligen PBIs
    > > definiert, wo auch Entwickler "Besitzer" der Task sind (sie schieben die
    > > Tasks ja in den "In Progress" Bereich und bearbeiten diese). Ein Task
    > > sollte in der Regel maximal 1 Tag dauern. Daran kann man sehen, wer mehr
    > > oder wer weniger Arbeit macht. Auch ein Architekt sollte tasks
    > definieren,
    > > häufig kann man auch in der DoD aufnehmen, dass die
    > > Architekturdokumentation aktualisiert wurde.
    >
    > Architekten sind in SCRUM nicht vorgesehen. Die Architektur macht das
    > Team

    In einem Scrum-Team können Softwarearchitekten, Tester, Designer etc. Teil des Teams sein, sind aber in der Regel cross-functional. Das heißt, dass auch ein Designer mal Quellcode oder Tests schreibt oder ein Software-Architekt sich um das Design kümmert. Das passiert nicht häufig, aber viele Entwickler machen das, um auch mal andere Punkte in der Software-Entwicklung durchzuarbeiten. Sozusagen macht dann die Architektur wirklich das Team.

    > > Wenn Tests zum Sprintziel nicht fertig werden, dann hat das Team sich
    > > verschätzt und das PBI (mit den fehlenden Tests) wird im nächsten Sprint
    > > behandelt. Klar, so kann man (mit minderer Qualitätsanforderungen) das
    > > Sprintziel erreichen, aber das PBI wandert dann in den nächsten Sprint
    > und
    > > dort wird dann weniger behandelt und das Sprintziel "verringert". Dem PO
    > > bringt das nichts, denn er legt nicht den Umfang fest, was im nächsten
    > > Sprint gemacht wird, sondern nur die Reihenfolge.
    >
    > Wenn das funktioniert, aber Tests fehlen oder DoD nicht erfüllt ist, dann
    > wird das trotzdem abgenommen, weil das ggf. ein anderes team benötigt.

    Der PO nimmt unfertige Sprints ab? Das glaube ich nicht, also würde ich jedenfalls nicht machen.
    Ein anderes Team wird aber dann mit dem Problemen des Teams kämpfen müssen. Damit ist nichts gewonnen, sondern mehr verloren. Dann muss eben das andere Team ggf. eine Sprintlänge länger warten.



    1 mal bearbeitet, zuletzt am 23.08.19 14:42 durch Serenity.

  5. Re: kurze Sprints mit jeweils shippable Ergebnissen

    Autor: mark.wolf 27.08.19 - 18:15

    Das funktioniert in der Entwicklung von Webanwendungen, wo SCRUM bekanntlich herkommt.
    Das funktioniert nicht bei einer Maschinensteuerung mit SIL3.

    Das funktioniert auch nicht bei einer Unternehmenskritschen Infrastruktur. Eine gute Architekt ist allemal notwendig und die ist weder shippable noch ist der Weg dorthin kurz.

    Die ganze Welt der eingebetteten Software ist nur sehr eingeschränkt mit SCRUM zu bearbeiten. Und genau da spielt die Musik, nicht in Schicki Micki Klicki Webanwendungen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Sekretariat der Kultusministerkonferenz, Bonn
  2. Hauk & Sasko Ingenieurgesellschaft GmbH, Stuttgart
  3. operational services GmbH & Co. KG, Berlin, Frankfurt am Main, Wolfsburg, Braunschweig
  4. GÖRLITZ AG, Koblenz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 51,95€
  2. 44,99€
  3. (-77%) 11,50€
  4. 2,80€


Haben wir etwas übersehen?

E-Mail an news@golem.de


HP Pavilion Gaming 15 im Test: Günstig gut gamen
HP Pavilion Gaming 15 im Test
Günstig gut gamen

Mit dem Pavilion Gaming 15 bietet HP für 1.000 Euro ein Spiele-Notebook an, das für aktuelle Titel genügend 1080p-Leistung hat. Auch Bildschirm und Ports taugen, dafür nervt uns die voreingestellte 30-fps-Akku-Drossel.
Ein Test von Marc Sauter

  1. Gaming-Notebooks Asus ROG mit Core i9 und fixen oder farbstarken Displays

Innovationen auf der IAA: Vom Abbiegeassistenten bis zum Solarglasdach
Innovationen auf der IAA
Vom Abbiegeassistenten bis zum Solarglasdach

IAA 2019 Auf der IAA in Frankfurt sieht man nicht nur neue Autos, sondern auch etliche innovative Anwendungen und Bauteile. Zulieferer und Forscher präsentieren in Frankfurt ihre Ideen. Eine kleine Auswahl.
Ein Bericht von Dirk Kunde

  1. E-Auto Byton zeigt die Produktionsversion des M-Byte

Astrobiologie: Woher kommen das Leben, das Universum und der ganze Rest?
Astrobiologie
Woher kommen das Leben, das Universum und der ganze Rest?

Erst kam der Urknall, dann entstand zufällig Leben - oder es war alles vollkommen anders. Statt Materie und Energie könnten Informationen das Wichtigste im Universum sein, und vielleicht leben wir in einer Simulation.
Von Miroslav Stimac

  1. Astronomie Amateur entdeckt ersten echten interstellaren Kometen
  2. Astronomie Forscher entdeckten uralte Galaxien
  3. 2019 LF6 Großer Asteroid im Innern des Sonnensystems entdeckt

  1. Surface Laptop 3 mit 15 Zoll: Microsoft könnte achtkernigen Ryzen verbauen
    Surface Laptop 3 mit 15 Zoll
    Microsoft könnte achtkernigen Ryzen verbauen

    Im Oktober 2019 soll Microsoft den Surface Laptop als 15-Zöller vorstellen. Das Notebook wird AMD-Hardware nutzen, offenbar sogar mit bis zu acht Kernen. Allerdings gibt es derzeit keinen Mobile-Ryzen-Octacore.

  2. PES 2020 im Test: Perfektes Rasenschach - trotz alter Probleme
    PES 2020 im Test
    Perfektes Rasenschach - trotz alter Probleme

    Neue Partner-Clubs, erweiterte Online-Funktionen und aufgewertete Spielbarkeit: Konami will mit PES 2020 dem Rivalen Fifa 20 die Stirn bieten. Doch im Test aller Spieloptionen bringen bekannte Schwächen das Spiel ins Wanken.

  3. SpaceX: Das Starship nimmt Form an
    SpaceX
    Das Starship nimmt Form an

    Der erste echte Prototyp des Starship ist fast fertig. Am Samstag soll er offiziell vorgestellt werden. Aber schon vorher wurden einige Details bekannt.


  1. 15:17

  2. 15:10

  3. 14:52

  4. 14:24

  5. 13:24

  6. 13:04

  7. 12:42

  8. 12:31