Wow, da steckt viel drin. Beginnen wir mit der einfachen:

Agile empfiehlt absolut keine Dokumentation.

Das Agile Manifest sagt, dass es Arbeitssoftware gegenüber umfassender Dokumentation schätzt. Wenn Sie etwas von einer der Personen lesen, die an der Erstellung dieser Erklärung beteiligt sind, bedeutet dies eindeutig, dass die Dokumentation der von Ihnen erstellten Software nicht mit der Erstellung identisch ist. Wenn Sie einen Stapel Designdokumente und keine Software haben, haben Sie immer noch keine Software. Dies wird verwendet, um kurze Stapel zu unterstützen, in denen Sie in kleinen Stapeln entwerfen und dokumentieren, anstatt eine große Entwurfs- und Dokumentphase gefolgt von einer Implementierungsphase durchzuführen. Für Teams, die Scrum üben, ist es üblich, in der Definition of Done ein Element zum Ausfüllen aller erforderlichen Dokumentationen zu haben. Dies bedeutet, dass die Arbeit erst ausgeführt wird, wenn die gesamte Dokumentation für diese Funktionalität abgeschlossen ist.

Nein Front-End / Back-End

Aus architektonischer Sicht gibt es natürlich ein Front-End und ein Back-End. Aus Sicht des Kunden sind dies unsinnige Worte. Dies bedeutet, dass Elemente in Ihrem Backlog die gesamte Funktion umfassen sollten. Zum Beispiel sollte ich ein Backlog-Element haben, das lautet:

Als registrierter Benutzer möchte ich die E-Mail-Adresse in meinem Konto aktualisieren können, damit ich E-Mails bei meinem neuen Konto erhalten kann Adresse.

Dieses Element wird ausgeführt, wenn sowohl das Back-End als auch das Front-End abgeschlossen sind. Darüber hinaus ist das Entwicklerteam dafür verantwortlich, den besten Ansatz für dieses Element zu finden. Das Niveau des Teilens, des Cross-Trainings und der Koordination liegt ausschließlich in ihrem Ermessen. Die genaue Zeile im Scrum Guide lautet:

[Das Entwicklungsteam ist] selbstorganisierend. Niemand (nicht einmal der Scrum Master) teilt dem Entwicklungsteam mit, wie Product Backlog in Inkremente potenziell freisetzbarer Funktionen umgewandelt werden soll.

Ich kann mir nur vorstellen, dass Ihr Scrum Master eine gute Idee ist:

Als Scrum Master oder Coach habe ich Zeit, die ich empfohlen habe das Team, etwas zu tun, das eine schlechte Art der Softwareentwicklung war. Diese waren normalerweise für kurze Zeit, um als Team etwas anderes zu lernen. Ich war mit dem Team klar darüber, was ich erreichen wollte und hatte ihr Buy-In. Wenn ich Ihre Geschichte ins bestmögliche Licht bringe, könnte dies eine Lernübung sein, für die sie zuerst das Buy-In des Teams hätten erhalten sollen. Ich konnte sehen, wie eine zufällige Auswahl von Aufgaben das Team dazu zwingen würde, die gemeinsame Code-Eigentümerschaft eng zu koordinieren und zu erstellen, wenn die Übung gut ausgeführt würde. Ohne Ihr Buy-In kann ich jedoch nicht sehen, dass es den gewünschten Effekt hat.

Mein Rat

Ich würde mich mit dem Scrum Master zusammensetzen und sie bitten, zu erklären, was sie erreichen wollen. Sie versuchen wahrscheinlich wirklich zu helfen. Schätzen Sie sie dafür und erklären Sie dann die tatsächlichen Auswirkungen, die sie haben. Am Ende machst du es vielleicht auf eine andere Art und Weise, die das Lernen bringt, das sie suchen, ohne Chaos zu verursachen. Vielleicht probierst du etwas anderes aus. Vielleicht lässt du es ganz fallen. Am Ende sollten Sie (das Entwicklerteam) immer in der Lage sein, Ihr Recht geltend zu machen, selbst zu entscheiden, wie das Inkrement aufgebaut werden soll. Eine Warnung, machen Sie es nicht zu einem Prozess der Rechtsetzung. Verwenden Sie den Scrum-Leitfaden als Anleitung, der jedoch nicht in Stein gemeißelt ist.

Der Einfachheit halber finden Sie hier einen Link zur Online-Version. Es sind kurze 16 Seiten. The Scrum Guide

Ist das normal? Nein.

Das ist weder agil noch scrum ... nicht einmal in der Nähe. Das ist Wahnsinn.

Es gibt ein agiles Konzept namens Planungspoker, aber es dreht sich um die Schätzung der Aufgabengröße ... Personen, die Spielkarten verwenden, um ihre Schätzung der Aufgabengröße anzugeben. Dies verhindert, dass Mitglieder andere Mitglieder auf Schätzungen der Aufgabengröße beeinflussen, und führt auch zu widersprüchlichen / fehlenden Annahmen, wenn die Schätzungen zu weit voneinander entfernt sind.

Produktbesitzer sollten Aufgaben / Funktionen priorisieren ... nicht RNGs. Aufgaben- / Feature-Abhängigkeiten sollten identifiziert worden sein, bevor Elemente priorisiert werden.

In Bezug auf die Dokumentation gibt es in Agile nichts, was „Keine Dokumentation“ sagt. Es sieht also so aus, als hätte jemand das agile Manifest missverstanden. oder eine persönliche (fehlgeleitete) Wendung hinzugefügt.

Ist Softwareentwicklung normalerweise so? Da ich nicht glaube, dass diese Karriere mehr für mich ist ...

Es gibt viele Unternehmen, die sagen , dass sie Agile und Scrum machen. Nehmen Sie es mit einer Prise Salz. Informieren Sie sich über Agile und Scrum. Es sind überraschend kurze Texte:

Das agile Manifest

The Scrum Guide (2017)

Der Scrum Master verwendet einen Zufallszahlengenerator, um Aufgaben auszuwählen, die während der Sprintplanung ausgeführt werden sollen. Es wird anscheinend als "Planen von Glücksspielen" bezeichnet.

Eine gängige Praxis in Scrum ist "Planen von Poker", das verwendet wird, wenn die Entwickler schätzen, wie lange die Implementierung einer bestimmten Story dauern würde. Jeder von ihnen hat einen Satz nummerierter Karten (üblicherweise nummeriert 1, 2, 3, 5, 8, 13, 21) und alle wählen eine Karte aus, die ihrer Meinung nach der Schwierigkeit entspricht. Wenn die Entwickler alle sehr unterschiedliche Karten zeigen, ist dies ein Zeichen dafür, dass sich die Entwickler nicht wirklich einig sind, was sie tun sollen. In diesem Fall muss die Geschichte wahrscheinlich besser erklärt werden. Der gesamte Zweck der Pokerplanung besteht darin, die Unsicherheit zu verringern. Kein Glücksspiel.

Die Auswahl zufälliger Aufgaben widerspricht in der Tat der Scrum-Philosophie, nach der jeder Sprint ein klares Gesamtziel haben sollte. Die Entwickler wählen dann Geschichten aus dem Backlog aus, an denen sie arbeiten möchten, um dieses Ziel zu erreichen.

Schließlich sieht dies wirklich nicht so aus, als würde ein Scrum Master seine Arbeit richtig machen. Der Scrum Master ist kein Joker / Projektmanager. Er coacht die Entwickler und Produktbesitzer darin, den Scrum-Prozess effektiv zu nutzen.

Sie befürworteten auch von ganzem Herzen die agile Philosophie, keine Zeit damit zu verbringen, etwas zu dokumentieren.

Dies ist keine agile Philosophie. Das Agile Manifest besagt wörtlich:

"Arbeitssoftware über umfassende Dokumentation"

(...)

"Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr."

Das Projekt bewegt sich langsam Da viel Zeit darauf verwendet wird, die tatsächlichen Anforderungen der Komponente

zu erraten, widerspricht dies sehr stark der gesamten Idee von Scrum, nämlich, dass Sie immer an etwas arbeiten, das eindeutig ist Mehrwert. Sie erstellen nichts in Scrum, bis Sie wissen, wofür es ist.

