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

25

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.


quelle
Ich bin nicht sicher, ob ich verstehe, was Sie unter "leichter" verstehen. Ist das wie ... gar nichts? Kein Prozess? Oder wie einige Spezifikationen, JIRA-Aufgaben und individuelle Entwicklerbeiträge? Bitte klären Sie, was Sie damit meinen.
Schultz9999
du brauchst es nicht Ich bin sicher, dass Scrum als Modell für größere Teams fungiert, in denen es mehr Variablen gibt, als Sie sich vorstellen können, oder in Situationen, in denen der Manager kein guter natürlicher Anführer ist und eine Art Schulungsvideo / -vorlage benötigt, um zu folgen. Es hört sich so an, als ob Sie in keine dieser Kategorien fallen, also mein Beileid. ein anderes gutes Team beißt den bürokratischen Staub.
Leeny
4
Mit leichter meine ich weniger steif. Ich erwarte von den Entwicklern, dass sie Aufgaben planen, Codeüberprüfungen durchführen, bewerten, was nicht funktioniert, und ihre Aufgaben halbjährlich teilen. Ich habe jedoch nicht das Gefühl, dass diese Dinge so streng sein müssen, z. B. jeden zweiten Montag planen, jeden Tag um diese Zeit aufstehen, jeden zweiten Freitag zurückblicken, Sprints in festgelegter Länge usw. Ich habe das Gefühl, dass ich bereits eine Menge von dem mache, was ich tue SCRUM umfasst, jedoch ohne ausdrückliche Anweisung, Terminologie oder Agenden.
Haben Sie sich mit Kanban- oder Lean-Techniken und -Prinzipien befasst? Es hört sich so an, als ob Sie bereits einen ziemlich agilen Prozess eingerichtet haben. Lean kann Ihnen dabei helfen, sich zu verbessern, ohne Ihre Arbeitsabläufe einzuschränken. Kanban verwendet auch "Trittfrequenz" anstatt eines Sprints, was bedeutet, dass jedes Meeting in einem eigenen Rhythmus stattfinden kann, anstatt mit allen anderen Meetings in einem 2-wöchigen Zyklus arbeiten zu müssen.
Lunivore
2
Sie sprechen von Scrum, zitieren aber das Agile Manifest. Bei Scrum geht es darum, Artefakte, Rollen, Besprechungen, Sprints, Messungen usw. zu definieren. Sie können auf jeden Fall agil sein, ohne Scrum zu implementieren, und zum größten Teil können Sie Scrum ausführen, ohne agil zu sein.
Guy Sirton

Antworten:

13

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.

Anne Schüßler
quelle
Danke für deine Antwort. Ich werde es auf jeden Fall versuchen, da ich muss, also hoffe ich, dass sich der Prozess mit der Zeit verbessern wird. Sie machen zwei gute Punkte. Ich bin zwar sehr zuversichtlich, dass ich und mein Team die Dinge in die Hand nehmen können, aber das gilt nicht für jedes Team im Unternehmen. Daher ist es verständlich, dass das Management einen Prozess wünscht, der dieses Verhalten fördert. Obwohl ich weiß, dass mein Vorgesetzter unserer Arbeit und unserem Wort vertraut, muss er auch für andere Interessenten sichtbar sein, z. B. für diejenigen, die mit dem Kunden oder dem oberen Management interagieren.
11

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.

anon
quelle
"Ob Sie es glauben oder nicht, es gab gute Software-Teams, bevor Scrum hinzukam. Scrum hilft den schlechten, besser zu werden." Andererseits würde ich dem widersprechen, dass sie aus Sicht des Managements so selten waren, dass Ihre Beobachtung umstritten ist.
Ben
+1 (+100, wenn ich könnte): Gleiche Erfahrung hier.
Giorgio
7

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.

Slebetman
quelle
Vielen Dank! Ich werde jetzt die Messung als einen wichtigen Aspekt bei der Bewertung von SCRUM betrachten. Ich nehme an, es ist richtig, dass ich meinem Team zwar vertrauen kann, dass es einen eigenen Zeitplan erstellt und sich effektiv entwickelt, es jedoch schwierig sein kann, das Gesamtbild des Fortschritts ohne explizite Anwenderberichte und regelmäßige Kundenakzeptanz zu sehen. Ich denke, ein Problem, das ich habe, ist, dass, obwohl es schön ist, expliziten visuellen Fortschritt zu sehen, dies nicht immer dazu führt, wie "erledigt" ich persönlich das Projekt finde. Ich stelle mir oft meine eigenen Verbesserungsbereiche vor, auf die ich bei der Entwicklung achten muss, und SCRUM schränkt diese Kreativität ein.
2
Ich persönlich führe einen modifizierten SCRUM durch, bei dem wir regelmäßig (alle vier oder fünf Sprints) einen Refactor-Sprint durchführen. Der Unterschied zwischen einem regulären Sprint und einem Refactor-Sprint besteht darin, dass Entwickler während eines Refactor-Sprints alle Geschichten einreichen. Grundsätzlich die Prioritäten des Produktbesitzers ignorieren. Mein Chef akzeptiert dies als notwendiges Übel, um Code Rot zu vermeiden. Manchmal lösen Geschichten auch einen Refactor aus, wenn mehr als ein Programmierer der Meinung ist, dass der Code, der berührt werden muss, "yucky" ist. Wenn das passiert, erlaube ich Entwicklern, ihre eigenen Geschichten einzureichen.
Slebetman
(weiter) .. Entwickler, die Beiträge einreichen, sind natürlich streng genommen nicht zu empfehlen. SCRUM funktioniert jedoch nicht ordnungsgemäß, wenn sich die Codequalität verschlechtert. Wenn Ihr Code so durcheinander ist, dass die Implementierung von Storys Wochen in Anspruch nimmt, sind Sie nicht mehr "agil". Versuchen Sie, die beiden oben genannten Änderungen an der Verwaltung vorzuschlagen. Denken Sie auch daran, dass SCRUM nur ein Werkzeug ist - es erfordert viel Übung, um es richtig zu verwenden, aber letztendlich nur ein Werkzeug.
Slebetman
Zusätzlicher Hinweis: Ursprünglich habe ich die Idee eines Refactor-Sprints an das Management verkauft, indem ich Refactor-Sprints nur eine Woche anstatt eines vollständigen Sprints durchgeführt habe. Heutzutage ist es ein vollständiger Sprint, aber das liegt hauptsächlich daran, dass das Produkt im Grunde genommen vollständig entwickelt ist und sich jetzt im Wartungs- / inkrementellen Upgrade-Modus befindet.
Slebetman
+1 für Slebetmans Kommentar zu Refactor-Sprints. Dies klingt nach einem effektiven Weg, um technische Schulden loszuwerden. Wenn Sie dies regelmäßig tun und nicht, wenn die Dinge bereits außer Kontrolle geraten sind und der Product Owner und die Manager damit einverstanden sind, kann ich mir vorstellen, dass dies dabei hilft, Probleme mit der Codequalität zu beheben, die während der letzten Sprints aufgetreten sind.
Anne Schuessler
2

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.


quelle
"Ich persönlich denke, der Zweck von SCRUM ist es, ältere Organisationen zufrieden zu stellen, bei denen das obere Management nicht hinter einen schlankeren Prozess kommen kann oder will." Sie mögen das glauben, aber die Erfahrung hat gezeigt, dass es sich bei Scrum um eine Reihe von Vorgehensweisen handelt, die dazu beitragen, Software pünktlich und in höherer Qualität bereitzustellen, während gleichzeitig die Flexibilität erhalten bleibt (Fähigkeit, auf sich ändernde Anforderungen zu reagieren). Ob diese Praktiken älteren Organisationen oder Unternehmen mit wasserfallliebendem oberen Management helfen, spielt keine Rolle.
Ben
1

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

Pradeep
quelle
Ihre Abwesenheit ist ein guter Punkt. Unabhängig davon, wie stark ich mich in meinem Team fühle, muss es genauso effektiv sein können, ob zwei oder sechs Teammitglieder im Büro sind. Wenn nur wenige Schlüsselpersonen Codeüberprüfungen planen, den Fortschritt überprüfen usw., ist die Gruppe möglicherweise zu abhängig von diesen Personen, um einen reibungslosen Ablauf zu gewährleisten. SCRUM sollte in der Lage sein, allen zu helfen, die richtige Denkweise anzunehmen.
1

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 ;-)

Schultz9999
quelle
1

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.

Antonio2011a
quelle
1

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.

Sean McMillan
quelle
0

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.

dietbuddha
quelle
0

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.

jonathangersam
quelle