Wie berücksichtigt ein Scrum-Team Infrastrukturaufgaben im Planungsmeeting?

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

Auf den ersten Blick scheinen sie keine User Stories zu sein, da sie keinen Mehrwert für den Endbenutzer bieten.

Es ist jedoch manchmal auch nicht sinnvoll, sie als Aufgaben an eine bestimmte User Story anzuhängen. Angenommen, die Aufgabe lautet: "Bamboo 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.

Das deutet also darauf hin, dass diese Aufgaben zu User Stories werden. Wenn die Team-Story auf sie verweist, ändert sich die Geschwindigkeit, die ungerade ist, da der Product Owner die Geschwindigkeit anhand seines Backlogs und nicht anhand seines Backlogs mit einer Reihe von technischen User-Storys ermitteln möchte.

Es sind eigentlich keine User Stories. Sie sind Stakeholder-Geschichten. Sofern die Software nicht direkt von den Benutzern bezahlt wird, ist es selten, dass eine Story ausschließlich zu deren Gunsten erstellt wird.

Ich gebe Ihnen ein paar Beispiele:

• Keyword-Artikel, mit denen Werbetreibende effektivere Anzeigen schalten können
• CAPTCHAs, die verhindern, dass Moderatoren Spam manuell bearbeiten müssen.

Die meisten technischen Geschichten bieten tatsächlich einen Geschäftsvorteil, aber nur selten für die Benutzer. 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>.

Hierbei werden alle Arten von Interessengruppen, einschließlich des Entwicklungsteams, ausdrücklich berücksichtigt. 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-Posts dazu geschrieben: Es handelt sich nicht um User Stories , Feature Injection und den Umgang mit technischen Stories . Ich hoffe, sie helfen.

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

Mach sie nach und nach.

Wenn es kein Stakeholder will, mache es nicht zu einer Geschichte. Pass einfach auf, ein bisschen nach dem anderen. Zum Beispiel, wenn Sie das erste Mal manuell bereitstellen. Beim zweiten Mal automatisieren Sie ein bisschen davon. Beim dritten Mal automatisieren Sie etwas mehr. Letztendlich ist dein Build nicht das größte Problem, also konzentrierst du dich auf etwas anderes.

Sie werden am Anfang mehr von diesen entwicklerorientierten Aufgaben haben, und das ist in Ordnung; Ihre Geschwindigkeit (gemessen an Geschichten) wird nur niedriger sein. Das ist eine korrekte Darstellung der Situation. Aber Sie werden immer welche haben, deshalb ist es wichtig, dass sich das Team daran gewöhnt, das Notwendige zu tun, um den Prozess zu verbessern.

Meiner Meinung nach besteht der ideale Ansatz darin, den Aufwand für die Infrastruktur als Aufgabe in die User Story einzubeziehen, in der er zunächst Wert hat. wie du erwähnt hast.

Nimm dein Beispiel; Das manuelle Erstellen und Bereitstellen bedeutet, dass es sich um eine fortlaufende Anstrengung handelt und keine Form der Fertigstellung aufweist. Es existiert auf unbestimmte Zeit.

Dasselbe gilt für Code, der in einer typischen Anwendung, die zuvor manuell ausgeführt wurde, jeden Teil des Aufwands automatisiert. Definieren Sie diesen Aufwand als Aufgabe unter einer User Story als abgeschlossen. die von Natur aus 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 formell über den Backlog verfolgt werden, und dies alles wird dann streitig.

User Stories definieren einen Geschäftswert aus der Benutzerperspektive. Aus diesem Grund werden Infrastrukturaufgaben im Allgemeinen als "Abfall" betrachtet. Das heißt nicht, dass sie nicht gebraucht werden. Dies bedeutet, dass mehr Infrastrukturaufgaben weniger geschäftlichen Nutzen bringen. Aus diesem Grund sollten Infrastruktur-Tasks nicht als User-Storie betrachtet und keinen User-Stories zugeordnet werden.

Bei einem Planungsmeeting 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.

Ich habe User Stories nie mit der Notwendigkeit gleichgesetzt, dem Endbenutzer einen Mehrwert zu liefern. Es mag üblich sein, aber es ist nicht so, wie wir mit User Stories umgehen. Manchmal werden diese Arten von Aufgaben als "Spikes" bezeichnet, aber wir haben auch regelmäßige User Storys, die wie jede andere User Story geschätzt werden.

Soweit ich weiß, wird ein Großteil der Infrastruktur als gegeben angesehen. Dies beinhaltet Dinge wie:

• Revisionskontrollsystem;
• Automatisiertes Build-System;
• IDE und andere Entwicklertools;
• Entwicklungsserver;
• Bereitstellungsprozess; und
• Projektablauf 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 anfangen, an den Geschichten zu arbeiten, können Änderungen an diesen Dingen als Prozessverbesserungen nachverfolgt 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 dürfte sich für das Unternehmen auszahlen.

Folgendes berücksichtigen:

• Das Scrum-Team erweitert eine vorhandene Produktsuite um wichtige Funktionen.

• 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, ein Release mit dieser Arbeit vorab zu laden, damit Sprints-Probleme im Laufe des Releases behoben werden können.

• Da das Unternehmen indirekten Wert aus diesen Artikeln bezieht, schlage ich im Interesse der Transparenz vor, dass es sich um Product Backlog Items (PBIs) handelt.

• Das Team bewertet diese Elemente und behandelt sie wie jede PBI.

Dieses Problem ist für mich darauf zurückzuführen, dass ich keine Zeit damit verschwenden möchte, herauszufinden, wie ich diese Arbeit als Aufgabe unter anderen geschäftsorientierten PBIs verstecken kann.

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

Ich halte es auch für sinnvoll, dass das Team das Engagement des Unternehmens versteht, indem es in die Infrastruktur investiert, die für die Bereitstellung hochwertiger Lösungen erforderlich ist.

XP empfiehlt eine "Iterationsnull", 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

In unserem Team machen wir Folgendes:

1. Nehmen Sie einen niedrigeren Fokusfaktor an .
2. Versuchen Sie, solche Aufgaben in User Stories einzubeziehen , die tatsächlich implementiert werden müssen.
3. Wenn einige Aufgaben absolut notwendig sind, aber keinen direkten geschäftlichen Nutzen bringen (wie das Migrieren von Komponententests von einem Framework auf ein anderes), erstellen wir zu Beginn des Sprints 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 den Geschichten getrennt. Während des Sprints überprüfen wir bei jedem täglichen Meeting, was getan wurde, um diese Ziele 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 eine Möglichkeit, Ihr Leben nicht damit zu verschwenden, unnötige Arbeit zu verrichten: Meine Erfahrung zeigt, dass bis zu 50% der Dinge, die "cool" sein würden, auf lange Sicht aufgegeben und nicht mehr gepflegt werden.