Es hört sich sehr danach an, als würde Ihr Scrum Master den Titel eines Dia-Decks über Scrum lesen , aber nichts anderes. Es ist wirklich ungewöhnlich, dass es genauso lächerlich ist wie das, was Sie beschreiben. Ich möchte mit einem Zitat aus dem Scrum-Handbuch schließen:

End Note

Scrum ist kostenlos und wird in diesem Handbuch angeboten. Die Rollen, Ereignisse, Artefakte und Regeln von Scrum sind unveränderlich. Obwohl die Implementierung nur von Teilen von Scrum möglich ist, ist das Ergebnis nicht Scrum. Scrum existiert nur in seiner Gesamtheit und fungiert als Container für andere Techniken. Methoden und Praktiken.

Ist Softwareentwicklung normalerweise so?

In den schlimmsten Wasserfallunternehmen kann es vorkommen, dass Sie einem starren Plan folgen und ignorieren, ob er tatsächlich funktioniert bis zum Ende. Es hört sich so an, als ob es Ihrem Unternehmen gelungen ist, die Probleme des Wasserfalls durch Ausschalten der (vermeintlichen) Vorteile wieder herzustellen! Prozesse, bis sie für Sie arbeiten. Sich strikt an den Prozess eines anderen zu halten, ist das Gegenteil von Agilität, selbst wenn er als "Agil" bezeichnet wird.

Erinnern Sie alle daran, dass ein Teil von Scrum Retrospectives ist. Setzen Sie sich und sprechen Sie darüber, was funktioniert und was nicht, und lernen Sie aus Erfahrungen. Sie erfinden das Rad vielleicht neu, aber das ist besser als der Versuch, quadratische Räder zu verwenden, weil Sie denken, dass all die coolen Leute es tun.

Sie verallgemeinern auf der Grundlage einer Erfahrung, und ich denke, Sie wissen es besser.

Klingt so, als wäre dieser Ort einfach ein Irrenhaus, und Sie müssen sich auf die Suche nach einem Job machen, der es Ihnen ermöglicht lernen und in einer strukturierteren Umgebung wachsen. Je mehr Erfahrung Sie haben, desto mehr können Sie mit weniger Struktur und mehr Verantwortung umgehen. Wenn Sie jedoch relativ neu sind, wirkt sich dies nachteilig auf Ihr berufliches Wachstum aus.

Ihre Führung verstümmelt die Methoden und spielt einfach Buzzword-Bingo. Die gesamte Operation wird eher früher als später enorm leiden (technische Schulden sind eine Sache).

Okay, also möchte ich darauf eingehen, dass ich nie auf die Idee gekommen bin, Aufgaben zufällig auszuwählen - das scheint kontraproduktiv zu sein, um Dinge tatsächlich zum Leben zu erwecken.

Aber alles in allem habe ich es auch nicht Ich habe wirklich gesehen, wie jeder Arbeitsplatz "Agile" aus der Ferne genauso macht wie andere Orte, also wer weiß. Aber auch bei Agile geht es nicht um einen "Mangel an Dokumentation". Gut dokumentierte Software zu behalten, ist einer der Schlüsselaspekte, damit Agile funktioniert. Daher sollte Ihre Software dokumentiert werden.

Von den Orten, an denen ich Ich habe gesehen, wie es funktioniert, obwohl die Dokumentation oft verdammt fehlt, und es macht das Aufnehmen von Projekten von jemand anderem zu einem Albtraum. Dieser Teil ist eine normale Sache in der Softwareentwicklung, aber Sie können helfen, indem Sie tatsächlich Dokumente für Dinge schreiben, die Sie abholen (es gibt auch Tools zum automatischen Generieren von Dokumenten überall).

Aber ja, die " Planen von Glücksspielen "ist etwas, auf das ich nicht gestoßen bin, und es wäre wahrscheinlich ziemlich stark dagegen, wenn mir nicht jemand eine ziemlich übersichtliche Liste von Gründen geben könnte, warum es vorteilhaft wäre, so dass dieser Teil zumindest nicht gerade typisch für Arbeitsplätze ist / p>

tl; drAgile wird in verschiedenen Unternehmen sehr unterschiedlich ausgeführt. "Planen von Glücksspielen" habe ich noch nie gesehen, aber aus Erfahrung ist der Mangel an Dokumenten häufig recht häufig.