Backend-Entwickler, die von User Stories erstellt wurden

10

Ich hatte vor, die Backend-Entwicklung vertikal in die User Stories zu integrieren. Aber ein Backend-Typ in unserem Team begann sich zu beschweren, dass dies ihre Arbeit unsichtbar macht.

Meine Antwort war das

  • Bei den Sprint-Planungs- und Überprüfungsmeetings diskutieren wir Backend-Aufgaben vor den Stakeholdern, damit sie sichtbar werden

  • Die Aufrechterhaltung einer hohen Qualität während des Projekts führt zu einem langsameren Starttempo als bei anderen Teams, aber wir werden während des Projekts eine stabile Geschwindigkeit haben. Und Geschwindigkeit ist für die Stakeholder sehr gut sichtbar.

Er besteht immer noch darauf, Geschichten zu haben wie: "Als Entwickler brauche ich eine Domänenschicht, damit ich die Geschäftslogik zusammenfassen kann."

Wie kann ich das Problem lösen, bevor es das Team verschmutzt?

Die Wurzel des Problems liegt darin, dass unser Management die Backend-Arbeit systematisch als unsichtbar betrachtet und unterstützte Entwickler-Miner oder andere abwertende Begriffe nennt.

Szili
quelle
7
Ich würde die Backend-Geschichten nicht haben, sie machen keinen Sinn. Allerdings würde ich diese Art von Managern nicht gerne haben. Ich dachte, die Backend-Entwickler wären vor einiger Zeit die Rockstars
Margabit
2
Das Erstellen separater Back-End-Storys bedeutet, dass die Back-End-Arbeit getrennt vom Front-End priorisiert werden kann. Dies birgt das Risiko, dass die Prioritäten so zugewiesen werden, dass die Back-End-Arbeit an den unteren Rand des Backlogs verschoben wird, bis sie wieder in die Front-End-Storys aufgenommen wird. Für das Problem mit der mangelnden Wertschätzung des Managements empfehle ich Ihnen, dies bei Workplace.SE zu erfragen.
Bart van Ingen Schenau
Meine Fantasielösung beinhaltet gelegentliches Schlagen aller Parteien. Schlag Hör auf zu jammern. slap Hören Sie auf, die entscheidende Rolle zu ignorieren, die Daten und Geschäftslogik zum Erfolg des Geschäfts beitragen, das unsere Miete zahlt. Schlag Hör auf, das Mittagessen anderer Leute zu essen. Es ist nicht der Kühlschrank deiner Mutter.
Erik Reppen
1
Schneiden Sie die Themen vertikal und dann die resultierenden Geschichten in horizontale Aufgaben.
Jwenting

Antworten:

4

In der beschriebenen Situation stimmen einige Dinge nicht. Das offensichtliche Problem ist der mangelnde Respekt gegenüber den Back-End-Entwicklern. Da diese Frage als agil markiert ist, werde ich auf andere Antworten zurückgreifen, die darauf hindeuten, dass dies nur ein soziales Problem ist. Es gibt mehrere schlechte Gerüche und mögliche Anti-Muster in Ihrer Geschichte, von denen keines mit ignorantem Management oder sogar damit zu tun hat, wie Sie die Geschichten in Scheiben schneiden.

Die Tatsache, dass sich eine Gruppe von Einzelpersonen im Team beleidigt fühlt, weil sie keinen Ruhm von der Arbeit bekommen hat, weist auf mehrere mögliche Probleme hin.

  • Es sollte keine Leute geben, die nur Back-End-Entwicklung betreiben. Ein gängiger agiler Ansatz besteht darin, funktionsübergreifende Teams zu bilden, die sich aus Generalisierungsspezialisten zusammensetzen, die den gemeinsamen Code-Besitz praktizieren. Einzelpersonen sollten sich nicht ausschließlich auf die Back-End- oder Front-End-Entwicklung konzentrieren, obwohl sie in einigen Dingen sicherlich erfahrener oder besser sind als in anderen.
  • Architektur verdient keinen Wert. Aus der Sicht eines Benutzers - die einzige Perspektive, die wirklich wichtig ist - spielt es keine Rolle, ob Sie Ebenen oder Domänensprachen haben oder ob die Lösung programmiert ist. Entscheidend ist nur, ob Sie Wert für die Benutzer geschaffen haben. Die vom Back-End-Entwickler vorgeschlagene "Story" ist eine Unsinnsanforderung - es handelt sich um eine Zusammenfassung von Entwurfsentscheidungen, die aus Sicht eines Benutzers / Kunden nichts tun, um die gewünschte Funktionalität zu erreichen. Mit anderen Worten, jede gegebene User Story kann durch eine beliebige Anzahl unterschiedlicher Architekturdesigns erreicht werden. Es ist möglich, dass eine User Story ohne Änderung des Backends abgeschlossen wird. Dies macht es nicht zu einer ungültigen Geschichte.
  • Systemisches Denken ist immer noch wichtig. Architektur kann zwar keinen Wert verdienen, ist aber dennoch entscheidend für den Erfolg. Der Back-End-Entwickler hat einige berechtigte Bedenken. Sie sollten darüber nachdenken, wie Sie das System erstellen. Sie sollten diese Entscheidungen aufschreiben. Das gesamte System ist wichtig, auch wenn nur die Front-End-Funktionen den ganzen Ruhm erhalten.

