Hilfe - Das technische Team möchte nicht agil arbeiten

Sie erwähnen in Ihrer Frage keinen Scrum Master, daher gehe ich davon aus, dass er / sie entweder nicht existiert oder nicht hilfreich ist. Wenn nicht, binden Sie unbedingt den Scrum Master ein! Es ist seine/ihre Aufgabe, Prozessprobleme anzusprechen.

Davon abgesehen bietet Scrum ein Werkzeug, um solche Dinge anzugehen – die Retrospektive. Folgendes würde ich an deiner Stelle tun.

1. Für einen Sprint würde ich mich zurückziehen und die Entwickler die Stories aufteilen lassen, wie sie wollen (Nebenbemerkung – das Aufteilen von Stories sollte ein kollaborativer Prozess zwischen dem PO und dem Dev-Team sein).
2. Am Ende des Sprints, während der Retrospektive, würde ich auf die tatsächlichen, praktischen Probleme hinweisen, die durch das fehlende Splitting verursacht werden. (Vorausgesetzt, es gibt welche! Wenn nicht, kehren Sie zu Schritt 1 zurück).
3. Ich würde das Team bitten, beim Brainstorming möglicher Lösungen für die Probleme zu helfen. Ohne Vorurteile. Nur wenn und nachdem das Team keine praktikable Lösung liefert, werde ich meinen Vorschlag unterbreiten, „die Geschichten aufzuteilen, um granularer zu sein“.

Denken Sie daran, dass es bei Agilität nicht darum geht, Probleme zu vermeiden. Es geht darum, sie schnell zu finden. Seien Sie nicht so sehr darauf fixiert, Agilität zu folgen, um potenzielle zukünftige Probleme zu vermeiden, dass Sie den Eckpfeiler von Agilität selbst umgehen – versuchen, prüfen, anpassen.

Das ist eine frustrierende Situation, Chris. Aus Ihrer Frage geht nicht hervor, dass das Team die Dinge nicht in kleineren Stücken entwickeln kann, sondern dass sie es nicht tun werden. Ich stütze mich darauf, dass es sich so anhört, als wäre der agile Coach da, und nach meiner Erfahrung als Entwickler ist die Art der Aufteilung, von der Sie sprechen, normalerweise nicht schwierig.

Kurz gesagt, Sie haben kein agiles oder technisches Problem, Sie haben ein Problem mit Menschen. Um dieses Problem zu lösen, müssen Sie verstehen, warum das Team seine Funktionen auf diese Weise erstellt. Ich würde hoffen, dass Ihr agiler Coach oder Scrum Master diese Diskussion erleichtern könnte, aber ich dachte, ich würde unten zwei Möglichkeiten nennen, nur um Sie zum Nachdenken anzuregen. Seien Sie jedoch vorsichtig, dies sind nur Möglichkeiten. Der einzige Weg, um herauszufinden, ob es sich um eines dieser Probleme oder etwas anderes handelt, besteht darin, ein gutes Gespräch mit dem Team zu führen.

Möglichkeit 1: Du trittst ihnen auf die Zehen. Menschen werden leicht beleidigt und technisch gesehen sagt Scrum ausdrücklich, dass niemand dem Entwicklungsteam sagen kann, wie es seine Arbeit zu erledigen hat. Die Situation, von der Sie sprechen, ist ein bisschen eine Grauzone, aber es ist durchaus möglich, dass jemand anderes, der ihnen sagt, wie sie die Arbeit aufschlüsseln sollen, als "Sie wissen nicht, wie Sie Ihre Arbeit machen sollen" gehört wird.

Möglichkeit 2: Ihre Art, es zu tun, ist etwas effizienter und sie denken, Sie werden sie bitten, sie einfach alle zu machen, damit sie den Weg des geringsten Widerstands gehen. In diesen Fällen haben sie möglicherweise Recht, oder Sie müssen ihnen möglicherweise ein anderes Szenario präsentieren, in dem Sie zunächst nur 4 oder 5 Bereiche hinzufügen und anzeigen möchten, bevor Sie den Rest der Funktionalität ausführen.

Wie gesagt, es gibt viel mehr Möglichkeiten, als ich aufzählen kann. Dies sind nur einige Beispiele, die Sie zum Nachdenken anregen sollen. Hoffentlich kann Ihr SM- oder Agile-Coach ein gutes Gespräch zum Thema ermöglichen.

Ich bin ein Entwickler, der mit Legacy-Code in Scrum arbeitet, und lassen Sie mich Ihnen sagen, dass ich denke, dass sie auf ihre Weise Recht haben, weil ich das Gleiche mache. Lassen Sie mich meinen Fall erklären, seien Sie sich bewusst, obwohl ich das bin, was die Leute als Cowboy / Hacker- Programmierer betrachten :

TL.DR:

• Bei kleineren Elementen alles zu zerbrechen ist nicht gut, Ihnen fehlen Muster und Interaktionen : Sie tauschen die Chance aus, einen faktorisierten Code für mehrere spezifische Funktionen zu haben, die sich überschneiden und später (nie) faktorisiert werden können. So entsteht beschissene Software.

• Sie konzentrieren sich auf die Methode statt auf das Ergebnis : Wenn ihr Weg funktioniert, die Qualität gut und die Anzahl der Fehler niedrig ist, was ist als PO falsch? Sie müssen die Spezialisten ihre Spezialität tun lassen, wie sie es für richtig halten. Sie können die Leute nicht zwingen, ihre Methoden zu ändern, weil Sie sie nicht mögen. So werden schreckliche Manager geboren.

• Moralisch gesehen ist es besser, an einem großen Projekt zu arbeiten, das ein Ende hat, als an der endlosen Schleiferei kleinerer Dinge : Wie die Arbeiter in den Ford-Fabriken gelitten haben, ist Scrum ziemlich seelenzerbrechend und demotivierend mit seinem endlosen Zyklus neuer kleiner Dinge, die es sind nie ein vollständiges Produkt. So entsteht die hohe Fluktuationsrate (Zitat ist erforderlich) .

Lange Antwort (mit Hintergrundgeschichte)

Wir haben eine Softwarelösung, die im Laufe der Jahre in einer Nischensprache geschrieben wurde und mehr als 1 Million Codezeilen spammt, die auf Hunderte von verschiedenen Modulen und Anwendungen verteilt werden. Also jedes Mal, wenn der Kunde/Besteller/jemand fragte: "Warum machen wir diese kleine Funktionalität nicht hier?" und der Scrum Master hat es bis zur Unkenntlichkeit atomisiert, wir haben neue Interaktionsfehler eingeführt, die ziemlich schwer zu lösen waren. Der endlose Kreislauf aus bedeutungslosen kleinen Aufgaben, ständigen Fehlerbehebungen, die hätten verhindert werden können, und fehlender Motivation, etwas Gutes zu tun, brachte unsere Entwickler allmählich dazu, weiterzumachen, bis wir am Ende nur noch einen hatten: mich.

Als klar war, dass ich die letzte Ratte auf dem Boot sein würde (ein Boot, das ich immer noch mag, wohlgemerkt), habe ich etwas Dummes, aber Notwendiges getan: Ich habe die GESAMTE Codebasis studiert. als ich schließlich der einzige war, der an dingen arbeiten konnte, implementierte ich die effizienteste methode, um probleme zu beheben: sagte ihnen, sie sollten sich verpissen, ich mache die sache auf meine art, mit meiner eigenen prioritätsliste und wenn sie es nicht mochten Sie könnten mich feuern und in einem Monat untergehen.

Zuerst habe ich die Meetings abgesagt, weil ich alleine war, ich musste keine Erklärungen abgeben oder mich mit irgendjemandem abstimmen. Dann habe ich das iterative Bereitstellungsmodell aufgegeben, weil ich den Fortschritt nicht zeigen musste und halb funktionierende Software hier nutzlos war. Dann habe ich den Sprint aufgegeben, weil ich schnell ein Qualitätsprodukt liefern wollte, also habe ich mir Zeit genommen, um es von Anfang an richtig zu machen. Und dabei habe ich ein paar wirklich nette Sachen gefunden:

• Wenn ich mich dazu widme, bei jeder Iteration das gesamte Modul statt einer Reihe von Elementen zu reparieren, konnte ich kleineren, effizienteren und fehlersicheren Code schreiben, der immer noch besteht.
• Mit jedem vollständigen Modul, an dem ich arbeitete, konnte ich lernen, Standards und Best Practices definieren, die die Interaktionen eher zu einer Transaktion als zu einer Vermutung machten.
• obwohl mir schmerzlich bewusst war, dass bei einem scheitern alles vorbei sein würde, fühlte ich mich in dieser zeit mit jedem live geschalteten modul wirklich motiviert und sehr zufrieden. Es war nicht nur ein moralischer Aufschwung, ich war mit meiner Arbeit zufrieden.

Als die Dinge gut genug liefen und wir anfingen, mehr Leute zu gewinnen, erhielt die Methode „Lass das Boot retten“ einige organische Modifikationen:

• Ich musste mich mit den Leuten koordinieren, also entwickelten wir anstelle von strukturierten Meetings eine „immer für Fragen jederzeit offen“-Politik.
• iterative Lieferungen wurden schließlich durch vollständige Aufgabenlieferungen ersetzt, die das Verständnis aller Teile, die damit interagierten, verbesserten und fehlersicherer waren als ein zyklisches Patch-Work.
• Jeder verstand, dass Aufgaben Zeit brauchten, um sie richtig zu erledigen, anstatt zu versuchen, sie in einen willkürlichen Zeitrahmen einzupassen.

Jetzt sind wir dem Namen nach Scrum, weil es nur Scrum ist, es sei denn, es behindert die Arbeit.

Was hat das mit Ihrem Team zu tun? :

Ihr Team scheint irgendwie zu den gleichen Schlussfolgerungen gekommen zu sein wie ich, dass die Atomisierung mehr Probleme erzeugt als sie löst. also, was machst du?

Es gibt viele verschiedene Möglichkeiten, etwas zu tun, und jede Person/Gruppe hat eine Methode, die für sie am besten funktioniert. Um es klar zu sagen, der einzige Grund, warum ich nicht gefeuert wurde und am Ende von all meinen Kollegen gehasst wurde, ist, dass das, was ich getan habe, funktioniert hat (damals haben sie mich allerdings ein bisschen gehasst); aber das gilt auch für scrum und jede methodik: es wird nur angewendet, weil es ergebnisse bringt, mit denen wir einverstanden sind. Wenn ihre Arbeitsweise gute Ergebnisse liefert und Ihre Fehlerzahl unter Kontrolle ist, warum sollten Sie sie ändern? weil es dir nicht gefällt? das klingt sehr danach, was ein schrecklicher Manager anstelle einer Bestellung sagen würde.

Wenn Ihre Rolle PO ist, besteht Ihre einzige Aufgabe darin, ihnen zu sagen, was Sie in Ihrem Produkt brauchen / wollen , nicht , wie es geht. Wenn Sie ein Produkt wollen, das so hergestellt wird, wie es Ihrer Meinung nach gemacht werden sollte, dann sind Sie kein PO, Sie sind nur ein schlechter Manager in der Kleidung von PO

Sie gehen davon aus, dass Sie wissen, was das Beste für das Team ist, ohne die Software liefern zu müssen.

Ich glaube fest an agile Methoden und Scrum im Besonderen. Ich unterstütze voll und ganz den iterativen User-Story-Ansatz. Vor diesem Hintergrund sind Kompromisse zu berücksichtigen:

• Wenn das Team entweder an einem vorhandenen Produkt arbeitet oder daran gewöhnt ist, an vorhandenen Produkten zu arbeiten , zögert es möglicherweise, an etwas zu arbeiten, da es weiß, dass es später umgestaltet werden muss. Es fühlt sich an, als würden sie ihre Zeit verschwenden.
• In vielen Organisationen ist es üblich, dass von Entwicklern erwartet wird, dass sie Funktionen schnell herausbringen, mit dem Versprechen, dass sie später zurückkommen und „es richtig machen“ können, und ihnen dann nie die Zeit dafür gegeben wird. Wenn das Team dies selbst bei früheren Jobs erlebt hat, könnte es konditioniert werden, der iterativen Entwicklung nicht zu vertrauen.

Die iterative Entwicklung geht von geringen Änderungskosten aus. Bei der iterativen Entwicklung dreht sich alles um Refactoring. Wenn Sie jeden Tag refaktorisieren, machen Sie es richtig. Aber wenn Sie ständig umgestalten, werden Sie dann nicht Ihre ganze Zeit mit Regressionstests verbringen? Agile funktioniert gut, wenn Sie einfach den Code ändern, die Tests ausführen und sicher sein können, dass Sie nichts kaputt gemacht haben. Das muss die Mannschaft erlebt haben, um daran zu glauben. Und es ist extrem schwierig, diese Art von Testbarkeit in ein bestehendes Produkt einzubacken.

Mein Rat ist also, mit dem Team zu sprechen und ihr Zögern zu verstehen. Sehen Sie, was Sie tun können, um zu helfen. Finden Sie heraus, ob es jemanden im Team gibt, der Erfahrung mit iterativem Arbeiten hat und der Ihr Verbündeter sein kann.

Aus Entwicklersicht

Das Beispiel, das Sie verwendet haben:'Users Grid', with everything written in (search, filter, sort, add/edit users

Um dies zu erreichen, bieten viele Frameworks integrierte Tools (z. B. Yii2 Gii) und generieren das Grid in wenigen Minuten. Wenn Sie es jetzt ausbrechen möchten, wird es mehr Zeit in Anspruch nehmen, da der Entwickler die Funktion entfernen und später wieder hinzufügen muss. Es wird frustrierend sein, diese Methode durchzugehen.

Diskutieren Sie also vielleicht mit ihnen und fragen Sie, warum sie dagegen sind. Wenn der Grund so etwas wie der oben genannte ist, ändern Sie Ihre Methode ein wenig, damit Sie und das Team Gemeinsamkeiten finden können.

Was Sie hier haben, ist eine Meinungsverschiedenheit . Sie ziehen es vor, die Dinge auf eine Art und Weise zu erledigen, das technische Team bevorzugt ihre Art und Weise. Der Weg, dies zu beheben, besteht also darin, zu fragen, WARUM? . Und nicht nur, warum sie ihren Weg bevorzugen, sondern auch, warum Sie Ihren Weg bevorzugen.

Vielleicht sind sie auf ihre Art eingestellt, und Sie sind auf Ihre eingestellt. Vielleicht verstehen sie diese ganzen Agile-Dinge nicht und sehen den Sinn nicht. Vielleicht erscheint Scrum dumm. Vielleicht gefällt ihnen nicht, wie du die Geschichten aufteilst. Vielleicht sind Sie wirklich schlecht darin, die Geschichten aufzuteilen. Vielleicht haben sie einen Einblick in das Produkt und denken, dass es besser ist, die Dinge auf ihre Weise zu tun. Sie sind die PO, aber vielleicht sollten Sie offener für ihr Feedback sein. Vielleicht sind sie technisch nicht sehr versiert und befürchten, dass sie die Dinge durcheinander bringen, weil sie nicht wissen, wie man die Arbeit richtig aufteilt, um eine inkrementelle Entwicklung zu ermöglichen, also versuchen sie, alles zusammenzuhalten. Viele "vielleicht", weil ich versuche zu erraten, was passiert, einfach anhand dessen, was hier gepostet wurde, aber ich 'und diese Frage stellen.

Organisieren Sie also ein Treffen mit allen und besprechen Sie die Dinge. Ziel dieses Treffens ist es , einander zu verstehen und dem Problem auf den Grund zu gehen . Nur so kann man eine Lösung finden, die für alle funktioniert . Ihnen zu sagen, dass Sie möchten, dass sie agiler arbeiten, wird ihnen nichts bedeuten, es sei denn, sie verstehen, warum dies erforderlich ist.

Der SM/Agile-Coach kann vermitteln und sicherstellen, dass die Gespräche auf einem angemessenen, respektablen Niveau bleiben, aber dies muss ein separates Meeting sein, nicht Teil der Scrum-Events. Die Retrospektive ist der Ort für solche Diskussionen, aber aus der OP-Frage geht hervor, dass Retrospektiven ihre Arbeit nicht richtig machen (das Team kehrt zu seinen alten Gewohnheiten zurück, sobald der SM nicht hinschaut, es gibt Widerstand gegen die Idee , und das schon seit langem, so sehr, dass das OP aufgegeben hat und trotz des Risikos für das Projekt und den Kunden bereit ist, mit Mini-Wasserfällen zu arbeiten). Ein separates Treffen signalisiert zusätzlich das Gewicht der Situation. Die Leute müssen verstehen, dass „ diese Regelung nicht für alle funktioniert". Sobald die Menschen das Gewicht der Situation verstehen, das Problem zerlegt ist und die Ursachen der Meinungsverschiedenheit gefunden sind, kann nur dann etwas dagegen unternommen werden. Andernfalls kann jeder auf beiden Seiten Dinge wahrnehmen wie "es ist, weil jemand sagt es oder will es ".

Es fühlt sich für mich ein bisschen so an, als würden Sie und das Team den gleichen Punkt verfehlen. Es geht nicht darum, was einfach zu erstellen oder zu testen ist, es geht nicht darum, inkrementell zu sein, sondern darum, den richtigen Wert zur richtigen Zeit zu liefern.

Wie näherst du dich derzeit deinen Sprintzielen? Sie haben die Priorisierung nach Priorität und Wert erwähnt, aber setzen Sie sich auch klare Sprintziele? Haben Sie klare Unternehmensziele? Lässt du es zu, den Arbeitsablauf anhand des Ziels auszuwählen, das für den Sprint festgelegt wurde, oder gibt es nur einen riesigen Rückstand an Dingen und du arbeitest dich nur nach unten?

Wenn es letzteres ist, kann ich mir vorstellen, dass Entwickler so denken, wie sie es jetzt tun. Wenn es keinen wirklichen Grund gibt, etwas jetzt oder im nächsten Sprint zu liefern, ist es einfacher, Funktionsbereiche zu bündeln und vollständig geformte neue Funktionen bereitzustellen.

Aber wenn es ein scharfes Ziel gibt, dann muss man irgendwann darüber reden: „Wie erreichen wir dieses Ziel?“ und Sie werden erkennen, dass Sie nicht alle unwesentlichen Nebenfunktionen liefern können, um das Sprintziel zu erreichen, und jeder wird erkennen, dass es wichtig ist, das Ziel zu erreichen , und dann können Sie eine Diskussion darüber führen, Komponenten aufzuteilen und das Wichtige aufzubauen Dinge zuerst und die weniger kritischen, nachdem das Ziel erreicht wurde.

Wenn es kein wichtiges Ziel zu erreichen gibt, ist keiner der beiden Ansätze besser als der andere, denn ohne das Sprintziel ist alles, was Sie tun, im Wesentlichen auf geschäftige Arbeit reduziert und es gibt keinen besten Weg, geschäftige Arbeit zu erledigen.

Wenn Menschen sehr resistent gegen Veränderungen sind, ist das oft ein Schutzverhalten und das ist das wichtigste Warum? du musst fragen.

Meine unmittelbare Reaktion war, dass sie anscheinend viel Auditing in die Aufgabe einbauen, was Sie als einen Mini-Wasserfall wahrnehmen .

Wenn das Team einen neuen Benutzer manuell in SQL erstellt, wozu hat es sonst noch die Möglichkeit zu tun? Sind sie besorgt über die Auswirkungen, wenn jemand anderes Benutzer erstellt? Manchmal beinhaltet ein manuelles Verfahren Überprüfungen, die eine Menge Arbeit in den Code einzubauen sind.

Sie scheinen einen gemeinsamen Ansatz zu verfolgen, Dinge in horizontale Funktionsabschnitte zu unterteilen. Es kann sein, dass sie auf die harte Tour gelernt haben, dass dies zu weiteren Fehlern und anderen Problemen im Zusammenhang mit dieser Codebasis führt.

Es kann ein politisches Problem oder Erinnerungen an ein solches in dieser Organisation geben, wo sie sehr schlechte Erfahrungen damit gemacht haben, nur einen Teil eines erwarteten Features zu liefern.

Wenn Sie also inkrementell liefern möchten, können Sie die gleichen umfangreichen Funktionen beibehalten, aber einfachere Versionen inkrementell liefern? Kann die Benutzeroberfläche drastisch einfacher sein?

Funktionalität ist einfacher zu entwickeln und zu testen, wenn sie inkrementell ist

Nun, nicht immer. Haben Sie direkte Erfahrung mit dieser Domäne oder einer bestimmten Codebasis, die es Ihnen ermöglicht, eine Autorität auf diesem Gebiet zu sein?

Ich verabscheue den Begriff agil , weil er sehr wertend ist, wenn man Leuten sagt, dass sie nicht agil sind .

Ich bin seit fast 40 Jahren Entwickler und als jemand, der sich sehr für Tools und Techniken interessiert, habe ich das Wachstum der inkrementellen Bereitstellung und die Geburt der Agile-Bewegung beobachtet. Ich habe auch an komplexen Codebasen gearbeitet, zB: 3D-CAD mit über 1 Million Zeilen C++. Ich bevorzuge die schrittweise Lieferung, weiß aber auch, dass dies nicht immer angemessen ist.

Adressieren Sie Time-Boxing & Organisationskultur

Der Begriff der „Nachbearbeitung“ ist schwierig, wenn es um iterative Entwicklungsmethoden geht. In traditionellen Frameworks wird alles andere als One-and-Done entweder als Fehler oder als Fehler seitens des Entwicklungsteams behandelt. Die Realität ist, dass agile Frameworks Veränderungen willkommen heißen und ein gewisses Maß an Überarbeitung und Refactoring ein bekannter Kompromiss für häufigere Inspektions- und Anpassungszyklen sind.

Es ist nicht die Aufgabe des Product Owners sicherzustellen, dass das gesamte Team (und die Organisation, in der es lebt) den Zweck des Timeboxing sowie den Nutzen häufiger Inspektionen sowohl des Produkts als auch des Entwicklungs-/Lieferprozesses vollständig versteht. Es gehört eigentlich zum Scrum Master, unterstützt von der übergeordneten Organisation und allen Trainern, die zugewiesen werden können, um den Übergang zu erleichtern.

Kurz gesagt, viele Entwickler, die neu bei Scrum sind, müssen sich sicher fühlen , wenn sie einen Entwicklungs-/Bereitstellungsprozess übernehmen, der von Natur aus auf emergentes Design setzt und nicht auf großes Upfront-Design (BUFD). Als empirischer Kontrollprozess bringt Scrum eine Menge Overhead und Nacharbeit mit sich, die Schuldzuweisungen, Schuldzuweisungen und nachteilige Personalmaßnahmen in BUFD-Organisationen auslösen würden. Bis das gesamte Team zuversichtlich ist, dass dies nicht passieren wird, werden sie berechtigterweise skeptisch sein, Arbeitsmuster zu ändern, die ihnen in ihrer bisherigen Karriere gute Dienste geleistet haben.

Ein tieferer Tauchgang: Das Gespräch neu gestalten

Meine Begründung ist, dass Funktionalität einfacher zu entwickeln und zu testen ist, wenn sie inkrementell ist; Es reduziert das Risiko, wir können dem Kunden Dinge früher präsentieren und erhalten früher Feedback. Für sie hingegen ist es einfacher, wenn wir die Arbeit nicht aufteilen und die Dinge sofort fertig liefern.

Arbeit nicht aufzuteilen, liefert nichts „sofort“. Andererseits liefern inkrementelle und iterative Paradigmen oft eher Slices als vollwertige Funktionen auf einmal. In beiden Fällen scheinen sich beide Seiten um die grundlegende Frage zu drehen, ob das Timeboxing, das Scrum innewohnt, einen Mehrwert für Ihre aktuellen Prozesse oder Ihr Produkt darstellt.

Niemand außerhalb Ihres Unternehmens kann dies wirklich feststellen. Sie sollten jedoch mit Ihrem Agile-Coach zusammenarbeiten, um dies anders zu formulieren als die aktuelle Debatte „monolithisch vs. inkrementell“, die Sie und das Team führen.

Als Product Owner sind Sie Mitglied des Scrum Teams. Das schränkt ein, wie viel Autorität (insbesondere keine gegenüber dem Entwicklungsteam) und Einfluss (so viel Sie bieten können) Sie innerhalb des Scrum-Prozesses haben. Sie sind jedoch auch die Person, die das Product Backlog steuert. Wenn Sie Ihre Doppelrolle als Product Owner und Mitglied des Scrum-Teams im Hinterkopf behalten, können Sie das Gespräch anders gestalten. Insbesondere sollten Sie:

1. Verwalten Sie das Product Backlog aktiv, um sicherzustellen, dass Sie Backlog-Elemente priorisieren, die (zumindest konzeptionell) in eine einzelne Iteration passen.

2. Arbeiten Sie mit dem Scrum Master und dem Entwicklungsteam zusammen, um die Erwartung festzulegen, dass das vereinbarte Sprint-Ziel innerhalb eines einzigen Sprints erreicht werden muss.

Indem Sie die Diskussion als „Was können wir getrost in unsere nächste Zeitbox packen?“ formulieren? Anstatt „Sie sollten inkrementell arbeiten ! Konzentrieren Sie sich auf das, was Sie brauchen (z. B. eine schnelle Überprüfungs- und Anpassungs-Feedbackschleife, die den Kunden als Work-in-Progress demonstriert werden kann), anstatt darauf, wie das Team dies erreichen soll.

Der Scrum Master und der agile Coach sollten mit Ihnen und dem Team zusammenarbeiten, um den geschäftlichen Blickwinkel (falls erforderlich) zu erklären, sowie einige praktische Techniken anbieten, wenn das Team mit der zeitlich begrenzten Entwicklung zu kämpfen hat. Sie und der Scrum Master müssen jedoch aktiv zusammenarbeiten, um sicherzustellen, dass das Entwicklungsteam die notwendige Gelegenheit zur Überarbeitung und Umgestaltung erhält, wenn sich das Product Backlog ändert.

Das Entkoppeln und Zerlegen von Features kann schwierig sein und erfordert viel Trial-and-Error, bevor das Team die Erfahrung und Prozessreife erlangt, um dies mit einem Konfidenzintervall von 60–80 % durchzuführen. Es sei denn, das Team ist motiviert (entweder aus eigener Motivation oder von außen), diese Anstrengungen zu unternehmen, und zuversichtlich , dass es eine sichere Gelegenheit hat, durch Versuch und Irrtum (mit Betonung auf „Fehler“) ohne nachteilige Folgen zu lernen, einfach zu übernehmen die Insignien von Scrum werden nichts bewirken.

Von der Modeerscheinung des Managements Erfolg zu erwarten, ist ein Dilbertismus. Agile Frameworks wie Scrum sind nur effektiv, wenn sie von eigenverantwortlichen und sich selbst verwirklichenden Teams verwendet werden . Unbekehrten Traditionalisten ein agiles Framework aufzuzwingen, ist eine Form von Buzzword Management™ und der Hauptgrund, warum ich gesehen habe, dass „agile“ Implementierungen scheitern. Um erfolgreich zu sein, muss Scrum vom gesamten Scrum-Team, der Mutterorganisation und den Kunden/Stakeholdern/Sponsoren des Projekts angenommen werden .

Jedem Mitarbeiter innerhalb des Prozesses dabei zu helfen, das Wertversprechen des Frameworks in Bezug auf seine eigene Skin im Spiel aufzudecken, sollten Sie nicht selbst tun müssen. Verlassen Sie sich stark auf Ihren Scrum Master und andere, um Probleme bei der Prozessannahme transparent und sichtbar zu machen , damit sie konstruktiv angegangen werden können.

(Benutzer suchen, filtern, sortieren, hinzufügen/bearbeiten usw.)

Nur aus Entwicklersicht:

• Eine Liste anzuzeigen, ohne Elemente hinzufügen zu können, ist nutzlos, also ist dies Ihre erste Sache.
• Die Maske zum Bearbeiten eines Artikels wird wahrscheinlich dieselbe sein wie die zum Hinzufügen eines Artikels.

Dies gibt Ihnen also den ersten Sprint für die CRUD-Funktionalität.

• Normalerweise ist eine Schlüsselwortsuche nur ein weiterer Filter, der auf die Datenbankabfrage angewendet wird.

Daher ist es sinnvoll, die Such- und Filterfunktionalität im zweiten Sprint gemeinsam zu entwickeln.

• Das Sortieren kann nach primitiven Typen erfolgen, dann ist es einfach, oder es könnte schwierige Algorithmen beinhalten, dann ist es sinnvoll, dies in einem separaten Sprint zu tun.

So würde ich die Arbeit aufteilen, aber ich sehe keinen Sinn darin, sie nach jedem Sprint abzuliefern. Es muss möglicherweise freigegeben werden können, bedeutet aber nicht, dass Sie es versenden oder mit dem Kunden überprüfen. Sehen Sie, wir haben eine Liste. Oh schau, jetzt kann es suchen. Und jetzt.. bist du noch wach? Hallo? Ich denke, die meisten unserer Kunden würden eine Bewertung vorschlagen, nachdem das Ding fertig ist. Es ist auch etwas umständlich für uns, einen kleinen Teil einer Funktionalität zu präsentieren, weil alle denken: „Das war alles, was Sie in einem Sprint getan haben?“, viel mehr Spaß, sich durch ein vollständiges Feature zu klicken und all die verschiedenen Dinge zu zeigen, die Sie auf einmal tun können .

Aus Erfahrung glaube ich nicht, dass sich viel Feedback für einen einfachen CRUD-Bildschirm ändern wird, vielleicht einige Design- oder Layoutaspekte, die auch nach der ersten Überprüfung behoben werden können. Für größere Teile des Projekts ist es sinnvoll, es aufzuteilen und eine frühzeitige Überprüfung zu erhalten, sagen wir, den von Ihnen beschriebenen Artikelverwaltungsbildschirm, einen anderen Bildschirm, auf dem die Artikel interagieren, oder eine Berichtsseite, auf der Sie Dinge drucken können. Dies sind separate Einheiten und sollten in separaten Sprints entwickelt werden.

Es hängt auch davon ab, welche Technologien und Plattformen Sie verwenden, wie viele Personen an der Entwicklung beteiligt sind, deren Verfügbarkeit und wie viel Koordination erforderlich ist, um etwas wirklich in einem Sprint fertigzustellen.

Sie müssen das Team fragen, was erforderlich wäre, um die Aufgaben effizient aufzuteilen und von dort aus zu arbeiten. Vielleicht brauchen sie andere Arbeitsbedingungen.

Scrum bedeutet auch, dass alle gemeinsam an einer Sache arbeiten, ist das überhaupt möglich? Vielleicht brauchen sie einen Blocker für andere eingehende Projekte. Vielleicht brauchen sie bessere Werkzeuge?

Finden Sie das eigentliche Problem heraus und lösen Sie es dann gemeinsam.