Alles dreht sich um Agile 1: Beliebte Mythen zur agilen Entwicklung



    Agile Entwicklungsmethoden haben sowohl in der IT als auch in der Nicht-IT Wurzeln geschlagen und sind von Vorzeichen, Stereotypen, Aberglauben und Mythologie überwältigt. Die Redakteure des Mail.Ru Cloud Solutions-Blogs beschlossen, mit dem 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 Agile-Ansatzes haben den Entwicklungsprozess verändert und Respekt gewonnen. Die moderne Welt beschleunigt sich sehr - täglich tauchen Dutzende neuer Dienste und digitaler Lösungen auf. Mit Agile kann das Unternehmen bei der Entwicklung neuer Produkte schnell genug sein, um mit diesem hohen Tempo Schritt zu halten und Benutzern und Kunden so früh wie möglich die Lösung ihrer Probleme zu bieten.

    Mit der Popularität in Agile ging auch die formale Interpretation einher. Wir werden die Mythen und Stereotype 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 genügt, sich die Liste der Unternehmen anzusehen, in deren Namen die Redner der Agile Days und der Agile Business Conference sprechen: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Diese und viele andere Organisationen, die nichts mit der IT-Branche zu tun haben, setzen mehr als erfolgreich agile Ansätze ein.

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


    Innerhalb eines festen Budgets können Sie sehr unterschiedlich arbeiten. Die Frage ist, wie die Beziehung zwischen dem Auftragnehmer und dem Kunden ist. Wenn Sie Agile verwenden, müssen Sie sich auf das konzentrieren, was das Problem des Kunden löst. Mit anderen Worten, wenn der Kunde und der Auftragnehmer zu Beginn gemeinsam die Planung durchführen und die Hauptprioritäten des Produkts ermitteln, hindert sie nichts daran, festzustellen, welcher der nützlichsten Teile des Produkts vom Auftragnehmer innerhalb eines begrenzten Budgets umgesetzt werden kann. Und wenn Sie auch regelmäßige Anzeigen für den Kunden festlegen, ist es durchaus möglich, den Prozess in kurzen Abschnitten anzupassen und dementsprechend die Kosten des Projekts anzupassen.

    Mythos 3. Agile - ein Allheilmittel für Geschäft und Entwicklung: umsetzen, 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.

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



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

    Mythos 4. Scrum, Lean, Kanban überschneiden 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. Und das ist normal, da alle die Agile-Werte erfüllen und es Ihnen ermöglichen, den Workflow für die Erstellung eines Produkts flexibel zu gestalten.

    Wenn wir über die spezifischen agilen Ansätze sprechen, die derzeit 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 werden für die Implementierung von Scrum oder Kanban verwendet.


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


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

    Darüber hinaus 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ß.

    Sprints
    Sprint ist ein Begriff aus dem Scrum-Arsenal. Dies ist ein festgelegter Zeitraum, in dem das Team einen Teil des Produkts herstellt, der für den Kunden von Wert ist. Der Punkt ist, dass das Team für jeden Sprint einen weiteren Schritt in Richtung des Ziels machen muss, den Sie "anfassen" können, um das tatsächliche Ergebnis zu bewerten. Meistens dauert der Sprint 2 Wochen.

    Sprint beinhaltet 4 obligatorische Meetings: Planung, Implementierung, Veröffentlichung, Sprint Review mit einer Retrospektive. Darüber hinaus finden täglich kurzfristige Besprechungen (Stand-up-Meetings) 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 schützt es vor dem Auftreten von Manager-Chaos.

    Mythos 6. Kanban ist eine Tafel mit Aufgaben.


    Gar nicht! Boards sind nur der erste und einfachste Schritt in Kanban. Die Sache ist aber 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 die Fassade hinauszublicken.

    Kurz gesagt, der Hauptpunkt von Kanban ist:

    • Machen Sie den aktuellen Workflow transparent und decken Sie alle Phasen ab - vom Auftreten der Aufgabe im Head of Business 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 auf der Grundlage von Metriken und nicht von Gefühlen.

    Mythos 7. Scrum und Kanban können in beliebigen Projekten und Firmen gepflanzt werden.


    Ich mag das Wort "Pflanzen" nicht, schließlich geht es bei Agile darum, mit Menschen zu arbeiten. Es wäre richtiger, davon zu sprechen, dem Team eine neue Denkphilosophie beizubringen.

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

    Die Erfolgsquote von Scrum hängt von der vorherrschenden Unternehmenskultur des Unternehmens ab. In einer starren hierarchischen Struktur, in der jeder ein Blatt Papier benötigt, sind keine Bemühungen zum „Wachsen“ von Scrum ohne die Unterstützung des Top-Managements erfolgreich. Wir müssen eine neue, parallele Struktur aufbauen, die auf einem Teamansatz basiert. Eine Art "Reserve Agile", die einen der Manager der höchsten Stufe beschützt. Unter solchen Bedingungen ist es möglich, innerhalb von drei bis vier Monaten ein schnelles Ergebnis zu erzielen. Es steht jedoch eine schwierigere Aufgabe bevor - diese Kultur in der gesamten Organisation zu verbreiten. Wie lange dies dauern wird, ist äußerst schwer abzuschätzen. Wenn der neue Ansatz meiner Erfahrung nach 30% des Unternehmens abdeckt, beginnt er sich weiter auszubreiten und muss nicht mehr von oben geschützt werden.

    Die Implementierung von Scrum erfordert im Allgemeinen große Änderungen, sowohl in der Organisationsstruktur als auch beim Abschluss von Verträgen mit Auftragnehmern (Sie benötigen einen Zeit- und Materialvertrag ) sowie bei der Budgetierung (gestaffelte Budgetierung) und 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 werden auf Statistiken basieren und klar begründet sein.

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


    Es gibt verschiedene Fälle, es gibt keine feste Regel, dass Scrum nur für die Entwicklung von Grund auf neu gedacht ist. Das Übertragen bestehender Projekte auf Scrum ist nicht nur möglich, sondern oft sinnvoll. 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 beschrieb einer der Macher von Scrum, Jeff Sutherland, in seinem Buch Scrum: Die Kunst, zweimal in der Hälfte der Zeit zu arbeiten, wie er Scrum zur Entwicklung eines automatisierten FBI-Datenabrechnungssystems verwendete. Als er das Projekt aufnahm, ging die Entwicklung das vierte Jahr weiter, es wurde keine einzige Funktion zum Release gebracht und das Projekt war weder für das Ende noch für den Rand sichtbar. Jeff konnte die Entwicklung radikal beschleunigen und für die Kunden transparent machen. Sechs Monate später wurde die erste Arbeitsversion des Produkts veröffentlicht und innerhalb von zwei Jahren wurde die Entwicklung erfolgreich abgeschlossen.

    Ein paar Worte zum Buch von Jeff Sutherland
    Scrum: Die Kunst, zweimal in der Hälfte der Zeit zu arbeiten. In der russischen Übersetzung - "Scrum: eine revolutionäre Methode des Projektmanagements." Das 2014 erstmals veröffentlichte Buch beschreibt die Voraussetzungen für die Erstellung einer Methodik, ihre Grundprinzipien, Tools und Implementierungsbeispiele. In den 20 Jahren, seit Jeff Sutherland und Ken Schweiber, der Autor des Buches, das Scrum-Konzept systematisch beschrieben haben, haben sie große Anstrengungen unternommen, um die Methodik außerhalb der IT-Branche zu verbreiten und in den Dienst von Nicht-Technologie-Unternehmen zu stellen - finanziell, industriell und so weiter. weiter.

    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 überlassen und einen wirklich erfahrenen Scrum-Master einzustellen, gibt es keine Konflikte. Das kommt aber nicht immer vor. Das Kombinieren dieser beiden Strukturen ist oft unmöglich, daher gibt es nur einen Ausweg: eine neue Struktur aufzubauen, die für eine schnelle Entscheidungsfindung und Produktimplementierung geschärft ist.

    Und wer 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 Komplexität, die Vorteile, die Fallstricke und die Zeitbomben.

    UPD. Und hier ist die Fortsetzung: Alles dreht sich um Agile - 2: Funktionen zur Implementierung agiler Entwicklung

    Es ist keine Zeit zu erklären, das Team von Mail.Ru Cloud Solutions hat das Material selbstlos und liebevoll vorbereitet .

    Jetzt auch beliebt: