Warum brauche ich SCRUM im Vergleich zu einem weniger formalen und leichtgewichtigen Prozess für mein Team?

Ich möchte meine Frage damit beginnen, dass ich verstehe, dass SCRUM oder ein Derivat davon wahrscheinlich ein guter Weg ist, um die Softwareentwicklung zu verwalten. Es scheint, dass alle großen Unternehmen und meine Manager es nutzen oder genutzt haben, und ich kann mit all dieser Erfahrung nicht wirklich streiten. Ich kämpfe jedoch darum, das "Warum" zu verstehen, und all das Lesen und sogar mein offizielles SCRUM-Training bei der Arbeit machen den Job nicht für mich. Es ist nur alles Rhetorik. Also komme ich hierher und suche nach Antworten.

Bis jetzt habe ich mich in Teams von 4 bis 5 Mitgliedern sehr effektiv entwickelt, vollständig selbstorganisiert und ohne die Notwendigkeit von Schulungen, Methoden oder spezieller Software. Nur Diskussionen in Würfeln, Ad-hoc-Besprechungen und eins-zu-eins-Codeüberprüfungen. Ich bin jetzt in einer Position auf der Arbeit, in der uns gesagt wird, dass SCRUM der richtige Weg ist und alles, was damit einhergeht. Wenn sie mir SCRUM beschreiben, lese ich so etwas:

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Arbeitssoftware über umfangreiche Dokumentation
• Zusammenarbeit der Kunden bei Vertragsverhandlungen
• Reaktion auf eine Umstellung nach einem Plan

Das ist großartig, aber alles scheint mir ein gesunder Menschenverstand zu sein. Warum musste dies kodifiziert werden? Dann wurde mir gesagt, dass die Methodik uns hilft, auf Veränderungen zu reagieren. Was genauAspekte von SCRUM ermöglichen es mir, so flexibel zu sein, wie ich es mit meinen Ad-hoc-Meetings, Cube-Diskussionen und Entwickler-Planungs-Meetings noch nicht erreicht habe? Sie erklären die Notwendigkeit, alle zwei Wochen ein funktionierendes Ergebnis zu erzielen oder zu sprinten. In meinem speziellen Projekt gibt es keinen "Client", die Software wird ein Jahr oder länger nicht fertig sein, und in der Zwischenzeit werde ich wahrscheinlich nur jeden Monat oder weniger dem oberen Management vorführen. Warum also die ausdrückliche Notwendigkeit einer Lieferung alle zwei Wochen? Sie unterstreichen die Bedeutung des Sprint-Planungstreffens, bei dem das gesamte Team die Geschichten und Aufgaben für den nächsten Sprint festlegt. Dies ist nicht anders als die spontanen Planungsmeetings, die ich in der Vergangenheit hatte. Warum muss es jeden zweiten Montag auftreten, und warum muss das gesamte team einbezogen werden? Ich verstehe das Konzept, dass jedes Mitglied das Produkt "besitzt", aber Tatsache ist, dass nur wenige Einzelpersonen jemals wirklich dazu beitragen können, jede Geschichte in Aufgaben aufzuteilen, während der Rest nur untätig zusieht.

Ich verstehe erneut, dass die Mehrheit der Menschen hinter diesem Prozess steckt, und daher muss es funktionieren, und ich muss an Bord gehen. Ich möchte nur verstehen, warum. Ist mein Problem, dass ich diese Dinge bereits praktiziere und es einfach nicht mag, sie unnötig zu kodieren? Oder habe ich die Vorteile dieser Techniken noch nicht erkannt, weil sie nicht ordnungsgemäß ausgeführt werden? Jede reale , persönliche Information oder Beratung in dieser Hinsicht, im Gegensatz zu dem Spiel, an das ich gewöhnt bin, wäre sehr dankbar.

