Alles dreht sich um Agile - 2: Agile Implementierungsfunktionen

Wir fahren mit den Nuancen der agilen Entwicklung fort, die in der Praxis auftreten. Wie kann man verstehen, ob Agile korrekt implementiert ist, welche Praxis für welche Aufgabe und Branche geeignet ist und wer im Unternehmen die Arbeit auf „Agile-Rails“ übertragen sollte? Vasile Savunov, Agile Coach ScrumTrek, teilt seine Erfahrungen weiterhin mit den Redakteuren des Mail.Ru Cloud Solutions- Blogs .

Das letzte Mal sprach Vasily darüber, was Agile ist, welche Methoden es beinhaltet und welche Stereotypen sich um es herum gebildet haben. Lassen Sie uns nun über die Implementierung sprechen.

Über agile Unternehmen

- Gibt es Branchenpräferenzen bei flexiblen Methoden?

Wie die Studie Agile Russia , die wir zum zweiten Mal in Folge durchführen, zeigt, wird Scrum hauptsächlich in der Softwareentwicklung, Kanban in Finanzinstituten und in der Telekommunikationsbranche eingesetzt.

Als Person, die die gesammelten Daten direkt analysiert und mit vielen der Befragten zusammengearbeitet hat, glaube ich, dass dieser Zustand zwei Gründe hat:

• Die Änderungsrate in der IT ist deutlich höher als im Finanzbereich. Daher ist Scrum dort als Ansatz vorzuziehen, der es aufgrund schneller Experimente ermöglicht, Prioritäten flexibel zu steuern und die Richtung in Abhängigkeit von Änderungen in der äußeren Umgebung und den Bedingungen am Eingang zu ändern. Finanzen sind konservativer.
• Die Kosten eines Finanzfehlers sind viel höher als bei der IT-Entwicklung. Daher sind sie Kanban mehr wert, basierend auf Mathematik als auf Experimenten, und ermöglichen durch kleine, aber konstante Änderungen die Verbesserung des gesamten Workflows.

Telecom Kanban ist ebenfalls geeignet. Schon allein deshalb, weil der Entwicklungsvektor der Branche die Digitalisierung ist. Allerdings verstehen nur wenige, wie genau es aussehen sollte. Darüber hinaus grenzt in der Telekommunikation der „schnelle“ Teil der Arbeit (Softwareentwicklung) an den „langsamen“ Teil (Unterstützung und Entwicklung der Hardware-Infrastruktur) an. Daher ist es zusammen mit den an Scrum durchgeführten Experimenten sinnvoll, aktuelle Prozesse mit Kanban evolutionär zu beschleunigen.


Agile Entwicklungspraktiken in verschiedenen Branchen. Beträge sind nicht gleich 100%, da mehr als ein Artikel ausgewählt werden kann. Image / ScrumTrek

- Und was ist mit den mobilen Entwicklern? Hat Agile Besonderheiten in der mobilen Entwicklung?

Aus meiner Sicht besteht die Hauptschwierigkeit bei der Entwicklung mobiler Anwendungen darin, Anwendungsanforderungen zu identifizieren, da es schwierig sein kann, Stakeholder zu identifizieren. Diese Schwierigkeiten können überwunden werden, indem die Kundenentwicklung zur Untersuchung der Kundenbedürfnisse und Scrum zum schnellen Testen von Produkthypothesen verwendet wird.


Im Allgemeinen passt Agile gut zur mobilen Entwicklung: Es erfordert eine schnelle Reaktion, Einbeziehung und koordinierte Arbeit verschiedener Spezialisten, die Fähigkeit, das Ergebnis schnell bereitzustellen und gegebenenfalls zu ändern.

Zusätzlich zu Scrum können Sie hier direkt auf mobile Entwicklungsansätze fokussierte verwenden. Zum Beispiel basiert Mobile-D auf XP, Crystal und RUP - Ansätze sind ziemlich alt und gut etabliert. Der Hauptunterschied zwischen Mobile-D und Scrum: das Vorhandensein klarer Phasen und der Schwerpunkt auf der technischen Seite der Produktentwicklung. Während Scrum dem Produktmanagement und der Lieferung mehr Aufmerksamkeit schenkt, konzentriert sich Mobile-D auf den Herstellungsprozess und umfasst XP-Verfahren, die die Qualität des Endprodukts erheblich verbessern. Gleichzeitig wirkt sich der Einfluss von RUP aus, sodass der Prozess ziemlich formalisiert ist.

Ein weiterer, modernster Ansatz für die mobile Entwicklung ist SLeSS , bei dem Scrum und Lean Six Sigma kombiniert werden. Zunächst implementiert er die Einstellung des Scrum-Workflows und wendet dann die Lean Six Sigma-Ansätze für das statistische Qualitätsmanagement an. Es scheint mir, dass SLeSS die notwendige Flexibilität mit den Mechanismen einer fundierten Entscheidungsfindung auf der Grundlage von Statistiken kombiniert.

Gleichzeitig verbietet der Scrum-Leitfaden zunächst nicht die Aufnahme anderer Ansätze und Tools in den Scrum-Workflow, die für die Produktentwicklung nützlich sein können. Daher kann alles oben Genannte im Rahmen des "klassischen" Scrum implementiert werden.

- Wie flexibel sind die Methoden zur Änderung unter bestimmten Bedingungen?

Es sollte getrennt von Scrum und Kanban betrachtet werden.

Scrum ist ein Framework, dh ein Framework, dessen Elemente alle erforderlich sind: Ereignisse, Rollen und Artefakte. Keiner kann weggeworfen werden. Es gibt jedoch keine strengen Anforderungen an die genaue Implementierung dieser Elemente - tun Sie, was Sie möchten. Und Scrum verbietet nicht das Hinzufügen neuer Elemente: Besprechungen, Artefakte, Rollen, die Sie zum Arbeiten benötigen, und beschleunigt den Prozess.

Kanban ist eine Reihe von Tools und Metriken. Er gibt keine strengen Einstellungen darüber vor, welche Tools und in welcher Kombination genau verwendet werden sollen, da sie für eine lange evolutionäre Änderung des vorhandenen Systems ausgelegt sind. Gleichzeitig wird der Erfolg von Kanban durch die Erhebung von Daten zum Arbeitsprozess und deren regelmäßige Analyse bestimmt. Wenn dies nicht getan wird, wird im Laufe der Zeit alles aussterben und es wird keine weiteren Verbesserungen geben. Aber das ist okay: Wie Edward Deming sagte, musst du dich nicht ändern, das Überleben ist freiwillig.

- Was sind die typischen Fehler bei der Anpassung, die Scrum macht?

Der Hauptfehler bei der Implementierung flexibler Methoden ist die Verwendung von Tools, ohne zu verstehen, warum sie speziell verwendet werden sollten.

In großen Organisationen beispielsweise benennen sie bei der Implementierung von Scrum häufig einfach den Projektmanager als Eigentümer des Produkts und das Projektteam in das Scrum-Team um und fordern, das fertige Ergebnis in zwei Wochen zu liefern. Dies funktioniert jedoch nicht und aus einem sehr einfachen Grund: Die Bedingungen, unter denen Scrum arbeiten kann, sind nicht erfüllt.

• Obwohl der Projektmanager als Product Owner bezeichnet wurde, hat er nicht die erforderliche Berechtigung erhalten und ist daher nicht berechtigt, eine Produktvision zu formulieren oder die Implementierungsprioritäten zu ändern. Nach wie vor ist er gezwungen, jeden seiner Schritte mit der Führung zu koordinieren und wird im Rahmen der Anforderungen an den Zeitpunkt und das Volumen der Arbeit geklemmt. Die Geschwindigkeit der Entscheidungsfindung ist also gleich geblieben. Keine Beschleunigung oder Anpassung an sich ändernde Bedingungen.
• Obwohl das Projektteam als Scrum-Team bezeichnet wurde, können die darin enthaltenen Personen in jeder Abteilung aufgelistet werden und direkt an ihre Vorgesetzten berichten. Dementsprechend tut jedes Teammitglied zunächst das, was ihm sein Vorgesetzter und nicht der Product Owner anvertrauen wird. Infolgedessen haben Produktaufgaben immer eine niedrigere Priorität, was bedeutet, dass die Geschwindigkeit der Produktimplementierung, für die das Scrum-Team „zusammengestellt“ wurde, überhaupt nicht zunimmt.
• Höchstwahrscheinlich sind die Teammitglieder nach wie vor mit anderen Projekten beschäftigt. Während Scrum direkt angibt: Teammitglieder müssen 100% ihrer Arbeitszeit dem Scrum-Team zugewiesen sein und sich nur mit dem Produkt befassen, das ihr Product Owner führt. Wenn Menschen zwischen Projekten / Produkten „durch Prozentsätze geteilt“ werden, wechseln sie zwischen ihnen, was sowohl die Beteiligung als auch die Effizienz der Arbeit an jedem bestimmten Projekt / Produkt drastisch verringert.

