Wie wir Agile & Scrum kennengelernt haben

    Einleitung


    Auf keinen Fall möchte ich sagen, dass dies ein Leitfaden für die Einführung von Scrum ist - dies ist nur die Erfahrung, Scrum an die Bedürfnisse eines Unternehmens anzupassen. Diese Erfahrung kann sowohl für Anfänger interessant / nützlich sein: grundlegende Tipps, Etappen, Zyklen usw. als auch für Profis: Diskutieren, was schief gelaufen ist, was es nicht wert ist, getan zu werden usw. Ich betone, dass das, was mit uns passiert ist, nur an Scrum erinnert.



    Hintergrund, wie alles begann, wie bist du dazu gekommen, Scrum zu brauchen


    Ich arbeite als IT-Manager (Projektmanager) in einem kleinen / mittleren Tomsker Unternehmen. Die Anzahl der Mitarbeiter in der IT-Abteilung zu Beginn der Tätigkeit: 5 Personen, zur Zeit: 24 Personen.

    Anfangs war ich Game Designer, aber nach und nach zogen die Projektmanager in das Camp. Dies geschah ungefähr im Sommer 2014, und diese Zeit wird als Ausgangspunkt angesehen.

    Wie die meisten unerfahrenen Manager beeilte ich mich, Materialien zu studieren: im Internet zu suchen, Konferenzaufzeichnungen anzusehen, Bücher zu lesen, mit älteren Kollegen anderer Unternehmen zu kommunizieren und viel Wissen zu sammeln, wie ich damals dachte (das war natürlich ein Fehler). Und ich, ehrgeizig und inspiriert von neuen Zielen, eilte in die Schlacht.

    Ich betrachte das Hauptproblem des Anfängermanagers: Abwesenheit oder falsche Kommunikation mit den Mitarbeitern. Es kann viele Gründe für dieses Problem geben: mangelnde Erfahrung, Misstrauen der Mitarbeiter, mangelnde Kenntnis der wichtigsten technischen / geschäftlichen Prozesse usw. Aber ich hatte Glück in dieser Sache. Anfangs habe ich als Game-Designer eng mit Entwicklern zusammengearbeitet und zuvor als Programmierer mit einem völligen Mangel an Management gearbeitet, so dass ich eine gewisse Vision von dem hatte, was fehlte.

    Wie es vor Scrum war


    Ursprünglich hatten wir die alte Redmine ohne Plug-Ins und Einstellungen bereitgestellt. Sie können sie als nahezu sauber betrachten, TeamCity (kostenlos), um zumindest eine Art Gebäude, SVN, bereitzustellen, wo es kein Repository gibt. Im Allgemeinen hat alles funktioniert.

    Aufgaben wurden in redmine festgelegt, da sie abgeschlossen waren, Stunden und manchmal Prozentsätze festgelegt wurden, aber oft gab es keine Termine oder Pläne. Es war sehr glücklich, wenn es überhaupt eine Terminverhandlung gab.

    Und dann ist meine Zeit gekommen. Die Führung gab mir die Erlaubnis, alles zu verwenden, was mein Herz begehrt (es wird mehr Profit bringen). Wie ich oben geschrieben habe - das ist der Sommer 2014.

    Zu dieser Zeit waren wir mit Agile, einem Universitätskurs und einigen Artikeln noch nicht sehr vertraut. Deshalb hatten wir immer noch keine Gedanken an Flexibilität und begannen, auf die altmodische Weise zu handeln (vielleicht kamen Gedanken auf, aber der Mangel an Erfahrung und etwas anderem erlaubte ihnen nicht, weiter durchzubrechen). Zunächst haben wir unsere Hauptaufgaben in den Vorständen festgelegt, die wir in fast jedem Büro haben. Es sah so aus:



    Natürlich wurde alles in elektronischer Form übertragen: Für einige Aufgaben wurde es in Form eines Features oder eines Epos in RedMine festgelegt, für einige in dem guten alten Excel wurde auch die Wichtigkeit und der ungefähre Termin für die Erledigung von Aufgaben festgelegt. Dann begannen wir mit jedem Mitarbeiter, der die Aufgaben ausführen wird, Aufgaben zu zerlegen und auszuwerten. Das Ergebnis war ein Feature-Set mit Unteraufgaben und einer Schätzung der Fristen für die Erledigung von Aufgaben. Es stellte sich als eine Art Rückstand heraus, aber Sie müssen irgendwie weiter damit arbeiten, an sich gibt es keine Ergebnisse.

    Balkendiagramme


    Vor einiger Zeit bin ich in einer Firma, in der ich als Programmierer gearbeitet habe, auf Gantt Charts (Banddiagramme) gestoßen. Ich habe ein paar Diagramme zu unseren Projekten angefertigt, dem Management die Skizzen gezeigt und sie mochten diese Technik. Und ich fing an, die Werkzeuge zu studieren, mit denen ich genau diese Diagramme bestmöglich erstellen konnte.

    Ich wurde getestet:

    • Viele Desktop-Programme , zum Beispiel: Gantt-Planung und vieles mehr, die im Internet leicht zu finden sind, einige von ihnen waren von ekelhafter Qualität, andere wurden bezahlt. Das einzige, was ich erwähnen kann, ist das Gant-Projekt. Dies ist sehr praktisch und ermöglicht es Ihnen, einfach und schnell die erforderlichen Diagramme zu erstellen. Nachteile: Aufgrund der Tatsache, dass ich eine kostenlose Version hatte, war das Hochladen im richtigen Format und die fehlende Möglichkeit der Teamarbeit an einem Projekt nicht möglich.

    • 1C Bitrix CRM . Zu dieser Zeit haben wir dieses Programm im Unternehmen aktiv umgesetzt. Sie durfte Diagramme mit eingeschränkter Funktionalität erstellen. Nachteile: Überlastung der Benutzeroberfläche, mangelnde Möglichkeit, die Farben im Diagramm zu ändern (es hat mir wirklich nicht gefallen). Zu diesem Zeitpunkt gab es wiederum keine Möglichkeit, im richtigen Format zu entladen (jetzt scheint es da zu sein). Ein großes Plus ist die Möglichkeit der Teamarbeit, aber die Arbeit in diesem Programm hat uns in der IT-Abteilung nicht besonders gefallen.

    • Redmine Hier ist alles einfach - Sie legen Aufgaben mit Fristen fest, und die Diagramme selbst werden angezeigt. Nachteile: Wenn Sie unter Einbeziehung vieler Entwickler hypothetische Pläne erstellen und sehen möchten, was gemäß den Plänen vor sich geht, sehen die Entwickler alles, und alle fangen an, den Arbeitsbereich zu überladen. Auch hier gibt es keine Möglichkeit, schöne Farben zu erstellen.

    • MS-Projekt . Ich habe es damals aus einem Grund verpasst, später habe ich es aktiv genutzt und mir hat alles gefallen, bis auf die Schwierigkeit, Teamwork aufzubauen.

    • Megaplan . Altes CRM-System der Firma. Sofort entlassen, war alles nicht bequem.

    • MS Excel . Gut alt, für manche Pläne benutze ich es manchmal noch.

    So sahen die Pläne aus:



    Nachdem wir einige Programme kennengelernt und von Zeit zu Zeit geändert hatten, führten wir mehrere Monate lang Projekte durch, bei denen Gantt-Diagramme aktiv verwendet wurden. Das Management mochte alles, sie sahen klare und genehmigte Pläne und alles war in Ordnung, außer einem kleinen ABER (groß).

    Das ist ABER, Führung und mehr: Vermarkter, Vertrieb usw. Ständig drängen wir jede Entwicklung in den unpassendsten Momenten in den Plan. Dies führte dazu, dass der Plan vollständig neu erstellt und die Aufgaben der Entwickler verschoben werden mussten, wobei gegebenenfalls neue Aufgaben für Ausfallzeiten erfunden werden mussten. Wenn nur wenige Personen im Team waren, gab es keine besonderen Probleme. Es war nicht schlimm, ein paar Personen zu versetzen, aber wenn mehr als zwei Personen anfingen, von der Erfüllung einer Aufgabe abhängig zu sein, und sie manchmal so weit trieben, dass die Aufgaben ganz verschwanden, wurde es problematisch, Pläne neu zu erstellen.

    Hier entstand das Bedürfnis nach etwas anderem.

    Was waren die Bedürfnisse


    Aus den Rückmeldungen des Managements und der Hauptfiguren des Unternehmens wurde eine Liste mit den gewünschten Informationen erstellt:

    1. Entwicklungstransparenz. Jede Abteilung (insbesondere Manager) sollte gesehen haben, was sich gerade in der Entwicklung befindet und wann das nächste Ergebnis vorliegen wird.
    2. Änderungen an der Entwicklung können jederzeit vorgenommen werden. Der Regisseur wollte den Entwicklungsprozess schnell beeinflussen.
    3. Berichterstattung über Ergebnisse. Das Management wollte die Berichterstattung sehen.
    4. Aufgabenpool mit Laufzeit und Priorität

    Feedback wurde auch von den Entwicklern gesammelt:

    1. Eine detailliertere Einschätzung der Frist für die Erledigung von Aufgaben.
    2. Minimierung der Folgen von Eingriffen in die Außenentwicklung.
    3. Sensibilisierung der Entwickler für eingehende Aufgaben im Voraus.
    4. Verschaffen Sie sich einen vollständigen Überblick über laufende Projekte.

    Was wurde noch berücksichtigt


    • Die Einführung eines streng regulierten „Wasserfalls“, damit Prozesse nicht unterbrochen werden können. Aber all diese Gelegenheit, die Führung zu unterbrechen, übermächtigte sie.
    • Kanban, aber irgendwie ging es nicht weiter, ich kann die genauen Gründe nicht angeben.
    • Option: "Nun, mit Gott", aber er hat schon alle!

    Warum Scrum die Bedürfnisse erfüllt


    1. Flexibilität. Sie können die Prioritäten jederzeit überprüfen und neue Funktionen einführen.
    2. Transparenz Jeder hat eine Sprint-Liste in der Mail (mit den Hauptcharakteren) und anfangs habe ich sie in jedem Büro aufgehängt. Sie können auch mit Scrum-desk ins Büro gehen und sehen, wer was gerade tut.
    3. Berichterstattung Demonstrationen am Ende des Sprints, ein ziemlich gutes Verfahren, das es möglich macht, (in gewissem Maße) zu verstehen, was als Ergebnis passiert ist.
    4. Ein detailliertes Bild des Projekts (abhängig vom Grad des Rückstandsabbaus). Ständig aktualisiert gibt eine bestimmte Vision des Projekts, sowohl Programmierer als auch Manager.
    5. Entwicklersicherheit Entwickler sind vor äußeren Einflüssen geschützt, zumindest während des Sprints.
    6. Detaillierteres Design / Planung. Die Aufgabe wird erst dann im Sprint übernommen, wenn sie von den Entwicklern vollständig verstanden wurde oder eine Mini-Sprint-Analyse / -Design durchgeführt wurde.
    7. Kontinuierliche, zyklische Prozessverbesserung. Das Feedback wurde nach der Demonstration nicht storniert. Tägliche Besprechungen (Meetings) führen auch zu einer positiven Steigerung der Verbesserungsprozesse. Und im Nachhinein: Alles verbessern, was schlecht war!

    Wie an alle vermittelt


    Die Entwickler haben die Grundkonzepte aus den Artikeln verstanden, so dass es praktisch keine Probleme mit ihnen gab, sie alle haben es mit Begeisterung aufgenommen. Das Hauptproblem war Führung, aber da es praktisch nicht in die Prozesse involviert ist, sind wir in den Händen von Karten.

    Wie hast du gelernt Was hast du gesehen? Welche Ressourcen? Was für Bücher?


    Kommunikation mit Fachleuten


    Wir haben mit Managern anderer Unternehmen gesprochen und erfahren, was und wie sie hatten. Wir haben uns angesehen, welche Abweichungen sie von der Norm gemacht haben, wie und was bei uns angewendet werden kann. Ganz ehrlich: Sie haben nicht viel davon mitbekommen. Das wichtigste Fazit: Jeder handelt nach Belieben (welches Agile für ihn am besten geeignet ist).

    Artikel lesen


    Wir haben eine Reihe von Artikeln überarbeitet, die genau erschienen sind, an die sich niemand erinnern kann. Aber es gab viele. Dafür war viel Zeit. Natürlich ruht alles auf dem Agilen Manifest, die meisten Artikel und Sites verlinken darauf, also waren wir keine Ausnahme und haben es als Quelle genommen. (Der Link ist in den Quellen und Links)

    Bücher lesen


    Es wurden nicht viele Bücher rezensiert. Einige der Ratgeber sahen kurz, fanden aber nichts anderes und hörten auf zu lesen. Die wichtigsten (für mich selbst), ich denke, "Agile und XP-Notizen mit Fortgeschrittenen" habe ich dreimal gelesen, und immer, wenn sie mir eine Frage stellen: "Wie finde ich etwas über Scrum heraus?" - nenne ich es. (Der Link ist in den Quellen und Links)

    Beginn der Implementierung


    Schlüsselereignisdokument


    Wir haben die wichtigsten Ereignisse gemalt und eine kleine Liste mit einer Beschreibung der Aktionen erstellt, die zur Überprüfung an alle Mitarbeiter verteilt wurde. Zu dieser Zeit war er natürlich alles andere als perfekt. (der link ist in den quellen und links)

    Karten


    Natürlich musste man sich irgendwo Karten für die Poker-Planung besorgen. Bei einer Überprüfung einer Reihe von Geschäften im Internet lagen die Kosten für ein Deck für vier Personen zwischen 1.000 und 2.000 Rubel. Ich wollte vor allem nicht das Management um Geld bitten, und so habe ich sie selbst gemacht. Normales A4-Papier, ein Schwarzweißdrucker, eine Schere - das ist passiert:



    Oft habe ich versucht, sie neu zu gestalten, einen Farbdrucker, Pappe und vieles mehr, aber diese guten alten Karten (nicht in voller Stärke) sind noch in Betrieb.

    Eine interessante Tatsache.Ich hoffe, ich habe nichts durcheinander gebracht. Einer der wenigen Kartenhändler, die ich damals mochte, war planningpoker.ru. Ich dachte mir dann was geiles Karten. Später, nach einigen Jahren auf der Konferenz, überreichte mir der Direktor des Unternehmens, das diesen Laden organisiert hatte, zufällig eines dieser Decks. (der link ist in den quellen und links)

    Vorstand


    Der nächste wichtige Schritt, dies ist die Vorbereitung des Scrum-Desks, nahm das übliche Whatman-Papier, ein Paar A3 und A4, Marker, Klebeband usw. und es stellte sich heraus, dass es ziemlich gut war:



    Was geschah als Ergebnis der Vorbereitung


    • Das Team, das sich mit den Hauptetappen vertraut gemacht hat;
    • Redmine hat eine Aufgabenliste erstellt.
    • Vorbereitet durch Poker-Planung;
    • Erstellt von Scrum-desk;
    • Und viel Begeisterung.

    Erste Erfahrung, erster Sprint


    Rückstand


    Beim ersten Rückstand, den wir in MS Excel erstellt haben, haben wir alles nach Bedarf in Spalten aufgeteilt:



    Natürlich gibt es eine Reihe von Spalten, die in der Abbildung nicht enthalten waren, aber dies ist eine andere Geschichte. Ich betone, dass wir genau die Aufgaben (Feature) und nicht die Benutzerwünsche (User-Story) haben, wie es in Agile üblich ist. Beim ersten Sprint wurde beschlossen, zwei Wochen zu fahren. Setze Prioritäten, sortiert, grün markiert, was ich gerne im Sprint sehen würde, platziere Story-Punkte. Hmm, was ist Story-Point?

    B. auf die Entwickler aufmerksam gemacht. Story-Point - Tag


    Das Story-Points-Bewertungssystem - ideale Personentage - ist für Entwickler eher schwierig und unverständlich. Wie wir Story-Point erklärt haben - dies ist ein idealer achtstündiger Arbeitstag des Entwicklers, an dem er alles zur Hand hat, nichts ihn von der Arbeit ablenkt (Probleme sind bereits spürbar, alles ist da und stört nicht hmm ...), er ist von anderen isoliert Ein Raum, in dem es frische Luft, Essen, Tee / Kaffee, eine Toilette gibt und er die Aufgabe produktiv erfüllt, deren Lösung ihm völlig klar ist. Einige Dinge wurden hinzugefügt, als sie Neuankömmlingen erklärt wurden, aber sie sind nicht wirklich wichtig.

    Rollenverteilung


    Es gibt praktisch keine Cross-Entwickler in unserem Unternehmen? Es gibt separate Tester und wir entwickeln für verschiedene Plattformen. Dementsprechend verlassen wir uns schwach auf eines der Konzepte von Scrum, nämlich die Vereinigung der Arbeiter. Wir haben es vernachlässigt und im ersten Sprint hatten wir verschiedene Entwickler im selben Team.

    Planung


    Alle Features aus dem Backlog, die für den Sprint vorgesehen waren, wurden gedruckt, und wir haben mit der Auswertung begonnen.

    Welche Maßnahmen zur Sprintplanung haben wir ergriffen:


    1. Kleben Sie alle Blätter an die Tafel.
    2. Wir erklären, dass das Ziel durch Sprint erreicht werden soll, leider (vielleicht glücklicherweise) hatten wir mehrere Ziele, es gab kein einziges Ziel, da Entwickler aus verschiedenen Projekten an der Planung teilgenommen haben.
    3. Der leitende Entwickler informiert jeden einzeln über jede Funktion.
    4. Wenn Fragen auftauchen, werden diese sofort gelöst.
    5. Wir beginnen, jedes Feature in Unteraufgaben zu zerlegen und erklären erneut, warum genau und nicht anders.
    6. Wenn alle Aufgaben aufgeschlüsselt und nachvollziehbar sind, beginnen wir die Auswertung mit der Poker-Planung.
    7. Eine Unteraufgabe wird aufgerufen und erneut erläutert, wenn jemand sie nicht versteht.
    8. Alle Entwickler, die für diese Aufgabe zuständig sind (häufig, fast alle), legen Karten verdeckt mit einer Zahl auf den Tisch, die den Story-Punkten für diese Aufgabe entspricht.
    9. Drehen Sie die Karten um, nachdem alle die Karten ausgelegt haben.
    10. Wenn es starke Abweichungen gibt, erklärt der Entwickler, der die Bewertung im Widerspruch zum Rest veröffentlicht hat, den anderen, warum diese Bewertung entstanden ist. Wenn er etwas nicht versteht, erklären sie ihm alles noch einmal. Als nächstes Neubewertung.
    11. Wenn es keine starken Unterschiede gibt, wird der bewerteten Unteraufgabe der Wert zugewiesen, den die Entwickler ihr zugewiesen haben.
    12. Auf diese Weise werden alle Unteraufgaben bewertet, und aus den Summen der Unteraufgaben wird eine Feature-Bewertung hinzugefügt.
    13. Wenn sich die Funktionsbewertungen stark von einer vorläufigen Bewertung unterscheiden, müssen Sie später Maßnahmen ergreifen.
    14. Wir tippen Features beim Sprint ein. Beim ersten Sprint haben wir festgestellt, dass unsere Entwickler in einem zweiwöchigen Sprint ungefähr sieben Story-Points schaffen können. Wenn es also fünf davon gibt, können Sie Aufgaben an 35 Story-Punkten übernehmen. Wir nahmen mehr - 39, wie sich später als Fehler herausstellte.
    15. Wir veröffentlichen die aufgenommenen Features auf dem Scrum-Desk.
    16. Wir vergeben die Uhrzeit der täglichen Besprechungen (Meetings), das Datum und die Uhrzeit der Demonstration.
    17. Erste Schritte

    Das erste Treffen war erfolgreich und dauerte ca. 4 Stunden. 5-6 Personen nahmen daran teil. Natürlich (wie sich für uns herausstellte) wurde weit von allem, was ursprünglich geplant war, im Sprint gefahren. Der Regisseur war zeitweise bei der Planungssitzung anwesend, und er und das Team mochten diese Veranstaltung sehr und begannen eifrig, die Funktionen umzusetzen.

    Kompilierte Scrum-Liste (in MS Word):

    (Der Link ist in den Quellen und Links)

    • Achten Sie darauf, Sprint und das Team zu nennen.
    • Das festgelegte Ziel, die Hauptaufgabe des Teams, um das Ziel zu erreichen.
    • Sprint-Rückstand - Funktionen, die abgeschlossen werden müssen, um das Ziel zu erreichen. In Klammern wird die Punktzahl in Story-Punkten angegeben. Die gleichen Aufgaben hängen am Scrum-Desk.
    • Die angegebenen Termine für den Sprint sowie Zeit und Ort der täglichen Versammlungen (Rallyes) und Demonstrationen.
    • Aufzählung der Teammitglieder in Klammern, Prozentsatz der Beschäftigung in diesem Sprint, wenn nichts vorhanden ist, dann 100%.

    Anfangs habe ich dieses Blatt gedruckt und in jedem Büro aufgehängt und es auch per Post an die Hauptdarsteller geschickt. Aber später stellte sich heraus, dass dies nur eine Verschwendung von Papier war und niemand es wirklich brauchte, ein Blatt war genug (später, als es mehr IT-Büros gab) im Büro des Entwicklers.

    Warum brauche ich ein Blatt?
    Damit sich andere an dem Projekt beteiligte Teams und Personen vorstellen können, welche Aufgaben dieses oder jenes Team derzeit ausführt. Und auch, um zu sehen, wie das Ergebnis nach einer gewissen Zeit aussehen wird.

    Tagesplaner


    Jeder kam zum ersten Treffen, wie ein Uhrwerk, das nicht glücklich ist (in Zukunft war es nicht so rosig). Sie versammelten sich, begannen abwechselnd zu diskutieren, mit wem die Dinge liefen, niemand hatte Fragen und Probleme. Wir sind zum Scrum-Desk gewechselt.

    Aufgabenbrett aus Papier


    Die Aufkleber begannen sich zu bewegen und es gab bereits ein Problem, da die Aufkleber auf das Papier auf dem Klebeband geklebt waren und sie abgerissen wurden und ein erneutes Kleben ein Problem darstellte. Sie kamen mit dieser Trauer in zwei Hälften zurecht (später erwarben sie ein Talent und dies stellte kein Problem dar). Sie fingen an, verbrannte Story-Points abzulegen, und dann stellte sich eine bestimmte Frage: Keiner der Entwickler hatte Probleme und Fragen, und gebrannte Story-Points reichen nicht aus. Der Grund ist wie immer banal: Es dauerte nur eine Weile, bis jemand schwang, und er erledigte seine Aufgabe einfach nicht die ganze Zeit. Jemand führte Vorarbeiten durch, die im Sprint nicht in irgendeiner Weise und im gleichen Sinne festgelegt waren. Als Ergebnis haben wir etwas Ähnliches bekommen:



    Anfangs klebten die Aufkleber einfach auf dem Brett, aber im Laufe der Zeit begannen sie zusätzlich auf Klebeband zu fixieren. Es gab ein paar Präzedenzfälle, als alles abflog. Später erschienen ein paar weitere Spalten des Typs: beim Testen, bei der Codeüberprüfung usw.

    Warum niederbrennen?


    Ein Abbrennen ist erforderlich, um den Fortschritt des Sprint'a-Teams zu verfolgen und Abweichungen vom Plan rechtzeitig visuell zu erkennen. Das Hauptziel des Abbrands ist es, dem Team (da wir selbstorganisierende Teams haben) zu zeigen, dass wir operative Maßnahmen ergreifen müssen, wenn eine Abweichung auftritt.

    Wie baut man einen Burn-Down?


    Mit vielen Tools können Sie Burn-Down-Diagramme in elektronischer Form erstellen. Wir verwendeten MS Excel und bauten auf whatman auf.

    Anfangs (später erschienen zusätzliche Spalten) enthielt unsere Tabelle:

    • Первый столбец — это даты начиная с первого рабочего дня по последний рабочий день sprint’a.
    • Второй столбец — Сколько осталось сжечь story-points. Каждый день во время планерки появляется значение.
    • Третий столбец — эталон идеального сжигания story-points командой во время sprint’a, Идеально сжигать в день = Количество story-points взятых на sprint/ число дней.

    Leider wurde es nicht in Papierform aufbewahrt, vor kurzem gab es eine globale Reinigung, der gesamte Müll wurde weggeworfen.
    In elektronischer Form haben wir es mit MS Excel gemacht:



    Wie Sie dem Diagramm entnehmen können, war der erste Sprint fast erfolgreich, kleine Abweichungen von der idealen Leistung. ABER , wie die Regel besagt: Wenn am Ende des Sprints keine Story-Punkte verbrannt wurden, ist der Sprint fehlgeschlagen. Nach dieser Regel schlossen wir in diesem Moment die Augen und freuten uns über den erfolgreichen Abschluss des Sprints!

    Vorführung


    Es ist Zeit, die Ergebnisse des Sprints dem Management vorzustellen. Das „Team“ (Manager) bereitete seine Präsentation vor, in Zukunft hat jedes Mitglied des Teams seinen Teil dazu beigetragen. Anfangs gab es keinen Präsentationsstandard. Viele Zuschauer versammelten sich: Management, Teil der Verkaufs- und Marketingabteilung.

    Die Präsentation fand auf MS Powerpoint statt:



    In der ersten Präsentation gab es nur vier Folien, weshalb es für die Entwickler schwierig war, diese zu demonstrieren, da es keine Folien gab, über die man sprechen konnte, aber in Zukunft haben wir uns selbst korrigiert.

    Wo und wie war die Demonstration?


    Da zu diesem Zeitpunkt keine Konferenzraumpräsentation im Büro der Entwickler stattfand, nahmen wir den Projektor heraus und leuchteten an der Wand.
    Zunächst sprach der Manager (ich), erzählte, warum sich alle hier versammelten, erläuterte die wichtigsten Ziele des Sprints und die Entwickler begannen sich abzuwechseln. Der Manager beendete die Demonstration eines Burn-Down-Diagramms und befragte die Öffentlichkeit.

    Die Hauptaufgaben des Managers auf der Demo:


    • Machen Sie alle mit den Aufgaben und Zielen des Sprints bekannt.
    • Beheben Sie alle Fragen und Vorschläge während der Leistung der Entwickler;
    • Beantworten Sie Fragen und helfen Sie dem Entwickler.
    • Beheben Sie alle Mängel / positiven Aspekte in der Präsentation der Entwickler.
    • Fassen Sie Sprinta mit einer Burn-Down-Demo zusammen.
    • Notieren und beantworten Sie alle Fragen am Ende der Präsentation.
    • Feedback einholen.

    Entwickler auf der ersten Demo


    Bei der ersten Demonstration sagten sich die Entwickler wie bei zehn anderen Sprints: Komplexe Terminologie, Vertiefung des Fachgebiets und Demonstrationsergebnisse sind nichts für normale Menschen. In den ersten Sprints musste ich manchmal sogar die Demonstration der Entwickler umformulieren und zusammenfassen, damit interessierte Leute verstehen konnten, was los war.

    Demo-Publikum


    Es gab viele abstrakte Fragen der Öffentlichkeit, die indirekt mit dem demonstrierten Sprint zu tun hatten und auf die sie wirklich eine Antwort haben möchten - dies ist bis heute eine sehr langwierige Demonstration. Die erste Demonstration dauerte ungefähr anderthalb Stunden.

    Rückblick


    Der erste Sprint war auch für Entwickler erfolgreich. Die Bewertungen waren nur positiv.

    Welche Verbesserungen wurden in der ersten Retrospektive diskutiert:

    • Notwendigkeit, mehr Folien in der Präsentation zu machen;
    • Fordern Sie keine Demonstration von Personen, die indirekt mit dem Projekt verbunden sind.
    • Einige technische Feinheiten zur Verbesserung der Ausrüstung der Arbeiter;
    • Um die Besonderheiten der Planung genauer zu erläutern, wurden während des Sprints einige Nuancen herausgefunden, die nicht berücksichtigt wurden.

    Feedback vom Management


    Mir hat alles gefallen, weitere Folien sind in der Präsentation erforderlich. Das Management wollte den Bonus-Teil des RFP des Entwicklers mit den Ergebnissen der Sprint-Demonstration verknüpfen: Die interessierten Parteien geben jedem Entwickler subjektive Bewertungen mit den Kriterien für diese Bewertung, die Manager-Bewertung ist der arithmetische Durchschnitt aller Bewertungen. Dieses System hat nicht wirklich Wurzeln geschlagen, aber das ist eine ganz andere Geschichte.

    Wie ist es gelaufen?


    Nach dem ersten Sprint war bereits viel Wasser ausgelaufen, es wurden viele Maßnahmen ergriffen, um die Prozesse zu optimieren, einige hatten einen Gewinn, viele nicht.

    Welche Maßnahmen wurden ergriffen?

    Teamwork warum passiert ist


    Anfangs hatten wir zwei Teams mit unterschiedlichen Entwicklungsprofilen, von denen jedes sein eigenes Scrum mit Blackjack und Scrum-Desk hatte. Aber da wir immer und jetzt Probleme mit dem Management haben (ich bin tatsächlich einer), hatte ich nicht genug Zeit, um Prozesse für die Planung / Wartung / Demonstration von zwei Teams zu organisieren. Aus diesem Grund haben wir uns entschlossen, die Teams zu einem zusammenzufassen.

    Ja, es hat geholfen, einige Zeit zu gewinnen, aber nein, es hat keine positiven Ergebnisse gebracht. Dies dauerte vier Sprint'a, aber da die Teams ein völlig anderes Entwicklungsprofil hatten, mussten die Entwickler absolut nicht zusammenarbeiten.

    Trennung von Teams


    Im Laufe der Zeit gab es mehr Arbeiter und mehr Entwicklungsbereiche, entweder Handys oder etwas anderes erschienen. Wie ich im Abschnitt über die Vereinigung von Teams sagte, haben die Menschen absolut nichts miteinander zu tun, wenn bei der Entwicklung von Projekten kein direkter Zusammenhang besteht. Dementsprechend haben wir die Teams in verschiedene Richtungen aufgeteilt. Ja, es gab ein produktives Ergebnis für jedes einzelne Team, aber jedes Team verschlang viel Zeit des Managers.

    Variation der Sprintzeit


    Versuchte verschiedene Variationen:

    • Zweiwöchiger Sprint. Das optimale Verhältnis von Entwicklungs- und Planungsarbeit. Aber es gibt ein gewisses Minus - über den Zeitraum von zwei Wochen gibt es zusätzliche (intelligente oder dringende Aufgaben des Managements) Aufgaben, die wir erledigen müssen, aus diesem Grund endet der Sprint nicht immer erfolgreich.
    • Wöchentlicher Sprint. Das Verhältnis ist eher in Richtung Planungsarbeit. Es gibt jedoch fast keine Aufgaben von Drittanbietern, alle Sprints werden erfolgreich beendet.
    • Vierwöchiger Sprint. Es zeigt sich eine sehr starke Abweichung im Sprint'a-Ergebnis. Der unglücklichste Sprint für uns.

    Infolgedessen haben wir uns für einen zweiwöchigen Sprint entschieden.

    Wir sind mit Markern auf die Tafel gewechselt


    Sie gaben das Whatman-Papier auf, es sieht hässlich aus, die Entwickler mochten es nicht auf dem Hintergrund.



    Und löst das Problem, Klebeband vom Papier abzureißen. Aber ein neues Problem ist aufgetreten - Kleber auf der Tafel. Das Burn-Down-Diagramm in Papierform verschwand ebenfalls, da ich begann, das Bild des Diagramms im Büro des Entwicklers auf dem Fernseher anzuzeigen.

    Die nächste Phase: Sie begannen, tägliche Rallyetabellen mit Markierungen an die Tafel zu schreiben: Die



    Tabelle enthält: die Nummer, die Spalte zum Brennen von Aufgaben, die nicht aus dem Plan stammt, die Spalte zum Brennen von Aufgaben aus dem Plan.

    Wechseln Sie zur Cloud-Lösung: Google Doc


    Abgelehnte MS-Produkte, Umstellung auf Google Doc Cloud-Lösung. Scrum / Sprint-Liste wurde ebenfalls aktualisiert. Der Hauptunterschied zur ersten Version des Arbeitsblatts: Die Aufgaben werden von jedem Mitarbeiter aufgeteilt und zerlegt. (Link ist in Quellen und Links)

    Sie begannen, Diagramme in Google-Tabellen abzubrennen. Mit der Zeit wurden mehr Werte in die Tabelle aufgenommen:



    Da wir bei einem langen Sprint die Tendenz hatten, nicht in den Sprint zu passen (wir versuchten, Reserven zu nehmen, was nichts Gutes brachte), führten wir einen neuen Wert ein - außerhalb des Plans, der die Grafik zeigt unter Berücksichtigung des Brennens von ungeplanten Aufgaben.

    Dann gingen wir noch weiter und gaben drei weitere Werte ein: Real, Off-Plan (Fehler) und Off-Plan (Extra): Die



    Grafiken spiegeln Folgendes wider:

    • Im Idealfall. Wie immer - wie man brennt.
    • Planen Sie Wie die geplanten Aufgaben verbrannt werden.
    • Off-Plan (Fehler). Wie die geplanten Aufgaben und Aufgaben, die im Plan nicht berücksichtigt wurden, verbrannt werden, sind Fehler in der Planung.
    • Off-Plan (extra). Wie die geplanten Aufgaben und Aufgaben, die nicht mit den Aufgaben des Sprints zusammenhängen (intelligent und vom Management kommen), gebrannt werden.
    • Echt. Die Art und Weise, wie Aufgaben gebrannt werden, ist real = Plan + Fehler + Extra.

    Wechseln Sie zur Google-Präsentation


    Eine bequeme Lösung, bei der Sie alle gleichzeitig arbeiten können:



    Jetzt haben wir viel mehr Folien als zu Beginn, aber wir erhalten eine übersichtlichere Darstellung und nehmen weniger Zeit in Anspruch.

    Versuchte ein Plugin für Redmine


    Sie haben das Plugin für Redmine installiert, es heißt Backlog. Es macht es möglich, die Arbeit mit dem Produkt-Backlog zu organisieren und über Redmine zu sprinten:



    Dieses Plugin verfügt über ein elektronisches Taskboard, das die Funktionalität von dem, das wir zu Beginn hatten, in realer Form vollständig wiederholt. Alle Spalten werden von Redmine abgeholt, dies ist der Wert des Aufgabenstatus. Sprint ersetzt die Bedeutung und Funktionalität der "Version" in Redmine. Ein ziemlich praktisches Plugin, wir verwenden es jetzt.

    Regalimeter eingeführt




    Reflektiert die insgesamt verbrannten Story-Punkte jedes Mitarbeiters für alle Sprints. Regt die Mitarbeiter dazu an, produktiver zu arbeiten. Jeder Mitarbeiter kann eine bestimmte Anzahl von Story-Ponts im Sprint ausführen. Der Angestellte sieht, dass andere Leute produktiver arbeiten als er, und versucht, bessere Ergebnisse zu erzielen. Wir haben eine durchschnittliche Anzahl von Story-Punkten pro zweiwöchigem Sprint - sieben.

    Welche Verbesserungen haben Innovationen gegeben


    Zuallererst zielen alle Innovationen darauf ab, die Produktivität zu verbessern und die Zeit für die Planung und die damit verbundene Arbeit zu verkürzen. Der Übergang zur Cloud und zum vollelektronischen Arbeiten hat die Planungszeit erheblich verkürzt.

    Was passiert gerade?


    Im Moment gibt es ein Problem: Die Anzahl der Mitarbeiter ist für einen Manager groß, und wir haben keine Zeit, alle Planungsarbeiten durchzuführen. Was damit zu tun ist, wissen wir. Wir versuchen, nach dem etablierten Schema zu handeln.

    Wurden die Ergebnisse erzielt?


    Das erfundene und implementierte System liefert die folgenden Ergebnisse:


    • Die allgemeine Verfügbarkeit von Materialien über die Arbeit von Teams.
    • Schnelle Voraussetzungen für die Planung neuer Sprints, der gesamte Rückstand ist bereits im System enthalten und wird in Echtzeit überprüft.
    • Es ist einfach und schnell, geplante Aufgaben Mitarbeitern zuzuweisen, da diese bereits im System vorhanden sind und Sie nur einen Ausführenden zuweisen müssen.
    • Anregung der Mitarbeiter zur Steigerung der Arbeitsproduktivität (ein Regalimeter ist bei weitem nicht das einzige Instrument).
    • Einfaches Arbeiten mit der Dokumentation, da sich alles in der Cloud befindet.
    • Einfache Arbeitskontrolle, alles ist im System.

    Was planen wir als nächstes zu tun?


    Momentan wird wieder 1C Bitrix aktiv eingeführt, die Geschäftsführung möchte, dass sich alle Mitarbeiter im selben System befinden. Wir planen, neue Tools zu untersuchen und zu sehen, wie unsere Arbeit auf CRM übertragen werden kann. Im Moment gibt es etwas im Sinn: ein Board für Bitrix - scrumban.ru. (Der Link befindet sich in den Quellen und Links.)
    Es gibt Pläne, das MS Project zu verwenden, um die Mastered-Volume-Methode parallel zu unserem gesamten System anzuwenden.

    Fazit


    Abschließend möchte ich wiederholen, dass dies keineswegs ein Leitfaden ist, sondern nur die Erfahrung einer kleinen Firma. Ich hoffe, dass Sie nach dem Lesen des Artikels nur positive Gedanken haben und etwas Nützliches für sich selbst herausbringen und vielleicht erfahren, wie es geht.

    Quellen und Links:

    " Buch:" Scrum und XP: Fortgeschrittene Notizen "
    " Agiles Manifest
    " Dokument mit Schlüsselereignissen
    " Scrum-Liste (zuerst)
    » Link zu dem Shop, in dem man Poker-Planung kaufen kann
    » Scrum-Liste im Laufe der Zeit
    » Forum für Bitrix

    Jetzt auch beliebt: