Sollten in Scrum Aufgaben wie das Einrichten der Entwicklungsumgebung und die Entwicklung von Funktionen als Unteraufgaben in tatsächlichen User Stories verwaltet werden?

Manchmal müssen wir in Projekten Zeit für folgende Aufgaben aufwenden:

1. Erkundung alternativer Frameworks und Tools
2. Erlernen des für das Projekt ausgewählten Frameworks und der Tools
3. Einrichten der Server und der Projektinfrastruktur (Versionskontrolle, Build-Umgebungen, Datenbanken usw.)

Wenn wir User Stories verwenden, wohin soll diese ganze Arbeit gehen?

Eine Möglichkeit besteht darin, sie alle Teil der ersten User Story zu machen (z. B. die Homepage für die Bewerbung zu erstellen). Eine andere Möglichkeit besteht darin, einen Spike für diese Aufgaben zu erstellen. Eine dritte Option besteht darin, die Aufgabe in ein Problem / eine Störung (z. B. eine noch nicht ausgewählte Entwicklungsumgebung) einzubeziehen und nicht in eine User Story.

Über dieses Problem haben wir im vergangenen Jahr viel nachgedacht.

Ich stimme zu, dass ein Grundgerüst vorhanden sein sollte, bevor das Projekt beginnt, aber in der Praxis kann es Teil des Projekts selbst sein. Man muss es also irgendwie schaffen.

Während das Mischen des Projekt-Setups mit User Stories manchmal Sinn macht, haben wir uns auf einfache Aufgaben festgelegt , die dem Produkt-Backlog hinzugefügt werden können und die gleiche Aufmerksamkeit erhalten wie User Stories. Wir wissen, dass diese technischen Aufgaben manchmal notwendig sind, aber sie müssen auf jeden Fall gerechtfertigt sein. Wenn das Team der Meinung ist, dass sie zur Erreichung eines bestimmten Ziels unbedingt erforderlich sind, sind sie Teil eines Sprints.

Es ist schwer zu sagen, was für Sie am besten funktioniert. Experimentieren Sie also ! Ein Spike mag vorerst ausreichen, aber ich denke, dass Sie später das gleiche Problem haben werden. Planen Sie also voraus. Führen Sie Aufgaben aus , die einen Platzhalter für solche Aktivitäten darstellen. Um die Aufgaben von den Geschichten zwei zu trennen, werde ich sie anhand meiner Erfahrungen mit ihnen schnell vergleichen.

Aufgabe: Eine Aufgabe ist eine technische Notwendigkeit. Es kann sich um Aufgaben für das Konfigurationsmanagement oder die allgemeine Projekteinrichtung handeln, z. B. das Einrichten eines Repositorys für Commits oder das Hinzufügen des heißesten Codeüberprüfungstools, das Sie jemals im Entwicklungsprozess gesehen haben. Aufgaben sollten in der Planung genauso berücksichtigt werden wie eine User Story. Wenn das Team den Produktbesitzer davon überzeugen kann, dass das neueste und beste Codeüberprüfungstool die Leistung steigert und die Teamkommunikation verbessert, indem langwierige Programmiersitzungen für Paare oder persönliche Codeüberprüfungen vermieden werden, wird die Aufmerksamkeit des Produktbesitzers auf das Produkt gelenkt.

Geschichten : Die Geschichten konzentrieren sich nur auf die Geschäftsperspektive und bieten dem Kunden immer einen sichtbaren Mehrwert. Interne Qualität ist etwas, das mit der Produktion von Geschäftswert einhergeht.

Wir weisen Aufgaben sogar Story Points zu und arbeiten mit ihnen manchmal genauso wie mit Storys.

Am Ende würde ich für diese Lösung in Ihrem Fall (die auch allgemein angewendet werden könnte) gehen:

1. Trennen Sie "Setup" - und technische Dinge in Aufgaben (Dinge, die für den Product Owner keinen direkten geschäftlichen Nutzen bringen).
2. Führen Sie vor dem Einrichten des Projekts möglicherweise einen Spike durch, um die wichtigsten Tools einzurichten (SCM, Entwickler-Tools, Prozessdefinition, Codierungsstandards usw.).
3. Akzeptieren Sie, dass diese Aufgaben über die Dauer des Projekts angezeigt werden, und planen Sie dies, indem Sie eine andere Art von Aktivitäten als Geschichten festlegen.

Tun Sie, was in Ihrem Unternehmen am sinnvollsten ist. Lass niemals zu, dass die Art und Weise, wie andere Menschen Dinge tun, den gesunden Menschenverstand behindert.

Aber ich werde sagen, dass all diese Aufgaben wie etwas klingen, das passieren sollte, lange bevor Sie mit der Entwicklung beginnen. Ich frage mich also, ob Scrum überhaupt für diese Aufgaben relevant ist. Die Quellcodeverwaltung und Datenbanken werden laufend gewartet. Diese sollten jedoch nicht geplant werden, sondern nur geschehen und sich auf Ihre Geschwindigkeit auswirken.

Es wird Zeiten geben, in denen Sie während eines Projekts ein Framework oder was auch immer auswählen müssen, aber wenn ich sage, dass ich ein Framework wie nHibernate meine, kein Framework wie .NET. In diesen Fällen sollte die Recherche mit einem Zeitraffer versehen werden, ganz zu schweigen von der kurzen Dauer. Versuchen Sie, es so zu handhaben, als ob ein Entwickler für ein paar Tage krank wäre.

Der Wissenstransfer ist ein weiterer fortlaufender Prozess, der außerhalb der allgemeinen Entwicklungsgeschwindigkeit gesteuert werden sollte.

Vor dem "offiziellen" Start Ihres Projekts müssen so viele Entwurfsentscheidungen wie möglich getroffen werden. Es heißt Wasserfall. An User Stories wie "Als Entwickler muss ich ein Framework auswählen, damit wir einen Ausgangspunkt für die Website haben." Ist nichts auszusetzen. Wenn das zu groß ist, um in eine Iteration zu passen, versuchen Sie es wie folgt aufzuschlüsseln: "Als Entwickler muss ich eine grundlegende Homepage in Drupal implementieren, damit wir wissen, ob sie unseren Anforderungen entspricht."

Eine Möglichkeit besteht darin, sie alle Teil der ersten User Story zu machen, z. B. die Homepage für die Anwendung zu erstellen.

Unterbricht "User Story" als Konzept. Welcher Benutzer ist daran beteiligt? Keiner. Dies ist Arbeit, die Sie bereits hätten tun sollen.

Eine andere Möglichkeit ist, dafür einen Spike zu machen.

Nicht schlecht.

Die dritte Option besteht darin, die Aufgabe in ein Problem einzubeziehen (z. B. eine noch nicht ausgewählte Entwicklungsumgebung) und nicht in eine User Story.

In Bezug auf Planung und Gemeinkosten ungefähr wie eine Spitze.

Setup ist keine User Story.

Es ist das, was Sie haben sollten , bevor Sie überhaupt mit diesem Projekt begonnen haben.

Sie können das Projekt erst wirklich starten, wenn Sie das Framework / Tool und die Server eingerichtet und einsatzbereit haben.

Mir ist bewusst, dass viele Organisationen erst nach Vertragsunterzeichnung existieren. Mir ist auch bewusst, dass sich viele Unternehmen erst nach Vertragsunterzeichnung für eine Technologie entscheiden . Dies sind alles ineffiziente Dinge, die außerhalb von User Stories liegen.

Bei der Arbeit nutzen wir eine Aufgabe zur Vorbereitung der Umwelt. Es mag für einige Leute verwirrend sein, aber die Aufgabe, die wir verwenden, ist im Großen und Ganzen die gleiche wie die Aufgabe aus einer User Story. Die Aufgabe gehört nicht zu einer User Story, sondern wird in Stunden geschätzt und muss vom Product Owner vereinbart werden, um in einem bestimmten Sprint erfolgreich zu sein.

Wir verwenden die Aufgabe auch für Architekturarbeiten, die keinen "offensichtlichen" Geschäftswert haben, aber dem Produkt Qualität verleihen, insbesondere für ein vorhandenes Produkt mit einer großen Codebasis.

Dies trifft möglicherweise nicht auf Ihre Arbeitsumgebung zu, hat aber bei uns gut funktioniert.

Ich denke, Sie mischen zwei unabhängige Dinge. Eine User Story sollte keine technischen Details enthalten.

Die Auswahl des Frameworks, das Einrichten von Repositorys und Servern sowie andere Aufgaben sollten in die anfängliche Iteration einbezogen werden.

Ich habe kürzlich einen Scrum-Kurs besucht und der Kursleiter schlug vor, einen speziellen Sprint namens Sprint 0 zu verwenden, um genau diese Art von Problemen zu lösen. Es gab Leute auf dem Kurs mit unterschiedlichem Erfahrungsgrad in Scrum, und so gut wie alle erfahrenen Leute stimmten zu und sagten, dass sie dasselbe taten. In einigen Fällen verwendeten die Unternehmen Sprint 0, um das Projekt zu bewerten, und entschieden, ob es machbar war oder nicht.