Ich denke, es gibt zwei Aspekte, um Ihre Frage zu beantworten, aber lassen Sie mich zunächst gratulieren, dass Sie mit Menschen zusammengearbeitet haben, die klug und kompetent genug scheinen, um so gut wie ohne einen genau definierten Prozess zu arbeiten und dennoch ein Produkt zu liefern. Leider ist dies nicht bei allen Softwareteams der Fall. Möglicherweise besteht eines Ihrer Probleme mit Scrum darin, dass Sie und Ihre Kollegen keinen Prozess benötigen, der auf Sie angewendet wird, um Ihre Effektivität zu steigern. Möglicherweise sind Sie bereits wirksam.

Andere Teams sind nicht und brauchen einen strengeren Prozess und einige Richtlinien, um sie dazu zu bringen, Dinge zu erledigen. Dies bedeutet nicht, dass diese Teams dümmer oder weniger fähig sind, sondern nur, dass sie Probleme haben, sich selbst zu organisieren oder als Team mit Disziplin zu arbeiten. Dies kann auch eine einfache Lernerfahrung sein, wenn Sie von einem Ort kommen, an dem die meisten Menschen allein arbeiten, um als Team zusammenzuarbeiten. Scrum kann dabei behilflich sein, da es einige Richtlinien enthält, die sowohl leicht zu verstehen als auch zu befolgen sind und dennoch effektiv genug sind, um Druck auf das Team auszuüben, damit es sich zusammensetzt.

Da Scrum nichts über die Art und Weise sagt, wie Software entwickelt werden soll, hat das Team auch die Freiheit, selbst zu entscheiden (z. B. können Sie nach wie vor einen Sprint mit einer eher konservativen Wasserfallmethode durchführen, solange Sie am Start sind Ende des Sprints).

Das Team ist also ein Thema. Das andere Problem ist das Management und das Managementvertrauen. Hier könnte Scrum gut sein, weil es transparent ist und es allen Beteiligten ermöglicht, den Fortschritt des Teams in definierten Zyklen zu sehen. Es ist also nicht "Wir machen Fortschritte, leider können wir Ihnen im Moment nichts zeigen, aber glauben Sie uns, wir werden pünktlich fertig sein". Dies mag sogar zutreffen, aber es kann für jeden Manager beruhigend sein, tatsächlich eine regelmäßige Demo zu haben, in der er sehen kann, dass tatsächlich Fortschritte erzielt wurden.

Scrum ist keine Wunderwaffe. Für einige Teams funktioniert dies aus verschiedenen Gründen möglicherweise nicht, für einige Teams funktioniert die Selbstorganisation möglicherweise nicht. Für Sie ist es vielleicht umgekehrt, und es scheint, als wäre ein Prozess auf ein bereits produktives und organisiertes Team verlagert worden.

Im Zweifelsfall empfehle ich Ihnen, es einfach zu versuchen und zu sehen. Wenn es nicht funktioniert und der größte Teil des Teams nicht gerne so arbeitet, tun Sie es nicht. Probieren Sie es jedoch für ein paar Monate aus (ich sage, ein paar Monate, da die ersten Sprints sowieso umständlich sind und Sie Zeit brauchen, um die Details anzupassen) und werten Sie es dann erneut aus.

Könnte umstritten sein, aber Scrum ist am besten geeignet, um die Ängste des Managements vor Agile abzubauen oder um es mit einem Team zu nutzen, das bereits unterdurchschnittlich abschneidet. Wenn Ihr Team großartig läuft, Ziele erreicht, Geld verdient und glücklich ist, wird Scrum Ihnen nichts kaufen, weil alles, was Sie tun, die Ausgewogenheit Ihrer Aktivitäten stören wird (und Ihr Team erfolgreich macht). Scrum ist keine Wunderwaffe. Nach meiner Erfahrung hilft es nur Teams, die von Anfang an eine schlechte Einschätzung und Kommunikation hatten. Ein Team, das mit realistischen Schätzungen in einem Umfeld effektiver Kommunikation arbeitet, wird nur durch den Prozessaufwand von Scrum behindert.

Ob Sie es glauben oder nicht, es gab gute Software-Teams, bevor Scrum hinzukam. Scrum hilft den Bösen, besser zu werden.

