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

23

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.

Asim Ghaffar
quelle
Ich habe Frage ein wenig geändert, um es klarer zu machen .. Frage hat jetzt als Unteraufgaben in tatsächlichen User-Geschichten statt als Geschichten
Asim Ghaffar

Antworten:

12

Ü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.
malte
quelle
Also, was Sie als AUFGABE bezeichnen, ist im Grunde ein Arbeitselement wie User Story oder Bug? Es ist nicht die AUFGABE wie in den Aufgaben in User Stories, z. B. Code, Test, Bereitstellung usw.
Asim Ghaffar
2
Ja, um die Unterscheidung zwischen denjenigen zu erhalten, die wir Unteraufgaben von Geschichten "Aktivitäten" nennen.
Malte
Was Sie Task nennen, ist dann im Grunde ein Problem gemäß MSF für Agile 5.0
Asim Ghaffar
Wenn Sie sich hier auf diese Beschreibung beziehen: msdn.microsoft.com/en-us/library/dd997897.aspx - Sie könnten es ein Problem nennen, wie es dort beschrieben wurde, das wäre meiner Meinung nach passend. Damit wäre es Ihre Option Nummer 3.
Malte
2
Punkt 3 "Akzeptieren Sie, dass diese Aufgaben über die Dauer des Projekts angezeigt werden" ist besonders wichtig. Der Agile Unified Process hat ein großartiges Bild, das dies demonstriert: i.stack.imgur.com/CUVFI.jpg . Beachten Sie, dass die "Umwelt" -Disziplin nie wirklich verschwindet. Beachten Sie auch, dass der Großteil der Umweltarbeit im Vordergrund steht. Wenn Sie also in einer späteren Phase plötzlich feststellen, dass Sie viel in der Umwelt arbeiten, läuft möglicherweise etwas schief.
Michael
4

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.

pdr
quelle
Als ich Framework sagte, war es so, als ob wir uns für JSF oder Spring entscheiden sollten. Oder als ich Tool sagte, war es so, als ob wir uns für JBoss oder Glassfish entscheiden sollten.
Asim Ghaffar
1
Ich weiß nicht, was Sie "lange bevor Sie mit der Entwicklung beginnen" meinen. Wenn das Projekt startet, sollte Sprint 1 nicht so schnell wie möglich gestartet werden, z. B. innerhalb von 2 Wochen nach Projektstartdatum. In Sprint 1 gibt es echte Codierung.
Asim Ghaffar
1
@AsimGhaffar: Ich denke nicht, dass es sollte, nein. Wenn Sie mit dem Codieren beginnen, bevor Sie überhaupt Entscheidungen getroffen haben, wie z. B. den zu verwendenden Anwendungsserver, müssen Sie mindestens eine Entscheidung treffen, bei der Sie den größten Teil des Codes neu schreiben müssen. Und ich kann mir heutzutage nicht vorstellen, ein Projekt ohne Quellcodeverwaltung zu starten. Ich meine, ok, wenn Sie Entwickler haben, finden Sie sie etwas produktives zu tun, wie Prototypen. Aber gehen Sie nicht kopfüber in das Projekt, bis Sie die wichtigsten Entscheidungen getroffen haben.
pdr
msgstr "sollte nicht so schnell wie möglich 1 Sprint starten, zB innerhalb von 2 Wochen nach Projektstart". Richtig. Das bedeutet, dass Ihre Umgebung vollständig eingerichtet und einsatzbereit ist. Sie sind bereits mit der Verwendung der Tools, Builds und Bereitstellungen vertraut. Wenn Sie mit diesen Dingen noch nicht vertraut sind und die Umgebung noch nicht eingerichtet ist, können Sie noch nicht loslegen.
S.Lott,
@ S.Lott hmm Ich dachte, dass man die erforderlichen Fähigkeiten AUF DEM JOB bekommt, dh während man am Projekt arbeitet und es keine Lernwerkzeugvoraussetzung für Sprint 1 gibt.
Asim Ghaffar
2

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."

Karl Bielefeldt
quelle
1

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.

S.Lott
quelle
Das Problem ist nicht dasselbe wie Spike. Stellen Sie sich das Problem als Arbeitselement vor, das im normalen Sprint geplant ist, aber keine Story Points hat. Beispiel für ein Problem: SVN ist nicht ausgewählt. Ich leihe mir die Word-Ausgabe von MSF für Agile 5.0
Asim Ghaffar vom
msgstr "Ausgabe ist nicht gleich Spitze". Für die Definitionen der Wörter sind Sie richtig. Wenn Sie jedoch überlegen, vor dem ersten Sprint zusätzliche Arbeit zu planen, spielt es keine Rolle, ob Sie von einem Problem oder einer Spitze sprechen. Wähle eins. Wirf eine Münze. Köpfe.
S.Lott,
Wiederum meinte ich, das Thema neben den Storys in Sprint 1 zu planen - nicht vor Sprint 1. Für Sprint 1 können wir also 2 User Storys und 1 Thema auswählen. Keine Story Points für Issue. Spike wird in der Tat vor dem Sprint 1 sein ..
Asim Ghaffar
Spike oder Issue spielt keine Rolle. Es ist alles Arbeit, die nicht Teil einer User Story ist. Es ist alles Arbeit, die vor dem ersten Sprint erledigt werden muss . Sie können es einen Dorn oder ein Problem nennen, was auch immer Sie glücklich macht. Aber es ist keine User Story.
S.Lott,
1

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.

Chris Chou
quelle
0

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.

BЈовић
quelle
Sie haben Recht und ich schlage nicht vor, sie in der Story-Beschreibung zu haben. Was ich meinte, war, Aufgaben wie "MySQL installieren", "Framework bewerten" als Teil der ersten tatsächlichen User Story zu haben eine homepage damit ich einen schnellen zugriff auf wesentliche funktionen habe.
Asim Ghaffar
@AsimGhaffar Dies kann in der ersten Iteration erfolgen. Nicht als User Story, da Benutzer nicht wissen müssen (und sich auch nicht darum kümmern sollten), welche Technologie Sie verwendet haben, um ihre Anforderungen zu erfüllen.
Freitag,
0

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.

Stuart Leyland-Cole
quelle
3
Alistair Cockburn zitierend, habe ich das schleichende Gefühl, dass jemand wegen seiner Verwendung von Scrum unter Druck gesetzt wurde, als er etwas tat, das zu Beginn keinen offensichtlichen geschäftlichen Wert hatte, und er erfand "Oh, das war Sprint Zero!" die Bauern mit den Spitzhacken von seiner Haustür zu holen.
Asim Ghaffar
0

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.

Ladislav Mrnka
quelle
Wir sind in der Produktentwicklung nicht Kundenprojekte :).
Asim Ghaffar
Okay. In diesem Fall sollten Sie die Zeit, die Sie für das Lernen und die Infrastruktur aufgewendet haben, immer noch getrennt nachverfolgen, um zu sehen, welchen Overhead Sie haben. Wenn Sie diese Zeit in Tasks verbergen, wird die Sichtbarkeit Ihres Entwicklungsprozesses beeinträchtigt.
Ladislav Mrnka