👨🏿‍💼 🐃 🧔🏻 Kann Scrum beim Outsourcing eingesetzt werden? 👋🏿 🈴 💀

Die Frage ist sehr kontrovers und ich persönlich habe keine einfache und offensichtliche Antwort darauf gefunden, obwohl ich schon lange danach gesucht habe und immer noch danach suche (ich glaube immer noch, dass ich einen Weg finden werde, die reine Essenz von Scrum und nichts anderes im Outsourcing-Projekt zu verwenden). Trotzdem bietet das Framework selbst viele Nishtyaks, deren Vorteile schwer zu leugnen, wenn nicht unmöglich sind. Und doch wird in der Frage, nach der der Artikel berechtigt ist, ein echtes Problem zwischen den Zeilen gelesen. Erlaube zu sprechen.

Problem

Scrum ist ein agiles Framework, das agile Entwicklung beinhaltet. Agile Entwicklung erfordert flexible Fristen und ein ähnliches Budget. Die Outsourcing-Entwicklung wiederum beinhaltet in 95% der Fälle (mit Ausnahme der Sackgasse) enge Fristen und ein knappes Budget. Bedingt: „Machen Sie mich in 3 Monaten zu einem Unternehmensportal, das Budget beträgt 3 Millionen. Ich bezahle dich für das Ergebnis. " Und der Kunde hat Recht, er will das Ergebnis sehen. Und der Manager muss das Team zu diesem Ergebnis führen. Aber so geht's mit Scrum?

Dieser Rahmen setzt Unsicherheiten in Bezug auf Zeitplan und Budget voraus. Das heißt, bereits in der Anfangsphase des Projekts sagt Ihnen das Scrum selbst: "Warten Sie, ich kann nicht hierher kommen, es gibt klare Fristen und ein echtes Budget. Sie müssen nach einem kritischen Pfad suchen, alles im Voraus planen, nach etwas Wasserfall suchen."

Lösung

Schritt 1. Beginnen Sie mit einem Wasserfall, um Ihre Dienstleistungen zu verkaufen.

Von Kindheit an lehrte mich mein Vater: "Es gibt kein Schwarz und Weiß, suchen Sie überall nach den Vor- und Nachteilen." Ja, Waterfall ist veraltet, ja, es ist nicht sehr gut für die agile Entwicklung geeignet, aber es gibt Verständnis und ermöglicht es Ihnen, den kritischen Pfad unter Berücksichtigung aller Risiken zu berechnen. Höchstwahrscheinlich ist der kritische Pfad ungenau und selbst eine pessimistische Einschätzung ist sehr optimistisch (wenn Sie verstehen, was ich meine). Dieser Schritt vermittelt jedoch ein ungefähres Verständnis des Arbeitsaufwands für Sie und Ihren Kunden.

Sie müssen viel Zeit damit verbringen, das Projekt mit den Entwicklern zu evaluieren. Zur Diskussion von Funktionen. Und dies ist eine Zeit, die schade ist, da die Funktionen später noch überschätzt werden müssen, aber bisher nirgendwo anders, sonst wird sich das Projekt nicht verkaufen und der Hund der ausgelagerten Entwicklung wird die Kette nicht brechen, um den nächsten Knochen zu verfolgen - es wird keinen Knochen geben.

!

Schritt 2. Hurra! Wir haben das Projekt aufgenommen und beginnen mit der Arbeit an Scrum (in seinem Bild und seiner Ähnlichkeit).

Das Projekt ist vergeben. Es scheint, dass alle Fristen da sind. Die Aufgabe ist klar, gut, gefahren zu tun. Warnen! Sei nicht so schnell. Höchstwahrscheinlich haben sich viele Dinge geändert, seit Sie das Projekt zum ersten Mal evaluiert haben. Könnte zum Beispiel Design erscheinen oder neue Wunschliste vom Kunden fliegen.

Ich habe einen Vorschlag. Versuchen Sie es mit Scrum. Wählen Sie aus dem Rückstand des Produkts den Sprint-Rückstand aus, Bräutigam. Planen Sie Ihren Sprint sorgfältig und sehen Sie, wie das Team damit umgeht. Führen Sie tägliche Scrams im Format "Was der Entwickler gestern getan hat / Was er heute getan hat" durch. Und Retro am Ende des Sprints, um die Erfolge jedes einzelnen und die Erfolge des gesamten Teams zusammenzufassen. Sie werden schnell feststellen, wie der KPI jedes Entwicklers von Sprint zu Sprint wächst, wie die Anzahl der Rückgaben aus der Qualitätssicherung abnimmt und wie der Produktbestand abnimmt.

PS Beeilen Sie sich nicht, neue Kundenwünsche abzulehnen. Vielleicht sind sie sinnvoll und können sicher in das Produkt-Backlog eingegeben werden, anstatt in andere Funktionen, die vom Unternehmen Ihres Kunden (und dementsprechend vom Kunden selbst) nicht mehr benötigt werden.

Schritt 2.1 Stellen Sie den Product Owner dem Projekt vor

In den meisten Fällen haben Outsourcing-Unternehmen nur einen Projektmanager. Ohne sich in Scrum-Master und Produktbesitzer zu unterteilen, ist dies jedoch kein so großes Problem, wie es auf den ersten Blick scheint.

Zum Beispiel habe ich einen coolen Tester für das Projekt, an den ich 90% der Verantwortlichkeiten des Produktbesitzers delegiert habe (die restlichen 10% stammen vom Kunden und ich gebe sie bereits an meinen Kollegen weiter). Neben der Tatsache, dass er mit Tests beschäftigt ist (und das perfekt macht), pflegt und füllt er auch den Rückstand auf, schreibt ein Dock, erstellt Flow- und Entitätstabellen: Er leistet hervorragende Arbeit (nicht zum Nachteil seines Kerns), für die ich einfach keine Zeit habe. aufgrund der Beschäftigung in anderen Projekten.

In diesem Ansatz gibt es ein weiteres großes Plus. Für einen erfahrenen Tester (und nur dieser kann mit dem Produktbesitz betraut werden) ist dies eine großartige Chance, sich nicht zu langweilen und Spaß an neuen Aufgaben zu haben + sich wert zu fühlen. Vergessen Sie nicht, den Mitgliedern Ihres Teams Vertrauen zu schenken, zumindest weil Sie auf diese Weise auch Ihre Autorität erhöhen.

PS Jetzt arbeite ich an einem solchen Modell, nicht an allen meinen Projekten. Irgendwo wird ein Scrum einfach nicht benötigt, weil es kompliziert ist. Dies sind hauptsächlich kleine Projekte für einen Zeitraum von einem Monat oder weniger.

Schritt 2.2 Konvertieren Sie die Uhrenbewertung in Story-Punkte

Nicht der wichtigste Schritt, Sie können ohne ihn arbeiten, aber schwieriger. Tatsache ist, dass, wenn Sie die Aufgabe in Stunden bewerten, die Uhr für jeden unterschiedlich ist. Es dauert 6 Stunden, bis jemand eine Domänenentität erstellt (bedingte Aufgabe), jemand hat 7, jemand hat 8. In Story-Punkten Jeder hat das gleiche = 8.

Laut Story Points ist es bequemer, den KPI jedes Entwicklers zu berechnen, eine Leistungsbeurteilung zu erstellen und den Erfolg des gesamten Projekts zu überwachen.

Vereinbaren Sie mit den Entwicklern 8 (mb 5 für Juni) Story Points pro Tag, planen Sie darauf basierend und sehen Sie, wie Aufgaben geschlossen werden und das Projekt umgesetzt wird.

Wenn ein Entwickler in 4 Stunden plötzlich 8 Story-Punkte schließt (5 Story-Punkte gemäß den Fibonacci-Zahlen), laden Sie ihn nicht mit neuen Handles. Schätzen Sie Ihre Zustimmung, respektieren Sie seine / ihre Arbeit. Ein Teil seiner verbleibenden „freien“ Zeit wird weiterhin für das Studium des nächsten Features und die Vorbereitung auf morgen aufgewendet, und ein Teil für die Selbstentwicklung oder sogar für die Freizeit. Gute Freizeit motiviert auch, gut zu arbeiten.

Schritt 3. Cool arbeiten

Tun Sie nicht alles so, wie es in Scrum-Handbüchern oder anderen PM-Standardisierern beschrieben ist. Treffen Sie Entscheidungen flexibel und bauen Sie auf der Situation auf. Wählen Sie die von verschiedenen Frameworks angebotenen Tools sorgfältig aus und zögern Sie nicht, ein neues auszuprobieren.

Sie müssen nicht an Wasserfällen oder Scrum arbeiten, um Projekte erfolgreich zu verwalten. Muss cool arbeiten. Das ist alles.

Fazit

Scrum kann verwendet werden und ist sehr nützlich: Ein hervorragendes Framework, das eine Reihe cooler Tools bietet, um ständig auf dem neuesten Stand zu sein, sich selbst zu entwickeln und die Grundlage für das Teamwachstum zu schaffen, den Projektfortschritt zu überwachen und KPI-Mitglieder Ihres Teams zu berücksichtigen.

Trotzdem ist Scrum kein Allheilmittel, und zum Beispiel dem Kunden zu sagen, dass wir zunächst nicht wissen, wie viel das Projekt für Sie bringt und wie viel Zeit es für die ausgelagerte Entwicklung benötigt, wird höchstwahrscheinlich scheitern. Ohne Wasserfallelemente ist es egal.

Kombinieren Sie die Frameworks und verwenden Sie die Tools, die Ihnen und Ihrem Team gefallen, auch wenn sie nicht als Scrum gedacht sind. Sorgen Sie dafür, dass es bequem funktioniert, da dies das Hauptziel jedes Frameworks ist. Und wie man ihn anruft, liegt bei Ihnen.

PS Ich habe es HMS - gentechnisch verändertes Scrum.

Kann Scrum beim Outsourcing eingesetzt werden?