Die meisten Antworten hier haben den Grund bereits aufgezählt, wenn auch etwas indirekt. Annes Antwort ist besonders aufschlussreich, wenn sie sich mit Transparenz befasst. Das heißt, Manager können sehen, was los ist. Und Schultz antwortet auch darauf, wenn er davon spricht, dass die Leute nicht in der Lage sind, die Tatsache zu verbergen, dass sie nachlassen.

Ich möchte also sagen, was andere bereits sagen, aber in einer direkteren Sprache: Das Hauptziel von SCRUM ist nicht die Verwaltung der Softwareentwicklung, sondern die Messung der Softwareentwicklung.

Andere Systeme haben es bereits versucht, und die Leute haben unzählige Metriken vorgeschlagen, um die Softwareentwicklung zu messen, sind jedoch gescheitert. SCRUM stellt das Problem auf den Kopf und verlagert die Messlast von den Managern auf die Entwickler. Die Logik ist einfach: Wer kann besser einschätzen, wie lange es dauert, etwas zu tun, als diejenigen, die die Arbeit selbst erledigen?

Das Problem dabei ist, dass Programmierer dafür bekannt sind, zu optimistisch zu sein. Fragen Sie einen Programmierer, wie lange es dauert, etwas zu tun, und er wird in der Regel unterschätzen, wie schwer die Aufgabe tatsächlich ist. SCRUM bietet die Tools, um dies zu steuern:

• Tägliche Besprechungen, um den Fortschritt zu messen und sich einen Überblick über das Projekt zu verschaffen
• Schätzungen werden in "Punkten" anstelle von Stunden / Tagen durchgeführt, um die Abwesenheitszeit abzugrenzen
• Burn-Down-Charts und Tortise / Hare-Charts zur Visualisierung der Geschwindigkeit von Punkten
• Geschichten und Aufgaben auf einer Tafel, um einen Überblick über die Arbeitsbelastung zu erhalten
• Sprints und Iterationen dienen als Fristen, damit wir den Fortschritt messen können
• Spezielle Rollen für Scrum Master, Eigentümer und Teammitglieder, um der Versuchung zu entgehen, zu betrügen

etc.

Möglicherweise stellen Sie fest, dass alle oben genannten Funktionen hauptsächlich zwei Funktionen haben:

1. Sie messen die Arbeit. Entweder zu erledigende Arbeit oder zu erledigende Arbeit oder abgeschlossene Arbeit.
2. Sie versuchen sehr, das Problem des überoptimistischen Programmierers zu umgehen, um eine bessere, realistischere Schätzung zu erhalten.

Je länger Sie SCRUM implementieren, desto genauer wird Ihre Schätzung. Ich persönlich bin der Meinung, dass das Ausführen von Sprints + einem Rückstand + einem Burn-Down-Diagramm ausreicht, um die meisten Programmierer davon abzuhalten, schlechte Schätzungen darüber vorzunehmen, wie lange es dauert, etwas zu tun.