Eine solche unfähige „Implementierung“ hat viele negative Konsequenzen, aber sie beginnen mit dem Versuch, die Mechanik zu reproduzieren, aber nicht die Essenz von Scrum. Die Hauptfehler bei der Scrum-Implementierung wurden in meinem Bericht „ Stop Signals for Agile “ auf der CodeFest 2017-Konferenz ausführlich beschrieben.

- Wie kann bewertet werden, wie kompetent flexible Methoden im Unternehmen implementiert werden?

Es gibt einen Scrum Open- Test, der jedoch eher als Test für theoretisches Wissen dient. Was in der Praxis passiert, lässt er nicht verstehen. Angesichts der Tatsache, dass die Grundlage von Scrum die Teamarbeit ist und die Liefergeschwindigkeit des Produkts und der Wert für den Verbraucher Priorität haben, sind 360 Umfragen am besten geeignet. Daher ist es zuverlässiger, den Grad der Teamreife und die Kundenzufriedenheit zu ermitteln.

Wir verwenden unsere eigene Methodik, die im ScrumTrek Diagnostic Tool-Service implementiert wurde. Sie arbeitet so. Einem Team und interessierten Parteien außerhalb wird eine Reihe von Fragen gestellt, wie sie den Grad der Teaminteraktion bewerten, ihre Arbeit planen, den Wert des an den Kunden gelieferten Ergebnisses, die Interaktion mit anderen Teams usw. Für jeden Parameter wird der Median der Meinungen berechnet und ein komplexes Kreisdiagramm erstellt - Radar, das das Aussehen sowohl von innen als auch von außen anzeigt.


Radar ScrumTrek. Wir betrachten die Streuung der Bewertungen


Radar ScrumTrek. Wir schauen uns die Mediane an

Das Diagramm enthält viele nützliche Informationen.

• Atomschätzungen von Individuen und ihren Durchschnittswerten sind an sich interessant, und Erklärungen sind hier nicht erforderlich.
• Die Streuung der Noten in einem Team ist eine interessante Sache. Wenn es sehr groß ist, gibt es Grund zu der Annahme, was wir als Team unter dem einen oder anderen Aspekt unserer Arbeit verstehen. Was verstehen wir zum Beispiel unter „Kundennutzen“? Und was ist mit der Liefergeschwindigkeit? Ein großer Spread zeigt an, dass das Team in einer Reihe von Fragen keine einzige Position gebildet hat.

Ein kleiner Spread zeigt Konsens und gute Teamarbeit an.

• Bewertungen werden kategorisiert. Sie können sehen, dass alles in Ordnung mit der Kultur ist, aber die Produktivität sinkt an einigen Stellen. Es ist klar, wo man "gräbt".
• Der Unterschied zwischen der Bewertung innerhalb und außerhalb des Teams ist einer der wichtigsten Indikatoren. Er zeigt die Unterschiede zwischen den Erwartungen von Kunden und anderen interessierten Parteien aus dem Team und wie sich das Team selbst wahrnimmt. Bei Agile geht es um die enge Interaktion zwischen dem Unternehmen und denjenigen, die das Produkt verkaufen. Diese Diskrepanzen sind daher ein hervorragender Grund, die Uhr zwischen diesen beiden Bereichen zu überprüfen und sich auf eine Umstrukturierung des Teams zu einigen.

Nach dem Sammeln der Daten wird notwendigerweise eine Analyse des Diagramms unter Einbeziehung des gesamten Teams und der Stakeholder durchgeführt. Alles, um ihnen zu zeigen, wie die Arbeit des Teams aus verschiedenen Blickwinkeln aussieht, und um die Ergebnisse der Analyse in konkrete Schritte zu verarbeiten, um die Arbeit zu verbessern.

Informationen zu Scrum-Implementierungsteams

- Von wem sollte das Unternehmen die Implementierung agiler Entwicklungsmethoden initiieren?

Die Scrum-Implementierung basiert immer auf einem Geschäftsziel. Daher sollte der Kunde als erster über eine interne oder externe Beschleunigung nachdenken. Dann müssen Sie das Konzept des Produkts ausarbeiten, damit es iterativ durchgeführt werden kann. Und erst dann ein Team bilden. Scrum für Scrum funktioniert nicht. Darüber hinaus kann es zu teuer sein, bestimmte Probleme zu lösen.

Wer der „Agile Guide“ im Unternehmen sein wird, ist eine Frage ohne die einzig richtige Antwort. Ich sah, wie der technische Direktor zum „Anstifter“ des Wandels wurde. Es gab Fälle, in denen die Initiative aus der Wirtschaft kam und sogar sah, wie eine solche Initiative „von unten“ entstand. Es hängt alles von der Energie und Motivation des Menschen ab, ob er seine Vision von Entwicklung mithilfe flexibler Ansätze in den Geschäftskontext des Produkts oder der Einheit einbetten kann.

Ideal, wenn die Initiative vom Top-Management ausgeht. Fortschritte in diese Richtung sind auf dem russischen Markt spürbar.

- Welche neuen Rollen und Funktionen entstehen in einer Organisation oder einem Team durch die Einführung flexibler Methoden? Welche davon sind erforderlich, welche sind optional?

Im Fall von Scrum sind dies die Rollen des Scrum-Masters, des Product Owners und des Entwicklungsteams. Alle von ihnen sind erforderlich. Das Entwicklungsteam wird auch als "Rolle" betrachtet, da es nicht nur Entwickler zusammenbringt, sondern auch alle, die das Produkt benötigen, um im Prinzip zu erscheinen: Analysten, Designer und so weiter.

Der Scrum-Master und der Eigentümer des Produkts können Assistenten haben, die einen Teil ihrer Aufgaben übernehmen, während die Verantwortung für das Ergebnis beim Scrum-Master oder dem Eigentümer des Produkts verbleibt.

Der Eigentümer des Produkts ist häufig eine Person aus dem Unternehmen. Aber nicht unbedingt: Nehmen wir an, wenn wir eine technische Lösung für die Produktion erstellen, kann der Chefingenieur diese Rolle spielen. Letztendlich ist dies die Person, die am besten versteht, für welchen Verbraucher wir das Produkt herstellen, welche Probleme es überhaupt löst und wie Prioritäten bei der Erstellung gesetzt werden sollten. Es ist sehr wichtig, dass der Produktbesitzer befugt ist, die Zusammensetzung des Produkts auf der Grundlage von Daten vom Markt und vom Verbraucher unabhängig zu bestimmen. Er sollte das Recht haben, Interessenten, mit denen er interagiert, Nein zu sagen. Dies ist notwendig, damit Prioritäten vereinbart und Entscheidungen umgehend getroffen werden.

Scrum-Master ist eine Person, deren Aufgabe es ist, ein starkes, geeintes, verantwortungsbewusstes und ideal selbst organisiertes Team zu bilden. Was wichtig ist, ist kein Teamleiter , dh kein Leiter. Scrum-Master darf keine Anleitung geben oder direkt in die Produktentwicklung eingreifen. Er ist der Organisator, Moderator, Coach und Agile Practitioner. Nach meiner Erfahrung kommen die besten Scrum-Master von Projektmanagern - vorausgesetzt, sie wurden geschult und haben es geschafft, von einem Richtlinienformat zu einem Coaching-Format zu wechseln.


Apropos Coaching-Kommunikationsstil. Es gibt auch einen agilen Trainer . Seine Aufgabe ist es, den Workflow einzurichten, Menschen zu schulen und ihnen Werkzeuge für die täglichen Aktivitäten innerhalb von Agile zu geben. Einschließlich Tools zur Konfliktlösung. Alles andere liegt außerhalb seines Zuständigkeitsbereichs. Idealerweise sollte ein agiler Coach ein Team oder eine Abteilung einrichten, damit alles von alleine funktioniert und kein agiler Coach benötigt wird.

