Wie kann ein Scrum-Team mit Budgets umgehen und mit anderen Abteilungen zusammenarbeiten?

In meiner Organisation verwenden die Entwickler Scrum (das kürzlich gestartet wurde), die Systemadministratoren jedoch nicht.

Wir stehen kurz davor, ein großes Projekt zu starten, und wir wurden um eine detaillierte Beschreibung unseres Hardwarebedarfs gebeten, damit er dem Budget hinzugefügt werden kann, und weil die Systemadministratoren eine lange Warteschlange mit Arbeit haben, müssten wir eine anfordern neuen Server weit im Voraus, wenn wir einen brauchen. Die Person, der die Leiter beider Abteilungen unterstellt sind, ist mit dem Prozess nicht voll einverstanden und scheint den Wasserfall zu bevorzugen, daher muss ich mit meinen Vorschlägen möglicherweise vorsichtig sein.

Kann jemand eine bessere oder zumindest mit Scrum konsistentere Methode vorschlagen, um damit umzugehen, als nur zu raten, was wir brauchen, und zu hoffen, dass es sich nicht ändert?

Antworten (2)

Verwenden Sie die Rückstandsschätzung, um Planungswerte bereitzustellen

In Scrum führen Teams zu Beginn eines Projekts häufig einen ersten Durchgang durch das Product Backlog durch (im Allgemeinen auf Themen- oder Epic-Ebene), um den Projektumfang zu definieren und erste Zieltermine festzulegen. Während sich Story Points, Sprint-Ziele und das Product Backlog im Laufe des Projekts häufig ändern, werden Zieldaten im Allgemeinen seltener geändert, wenn sie für das Timeboxing der Projektergebnisse verwendet werden.

Derselbe First-Pass-Prozess kann bei der Bestimmung der Ressourcenanforderungen nützlich sein. Während der Unsicherheitskegel zu Beginn des Projekts am größten ist, ist es dennoch möglich, eine Annäherung basierend auf dokumentierten Annahmen darzustellen.

Wenn Sie beispielsweise eine neue Webanwendung erstellen, können Sie während Ihrer First-Pass-Schätzung des Rückstands Folgendes identifizieren:

  1. Die Notwendigkeit eines Datenbankservers, eines Webservers und eines E-Mail-Servers in jeder Umgebung.
  2. Die Notwendigkeit von drei Umgebungen: Entwicklung, Qualitätssicherung und Produktion.
  3. Eine Voraussetzung für die Hochverfügbarkeit in der Produktion, von der das Team ausgeht, sind ein Hot- und ein Standby-Server pro Dienst.

Sie könnten diese anfänglichen Annahmen nehmen und eine Anfrage für 12 Server stellen, basierend auf dem, was das Team heute weiß . Sie können es sogar als Bereich darstellen, der Ihr Vertrauen in die Annahmen widerspiegelt. Du könntest zum Beispiel so etwas sagen:

Basierend auf der anfänglichen Bewertung der Projektanforderungen durch das Team gehen wir davon aus, dass das Projekt mindestens 12 Server erfordert. Diese Annahmen basieren auf X, Y und Z mit einem aktuellen Konfidenzintervall von etwa 60 %. Wir empfehlen daher, das Projektbudget für 18 Server und die Projektannahmen vierteljährlich zu überprüfen, um festzustellen, ob:

  • Die Ressourcenanforderungen haben sich geändert.
  • Planungswerte bleiben gültig.

Indem Sie Ihren Schätzungsprozess transparent machen, geben Sie der Organisation Einblick in die Annahmen des Projekts und machen deutlich, dass es sich um Schätzungen handelt, die im Zuge der Entwicklung des Projekts und der Verengung des Unsicherheitskegels im Gegensatz zu festen Garantien revidiert werden können . Schließlich ist die Fähigkeit zur Überprüfung und Anpassung das Markenzeichen eines agilen Prozesses und gibt dem Management die Hebel an die Hand, die es braucht, um das Projekt erfolgreich zu steuern.

Gute Antwort. Danke dir. Der Satz make it clear that these are estimates that can be revised as the project evolvesist wirklich das Herzstück der Frage, die ich stellen wollte. Es ist der Teil, von dem ich nicht erwarte, dass er gut aufgenommen wird. Hast du dafür einen Rat?
@Ivy Ehrlichkeit und Transparenz helfen sehr. Wenn Sie die Annahmen, die den Planungswerten zugrunde liegen, klar artikuliert haben, haben Sie Ihre Aufgabe erfüllt. Ob sich andere über die Planungswerte freuen , können Sie allerdings nicht kontrollieren; das ist unter ihrer Kontrolle, nicht bei Ihnen.

Scrum konzentriert sich auf die Entwicklungsarbeit, die über ein festgelegtes Intervall (z. B. Iteration oder Sprint) erbracht wird.

Wenn das Scrum-Team die Hardware nicht physisch einrichtet, gilt das Scrum-Framework nicht für Ihre Situation.

Für Agile-Scrum-Projekte gibt es Planungsanforderungen auf hoher Ebene, zu denen auch die Erstellung einer Produkt-Roadmap gehört. Diese Roadmap sollte den Fortschritt von Epics oder Features skizzieren und ausreichend Details enthalten, um abzuschätzen, wann zusätzliche Hardwareressourcen hochgefahren werden müssen.

Hardware besteht normalerweise aus zwei Budgetierungskomponenten; feste, wiederkehrende Kosten für Wartung/Support der Hardware plus eine einmalige Kauf- oder Konfigurationsgebühr. Es hängt wirklich davon ab, ob Ihr Projekt Cloud/VM/physische „Server“ verwendet, aber diese Kosten können leicht zu Beginn eines Wasserfall- oder Agile-Projekts budgetiert werden.

Die wiederkehrenden und einmaligen Kosten für ein Agile-Scrum-Projekt können alle aus der Produkt-Roadmap abgeleitet werden, und die Systemadministratoren müssen die Wörter Agile, Scrum, Wasserfall usw. nicht erwähnen.

Denken Sie daran, dass die Budgetierung eine Schätzungsübung ist. Unabhängig davon, ob es sich bei Ihrem Projekt um ein Wasserfall- oder Scrum-Projekt handelt, enthalten die meisten Budgets eine prozentuale Absicherung gegen Unsicherheit.

Wie kann ein Scrum-Team mit Budgets umgehen und mit anderen Abteilungen zusammenarbeiten?
AntwortenHierDatenschutz-Bestimmungen1y, 0v