Persönlich denke ich, dass der Zweck von SCRUM darin besteht, ältere Organisationen zufrieden zu stellen, bei denen das obere Management nicht hinter einen schlankeren Prozess kommen kann oder wird. Ich arbeite seit ungefähr einem Jahr als Architekt (Chicken) in einer Abteilung, die SCRUM stark nutzt. Mein vorheriger Hintergrund sind Silicon Valley-Startups, von denen die meisten einen viel schlankeren, ad-hoc und stark iterativen (manchmal wöchentlichen oder sogar täglichen Pushs), auf Funktionen fokussierten Prozess verwendeten. Ich finde SCRUM zumindest so, wie wir es implementieren, prozessseitig übertrieben (und in gewisser Weise schwerer als Wasserfall (zumindest aus Entwicklersicht). Um fair zu sein, möchte ich sagen, dass ein Aspekt unseres Prozesses dies ist Abweichend ist, dass unsere Produktverantwortlichen eher mit Anforderungsanalysten in der IT-Organisation verwandt sind. Infolgedessen tendieren sie dazu, die aus dem Geschäft stammenden Informationen zu stumpfen und das Geschäft für das Entwicklungsteam unerklärlich zu machen (was regelmäßige, aufeinanderfolgende Infusionen von User Stories erfordert). Trotzdem würde ich in meinem zukünftigen Startup keinen SCRUM verwenden. Ich würde es wahrscheinlich nur in der Situation verwenden, in der die Verwaltung den zusätzlichen Aufwand erfordert.

Ich werde nicht aus puristischer Sicht sprechen. Ich habe das Gefühl, dass Sie es in ähnlicher Weise ausführen können, wie es Scrum sagt. Der wichtigste Punkt ist jedoch Ihre Fähigkeit, die Show zu leiten. Was passiert, wenn Sie einen Monat im Urlaub sind?

Ich sehe Scrum als Mechanismus, um alles, was Sie getan haben, zu rationalisieren und einige definierte Aspekte darauf abzulegen. Damit in Ihrer Abwesenheit jemand anderes es auch replizieren und auf andere Projekte replizieren kann. Scrum ist jedoch keine Wunderwaffe. Ich habe viele Leute gesehen, die gerade mit Scrum angefangen haben (weil es in Mode ist) und schlecht geschlagen wurden, weil sie das Wesentliche nicht verstanden haben.

PS: Scrum schreibt nicht vor, dass Ihr Sprint zwei Wochen dauern muss. Es kann einen Monat dauern (Ihr Fall).

Bitte lesen Sie zuerst meine Kommentare zur Frage.

SCRUM ist ein agiles Softwareentwicklungsparadigma. Als solches ist es selbst agil. Es wird nicht vorausgesetzt, dass Sie seinem klassischen Modell folgen müssen . Und ich bezweifle, ob das tatsächlich jemand tut. Ich habe in mehreren Organisationen gearbeitet und jedes Team hat es an ihre Bedürfnisse angepasst. Es ist nicht ungewöhnlich, dass es keinen Kunden / Konsumenten gibt, der ein öffentliches Produkt / eine Bibliothek / eine API veröffentlicht. Ich hatte nie einen In meinem Fall hat unser GM als einer gehandelt, was meiner Meinung nach mit keinem vergleichbar war.

2 Wochen Sprints zu haben ist schwierig. Sehr mutig. 3 Wochen ist besser, ist aber wirklich für erfahrene und mit dem Prozessteam vertraute. Wir hatten 4 Wochen oder einen Monat. Das gab uns genug Zeit, uns sozusagen am Anfang "zurechtzufinden" und am Ende mehr Selbstvertrauen zu haben, da wir während des gesamten Testens mehr Zeit hatten. Mir hat das gefallen und ich würde mich mindestens an 3 Wochen halten.

Das andere Team, mit dem ich zusammengearbeitet habe, hatte nur einen Rückstand. Sie trafen sich, berichteten über den Status und was als nächstes kommt und das wars. Sobald alles erledigt war, würden sie sich einen weiteren Rückstand einfallen lassen. Sie wussten, dass es nicht SCRUM war, aber es funktionierte für sie und das ist wichtig.

Ist es leichter? Es ist definitiv so. Aber es ist nicht SCRUM. Was ich an SCRUM mag, ist, dass es Disziplin fördert. Die Leute haben das Gefühl, jeden Tag etwas zu liefern. Jeder weiß, was andere tun und er scheitert, das wird jeder wissen. Selbst wenn man versucht, dies zu vertuschen (Lüge lesen), wird dies viel früher als bei anderen Prozessen offensichtlich. Wenn Sie also von diesem Team abweichen und es vereinfachen, müssen Sie sicherstellen, dass Sie dies mit den richtigen Leuten tun. Andernfalls kann es sehr schnell zu bedeutungslosen Statusmeetings führen, bei denen jeder einfach bleibt und denkt: "Was mache ich hier? Ich weiß, was ich tun muss, was zur Hölle?"

Das sind meine zwei Cent. Ich mache meine eigene SCRUM-ähnliche Entwicklung: Planen Sie die Arbeit, teilen Sie sie in Aufgaben auf, schätzen Sie sie ein und beobachten Sie den Fortschritt. Es hilft mir wirklich, den Überblick zu behalten. Ich habe einige Dinge von SCRUM auf Projekte angewendet, die ich ausgelagert habe, und es hat großartig für mich funktioniert.

Bleib einfach ... agil ;-)