Für jemanden wie mich, der mit der Scrum-Methodik noch nicht vertraut ist, scheint dies eine fantastische Lösung zu sein, da Sie dadurch nicht an User Stories und allen anderen Aspekten eines normalen Sprints, wie z. B. Benutzerfeedback, interessiert sind.

Da Sprint 0 genauso lange dauert wie Ihre anderen Sprints, können Sie auf diese Weise sicherstellen, dass Sie nicht zu viel Zeit damit verbringen, die Dinge einzurichten, da sie später immer noch geändert werden können. Der wichtigste Punkt ist, sich in einen Zustand zu versetzen, in dem Sie tatsächlich mit der Entwicklung des Produkts beginnen können.

auf 2-3 alternative Framework / Tool erkunden

Manchmal kann dies vorkommen, wenn Sie eine spezielle Anforderung haben und einen POC-Vorgang ausführen müssen, um das beste Tool zur Lösung der Anforderung auszuwählen. Dies ist, was Spike ist, denn ohne zu wissen, welches Framework Sie verwenden werden, können Sie die Story höchstwahrscheinlich nicht einschätzen und speichern, ohne dass Schätzung nicht geplant und in Aufgaben unterteilt werden kann.

Nachdem wir das Framework gelernt haben, wählen wir es für das Projekt aus

Gut. Das ist ziemlich gefährlich. Wenn der Kunde Sie für eine Software bezahlt, erwartet er, dass Sie professionell sind und bereits wissen, wie er mit seinen Werkzeugen umgeht. Der Kunde bezahlt Sie nicht für Lern- oder Test- / Fehlerentwicklungsansätze. Es liegt in der Verantwortung des Entwicklers, neue Tools in seiner Freizeit oder in einer von seinem Mitarbeiter und nicht vom Kunden bezahlten Zeit zu erlernen . Kundengeld für das Lernen auszugeben, ohne den Kunden zu informieren, ist unprofessionell.

Wenn Sie wirklich etwas Besonderes verwenden müssen (zum Beispiel die API eines Kunden oder ein von Ihnen ausgewähltes Tool), das Sie nie zuvor verwendet haben, müssen Sie den Kunden darüber informieren, dass sich der Preis um die Zeit erhöht, die erforderlich ist, um die Verwendung der API zu erlernen. Vielleicht wird der Kunde seine Meinung ändern, wenn die Preiserhöhung zu groß wird.

Klar, ich meine nicht die Situation, in der Sie nach einem bestimmten neuen Problem in einem Framework suchen müssen, das Sie oft verwendet haben. Ich meine die Situation, in der Sie anfangen, eine neue API oder ein neues Framework zu verwenden, ohne einige Zeit (außerhalb des Projekts) für das Lernen aufzuwenden.

Wenn Sie dagegen verstoßen, wird dies ohnehin in Ihrer Geschwindigkeit sichtbar, da Sie pro Iteration nur eine sehr geringe Menge an Geschäftswert liefern. Wenn der Kunde den Grund nicht kennt, wird er höchstwahrscheinlich das Projekt stornieren.

Dies gilt auch für interne Projekte. Sie müssen Ihren Manager / Ihr Unternehmen über die Zeit informieren, die zum Erlernen der neuen API oder des neuen Tools erforderlich ist. Es hat normalerweise sehr schlimme Konsequenzen, wenn Manager mit Ihrer normalen Produktivität rechnen und Ihre Produktivität nur ein Bruchteil ist, weil Sie während Ihrer Aufgaben eine neue API erlernen möchten. Das ist natürlich noch schlimmer, wenn einige Verkäufer bei Vertragsunterzeichnung mit dem Kunden mit normaler Produktivität rechnen.

zum Einrichten der Server (SVN, Datenbanken usw.)

Das sind Ihre Infrastruktur und internen Kosten. Wenn Sie das Projekt starten, wird erwartet, dass Sie Ihre Infrastruktur vorbereitet haben. Das Einrichten Ihrer Entwicklungsumgebung hat für den Kunden keinen Wert und sollte nicht Teil von projektbezogenen Indikatoren sein - zum Beispiel Velocity in Scrum. Ich sah dies als spezielle Iteration vor dem Projekt implementiert, die nur zum Einrichten der Umgebung, zum Erstellen der Basisinfrastruktur usw. verwendet wurde.