Meine Empfehlung ist, Architektur als erstklassigen Bürger zu behandeln - aber machen Sie es richtig. Führen Sie einen Workshop mit Qualitätsmerkmalen mit Stakeholdern durch . Beziehen Sie wichtige Stakeholder in Architekturprüfungen ein oder fassen Sie zumindest wichtige Entwurfsentscheidungen an wichtigen Meilensteinen zusammen. Zeichnen Sie die Architektur auf großes Papier und machen Sie sie sichtbar, damit das gesamte Team sie sehen kann.

Erfordern, dass jeder überall im System (Front-End und Back-End) ein Pair-Programm entwickelt, wenn dies erforderlich ist, damit dies effektiv geschehen kann. Erstellen Sie weiterhin benutzerorientierte User Stories. Identifizieren Sie aber auch wichtige Szenarien für Qualitätsattribute, die zeigen, warum das System so konzipiert ist, wie es ist, und die Entscheidungsfindung in Bezug auf das "Back-End" -Design vorantreiben. Erhöhen Sie das Architekturdesign, damit es nicht mehr unsichtbar ist.

Michael
quelle
1
Vielen Dank für eine umsetzbare Antwort! Ich möchte ein bisschen Verständnis aufklären, das durch meine falsche Formulierung verursacht wurde. Er ist nicht nur ein "Backend-Entwickler", sondern arbeitet auch in der Firmware über den gesamten Stack. Sein Problem ist, dass die Backend-Architektur nicht richtig erkannt wird. Und während Architektur an sich keinen Wert verdient, kann eine schlampige Architektur Systeme beschädigen oder zumindest die Wartung sehr teuer machen. Mein Plan war es, während Überprüfungs- und Planungsmeetings mehr Gespräche über die Architektur zu ermöglichen, und ein Qualitätsworkshop scheint auch ein großartiges Werkzeug zu sein!
Szili
FWIW, es ist nicht immer praktisch, wenn ein Entwickler den gesamten Stapel bearbeitet. Eine Anforderung in meinem aktuellen Unternehmen könnte die CICS-Entwicklung auf einem IBM Mainframe, MQ, Java in Mule ESB, Datapower und schließlich eine umfangreiche Web-Benutzeroberfläche mit JQuery und anderen Vorlagen sein. Eine andere User Story könnte beinhalten, dass CORBA über VMS COBOL spricht, und ein anderes Backend ist in Gupta geschrieben.
Alan Shutko
@ AlanShutko - genau. "Das vordere Ende einer Person ist das hintere Ende einer anderen Person", oder? Dies ist einer der Gründe, warum ich Slang wie "Back-End" und "Front-End" nicht mag, insbesondere wenn ich über mehrere Komponenten in einem System spreche. Ihr Punkt ist äußerst wichtig! Sogar "Full Stack" ist ein relativer Begriff, der in verschiedenen Teilen eines Systems unterschiedliche Bedeutungen haben kann!
Michael
11

Dies scheint ein soziales Problem zu sein, daher wird es eine soziale Lösung brauchen.

Wenn sich Backend-Entwickler (wie ich Sie verstehe) ignoriert und beleidigt fühlen und das Gefühl haben, dass ihre Arbeit nicht genug geschätzt wird, kann der Entwicklungsprozess wenig tun, um dies zu ändern.

Wenn ich das richtig verstehe, haben die Entwickler das Gefühl, dass sie zumindest ihre "eigenen" User Stories haben sollten, damit sie auf sie zeigen und sagen können: "Das haben wir getan, nur wir Backend-Jungs / Mädels." Es ist jedoch eine schlechte Idee, Geschichten so "horizontal" zu schneiden, und ich stimme Ihnen zu, sie vertikal zu schneiden.

Die beste Lösung besteht wahrscheinlich darin, ein leises Gespräch mit den betreffenden Entwicklern (einzeln oder als Gruppe) zu führen und das zugrunde liegende Problem anzusprechen, das Respekt zu sein scheint. Irgendwann muss dies wahrscheinlich zum Management eskalieren.

