Alles dreht sich um Agile 1: Beliebte Agenda-Mythen

Agile Entwicklungsmethoden haben sowohl in der IT als auch in der Nicht-IT Wurzeln geschlagen und sind mit ihren Vorzeichen, Stereotypen, Aberglauben und Mythologien überwachsen. Die Redakteure des Mail.Ru Cloud Solutions-Blogs haben beschlossen, mit Agile-Coach Vasily Savunov von ScrumTrek über diese Mythologie zu sprechen.

Agile ist eine agile Entwicklungsphilosophie, deren Grundlagen im Agile Software Development Manifesto beschrieben sind . Das Konzept basiert auf vier Grundwerten:

• Menschen und Interaktion sind wichtiger als Prozesse und Werkzeuge;
• Ein funktionierendes Produkt ist wichtiger als eine umfassende Dokumentation.
• Die Zusammenarbeit mit dem Kunden ist wichtiger als die Vereinbarung der Vertragsbedingungen.
• Die Bereitschaft zur Veränderung ist wichtiger als die Befolgung des ursprünglichen Plans.

Die Prinzipien des agilen Ansatzes haben den Entwicklungsprozess verändert und Respekt gewonnen. Die moderne Welt beschleunigt sich sehr - täglich erscheinen Dutzende neuer Dienste und digitaler Lösungen. Dank Agile kann das Unternehmen bei der Entwicklung neuer Produkte schnell genug sein, um mit diesem schnellen Tempo Schritt zu halten und Benutzern und Kunden so früh wie möglich die Möglichkeit zu geben, ihre Probleme zu lösen.

Zusammen mit der Popularität in Agile kam seine formale Interpretation. Wir werden die Mythen und Stereotypen analysieren, die uns daran hindern, die Essenz eines flexiblen Ansatzes zu erkennen und mehr daraus zu machen.

Mythos 1. Agil ist nur IT

Nicht mehr. Es reicht aus, sich die Liste der Unternehmen anzusehen, für die Redner bei Agile Days und Agile Business Conference sprechen: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Diese und viele andere Organisationen, die nicht mit der IT-Branche verbunden sind, setzen agile Ansätze mehr als erfolgreich ein.

Mythos 2. Agil - Nicht für Projekte mit festem Budget

Innerhalb eines festen Budgets können Sie sehr unterschiedlich arbeiten. Die Frage ist, in welchem ​​Verhältnis der Auftragnehmer zum Kunden steht. Wenn Sie Agile verwenden, müssen Sie sich darauf konzentrieren, was das Problem des Kunden löst. Mit anderen Worten, wenn der Kunde und der Auftragnehmer zu Beginn gemeinsam planen und die Hauptprioritäten des Produkts identifizieren, hindert sie nichts daran, zu bestimmen, welcher der nützlichsten Teile des Produkts vom Auftragnehmer innerhalb eines begrenzten Budgets implementiert werden kann. Und wenn Sie auch regelmäßige Anzeigen für den Kunden festlegen, ist es durchaus möglich, den Prozess in kurzen Segmenten anzupassen und dementsprechend die Kosten des Projekts anzupassen.

Mythos 3. Agil - ein Allheilmittel für Geschäft und Entwicklung: implementieren, etwas verbessern lassen

Es scheint mir, dass dies eine vereinfachte und sehr schädliche Sicht der Dinge ist. Alle Fälle und Unternehmen sind unterschiedlich, und Sie müssen den richtigen Ansatz wählen, der in diesem speziellen Fall hilfreich ist.

Agile wird definitiv nicht benötigt, wenn der Schlüssel zum Erfolg in einem genau definierten Aktionsalgorithmus liegt. Zum Beispiel in der Arbeit eines Callcenters, wo die Betreiber für einen besseren Service ein Gespräch unter Verwendung von "Skripten" führen sollten, d. H. vordefinierte Kommunikationsszenarien. Es gibt kein Experimentierfeld und sie können hier sogar schädlich sein. Daher wird Agile für die Aktivitäten von Call-Center-Betreibern nicht benötigt.



Agilität ist schädlich, wenn die Kosten für die "Verarbeitung" oder "Verfeinerung" des Produkts enorm sind oder sogar Menschenopfer bedeuten können. Sagen wir, während des Baus eines Kernkraftwerks ist es offensichtlich, dass wir nicht iterativ inkrementell bauen können, wie es uns Agile vorschreibt.

