Hallo Habr! Ich heiße Zhenya. Ich bin Systemanalyst bei NORBIT und Scrum-Master-Anfänger. Ich habe mich schon lange mit Scrum befasst, um seine Fähigkeiten in unserem Analystenteam zu untersuchen, zu testen und zu bewerten. Und jetzt, nach einem
leichten Kick eines inspirierenden Gesprächs mit dem RP, wurde mir klar: Hör auf zu denken, es ist Zeit, es zu tun.
In diesem Artikel werde ich über unsere Erfahrungen bei der Vorbereitung der Verwendung des eingeschränkten Scrum im Auftrag des Scrum-Masters sprechen: Was wir getan haben, um loszulegen. Zum Zeitpunkt des Schreibens ist der 15. Sprint abgeschlossen. Der Flug ist normal!
Ich habe oft von der Verwendung des Scrum-Frameworks in Teams gehört, deren Mitglieder keine Entwickler sind. Teams mit unterschiedlichem Fachwissen schließen sich Agile aktiv an. Ich dachte, dass Scrum ursprünglich für Entwicklungsteams mit vollem Zyklus erstellt wurde. Daher gibt es eine Reihe von Schwierigkeiten oder interessanten Punkten, auf die Sie achten sollten, wenn sich das Team von dem Referenzteam unterscheidet, an das die Entwickler gedacht haben. Ich unterscheide Teams in Richtung Fachwissen und Grad der Teilnahme am Produktentwicklungszyklus. Die Richtung des Fachwissens schränkt meiner Meinung nach den Einsatz von Scrum nicht ein. Der Grad der Beteiligung an der Produktentwicklung kann jedoch begrenzt sein. Einige von ihnen können den gesamten Arbeitszyklus des Produkts ausführen und sind für das Endergebnis verantwortlich, das dem Kunden zur Verfügung steht. Meiner Meinung nach können Sie in solchen Teams ein vollwertiges Scrum verwenden. Und andere machen nur einen Teil des gesamten Zyklus und sind Teil der Arbeitskette. In diesem Fall kann es zu Fragen und Schwierigkeiten mit einem vollwertigen Scrum kommen. Eine solche Entwurfssituation kann einen Kompromiss erfordern.
Dieser Artikel konzentriert sich auf das Team, das für einen Teil des Produktentwicklungszyklus und die Vorbereitung für den Start von ScrumBut verantwortlich ist.
Unser Aktionsplan für den Start war wie folgt:
- die aktuelle Situation und die gewünschte zu studieren und zu bewerten
- Erstellen Sie ein so wie es ist und um ein Modell in der ScrumBut-Terminologie zu sein.
- Präsentieren und inspirieren Sie das Team
Wie ich gelernt habe, was ScrumBut ist
Zuerst habe ich gegoogelt und bekommen:
Ein ScrumBut hat eine bestimmte Syntax: (ScrumBut) (Grund) (Problemumgehung). ScrumBut-Beispiele: "(Wir verwenden Scrum, aber) (ein tägliches Scrum jeden Tag ist zu viel Aufwand) (wir haben also nur eines pro Woche.)" "(Wir verwenden Scrum, aber) (Rückblicke sind Zeitverschwendung ,) (also machen wir sie nicht.) "
Das heißt, ScrumBut ist ein limitiertes Scrum. Diese Variation des Frameworks ermöglicht es Ihnen, alles, was Sie brauchen, von Scrum zu nehmen und nicht das zu nehmen, was unserer Meinung nach nicht erforderlich ist. Natürlich ist dies ein rutschiger Weg, weil Um zu verstehen, was notwendig ist und was nicht, war es wichtig, eine Vorstellung vom klassischen Scrum zu haben. Für mich war es wichtig zu verstehen, warum dies in der Vollversion enthalten ist.
Nützlich für mich im Material waren:
- Literaturstudie: Agiles Manifest der Softwareentwicklung , „SCRUM revolutionäre Projektmanagementmethode“ (Joseph Sutherland), „Agiles Team-Coaching“ (Lissa Adkins);
- Eine Reihe langwieriger und interessanter Konsultationen mit einem aktuellen zertifizierten Scrum-Meister, der die Klassiker praktiziert.
Wie habe ich die aktuelle Situation beurteilt?
Zunächst nutzte ich meine Vision und brachte einige Punkte zur Bewertung durch die Manager vor.
Sammelte die Meinungen der Teammitglieder und zeichnete sie auf.
Wir haben zwei Listen: Was wir am Eingang haben und was wir bekommen wollen.
Hier werde ich konsolidierte und verallgemeinerte Listen erstellen.
Was sie am Eingang hatten
- Ein großes Projekt zur Entwicklung eines Interpraise-Systems.
- Separate Teams aus Entwicklern, Support und Analysten.
- Ein cooles Analystenteam (ca. 14 Personen).
- Die Fähigkeit, nur im Rahmen eines Analystenteams zu handeln.
- Release Release von Systemversionen.
- Lebenszyklus-Management-Modell für Wasserfall-Software.
- Die Unmöglichkeit einer harten Planung, da Aufgaben vom Kunden jederzeit kommen.
- Ungleichmäßige Arbeitsbelastung der Analysten.
- Funktionale Verteilung der Untersuchungszonen der Analysten.
Was wollen wir bekommen?
- Seien Sie in der Lage, schnell auf geschäftliche Änderungen zu reagieren.
- Berücksichtigen und priorisieren Sie Aufgaben in der Arbeit
- Machbare Produktwachstumsprognosen.
- Mit kurzen Sprints können Sie Aufgaben verfolgen, aufzeichnen und abschließen und genauer vorhersagen, wann Aufgaben freigegeben werden.
- Erstellen Sie einen Aufgabenstau für Analysten.
- Der Analyst weiß jederzeit, was zu tun ist.
- Erfahrungsaustausch bei der Lösung komplexer Probleme.
- Teamarbeit so aufzubauen, dass Wissen geteilt wird, war angenehm, komfortabel und für beide Seiten von Vorteil.
- Organisieren Sie Ihr Scrum mit Black Jack usw. :) :)
- Probieren Sie neue Dinge aus, verbessern Sie den Teamgeist. Coole Jungs. Warum nicht?
Modellierung
In der Modellierungsphase haben wir Teamrollen zugewiesen: Wir haben die Produktbesitzer, Teammitglieder und mich als Scrum Master identifiziert, die Dauer des Sprints, den Prozess des Füllens und Priorisierens des Rückstands.
Obligatorische Aufgabenattribute, Workflow für die Nachverfolgung, Nachverfolgungstool, Zuweisung einer Schätzung in menschlichen Stunden für jeden Aufgabentyp und die Gesamtzahl der Stunden pro Woche für jeden Analysten wurden unter Berücksichtigung der Erfüllung des Sprint-Teamplans, der Zeit und der Regelmäßigkeit der täglichen Rallyes und Rückblicke ermittelt.
Der Eigentümer des Produkts und die Person, die den Rückstand festlegt, ist der Leiter der Analystengruppe. Es wurde beschlossen, Teams von 2-7 Personen zu bilden, die die Anforderungen von 7 ± 2 erfüllen. Dies waren zwei Teams, die bedingt nach dem Funktionsmerkmal der zu lösenden Aufgaben aufgeteilt waren, das näher am ursprünglichen Modell, aber weiter vom beabsichtigten Ziel entfernt war - funktionsübergreifende.
Für die Nachverfolgung haben wir uns entschieden, das vorhandene TFS zu verwenden, in dem es bequem ist, Aufgaben mit den Status "Neu", "In Arbeit", "Abgeschlossen" an die Tafel zu setzen und am Ende des Sprints kleine Statistiken über die Ergebnisse zur Diskussion in einem retrospektiven Meeting zu sammeln. Das TFS-Board imitiert ein physisches Scrum-Board, aber wir hatten auch ein physisches.
Präsentation
Die Planungsphase endete mit einer Demonstration des Teams der Präsentation über die Ergebnisse der Modellierung, Diskussion und Korrektur von „Gemeinsam gemeinsam beginnen“, was von den Jungs nicht beantwortet wurde.
Insbesondere Scrum und ScrumBut stehen für Teamwork, Kohärenz, Transparenz und allgemeine Akzeptanz. Es war ein wichtiger Moment, von dem aus wir mit Inspiration begannen.
QuelleSchlussfolgerungen aus den Startvorbereitungen
Wenn Sie an einem großen Projekt arbeiten, gibt es keine Möglichkeit, mit dem Kopf in den Pool zu gehen. Sie können also nicht ohne Planung auskommen. Es ist wichtig zu verstehen, wie es sein wird und welche Ergebnisse es bringen wird, aber wir mussten uns darauf einstellen, dass der Plan in einigen Aspekten der Plan bleibt. Bei der Planung haben wir mit großen Strichen gemalt und bereits in der Implementierungsphase konnten wir die Details hinzufügen, die das Team und die Design-Situation gebracht haben.
Unser Team ist nur für einen Teil des Softwareentwicklungszyklus verantwortlich, daher gab es Schwierigkeiten, wie man ein Produkt nennt und was man als Erhöhung erhält. Wir wussten, dass es ganzheitlich und vollständig sein sollte. Wir waren uns einig, dass wir seitens des Analystenteams verschiedene Arten von Dokumenten für die Interaktion mit dem Kunden vorbereiten und Aufgaben für Entwickler erstellen, um diese zu überarbeiten. Somit fallen die Aufgaben in die Sprints der Entwickler. Meiner Meinung nach kann ein solcher Kompromisspfad sowohl für Projekte geeignet sein, in denen einzelne Teams aus Analysten, Entwicklern, Testern, Support, als auch für Projekte, bei denen die Anzahl der Personen in mehrere Teams aufgeteilt werden muss. Diese Entscheidung hat auch ein Minus: Unsere Teammitglieder können den Zeitpunkt der Verfügbarkeit der Produktfunktionalität nicht beeinflussen, wir können nur die Leistung ihres Teils der Arbeit beeinflussen. Es gibt Pluspunkte - die Kontinuität der Aufgaben von Analysten für Entwickler. Diese Entscheidung ermöglichte es uns, Versuche zu vermeiden, ein funktionsübergreifendes Team zu werden (Analysten = Entwickler = Tester usw.), was in unserem Fall zu diesem Zeitpunkt unmöglich wäre, während der Produktentwicklungszyklus mit einer Kompromissbrechung an der Schnittstelle der Teaminteraktion aufrechterhalten wird.
In der Präsentationsphase reagierten unsere Jungs von
NORBIT ziemlich
enthusiastisch und mit Interesse. Aber ich nehme an, dass die positive emotionale Reaktion des Teams das Verdienst ist, die Ziele und ihren Zusammenhang mit dringenden und offensichtlichen Problemen zu erarbeiten.
Die oben beschriebenen Schritte (theoretisches Studium, Modellierung und Präsentation) haben den Trick gemacht: Wir haben erfolgreich begonnen.
Das Starten ist jedoch nur der erste Schritt. Ich werde Ihnen in meinem nächsten Artikel erzählen, was nach dem Start passiert ist und welche Ergebnisse erzielt wurden.