Ich empfehle dir Scrum zu ignorieren. In ein paar Jahren wird eine neue Modeerscheinung auf Sie zukommen, und Sie werden weniger zynisch sein und es dennoch von ganzem Herzen annehmen können. Tatsächlich könnten Sie schnell ein Experte werden. Dann können Sie viel Geld verdienen, indem Sie ein Buch darüber schreiben und auf Konferenzen sprechen.

Da viele Dinge zyklisch sind, wird diese neue Modeerscheinung höchstwahrscheinlich ein schwerer Prozess sein, der RUP ähnelt. Was passiert sein wird, ist, dass jeder leichte agile Prozesse befolgt hat und diese für ihre Projektfehler verantwortlich gemacht werden. Die logische Lösung ist also, dass mehr Vorausplanung und Design erforderlich sind!

Im Ernst, ich glaube nicht, dass Sie Scrum brauchen. Nichts in Scrum ist besser als andere konkurrierende agile Prozesse. Es hat auch viele dumme Namen für Dinge.

Das ist großartig, aber alles scheint mir ein gesunder Menschenverstand zu sein. Warum musste dies kodifiziert werden?

Scrum wird normalerweise mit älteren, schwergewichtigeren Methoden verglichen. Die Methoden versuchten, den rückkopplungsfreien Wasserfall funktionsfähig zu machen, indem mehr Dokumente, mehr Abnahme und mehr Planung im Voraus erzwungen wurden. Das Agile Manifest (das Sie zitieren) war eine Umkehrung dieser Ideen.

Dann wurde mir gesagt, dass die Methodik uns hilft, auf Veränderungen zu reagieren. Welche spezifischen Aspekte von SCRUM ermöglichen es mir, so flexibel zu sein, wie ich es bei meinen Ad-hoc-Besprechungen, Cube-Diskussionen und Entwicklerplanungsbesprechungen bisher nicht erreicht habe?

Es hört sich so an, als ob Sie bereits eine agile Struktur haben. Wenn Sie bereits gut auf Änderungen reagieren, brauchen Sie offensichtlich keine Hilfe. Einige Prozesse sind mit der Prozedur so eng verbunden, dass die Behebung eines Fehlers eine vollständige Analyse- und Funktionsentwurfsphase erfordert und frühestens im nächsten Jahr in das Projekt einbezogen werden kann.

Sie erklären die Notwendigkeit, alle zwei Wochen ein funktionierendes Ergebnis zu erzielen oder zu sprinten. In meinem speziellen Projekt gibt es keinen "Client", die Software wird ein Jahr oder länger nicht fertig sein, und in der Zwischenzeit werde ich wahrscheinlich nur jeden Monat oder weniger dem oberen Management vorführen. Warum also die ausdrückliche Notwendigkeit einer Lieferung alle zwei Wochen?

Original Scrum schreibt monatelange Sprints vor. Bei der Verkürzung von Sprints gibt es einen unangenehmen Trend zum agilen Machismo. ("Ja, unsere Sprints dauern nur einen Tag ...") Der Kunde / Auftraggeber ist derjenige, der befugt ist, zu sagen, dass das Projekt in Ordnung ist oder mehr Arbeit benötigt. Wenn Sie sich jeden Monat an das obere Management wenden, handelt es sich wahrscheinlich um Ihren Kunden, und Sie stehen Scrum wahrscheinlich bereits sehr nahe.

Basierend auf Ihrer Beschreibung, was Ihr Team tut, ist Scrum wahrscheinlich nicht viel anders. Wenn Sie die Scrum-Begriffe verwenden, können Sie Außenstehenden leichter erklären, was passiert, wenn Sie sie standardisieren. Scrum kann auch als Schutzschild verwendet werden. Beispielsweise schreibt Scrum vor, dass technische Entscheidungen vom Team getroffen werden sollten. Dieses Prinzip kann ein guter Weg sein, um einen technischen Wert zu erzielen, der ansonsten schwer zu verkaufen ist (z. B. Pair-Programmierung).

Scrum ist im Grunde eine Schnittstelle, die Ihr Team implementieren kann. Wenn Sie dies tun, haben Sie eine gute Vorstellung davon, wie Sie mit Personen außerhalb des Teams kommunizieren können, und sie haben eine gute Vorstellung davon, wie Sie mit Ihnen kommunizieren können. Nur Sie können wissen, ob Ihr Team dies benötigt.

Wir verwenden Scrum nicht bei der Arbeit. Wir verwenden eine Methodik, die auf Agile und Lean basiert und in vielerlei Hinsicht ähnlich ist. Ich habe diesen Prozess in Teams mit einer Größe zwischen 3 und 5 Personen einschließlich des Leaders angewendet. Obwohl es Unterschiede gibt, denke ich, können Sie vielleicht herausfinden, ob Scrum für Ihre Situation nützlich ist.

Die Methodik erweitern

Wir machen unseren Prozess explizit, weil wir unseren Prozess bei jeder Sprint-Zusammenfassung / Überprüfung überprüfen. Ein Teil der Zusammenfassung / Überprüfung besteht darin, Praktiken zu identifizieren, die für uns nicht funktionieren. Wir besprechen auch Praktiken, von denen wir glauben, dass sie für uns funktionieren werden, und wenn es genug Übereinstimmung gibt, werden wir es ausprobieren. Wir wären dazu nicht in der Lage, ohne unsere Methodik zu kodifizieren.

Abmelden

Dies ist das Arbeitstier für unseren Prozess. Dies garantiert, dass das, was wir schreiben, das ist, was benötigt wird. Wenn wir eine bestimmte Funktion erhalten, gehen wir zu unserem Kunden. Der Kunde ist derjenige, der das verwendet, was Sie schreiben. In einigen Fällen müssen Sie den Kunden mit einer Person vertreten, die den Kunden vertritt (z. B. Produktmanagement). Dies sind unsere Schritte, und bis der letzte Schritt abgeschlossen ist, wird die Funktion nicht ausgeführt.

• Holen Sie sich das Feature vom Board, Tracker usw.
• Sprechen Sie mit dem Kunden und verstehen Sie, wonach er sucht, bevor Sie etwas schreiben.
• Implementieren Sie die Funktion.
• Zeigen Sie dem Kunden das Funktionsmerkmal in seiner endgültigen Form. Lassen Sie den Kunden das Funktionsmerkmal abmelden, damit es vollständig ist.

Vertikale Scheiben

Wir entwickeln alles in vertikalen Schichten. Dies unterstützt die Möglichkeit, sich mit einer abgeschlossenen Funktion abzumelden, sowie diese anderen Gründe.

• Amortisiert Integrationsprobleme, indem sie für jedes Feature hinzugefügt werden. Hilft bei der Eliminierung der Crunch-Zeit am Ende eines Projekts.
• Ermöglicht das einfache Ausschneiden von Features, da viele der Kreuzabhängigkeiten beseitigt werden.
• Ermöglicht es uns, die Entwicklung abzubrechen, wenn wir die Richtung ändern müssen.
• Wir können iterative Releases durchführen , um den Kunden frühzeitig mit Funktionen zu versorgen.

Abnahme TDD

Wir nutzen Unit-Test-Frameworks für die Akzeptanz von Tdd. Das bringt uns viele Vorteile.

• Große Umstrukturierungen kosten nicht viel Zeit für die Überarbeitung von Tests.
• Wir stellen die Kundenfunktionalität sicher.
• Wir behandeln die Code-Integration.
• Unterstützen Sie die vertikale Slice-Entwicklungspraxis.

Der Build kann immer freigegeben werden

Nach jedem Tastendruck sollte der Code wieder freigegeben werden können. Auch wenn das Feature unvollständig ist, sollte nichts kaputt gehen. Alle Tests sollten ausgeführt werden und alle vorherigen Funktionen sollten vorhanden sein. Dies ist wirklich eine Erweiterung unserer vertikalen Slice-Entwicklung. Als solches teilt es viele der gleichen Vorteile.

• Ermöglicht das einfache Ausschneiden von Features, da viele der Kreuzabhängigkeiten beseitigt werden.
• Ermöglicht es uns, die Entwicklung abzubrechen, wenn wir die Richtung ändern müssen.
• Wir können iterative Releases durchführen , um den Kunden frühzeitig mit Funktionen zu versorgen.

