it-swarm.dev

Wie berücksichtigt ein Scrum-Team Infrastrukturaufgaben in der Planungsbesprechung?

Wie berücksichtigt ein Scrum-Team Entwicklungs-/Infrastrukturaufgaben in der Planungsbesprechung?

Auf den ersten Blick scheinen sie keine User Stories zu sein, da sie keinen Endbenutzerwert liefern.

Es ist jedoch manchmal auch nicht sinnvoll, sie als Aufgaben an eine bestimmte User Story anzuhängen. Angenommen, die Aufgabe lautet: "Bambus einrichten". Diese Aufgabe ist nicht erforderlich, um eine User Story abzuschließen, da das Team sie manuell erstellen und bereitstellen kann. Das Anhängen an eine User Story ist daher nicht sinnvoll, da diese Aufgabe nicht erforderlich ist, um die User Story zu vervollständigen.

Dies deutet darauf hin, dass diese Aufgaben zu User Stories werden. Wenn die Team-Story jedoch auf sie verweist, ändert sich dadurch die Geschwindigkeit, die ungerade ist, da der Product Owner die Geschwindigkeit anhand seines Rückstands und nicht anhand seines Rückstands mit einer Reihe technischer User Stories ermitteln möchte.

33
user11347

Sie sind eigentlich keine User Stories. Es sind Stakeholder-Geschichten. Sofern die Software nicht direkt von den Benutzern bezahlt wird, wird eine Story nur selten zu ihrem Vorteil erstellt.

Ich gebe Ihnen einige Beispiele:

  • artikel mit Schlüsselwörtern, mit denen Werbetreibende effektivere Anzeigen schalten können
  • CAPTCHAs, die verhindern sollen, dass Moderatoren manuell mit Spam umgehen müssen.

Die meisten technischen Geschichten bieten tatsächlich einen geschäftlichen Vorteil, sind jedoch für die Benutzer selten. Eine andere Formulierung kann helfen. Normalerweise verwende ich die Feature Injection-Vorlage von Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Dies erkennt ausdrücklich alle Arten von Stakeholdern an, einschließlich des Entwicklungsteams. Jetzt können Sie auch Ihre technischen Geschichten formulieren und den geschäftlichen Nutzen herausstellen:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Ich habe ein paar Blog-Beiträge dazu geschrieben: Sie sind keine User Stories und Feature Injection und Umgang mit technischen Storys . Hoffe sie helfen.

25
Lunivore

Die Geschwindigkeit ist ein Maß für die Fähigkeit des Teams, nützliche Arbeit zu leisten (im Gegensatz zu Drag). Infrastrukturaufgaben bieten immer noch einen Mehrwert für den Endbenutzer, wenn auch indirekt, indem sie das Team auf lange Sicht effizienter machen. Ich habe kein Problem damit, diese Dinge als User Stories zu verfolgen (in diesem Fall ist der Benutzer das Entwicklerteam) und sie entsprechend zu priorisieren. Ein Product Owner in guter Kommunikation mit dem/den Kunden sollte in der Lage sein, herauszufinden, wo solche Aufgaben passen, ohne die Ergebnisse zu stören.

12

Mach sie nach und nach.

Wenn kein Stakeholder es will, machen Sie es nicht zu einer Geschichte. Kümmere dich nur ein bisschen darum. Zum Beispiel beim ersten manuellen Bereitstellen. Beim zweiten Mal automatisieren Sie ein bisschen davon. Beim dritten Mal automatisieren Sie etwas mehr. Letztendlich ist Ihr Build nicht das größte Problem, also konzentrieren Sie sich auf etwas anderes.

Sie werden am Anfang mehr von diesen entwicklerorientierten Aufgaben haben, und das ist in Ordnung. Ihre Geschwindigkeit (gemessen an Geschichten) ist nur niedriger. Das ist eine korrekte Darstellung der Situation. Aber Sie werden immer welche haben, daher ist es wichtig, dass sich das Team daran gewöhnt, das zu tun, was zur Verbesserung des Prozesses erforderlich ist.

11
William Pietri

Meiner Meinung nach besteht der ideale Ansatz darin, den Infrastrukturaufwand als Aufgaben unter die User Story zu stellen, in der er zuerst Wert hat. wie du schon erwähnt hast.

Nehmen Sie Ihr Beispiel; Das manuelle Erstellen und Bereitstellen bedeutet, dass dies ein fortlaufender Aufwand ist und nicht abgeschlossen werden kann. Es existiert auf unbestimmte Zeit.

Das Gleiche gilt für Code, der einen Teil des Aufwands in einer typischen Anwendung automatisiert, die zuvor manuell ausgeführt wurde. Das Definieren dieses Aufwands als Aufgabe unter einer User Story definiert die Vollständigkeit. was von Natur aus einen Wert für den Endbenutzer hat.

Sie könnten die Anwendung sicherlich bei jedem Sprint erstellen und bereitstellen, aber das wird dann Teil der täglichen Aufgaben, die nicht offiziell über das Backlog verfolgt werden, und dann wird dies alles strittig.

6
Aaron McIver

User Stories definieren einen Business-Wert aus der Sicht des Benutzers. Aus diesem Grund werden Infrastrukturaufgaben im Allgemeinen als "Verschwendung" betrachtet. Das bedeutet nicht, dass sie nicht gebraucht werden. Dies bedeutet, dass mehr Infrastrukturaufgaben weniger geschäftlichen Nutzen bringen. Aus diesem Grund sollten Infrastrukturaufgaben nicht als Benutzerstory betrachtet und nicht an User Stories angehängt werden.

Bei einem Planungstreffen muss das Team überlegen, welche Infrastrukturaufgaben beim nächsten Sprint unbedingt erforderlich sind. Das Engagement wird unter Berücksichtigung dieser Infrastrukturaufgaben erfolgen. Dies wirkt sich auf die Geschwindigkeit des Teams aus. Dies ist das richtige Ergebnis, da die Geschwindigkeit misst, wie viel Geschäftswert das Team liefern kann.

4
Ladislav Mrnka

Ich habe User Stories nie mit dem Wert des Endbenutzers gleichgesetzt. Es mag üblich sein, aber es ist nicht so, wie wir mit User Stories umgehen. Manchmal werden diese Arten von Aufgaben als Spitzen angesehen, aber wir hatten auch regelmäßige User Stories, deren Punkt wie bei jeder anderen User Story geschätzt wird.

2

Nach dem, was ich gesehen habe, wird ein Großteil der Infrastruktur als gegeben angesehen. Dies beinhaltet Dinge wie:

  • Revisionskontrollsystem;
  • Automatisiertes Build-System;
  • IDE und andere Entwicklertools;
  • Entwicklungsserver;
  • Bereitstellungsprozess; und
  • Projektprozess und Standards.

Die meisten Methoden, mit denen ich gearbeitet habe, widmen ihnen nicht viel Aufmerksamkeit. Diese bilden das, was ich Release 0 nenne. Diese Dinge sollten vorhanden sein, bevor Sie mit der Entwicklung beginnen. Sobald Sie mit der Arbeit an den Storys beginnen, können Änderungen an diesen Dingen als Prozessverbesserungen verfolgt werden.

Während das Entwicklungsteam möglicherweise Eingaben hat, sollten die meisten dieser Elemente von einem Projektunterstützungsteam bearbeitet werden. Die Standardisierung dieser Elemente über mehrere Projekte hinweg sollte sich für das Unternehmen erheblich auszahlen.

2
BillThor

Folgendes berücksichtigen:

  • Scrum-Team, das einer vorhandenen Produktsuite wichtige Funktionen hinzufügt.

  • Die Entwicklungstechnologie/Tools/Dienstprogramme müssen aktualisiert werden, um auf der Grundlage der Best Practices für das Engineering auf dem neuesten Stand zu bleiben.

  • Es ist sinnvoll, eine Version mit dieser Arbeit von vorne zu laden, damit Sprints-Probleme im Laufe der Version behoben werden können.

  • Da das Unternehmen aus diesen Elementen einen indirekten Wert erzielt, schlage ich vor, dass dies im Interesse der Transparenz Product Backlog Items (PBIs) sind.

  • Das Team dimensioniert diese Elemente und behandelt sie wie jeden PBI.

Dieses Problem läuft für mich darauf hinaus, dass ich keine Zeit damit verschwenden möchte, herauszufinden, wie diese Arbeit als Aufgaben unter anderen eher geschäftsorientierten PBIs versteckt werden kann.

Ich möchte nicht, dass die PBI-Größe durch diese Art von Infrastrukturarbeit verzerrt wird. Ich möchte sehen, was getan wird und verstehen, wofür ich bezahle.

Ich denke auch, dass es von Wert ist, wenn das Team die Verpflichtung des Unternehmens versteht, indem es in die Infrastruktur investiert, die für die Bereitstellung hochwertiger Lösungen erforderlich ist.

1
Chris

In unserem Team machen wir Folgendes:

  1. Angenommen, ein niedrigerer Fokusfaktor.
  2. Versuchen Sie, solche Aufgaben in User Stories aufzunehmen, die tatsächlich implementiert werden müssen.
  3. Wenn einige Aufgaben unbedingt erforderlich sind, aber keinen direkten Geschäftswert bieten (z. B. das Migrieren von Komponententests von einem Framework zu einem anderen), erstellen wir zu Beginn des Sprints erstellen Sie eine Liste mit "fortlaufenden Aufgaben". Dies sind entwicklungsbezogene Aufgaben, die keine Geschichten sind, aber das Entwicklungsteam möchte, dass sie erledigt werden. Wir listen diese Aufgaben an unserer Tafel auf und halten sie dennoch von Geschichten getrennt. Während des Sprints überprüfen wir bei jedem täglichen Treffen, was getan wurde, um sie zu erreichen.

Der Schritt 2 ist der wichtigste. Wie in einer agilen Praxis versuchen Sie in Scrum, so wenig wie möglich zu tun, um Ihre Aufgaben zu erfüllen. Nehmen Sie es als einen Weg, Ihr Leben nicht mit unnötiger Arbeit zu verschwenden: Meine Erfahrung zeigt, dass bis zu 50% der "coolen" Dinge auf lange Sicht aufgegeben und nicht gewartet werden.

0
P Shved

XP empfiehlt schlägt eine "Iterationsnull" vor, bei der alle Tools und die Infrastruktur eingerichtet sind. Das Schreiben von Geschichten für diese ist optional, aber wahrscheinlich eine gute Idee. Das Testen Ihrer Infrastruktur (inkrementelle Erstellung, automatisiertes Testen und Bereitstellen, Benachrichtigungen usw.) ist von Vorteil

0
Steven A. Lowe