Mythos 4. Scrum, Lean, Kanban kreuzen sich nicht.

Methoden und Werkzeuge sollten getrennt werden. Die Methodik ist ein Algorithmus zum Erstellen eines Workflows. Werkzeuge sind die „Bausteine“, die in diesem Algorithmus verwendet werden.

Unterschiedliche Methoden können dieselben Tools enthalten, jedoch in einem anderen Layout. Sie können oft sehen, wie sie bei der Implementierung von Scrum auf XP- (extreme Programmierung) oder Kanban-Tools zurückgreifen. Dies ist normal, da alle die Agile-Werte erfüllen und Sie den Workflow für die Produkterstellung flexibel gestalten können.

Wenn wir über die spezifischen agilen Ansätze sprechen, die heute am weitesten verbreitet sind, dann sind dies sicherlich Scrum und Kanban. Andere - FDD, XP, RUP usw. - haben entweder die Bühne verlassen oder werden selten als Ganzes verwendet, aber einzelne Tools aus ihrem Arsenal sind an der Implementierung von Scrum oder Kanban beteiligt.

Mythos 5. Scrum - wie man ein Produkt schnell und billig herstellt.

Was "schnell" betrifft, ist alles wahr, aber was "billig" betrifft - nein. Überzeugen Sie sich selbst: Sie müssen ein vollwertiges Team bilden und die erforderlichen Kompetenzen zu 100% hervorheben. Diese Personen werden nur mit der Entwicklung des ihnen anvertrauten Produkts beschäftigt sein und sonst nichts, was bedeutet, dass sie entweder solche Spezialisten einstellen oder sie aus einer Abteilung „herausreißen“ müssen. Gleiches gilt für den Geschäftsteil: Wenn Sie möchten, wenn Sie nicht möchten, müssen Sie den Product Owner zuweisen, der 50–80% seiner Zeit nur diesem Team und seinem Produkt widmet.

Außerdem müssen Sie sie alle in einem Raum zusammenbringen, ihnen ihren eigenen Raum, Requisiten für Teamaktivitäten usw. zur Verfügung stellen. Außerdem müssen Sie berücksichtigen, dass mindestens acht Stunden pro Sprint für die Kommunikation aufgewendet werden, da Scrum eine Reihe von obligatorischen Besprechungen umfasst, die ein oder zwei Stunden dauern. Sie müssen auf jeden Fall investieren, aber der endgültige Gewinn an Geschwindigkeit und Qualität, den Scrum bietet, ist sehr groß.


Sprint umfasst 4 obligatorische Meetings: Planung, Implementierung, Veröffentlichung, Sprint-Überprüfung mit einer Retrospektive. Darüber hinaus finden jeden Tag kurzfristige Besprechungen (Stand-up-Besprechungen) statt, bei denen die Teammitglieder in einem einzigen Format auf die Uhr schauen und ihre Aktionen koordinieren. Sie können dem offenen Sprint keine neuen Aufgaben hinzufügen - dies gewöhnt das Team an die Planung und versichert gegen das Auftreten von Management-Chaos.

Mythos 6. Kanban ist eine Tafel mit Aufgaben.

Überhaupt nicht! Boards sind nur der erste und einfachste Schritt in Kanban. Aber die Sache ist nicht auf sie beschränkt . Das Herzstück von Kanban ist ein komplexer mathematischer Apparat, der auf statistischen Daten basiert. Kanban mit Brettern gleichzusetzen bedeutet daher, nicht über seine Fassade hinauszuschauen.

Kurz gesagt, der Hauptpunkt von Kanban ist:

• Machen Sie den aktuellen Workflow transparent und decken Sie alle Phasen ab - vom Auftreten der Aufgabe im Leiter des Unternehmens bis zur Implementierung und dem Versand des Produkts an den Verbraucher.
• Verwalten Sie Ihren Workflow, indem Sie Zeitverluste identifizieren und beseitigen. So machen wir unseren Workflow vorhersehbar.
• Treffen Sie Managemententscheidungen basierend auf Metriken, nicht auf Gefühlen.

Mythos 7. Scrum und Kanban können in alle Projekte und Unternehmen gepflanzt werden.

Ich mag das Wort "Pflanzen" nicht, schließlich geht es bei Agile darum, mit Menschen zu arbeiten. Es wäre richtiger, über das „Einflößen“ einer neuen Denkphilosophie in das Team zu sprechen.

Gleichzeitig unterscheiden sich der Scrum- und der Kanban-Transplantationsalgorithmus.

Die Erfolgsquote bei der Verwendung von Scrum hängt von der vorherrschenden Unternehmenskultur des Unternehmens ab. In einer starren hierarchischen Struktur, in der jeder ein Stück Papier benötigt, werden keine Bemühungen, Scrum zu „wachsen“, ohne die Unterstützung des Top-Managements erfolgreich sein. Wir müssen eine neue, parallele Struktur aufbauen, die auf einem Teamansatz basiert. Eine Art "Reserve Agile", die einen der Manager der höchsten Ebene schützt. Unter solchen Bedingungen ist es möglich, in drei bis vier Monaten ein schnelles Ergebnis zu zeigen. Es wird jedoch eine schwierigere Aufgabe geben - diese Kultur in der gesamten Organisation zu verbreiten. Wie lange dies dauern wird, ist äußerst schwer zu beurteilen. Wenn der neue Ansatz meiner Erfahrung nach 30% des Unternehmens abdeckt, breitet er sich weiter aus und benötigt keinen Schutz mehr von oben.

Die Implementierung von Scrum erfordert im Allgemeinen große Änderungen, sowohl in der Struktur der Organisation als auch in der Auftragsvergabe mit Auftragnehmern (Sie benötigen einen Zeit- und Materialvertrag ), in der Budgetierung (schrittweise Budgetierung) und in allem anderen.



Kanban erfordert keine solch radikale Veränderung. Er bietet an: "Beginnen Sie mit dem, was ist, und beginnen Sie, es evolutionär zu verbessern." Die Änderungsrate wird erheblich niedriger sein als in Scrum, aber alle Änderungen basieren auf Statistiken und haben eine klare Begründung.

Mythos 8. Scrum wurde nur für Projekte entwickelt, die von Grund auf neu erstellt wurden.

Es gibt verschiedene Fälle, es gibt keine starre Regel, dass Scrum nur für die Entwicklung von Grund auf neu gedacht ist. Die Übertragung bestehender Projekte auf Scrum ist nicht nur möglich, sondern häufig angemessen. Alles hängt von der Bereitschaft der Künstler und Kunden ab, ihre Arbeit neu zu strukturieren, um die Entwicklung zu beschleunigen. Wenn sie bereit sind, ist alles erreichbar.

Zum Beispiel sprach einer der Schöpfer von Scrum, Jeff Sutherland, in seinem Buch Scrum: Die Kunst, zweimal die Arbeit in der Hälfte der Zeit zu erledigen, darüber, wie er mit Scrum ein automatisiertes FBI-Buchhaltungssystem entwickelte. Als er das Projekt aufnahm, wurde die Entwicklung für das vierte Jahr fortgesetzt, es wurde keine einzige Funktion zur Veröffentlichung gebracht und das Projekt war weder am Ende noch am Rand sichtbar. Jeff konnte die Entwicklung radikal beschleunigen und für die Kunden transparent machen. Sechs Monate später wurde die erste funktionierende Version des Produkts veröffentlicht, und innerhalb von zwei Jahren wurde die Entwicklung erfolgreich abgeschlossen.

Mythos 9. Bei der Einführung flexibler Methoden sind Konflikte mit Vertretern der traditionellen Hierarchie unvermeidlich

Wenn alles richtig gemacht wird - um das Team von der traditionellen Hierarchie zu trennen, das Budget dem Product Owner zu geben und einen wirklich erfahrenen Scrum-Master einzustellen, gibt es keine Konflikte. Dies ist jedoch nicht immer der Fall. Es ist oft unmöglich, diese beiden Strukturen zu kombinieren, daher gibt es nur einen Ausweg: eine neue Struktur aufzubauen, die für eine schnelle Entscheidungsfindung und Implementierung des Produkts geschärft ist.

Und wer so ein Scrum-Master ist, erfahren Sie in der nächsten Serie. Warten Sie im zweiten Teil der Geschichte von Vasily über die Implementierung flexibler Entwicklungsmethoden: die Schwierigkeiten, Vorteile, Fallstricke und Zeitbomben.

UPD Und hier ist die Fortsetzung: Es geht um Agile - 2: Funktionen zur Implementierung der agilen Entwicklung

Es gibt keine Zeit zu erklären, das Material wurde vom Mail.Ru Cloud Solutions- Team desinteressiert und liebevoll vorbereitet.