Kontinuierliche Integration

Jeder Push generiert einen Build über unseren CI-Build-Server. Der Build-Server checkt den Code aus, durchläuft die gesamte Testsuite, markiert den Code und packt ihn für die Bereitstellung. Verstärkt unsere Politik, dass der Build immer freigegeben werden kann.

Punktschätzung für Karten

Jeder Fehler, jedes Feature und jede Aufgabe wird zur "Karte". Eine Karte ist die kleinste logische Arbeitseinheit mit einem gewissen Kundennutzen. Wir weisen darauf hin, entsprechend unserer Skala. Alle, die unseren Maximalpunktwert überschreiten oder weiter aufgeschlüsselt sind. Wir haben festgestellt, dass je größer der Punktwert ist, desto größer die Abweichung in der Zeit bis zur Fertigstellung sein kann, wodurch große Karten weiter zerlegt werden. Wenn die Karte mehrdeutig genug ist, wird sie auf den nächsten Punktwert in der Skala aufgerundet. Jede Karte muss abgemeldet werden, bevor sie als vollständig angesehen werden kann. Die richtige Schätzung unterstützt unsere Fähigkeit, die Geschwindigkeit zu berechnen.

Geschwindigkeit

Wir haben einwöchige Sprints. Jeden Freitag planen wir die Arbeit und priorisieren sie für die nächste Woche. Basierend auf unserer Geschwindigkeit haben wir eine gute Vorstellung davon, wie viel "Arbeit" wir in der Woche leisten können. Unsere Geschwindigkeit ist der Mittelwert und der Median der Gesamtpunktzahl innerhalb einer Woche. Erhöhungen der Standardabweichung werden auf schlechte Schätzungen (die immer versuchen, besser zu werden) oder auf vermehrte Unterbrechungen (über die ich mit dem Manager spreche) hin analysiert. Die Geschwindigkeit kann auch verwendet werden, um ein genaues Fertigstellungsdatum für ein Projekt zu schätzen, aber nur, wenn es das einzige Projekt ist, an dem gearbeitet wird.

Inkrementelle Verbesserung und Design

Wir haben auch die Richtlinie, den Code in einem etwas besseren Zustand zu belassen, als Sie ihn vorgefunden haben. Refactor / Neugestaltung des Codes am Kartenanfang. Ziel ist es, dem organischen Wachstum Rechnung zu tragen, das bei einer schrittweisen Entwicklung vorherrschen kann. Wir überarbeiten auch am Ende ganz normal.

Zum größten Teil sind dies die Regeln, denen wir folgen und warum wir ihnen folgen.

Es hört sich für mich so an, als ob Sie in einem sehr erfahrenen, hoch funktionierenden Team wären. Herzlichen Glückwunsch, Scrum / Agile formalisiert im Grunde genommen, was Ihr Team die ganze Zeit gedacht hat.

Ich denke, was für Ihr (gesamtes) Unternehmen von Vorteil sein kann, ist die Übernahme von Scrum als "gemeinsame Basis", nicht zwischen den Mitgliedern Ihres Entwicklungsteams, sondern zwischen Ihrem Entwicklungsteam und der gesamten Geschäftsabteilung .

Während Scrum Sprints mit einer Zeitbox versehen sind, können die Teams zwischen zwei Wochen und einem Monat wählen. Weniger und es gäbe zu viele Bewertungen und Rückblicke, und weitere könnten die Fähigkeit des Unternehmens beeinträchtigen, innerhalb eines Jahres die Richtung zu ändern. Es hört sich so an, als hätten Sie Ihren Sweet Spot von 1 Monat gefunden.

Sie haben viel Spielraum, um die Scrum-Parameter anzupassen, und ich bin sicher, Sie können Ihrem Unternehmen erklären, dass Sie Scrum immer noch richtig ausführen. Ein Vorteil ist, dass wenn Sie das Geschäft auf halbem Weg treffen, ihre Beteiligung positive Unterstützung bringen kann.