sleske
quelle
Danke für die Antworten. Das Problem ist in der Tat ein soziales. Heute haben wir über das gestrige Argument gesprochen, und der fragliche Entwickler sagte mir, es gehe mehr um jahrelange systematische Missachtung seiner Back-End-Arbeit als um seine Sicht auf unser aktuelles Projekt und sein Verständnis des Scrum-Prozesses. Wir waren uns einig, mit vertikal geschnittenen Geschichten voranzukommen.
Szili
1
@Szili: Ist die Backend-Arbeit so schlecht, dass sie keinen Respekt verdient, oder ist er nur abgehakt, dass er nicht erkannt wird?
Blrfl
Seine Backend-Arbeit ist ausgezeichnet. Die richtige Anerkennung und sogar Mobbing im Management ist das Problem.
Szili
4

Die Wurzel des Problems liegt darin, dass unser Management die Backend-Arbeit systematisch als unsichtbar betrachtet und unterstützte Entwickler-Miner oder andere abwertende Begriffe nennt.

In der Tat ist dies das Problem. Es ist offensichtlich, dass Sie es nicht mit Geschichten lösen werden!

Im Allgemeinen ist Transparenz eines der Merkmale der agilen Entwicklung. Dies bedeutet auch, dass Ihre organisatorischen Probleme dadurch offensichtlicher werden .

Die agile Standardlösung für dieses Problem besteht darin, einen "vertikaleren" oder "Full-Stack" -Ansatz für die Entwicklung zu wählen, bei dem Ihre Backend-Entwickler Geschichten von oben nach unten aufzeichnen, anstatt einfach in ihrer Komfortzone der Back-End-Ebene zu arbeiten Frontend-Entwickler erstrecken sich ebenfalls zum Backend (*).

Mit anderen Worten: Lassen Sie jeden Wert für Ihre Endbenutzer produzieren.

(*) Hinweis: Nicht alle Storys müssen eine Front-End-Komponente oder eine Back-End-Komponente haben. UI-Elemente können ohne zusätzliche Back-End-Arbeit neu gemischt werden, und die Leistung ist eine Funktion .

Sklivvz
quelle
3
Klingt so, als hätten Sie kein Verständnis für die Backend-Entwicklung. Sehen Sie, wie wenig Wert ein guter Backend-Typ hat, wenn die Front-End-Mitarbeiter die gesamte Datenmodellierung und Logikimplementierung im Front-End durchführen, und warten Sie dann sechs Monate. Bei den meisten guten Ingenieurleistungen geht es nicht darum, unmittelbaren Wert zu erzielen, sondern um langfristige Dividenden. Ihr Ansatz für den Brückenbau würde jede Brücke nur für eine Woche stehen lassen und es würde keine Blaupause oder einen Architekten geben, da diese keinen unmittelbaren Wert haben.
Jimmy Hoffa
1
Nein @JimmyHoffa Ich bin mit der Backend-Entwicklung ziemlich vertraut. Meine Antwort ist ziemlich agil im Lehrbuch. Wie Sie vielleicht bemerken, befürworte ich nicht, nur Front-End-Leute zu haben. Wenn Sie Agilität nicht mögen, verwenden Sie sie nicht, aber ich beschreibe lediglich, wie eine Methodik funktioniert. Nehmen Sie also nichts über mich oder was auch immer an.
Sklivvz
2
Der Teil, in dem es vom Kurs abweicht, ist der, in dem Sie sagen, dass die Back-End-Leute keinen Wert produzieren und nur Front-End-Arbeit leisten sollten. Wenn dies nicht Ihre Absicht in dieser Antwort ist, sollten Sie es wirklich umformulieren, um klarer zu sein was du hier meinst
Jimmy Hoffa
1
@JimmyHoffa Aber sie sind nicht produzieren einen beliebigen Wert, an den Endverbraucher. Wenn es sich nur um ein Team von Back-End-Entwicklern handeln würde, wären die Benutzer die Front-End-Entwickler. In diesem Fall wäre Ihre Argumentation sinnvoll, aber es scheint nicht der Fall zu sein.
Sklivvz
1
Wenn in Ihrer Welt der Wert nur durch die Erstellung eines benutzerinteraktiven Produkts erzeugt wird und Back-End-Entwickler dafür nicht erforderlich sind, sind in Ihrer Welt anscheinend auch Architekten und Projektmanager, Geschäftsanalysten, die Personalabteilung und alle anderen irrelevant. In meiner Welt wird Wert durch die Qualität eines Systemdesigns und einer Systemimplementierung erzeugt, sodass bei der zukünftigen Funktionsentwicklung nicht durch das Spinnennetz einer Zugriffsdatenbank gewandert werden muss, da nur vom Benutzer interagierbare Produkte bewertet wurden ... Qualitätsimplementierung ist Wert . Vielleicht nicht sofort, aber auf lange Sicht.
Jimmy Hoffa
1

Ihre Probleme sind:

  • Sie haben Managementebenen in Ihrem Unternehmen, die keinen Zweck erfüllen. Scrum, agil, das ist mir egal. Management und Entwicklung sollten von geschäftlichen Bedenken isoliert sein, die von einem Produktmanager behandelt werden, der eine Ahnung von Technologie hat. Vielleicht hat es bei Steve Jobs funktioniert, aber ich war noch nie in einer Situation, in der nicht technisch versierte Manager, die dem Entwickler nahe standen, eine gesunde Sache waren oder letztendlich dazu dienten, das beste Qualitätsprodukt zu produzieren, das ein Team hätte herstellen können.

  • Sie haben Entwickler, die sich mehr Sorgen um das Aussehen machen als Probleme lösen. Das ist entweder ein sehr ernstes Kulturproblem (scheint angesichts dieses ganzen "Bergmann" -Phänomens wahrscheinlich) und / oder Sie haben ein Problem mit der Entwicklungsqualität, das mich angesichts des mangelnden Vertrauens auch nicht schockieren würde.

Holen Sie sich die Leute, die nicht da sein müssen, aus der Planung und dem Aufstehen. Jeder, der Vorstellungen davon hat, dass Back-End weniger wichtig ist als Front-End, ist jemand, der nicht da sein muss und tatsächlich den Prozess behindert, indem er da ist.

Grabengeschichten. Ja, es ist mein Ernst. Wenn sie solche Probleme verursachen, werfen Sie sie aus der Luftschleuse. Bei meinem derzeitigen Job halten wir uns nur an die "erledigten" Kriterien für eine bestimmte Aufgabe, die sich in der Regel mehr auf die App konzentrieren als auf den Benutzer, der diejenigen beleidigen kann, die glauben, dass Agilität (die sich seit 20 Jahren ständig ändert) gewonnen hat. ' Es funktioniert nicht, wenn Sie es nicht genau befolgen, aber wenn wir Profis sind, brauchen wir nichts, was uns Probleme bereitet. Crumple 'em up, wirf sie über deine Schulter.

Und vielleicht möchten Sie diesen Entwickler daran erinnern, dass die Leute, um die sie sich wirklich Sorgen machen müssen, ihre unmittelbaren Kollegen sind, nicht die Leute, die zu ahnungslos sind, um an der Sprintplanung teilzunehmen.

Erik Reppen
quelle
Guter Rat. Denken Sie daran, dass das agile Manifest nichts über "User Stories" enthält und dass es sich lediglich um eine beliebte Praxis handelt, die mit bestimmten Prozessen entstanden ist. Sie können mit User Stories genauso agil sein wie ohne.
Michael
Das ist wahr. Ich bin mir nicht sicher, ob das agile Manifest nach vielen Maßstäben der gesamten Ausbildungsbranche, die darauf aufgebaut sind, als ausreichend angesehen wird, um es richtig zu machen, aber wie immer die Ideen und welche für Sie und Ihr Team sollte Vorrang vor den Auswirkungen haben, IMO. Außerdem erhalten Sie von dieser Seite so viele Antworten, wie Sie "agil" richtig vorgehen können, wie Sie College-Studenten nach den Regeln für die Datierung fragen würden. Es gibt keinen Ersatz für kritisches Denken.
Erik Reppen
Ich würde User Stories nicht fallen lassen. Eigentlich arbeite ich hart daran, sie vorzustellen, da wir die Tradition haben, Endbenutzer zu ignorieren. Die Steve Jobs-Analogie ist sehr zutreffend, da unser CEO ein brillanter technischer Typ ist, der mehrere Millionen Unternehmen gebootet hat. Das einzige, woran er gescheitert ist, ist der Aufbau einer Führungsebene, sodass er bei der geleisteten Arbeit sehr praktisch blieb. Dies gab Platz für die Entstehung der Sternenkultur, was dazu führte, dass man sich Sorgen um das Aussehen machte. Um es zusammenzufassen: Wir haben ein kulturelles Problem. Aber wenn ich es als gegeben betrachte, brauche ich die Werkzeuge wie die in der Antwort, um die erforderlichen Babyschritte zu machen.
Szili
In jedem Fall würde ich einen erfahrenen anal-remanenten UI-Entwickler empfehlen, wenn Sie UX-Probleme haben. Es gibt keinen Ersatz, außer einigen großartigen Generalisten, von denen nur wenige jemals ein volles Team bezahlen möchten.
Erik Reppen