Die Übergangszeit ist immer mit Unbehagen verbunden. Agile-Coach soll dem Team helfen, diese Zeit mit minimaler Reibung zu überstehen und neue - bequeme und effektive - Arbeitsmethoden zu entwickeln.

Bei der Skalierung können zusätzliche Rollen eingeführt werden, wie beispielsweise im SAFe-Framework beschrieben . Sie basieren jedoch weiterhin auf den Vorgaben und Arbeitsprinzipien des Scrum-Masters oder Produktbesitzers: Hierarchieebenen zum Produkt werden einfach angezeigt.


- Wie unterscheiden sich die Funktionen des Product Owners und des Scrum-Masters „in einer idealen Welt“?

Auf der einen Seite der Skala stehen die Interessen des Unternehmens, die der Product Owner vertritt, auf der anderen Seite die Vitalität und Effektivität des Teams, für das der Scrum-Master verantwortlich ist. Damit das Team schnell Ergebnisse erzielen kann, muss das System im Gleichgewicht sein. Wenn der Besitzer des Produkts „kneift“, wird das Team Nächte und Wochenenden arbeiten und bald wird er einer Handvoll demotivierter, unbeteiligter Menschen gegenüberstehen, anstatt einem gut koordinierten Team. Wenn der Scrum-Master die Decke über sich zieht, wird die Entwicklung weder wackelig noch schwadig sein, mit ständigen Streitigkeiten und viel länger als nötig.


- Welche Methoden und Managementmodelle sind es wert, beherrscht zu werden, wenn Sie eine der zuvor beschriebenen Rollen übernehmen?

In Bezug auf die Geschäftskompetenzen entspricht alles „den Klassikern“, wie beim normalen Management, mit Ausnahme der Notwendigkeit, Prioritäten schrittweise festzulegen und enger mit dem Team zusammenzuarbeiten.

Der Product Owner sollte Lean Startup, Kundenentwicklung und andere moderne Ansätze zur Produktentwicklung kennenlernen.

Für den Scrum-Master ist das Kompetenzspektrum breiter: Moderation, Konfliktmanagement, Gruppendynamik, Coaching und natürlich Agile Praxis. Es handelt sich vielmehr um Fähigkeiten aus dem Bereich der Psychologie, weshalb ihr Mangel bei der Ausbildung von Managern zu spüren ist.

- Reduziert das kollektive Eigentum an dem Code wirklich die Abhängigkeit des Unternehmens von "Star" -Entwicklern? Fällt ihre Motivation?

Kollektiver Codebesitz ist ohne flexible Methoden möglich. Genug Codeüberprüfungsvereinbarungen und andere formale Regeln, und Entwickler können atomar handeln.

Oft provoziert das Unternehmen selbst das "herausragende" Verhalten von Ingenieuren: Auf den ersten Blick ist es rentabler, einen Superspezialisten zu finden und ihm eine ganze Richtung mit voller Verantwortung für das Ergebnis anzuvertrauen, als ein Team von Mittelbauern zusammenzustellen, Risiken aufgrund von Fehlern systematisch zu reduzieren und ihre Professionalität zu steigern.

Dies ist ein Dilemma: entweder kurzfristiger oder langfristiger Erfolg. Es scheint, dass die Einstellung eines „Sterns“ gut für das Geschäft ist. Aber was wird in drei, fünf, sieben Jahren nach dem Eintritt eines solchen Profis in das Unternehmen passieren? Er wird unverzichtbar. Und mit mindestens drei negativen Folgen.

Erstens hat eine solche Person fast keine Freizeit , und das Unternehmen kümmert sich im Großen und Ganzen nicht darum. Ihre Logik: "Wir zahlen Ihnen kein großes Gehalt, damit Sie sich ausruhen können." Wenn Menschen in eine ähnliche Situation geraten, brennen sie schnell aus, geraten in Zynismus und versuchen, aus ihrer Position den größtmöglichen Nutzen zu ziehen.

-, . , , , . : , , , , . , .

-, «» . , : , «», «» . : , , .

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

, , . , « ». , , « » . , « . - ».

Mail.Ru Cloud Solutions .