Agile Kalkulation. Agile Entwicklungsmethodik (Agile)

Bestehend aus 12 Prinzipien. Gewisse Bestimmungen des agilen Vorgehens sind natürlich schon vorher aufgetaucht, aber erst dieses Dokument systematisiert und skizziert sie in ausreichendem Umfang für die Anwendung. Jedes Jahr unterzeichnen neue Unternehmen, IT-Spezialisten und Projektmanager das Manifest. Es gibt neue Methoden und Modifikationen des agilen Entwicklungssystems.

Was ist Agile Methodology (flexible Methodik)?

Agile ist ein iteratives Entwicklungsmodell, bei dem Software von Beginn eines Projekts an inkrementell erstellt wird, im Gegensatz zu Wasserfallmodellen, bei denen Code am Ende eines Arbeitszyklus geliefert wird.

Die Grundlage einer agilen Methodik ist das Aufteilen von Projekten in kleine Arbeitsstücke, die User Stories genannt werden. Entsprechend der Priorität werden die Aufgaben im Rahmen von kurzen zweiwöchigen Zyklen (Iterationen) gelöst.

Die 12 Prinzipien, aus denen sich die agile Methodik zusammensetzt, lassen sich in 4 Hauptideen unterteilen:

• Priorität von Menschen und Kommunikation gegenüber Tools und Prozessen;
• Vorrang eines funktionierenden Produktes vor vollständiger Dokumentation;
• Vorrang der Zusammenarbeit mit Kunden vor Vertragsfreigabe;
• Priorisieren Sie die Bereitschaft zur Umstellung gegenüber dem Befolgen des ursprünglichen Plans.

Methoden, die in Agile vorhanden sind:

Rugby verdankt seinen Begriff "Scrum", in dem dieses Wort eine Methode des Teamspiels in der Form bedeutet, dass jeder der Gegner drei Reihen bildet und versucht, den Ball zu erobern. Ein erfolgreiches Abfangen erfordert nicht nur eine gute körperliche Vorbereitung, sondern auch die Kohärenz jedes Kampfteilnehmers und ein klares Verständnis des Ziels.

Die Methode wird von Unternehmen wie Microsoft, Yahoo, Siemens Healthcare erfolgreich eingesetzt und der Projektleiter bei Amazon hat sie anhand der gewonnenen Erfahrungen sogar beschrieben.

Da es sich bei Scrum um ein Entwicklungsframework handelt, kann es sich in jedem nachfolgenden Beispiel deutlich vom vorherigen unterscheiden.

Jeff Sutherland, der Autor, identifizierte 8 Schritte zur Anwendung der Technik:

1. Auswählen Produkteigentümer- Er kennt den Zweck des Projekts und das erwartete Ergebnis.
2. Versammeln Befehl- bis zu 10 Personen mit den notwendigen Fähigkeiten, um ein funktionsfähiges Produkt zu erstellen.
3. Finden Scrum-Master— Er überwacht den Fortschritt des Projekts, hilft dem Projektteam bei der Bewältigung von Schwierigkeiten.
4. Bilden Produktrückstand- Priorisieren Sie auf dem Agile-Board jede Produktanforderung. Hier spielt der Product Owner eine große Rolle, der die Wünsche für das Produkt zur Bewertung durch das Backlog-Team sammelt.
5. Plan Sprints(Iterationen) - Zeitspannen zur Durchführung einer bestimmten Anzahl von Aufgaben.
6. Organisieren täglich fünfzehnminütige "Meet-ups"- Stellen Sie jedem Teammitglied 3 Fragen: Was haben Sie gestern gemacht, was wird heute passieren, was hindert Sie daran, die Aufgabe zu erledigen?
7. Tun Bewertungen der Arbeitsteile des Produkts- mit Beteiligung an der Sichtung und Diskussion von Stakeholdern.
8. Ausgeben Rückblick— Besprechung des Problems und Suche nach einer Lösung nach jedem Sprint. Implementieren Sie den resultierenden Änderungsplan im nächsten Sprint.

Retrospektive in Agile

Scrum hat 4 Schlüsselelemente:

• Produktrückstand- Anforderungsliste für das Projekt
• Sprint-Rückstand- eine Liste der Anforderungen, die im nächsten Sprint erfüllt werden müssen
• Sprint-Ziel- Sprintziel
• Sprint-Burndown-Diagramm- Ein Diagramm, das nach Abschluss der Aufgaben aktualisiert wird. Es ist leicht, die Dynamik und den Fortschritt des Teams im Projekt zu verstehen.

(XP)

Der Entwickler der Methodik, Kent Beck, hat die Extreme Programming-Methode geschaffen, deren Zweck es ist, den sich ständig ändernden Anforderungen an ein Softwareprodukt gerecht zu werden und die Qualität der Entwicklung zu verbessern.

Es ist ausschließlich im Bereich der Softwareentwicklung anwendbar und basiert auf 4 Prozessen:

1. Kodierung— nach einheitlichen Gestaltungsstandards im Team;
2. testen- Tests werden von Programmierern selbst geschrieben, bevor der zu testende Code geschrieben wird;
3. Planung- sowohl der endgültige Build als auch einzelne Iterationen. Letzteres findet durchschnittlich alle zwei Wochen statt.
4. Hören- sowohl Entwickler als auch der Kunde, bei dem Unklarheiten verschwinden, Anforderungen und Werte ermittelt werden.

Methoden

Eine Familie von Methoden, die in den heimischen Weiten des Projektmanagements wenig bekannt sind, entwickelt von Alistair Cockburn, einem der Autoren des "Agile Software Development Manifesto". Cockburn schlägt vor, nach Farbe nach dem Kriterium der Anzahl der Personen im Team zu klassifizieren: von 2 (Crystal Clear) bis 100 (Crystal Red). Für größere Projekte werden die Farben Kastanienbraun, Blau und Violett zugewiesen.

Crystal-Projekte müssen 3 Hauptindikatoren erfüllen:

1. schnelle Lieferung von Arbeitscode— Entwicklung der Idee eines iterativen agilen Entwicklungsmodells.
2. Perfektion durch Reflexion- Die neue Version der Software wurde basierend auf den Daten der vorherigen Version verbessert.
3. "osmotische" Interaktion- Alistairs Innovation, eine Metapher für Kommunikation und Informationsaustausch zwischen Softwareentwicklern im selben Raum.

Dynamische Softwareentwicklungsmethode (DSDM)

Nicht eine Person oder gar ein Team hat an der Entwicklung von DSDM gearbeitet, sondern ein Konsortium aus 17 englischen Firmen. DSDM wird wie Extreme Programming hauptsächlich zum Erstellen verwendet Software.

Eine besondere Rolle kommt der Beteiligung des Endverbrauchers (Anwenders) am Entwicklungsprozess zu. Zusätzlich zu diesem Prinzip gehören zu den grundlegenden:

• häufige Veröffentlichungen von Arbeitsversionen des Produkts
• Entscheidungsfreiheit der Entwickler
• Prüfung während des gesamten Arbeitszyklus.

DSDM ist in Versionen unterteilt, die aktualisiert werden, wenn sich die Technologie weiterentwickelt und neue Anforderungen für die Softwareentwicklung auftreten. Das letzte für heute ist DSDM Atern, das 2007 veröffentlicht wurde, obwohl das vorherige (2003) immer noch in Betrieb ist.

Zu Beginn erkundet das Team die Realität der Anwendungsentwicklung und den Umfang. Die weitere Arbeit gliedert sich in drei miteinander verbundene Zyklen:

1. Funktionsmodellzyklus— Erstellung analytischer Dokumentationen und Prototypen.
2. Planungs- und Bauzyklus- das System in einen funktionsfähigen Zustand zu bringen.
3. Implementierungszyklus- Systembereitstellung.

Funktionsgesteuerte Entwicklung (FDD)

Eine Methodik, die sogar älter ist als das Agile Manifest.

Obwohl FDD ebenfalls ein iteratives Entwicklungsmodell verwendet, unterscheidet es sich in folgenden Punkten von Agile:

• mehr Aufmerksamkeit für die Vormodellierung
• Erhöhte (im Vergleich zu Agile) Bedeutung von Berichten und Grafiken
• auf die Unternehmensentwicklung ausgerichtet.

Feature Driven Development besteht aus folgenden zyklischen Phasen:

1. Erstellen Sie ein gemeinsames Modell— Vision des Projekts auf der Grundlage vorläufiger Daten.
2. Erstellen einer Immobilienliste- ein Analogon des Product Backlogs in der Scrum-Methodik.
3. Planung nach Eigenschaften- Bewertung der Komplexität der Eigenschaften durch jedes Teammitglied.
4. Für jede Immobilie- technisches Design und Umsetzung - die letzte Phase, an deren Ende die Eigenschaft in das Produkt übergeht und der Zyklus sich wiederholt.

Software-Entwicklung

Lean Software Development – ​​keine Methodik, sondern eine Reihe von Prinzipien schlanke Fertigung, das darauf abzielt, die Effizienz des Entwicklungsprozesses zu steigern und die Kosten zu minimieren.

Das Set beinhaltet die folgenden 7 Prinzipien:

1. Verluste loswerden- alles, was dem Produkt keinen Mehrwert für den Endverbraucher verleiht.
2. Fortlaufendes Lernen– Kontinuierliche Entwicklung des Teams erhöht die Möglichkeiten Wirksame Umsetzung Aufgaben.
3. eine Entscheidung so spät wie möglich treffen- Priorität haben nicht spontane Entscheidungen, sondern durchdachte, auf der Grundlage des erworbenen Wissens entwickelte.
4. schnelle Lieferung- eigentlich die Grundlage des iterativen Modells.
5. Team-Stärkung- Einer der Grundsätze des "Manifesto ..." besagt, dass Menschen und Interaktion wichtiger sind als Prozesse und Werkzeuge. Das Projektteam ist die Basis für die erfolgreiche Erledigung von Aufgaben.
6. Integrität und Qualität- Sie müssen zunächst ein Qualitätsprodukt herstellen, um keine Zeit und Ressourcen für weitere Tests und die Beseitigung von Fehlern zu verschwenden.
7. das ganze Bild sehen- Das Aufteilen des Projekts in einzelne Teile ist ohne Verständnis des aktuellen Entwicklungsstands, der Ziele, des Konzepts und der Strategie der zu entwickelnden Software nicht möglich.

Varianten agiler Entwicklungsmethoden

Agile Modellierung (AM)

Agile Modellierung ist eine Reihe von Werten, Prinzipien und Praktiken für die Softwaremodellierung.

AM wird als Teil einer vollständigen Softwareentwicklungsmethodik wie Extreme Programming oder Rapid Application Development verwendet.

Die Prinzipien der agilen Modellierung sind:

• effektive Interaktion zwischen den Projektbeteiligten
• bestrebt, das einfachste zu entwickeln mögliche Lösungen das allen Anforderungen gerecht wird
• ständige Rückmeldung
• Mut zu treffen und Verantwortung für Entscheidungen zu übernehmen
• zu verstehen, dass Sie nicht alles wissen.

Agiler einheitlicher Prozess (AUP)

AUP ist eine vereinfachte Version einer anderen Softwareentwicklungsmethodik, des Rational Unified Process (RUP). Seit 2012 ist es durch Disciplined Agile Delivery (DAD) ersetzt worden, aber AUP ist an einigen Stellen immer noch zu finden.

Der Autor der Methodik, Scott Ambler, identifizierte die folgenden Schlüsselpositionen des Agile Unified Process:

• Ihr Team weiß, was es tut;
• Einfachheit steht über allem.
• Einhaltung der Prinzipien der agilen Entwicklungsmethodik.
• Konzentrieren Sie sich auf Aktivitäten, die für das Projekt wertvoll sind.
• Unabhängigkeit in der Werkzeugwahl.
• Individuelle Anpassung von AUP an die Bedürfnisse eines bestimmten Projekts.

Agile Datenmethode (ADM)

ADM ist eine Reihe iterativer agiler Softwareentwicklungsmethoden, die die Generierung von Anforderungen und Projektentscheidungen durch die Zusammenarbeit einzelner Teams betonen. Wie AUP ist es an sich keine wertvolle Technik.

Die Essenz der Agile Data Method wird durch sechs Bestimmungen definiert:

1. Daten- die Grundlage für die Erstellung jeder Anwendung.
2. Probleme mit dem Projekt— Sie können nur mit einem klaren Verständnis des Zwecks und Konzepts des Projekts erkannt werden.
3. Arbeitsgruppen- Neben dem direkten Entwicklungsteam gibt es Unternehmensgruppen, die andere Arbeitsgruppen unterstützen.
4. Einzigartigkeit— Es gibt keine perfekte Methodik, für jedes Projekt müssen Sie Tools aus verschiedenen Methodologien kombinieren.
5. Zusammenarbeit — Zusammenarbeit viel effektiver als einzeln.
6. "Sweet-Spot"- Suche optimale Lösung Probleme ("Sweet Spot"), Extreme vermeiden.

Wesentlicher einheitlicher Prozess (EssUP)

Die Entwicklung des schwedischen Wissenschaftlers Ivar Jacobson, geschaffen, um den Rational Unified Process zu verbessern.

EssUP arbeitet mit dem Konzept der Praxis, das Folgendes beinhaltet:

• Anwendungsfall – eine Beschreibung des Verhaltens des Systems.
• iterative Entwicklung - die Erstellung von funktionierenden Codestücken in kurzen Zyklen von mehreren Wochen.
• Teampraktiken - mit dem Ziel, das Team zusammenzubringen und seine Effektivität zu steigern.
• Prozesspraktiken – zum Beispiel „Think big, start small“ oder „Involve Stakeholders in Business Processes“.

Alle Praktiken in der einen oder anderen Form finden sich in RUP, CMMI und agilen Methoden.

Echt werden (GR)

Eine Methode, die für Startups und unerfahrene Teams effektiv ist und die Möglichkeiten bietet, die Merkmale kleiner Projekte und Unternehmen optimal zu nutzen: Mobilität, Flexibilität, die Suche nach neuen Lösungen, das Fehlen einer starren, verwirrenden Hierarchie usw. Jason Fried und David Hansson, Gründer von 37signals (jetzt Basecamp), haben Getting Real als ein System zur Lösung realer Probleme definiert: so einfach, verständlich und funktional wie möglich.

GR ist ein Sammelsurium aus einem Dutzend agiler Entwicklungstools, die verwendet werden, um Folgendes zu minimieren:

• Gelegenheiten
• Optionen und Einstellungen
• Unternehmensstrukturen
• Sitzungen
• Versprechen.

Das ungewöhnliche Konzept hat keine breite Akzeptanz gefunden, obwohl einzelne Elemente andere Techniken verwenden.

OpenUP (OUP)

Eine Tool-unabhängige Softwareentwicklungsmethodik ohne starre Struktur, die die folgenden Praktiken enthält:

• Messen der Geschwindigkeit des Teams;
• Abhalten täglicher Meetings und Retrospektiven am Ende der Iterationen;
• das Konzept der Mikroschritte und des frühen Testens anhand von Checklisten;
• flexible Modellierungstechnik (AMDD).

Praktiken werden auf der Grundlage von vier Prinzipien implementiert:

Agile Metriken

Angesichts der Vielzahl von Tools, Praktiken, Methoden und Methodologien in Agile müssen Sie ein Tool auswählen, das Ihnen hilft, die Effektivität jedes einzelnen von ihnen zu bestimmen. Metriken sind ein solches Werkzeug.

Für die meisten Projekte sind 4 Bereiche von Metriken ausreichend:

1. Leistung- dazu gehören Velocity und WIP. Ersteres ist nicht für alle Projekte geeignet, da die Anzahl der abgeschlossenen Aufgaben pro Iteration gemessen wird und diese nicht gleichwertig sind. Die Work-in-Progress-Metrik bestimmt die Grenze der Aufgaben in verschiedenen Phasen: Je höher sie ist, desto schlechter ist sie;
2. Prognose- Kapazitätsmetrik: Bestimmung der Anzahl idealer verfügbarer Stunden im nächsten Sprint. Dementsprechend können Sie nachvollziehen, wie viel Zeit für die Arbeit zur Verfügung steht, wie effizient die Ausführung von Aufgaben ist und wie Sie die Anzahl der Aufgaben für den Sprint planen;
3. Qualität- zum Beispiel der Anforderungsstabilitätsindex, der nach folgender Formel berechnet wird: = (Gesamtzahl der ursprünglichen Geschäftsanforderungen + Anzahl der Anforderungen, die sich bisher geändert haben + Anzahl der hinzugefügten Anforderungen + Anzahl der entfernten Anforderungen) / (Gesamtzahl der ursprünglichen Anforderungen ). Die Metrik misst die Zeit, die für das Wiederholen von Aufgaben aufgewendet wurde;
4. Werte- sie wird jeweils individuell berechnet, je nach Format des Projektes. Das Startup AirBnb hat beispielsweise die Anzahl der hochgeladenen Fotos als Metrik gewählt, die den endgültigen Wert des Produkts für die Nutzer bestimmt. Hohe Qualität. Mit ihrer Zunahme stieg auch die Zahl der Verbraucher proportional.

Für Metriken gelten die gleichen Regeln wie für andere agile Tools.

Es gibt nicht die eine richtige oder richtige Metrik für Ihr Projekt.

Sie müssen ständig überprüft, veraltete verworfen und bei Bedarf neue hinzugefügt werden. Es sollte für das gesamte Team verständlich und zugänglich sein, nicht zum Selbstzweck werden. Metriken um der Metriken willen ist eine schlechte Entscheidung.

Mythbusters: Agil

Die Popularität der Familie der agilen Entwicklungsmethodik hat einen grausamen Scherz damit gespielt, und selbst auf spezialisierten Portalen gibt es Mythen über diesen oder jenen Aspekt von Agilität. Wir finden es heraus!

Mythos #1: Agile ist gut für alle Projekte.

Das hartnäckigste Missverständnis. Keine agile Methode allein wird einen Mehrwert für ein Produkt schaffen oder ein Team motivieren.

Mythos Nr. 2: Agil versus Dokumentation.

Agilität ist nicht gegen Dokumentation, es ist gegen Dokumentation als Selbstzweck. Aber bei der Wahl der Dokumentation als Kommunikationsmittel priorisiert Agile wirklich die Live-Kommunikation.

Mythos Nr. 3: Agilität und Planung passen nicht zusammen.

Dieser Mythos wird durch Tagesplanung mit 10-Minuten-Standups, iterative Planung alle zwei Wochen, Sprint-Meetings usw. entlarvt.

Mythos Nr. 4: Agile erfordert viel Nacharbeit.

In der agilen Softwareentwicklung gibt es zwei Formen von Redesign: Rewrite von Anforderungen (Benutzer verstehen, was sie wirklich brauchen) und Software (Entwicklungsteams finden bessere Wege, eine Anwendung zu schreiben und zu entwerfen). Damit muss man sich aber auch bei anderen Methoden auseinandersetzen! Darüber hinaus ist ein iteratives Modell erforderlich, um die negativen Auswirkungen von Nacharbeiten zu reduzieren, was ein Merkmal von Agile ist.

Vor- und Nachteile der Verwendung von Agile

Vorteile:

1. Stakeholder-Beteiligung- Das Team hat mehr Möglichkeiten, die Wünsche des Kunden zu verstehen. Und eine frühzeitige und häufige Softwarebereitstellung stärkt das Vertrauen der Stakeholder in das Projektteam und eine noch tiefere Beteiligung am Projekt.
2. frühe und vorhersehbare Lieferung- Entwicklungsmodell durch Iterationen (kurze Intervalle von 1 bis 6 Wochen) gibt Flexibilität, beschleunigt die Freigabe der Produktfreigabe.
3. Fokus auf den Geschäftswert- Die Zusammenarbeit mit dem Kunden stellt sicher, dass das Team versteht, das Produkt für den Verbraucher so wertvoll wie möglich zu machen.
4. kontinuierliche Qualitätsverbesserung- Das Testen während jeder Iteration, das Aufteilen des endgültigen Builds in separate Teile des Arbeitscodes ermöglicht es Ihnen, Softwarefehler zu verbessern und vor der Veröffentlichung des Endprodukts zu beheben.

Minuspunkte:

• erhöhte Anforderungen an Team und Kunden– Ohne eine enge Interaktion zwischen dem Projektteam und den Benutzern ist es unmöglich, ein qualitativ hochwertiges Produkt mit hohem Wert zu erzielen. Und die Fülle an Werkzeugen und Methoden in Agile zur Umsetzung erfordert ein erfahrenes Team.
• nicht für Outsourcing geeignet und Projekte, bei denen die Teilnehmer nur online miteinander interagieren.
• das Risiko, niemals die endgültige Version der Software zu veröffentlichen- dieses Minus ergibt sich seltsamerweise aus der iterativen Entwicklung und kontinuierlichen Verbesserung des Produkts - die Pluspunkte von Agile.
• funktioniert nicht ohne eine klare Vision der Geschäftsziele des Projekts- Da sich das agile Team auf Stakeholder konzentriert, ist Entwicklung ohne die Entwicklung von Zielen und einem Produktkonzept nicht möglich.

Anwendungen

Projekte verwalten mit Agile ist nicht für alle Dienste oder Programme zum Projektmanagement geeignet, da jedes seine eigenen Besonderheiten hat.

Wenn Ihr Unternehmen dabei istMarketing und Werbung, Design, SEO bzw digitale Agenturen , dann der SaaS-Dienst kann auf die Arbeit des gesamten Teams als Ganzes angewendet werden. Wir werden empfohlen .

Hier sind ein paar Lifehacks, um Agile einzurichten

1. Etiketten und Status anpassen die für den Betrieb Ihres Unternehmens erforderlich sind.
   Status können sein: in Bearbeitung, Verifizierung, abgeschlossen, Verbesserungsbedarf, kritisch, Funktion, Bezahlung.
   Etiketten sehen oft so aus: Layout, Test, Produktion, Konzept, Code.
2. Erstellen Sie ein Backlog-Projekt und Frühlingsprojekt.
3. Aufgaben erstellen und vorläufige Checklisten, Skizzen und mehr im Rückstand.
4. über Treffen entscheiden Frühjahrsaufgaben und verschieben Sie sie aus dem Rückstand im Sprint.
5. benutzen Client-Gastzugang zu Aufgaben, um immer konsistente und aktuelle Kommentare zum Projekt zu haben.
6. zelebrieren Aufgaben zuständig damit jeder Kollege sein Aufgabengebiet kennt und sich am Sprintergebnis beteiligt fühlt.

Urteil

Mit einer agilen Softwareentwicklungsmethodik erzielen kleine Projektteams maximale Effizienz. Agile wird durch andere agile Methoden implementiert: Scrum, XP, Lean usw.

Es lässt sich nicht auf einen Schlag, von einem unerfahrenen Team, in kurzer Zeit umsetzen, aber die Einführung von Agile wird die Interaktion zwischen IT und Business verbessern, die Markteinführung des Produkts beschleunigen und den Wert des Produkts für den Endbenutzer steigern.

• Übersetzung

"Jeder Fall dauert immer länger als erwartet, auch wenn man das Gesetz von Hofstadter berücksichtigt."
- Hofstadtersches Gesetz

Meistgesehenes agiles YouTube-Video. 744.625 Aufrufe zum Zeitpunkt der Veröffentlichung dieses Artikels. Leichte Art der Präsentation, Bilder und nur 15 Minuten - das Beste, was ich je gesehen habe. TED ruht sich aus.

Rollen

Bandbreite

Um diesen Rhythmus beizubehalten und sich nicht in manuellen Regressionstests zu verzetteln, arbeitet das Team mit Hochdruck daran automatische Prüfung und laufende Integration. Daher müssen Sie für jede Funktion Autotests schreiben, und der meiste Code verfügt über integrierte Autotests.

Jedes Mal, wenn wir eine User Story umsetzen, kommen ein paar Ideen mehr, aus denen noch mehr Anfragen fließen.

Was passiert, wenn wir alles tun, worum sie uns bitten? Wir werden überlastet.

Scrum und XP verwenden in diesem Fall die „Gestern-Wetter“-Methode. Das Team sagt: „In letzter Zeit haben wir 4-6 Features pro Woche gemacht, welche 4-6 Features werden wir nächste Woche machen?“

Die Aufgabe des Product Owners besteht darin, mit Bedacht auszuwählen, welche User Stories diese Woche implementiert werden.

Kanban empfiehlt, sich auf wenige Aufgaben zu beschränken – WIP-Limit. Nehmen wir an, das Team entscheidet, dass 5 eine akzeptable Anzahl von User Stories ist, an denen es gleichzeitig arbeiten kann, ohne überfordert zu sein, ohne von einer zur anderen zu springen.

Auch diese Warteschlange muss gemanagt werden: Wenn Stakeholder 10 Stories pro Woche anfordern und das Team 4-6 Stories umsetzt, dann wird diese Warteschlange immer länger. Und bald wird Ihr Backlog für sechs Monate im Voraus geplant. Das heißt, eine Geschichte wird auf die Veröffentlichung von 6 Monaten warten.

Es gibt nur einen Weg, Ihre To-do-Liste unter Kontrolle zu halten, und das ist das Wort „nein“

Ja sagen ist einfach. Aber die wichtigere Aufgabe ist entscheiden, was nicht zu tun ist und dafür Verantwortung übernehmen. Der Product Owner bestimmt auch die Reihenfolge dessen, was wir jetzt tun und was wir später tun. Das harte Arbeit und sollte mit dem Entwicklungsteam und mindestens einem Stakeholder durchgeführt werden.

Entscheidungen treffen

Wie verhält sich die Größe einer Geschichte zu ihrem Wert? Auf keinen Fall. Mehr bedeutet nicht besser. Der Wert und die Komplexität der Aufgabe helfen Pat bei der Priorisierung.

Wie bestimmt der Product Owner den Wert und Umfang einer Story? Auf keinen Fall. Dies ist ein Ratespiel. Und es ist besser, wenn alle daran teilnehmen. Pat kommuniziert ständig mit Stakeholdern, um den Wert jeder Geschichte zu erfahren, kommuniziert mit dem Entwicklungsteam, um den Umfang der Arbeit zu erfahren, aber das sind alles grobe Schätzungen, keine genauen Zahlen. Am Anfang wird es immer Fehler geben, und das ist in Ordnung. Kommunikation ist viel wertvoller als supergenaue Zahlen.

Jedes Mal, wenn die Entwickler etwas Neues veröffentlichen, erfahren wir mehr Informationen und können besser navigieren.

Priorisierung allein reicht nicht aus. Um Geschichten schnell und oft zu veröffentlichen, müssen Sie in Stücke zerlegen, die in ein paar Tagen erledigt werden können. Wir wollen kleine und klare Geschichten am Anfang des Trichters und große und vage Geschichten am Ende. Indem wir diese Aufschlüsselung rechtzeitig vornehmen, können wir unsere neuesten Erkenntnisse in Bezug auf die Produkt- und Benutzeranforderungen nutzen. Dies alles wird als „Aufräumen des Backlogs“ bezeichnet.

Pat veranstaltet jeden Mittwoch von 11:00 bis 12:00 Uhr ein Backlog-Cleanup-Meeting, bei dem normalerweise das gesamte Team und manchmal ein paar Stakeholder zusammenkommen. Die Inhalte der Treffen sind unterschiedlich. Konzentrieren Sie sich auf Bewertung, Aufschlüsselung der Geschichten, Akzeptanzkriterien.

Der Besitzer eines IT-Produkts muss ständig mit allen kommunizieren

Balance zwischen Entwicklungskomplexität und User-Story-Wert

Risiken

Soziales Risiko: „Können wir tun, was getan werden muss?“

Technisches Risiko: "Wird das Projekt auf dieser Plattform funktionieren?"

Risiken bei Kosten und Zeitpunkt der Umsetzung: „Gelingen wir und wird es genug Geld geben?“

Wissen kann als das Gegenteil von Risiko angesehen werden. Wenn die Unsicherheit groß ist, konzentrieren wir uns auf den Wissenserwerb - Schnittstellenprototypen, technische Experimente,

Trade-off zwischen Werten des Wissens und Werten für den Kunden

Kompromiss zwischen kurzfristigem und langfristigem Denken

Die richtigen Dinge tun, die Dinge richtig tun oder die Dinge schnell tun?

Es gibt einen gesunden Gegensatz zwischen den Rollen in Scrum.

Unabhängig davon lohnt es sich, die Bedeutung der Geschwindigkeit zu betonen, da eine kurze Feedback-Schleife das Lernen beschleunigt. Dadurch können wir schnell lernen, was richtig ist und wie man es richtig baut.

Kompromiss zwischen der Entwicklung eines neuen Produkts und der Verbesserung eines alten

Zeitplan für die Zerstörung der Geschichte

Angenommen, ein Stakeholder fragt, wann diese Funktion erstellt wird?

Es ist in der Regel besser, den Inhalt eines Projekts zu reduzieren, als die Zeit zu verlängern. Wenn wir den Inhalt reduzieren, haben wir die Möglichkeit, die Fristen zu verschieben. Wir können einige hier veröffentlichen und den Rest später.

Der Product Owner führt wöchentlich Berechnungen durch und verwendet nur empirische Daten und kein Wunschdenken. Er spricht ehrlich über Unsicherheit. Das Team behält das Arbeitstempo bei und Pat setzt es nicht unter Druck und zwingt es, schneller zu arbeiten.

Es ist schwierig, eine Person zu finden, die nicht mit Respekt behandelt werden möchte. Aber es muss einen Grund für diesen Zustand geben. Zum Beispiel, wenn eine Person eine hochqualifizierte anerkannte Fachkraft auf dem Gebiet der Softwareentwicklung ist. Und dafür muss man studieren. Und im Rahmen dieses Artikels werden wir betrachten, was Agile ist, was es nutzt und wie man diese Technologie versteht.

allgemeine Informationen

Befassen wir uns zunächst mit den technischen Fragen. Was ist agil? Übersetzung (wörtlich) dieses Wortes aus auf Englisch- „Live, mobil“, „flexibel“ wird etwas seltener genannt. Übrigens ist es eine Abkürzung. Der vollständige Name dieses Ansatzes lautet Agil Software-Entwicklung. Da es aber zu lang ist, wurde entschieden, es zu kürzen. Und jetzt sagen sie nur noch agil. Die Übersetzung als "flexibel" wird verwendet, da sie der realen Situation am nächsten kommt.

Was ist hier enthalten?

Wir denken weiter darüber nach, was Agilität ist. Hier möchte ich darauf hinweisen, dass dies ein flexibler Ansatz ist, der auf vielen verschiedenen XP, "Kanban", Lean) basiert. Um das Thema besser zu verstehen, ziehen wir Parallelen. Nehmen wir an, dass agile Technologien der Prozess der Geburt des Universums sind. Das Endprodukt ist die eigentliche Welt selbst. Und der Urknall ist das schmerzhafteste Problem, dem Sie sich stellen müssen – die Änderung der Liste der Produktanforderungen. Typischerweise beinhalten Erstellungsprozesse die Verwendung Wasserfall-Modell. In diesem Fall geht alles sequentiell und in Etappen. Diese Vorgehensweise lässt sich kurz ausdrücken: Ich sehe das Ziel – ich gehe darauf zu. Und wenn sich die Anforderungen an das Endergebnis ändern, dann muss man manchmal fast alles neu machen. Was diese Situation noch komplizierter macht, ist der Versuch, so zu tun, als sei alles in Ordnung und wir müssten vorankommen.

Und hier ist das Management, das dank seiner Flexibilität darauf ausgelegt ist, all dies zu bewältigen. Dieses Sammelsurium minimiert verschiedene Risiken durch die Verwendung von Prinzipiensammlungen. Sie alle spiegeln sich im Agilen Manifest wider, das 2001 veröffentlicht wurde. Kurz gesagt klingen sie so:

1. Die Hauptsache sind Menschen, nicht Dinge.
2. Arbeiten Sie mit, lesen Sie nicht den Vertrag.
3. Die Dokumentation sollte die Arbeit nicht beeinträchtigen.
4. Ändern Sie so schnell wie möglich.

Es mag zu vage und nicht genau erscheinen, aber lassen Sie uns ins Detail gehen.

Prozessgestaltung

Wenden wir uns in Anbetracht dessen, was Agile ist, einer der beliebtesten Methoden zu, die als „Scrum“ (Scrum) bekannt ist. Was bietet sie an? Um loszulegen, benötigen Sie:

1. Wählen Sie einen Product Owner aus. Diese Rolle ist für eine Person geeignet, die sieht, welches Ziel Sie erreichen müssen und was am Ende passieren wird.
2. Entscheiden Sie sich für ein Team. Dies erfordert eine Gruppe von drei bis zehn Personen, die über die erforderlichen Fähigkeiten verfügen, um Ergebnisse zu erzielen.
3. Wählen verantwortlicher Fachmann. Dies ist eine Person, die die Entwicklung des Projekts überwacht und dem Team hilft, Schwierigkeiten zu umgehen.
4. Gehen Sie mit Schwierigkeiten um. Alle bestehenden Produktanforderungen sollten an einer Stelle gesammelt und priorisiert werden. Hier sollte der Product Owner all seine Wünsche sammeln. Dann wertet das Team diese aus und versteht, ob es umsetzbar ist und wie viel Zeit dafür benötigt wird.
5. Sie sollten den gesamten Arbeitsumfang in Zeiträume von ein oder zwei Wochen unterteilen, in denen das Team bestimmte Aufgabenbereiche ausführen wird.
6. Sitzungen sollten täglich abgehalten werden, nicht länger als fünfzehn Minuten. Die Tagesordnung sollte diskutieren, was gestern getan wurde, was die Pläne für heute sind und die Hindernisse, die uns daran hindern, die Höhe zu erreichen.
7. Führen Sie am Ende der Woche (zwei) Bewertungen durch, in denen das Team über das spricht, was getan wurde. Gleichzeitig ist es notwendig, die Leistung von Teilen des Produkts nachzuweisen.
8. Nach jedem Zeitraum sollten Probleme besprochen und Lösungen gesucht werden. Außerdem müssen alle Entwicklungen sofort umgesetzt werden.

Woran erkennt man Agilität?

Die Managementmethodik weist unabhängig von der gewählten Richtung immer folgende Merkmale auf:

1. Risikominimierung. Das Das Hauptziel die jeder flexible Ansatz verfolgt.
2. Iterative Entwicklung. In diesem Fall ist die Arbeit in kleinen Zyklen impliziert.
3. Das Wichtigste sind die Menschen und die Kommunikation zwischen ihnen.

Stellen wir uns einen Fluss vor. Auf der einen Seite des Kunden. Das zweite ist das Team. In diesem Fall hat die agile Entwicklungsmethodik Vorteile für alle:

1. Der Kunde will ein Minimum Viable Product. Gleichzeitig können sich die Bedingungen während seiner Erstellung ändern.
2. Es ist nützlich für das Team, mit Kollegen und dem Kunden zu kommunizieren. So wird das Risiko missverstanden zu werden minimiert, die Prozesstransparenz erhöht, Probleme schnell gelöst und die Wahrscheinlichkeit einer Überraschung bei der Produkterstellung reduziert.

sozialer Faktor

Wenn sie darüber sprechen, was Agilität ist, sprechen sie normalerweise nur über positive Dinge. Tatsächlich verbessert sich die Kommunikation innerhalb des Teams. Alle Menschen konzentrieren sich auf eine Idee, machen untereinander keine Geheimnisse, gehen Verpflichtungen ein. Dadurch arbeitet das Team unter komfortablen Bedingungen und in einem schnellen Tempo. Mit diesem Ansatz können Sie das Chaos rationalisieren.

Seit seiner Gründung konnte es Anerkennung in den Technologiebranchen finden. Im Moment wird es häufig zum Entwerfen neuer Softwareprodukte verwendet. In der allgemeinen Unternehmenspraxis ist dieser Ansatz jedoch noch wenig bekannt. Daher sind diejenigen, die Agile noch nie zuvor getroffen haben, vorsichtig damit. Es sollte auch verstanden werden, dass es nur in Fällen verwendet werden sollte, in denen Menschen mit der Aufgabe geistiger Arbeit konfrontiert sind.

Kleines Beispiel

Werfen wir einen Blick darauf, wie diese Softwareentwicklungsmethoden funktionieren. Nehmen wir an, wir haben Peter, den Eigentümer des Produkts. Er kennt die technischen Details nicht, aber er hat eine Vision Gesamtbild. Er weiß, warum das Produkt gebraucht wird, welche Probleme es löst und wen es zufriedenstellt. Es gibt auch Interessenten. Sie können das Produkt verwenden, seine Erstellung unterstützen oder anderweitig an seiner Erstellung beteiligt sein. Sie können auch User Stories hinzufügen, die die Wünsche von Interessenten zum Ausdruck bringen. Zum Beispiel: Das System zum Buchen von Tickets für Linienbusse Moskau-St. Petersburg sollte eine Suche nach Flügen haben. Peter hilft Interessierten weiter. Es übernimmt die Kontrolle über die Implementierung von User-Story-Ideen. Es gibt auch ein Entwicklungsteam. Das sind die Leute, die das funktionierende System aufbauen werden.

Da agile Entwicklungsmethodik zum Einsatz kommt, werden User Stories nicht vor einem großen Release angesammelt, sondern sofort nach Fertigstellung und so oft wie möglich veröffentlicht. Die Anzahl der verarbeiteten Anfragen entspricht dem wöchentlichen Durchsatz des Teams. Um den Schwung nicht zu verlieren und sich im manuellen Testen zu verzetteln, sollte das Team an einer automatisierten Integration arbeiten. Was ist es? Für jeden Arbeitsmoment wird ein automatischer Test geschrieben. Wenn es zu viele Geschichten gibt, dann kann es zu Hektik, Motivationsverlust, Produktivitäts- und Qualitätsverlust kommen. Für solche Fälle steht die Methode "Wetter von gestern" zur Verfügung. Es liegt in der Tatsache, dass Sie dem Arbeitsaufwand strenge Grenzen setzen und sorgfältig auswählen müssen, was genau implementiert werden soll. Das bereits erwähnte „Kanban“ schlägt vor, ein Aufgabenlimit festzulegen.

Was tun mit der Warteschlange?

Okay, also entschied das Team, dass sie vier Geschichten pro Woche verarbeiten könnten. Aber wie navigiert man in allem, was ist? Nehmen wir an, Benutzer laden zehn Geschichten pro Woche hoch. Vier werden bearbeitet. Somit wird die Warteschlange ständig wachsen. In diesem Fall gibt es nur einen effektive Methode- das Wort "nein". Für den Product Owner ist dies extrem wichtig. „Ja“ zu sagen ist nicht schwer. Es ist viel schwieriger und wichtiger zu entscheiden, was man nicht tut. Darüber hinaus gilt es, dafür auch Verantwortung zu tragen. Daher muss entschieden werden, worauf jetzt geachtet und was verschoben werden soll. Um es richtig zu machen, muss der Product Owner den Wert und Umfang jeder Geschichte verstehen.

Wir treffen Entscheidungen

Einige der Geschichten sind äußerst notwendig. Andere sind einfach schöne Prämie. Manche Geschichten brauchen mehrere Stunden, um sich zu entwickeln. Andere werden Monate dauern, bis sie fertig sind. Viele ziehen oft eine Korrelation zwischen der Größe einer Geschichte und ihrem Wert. Aber das ist nicht immer richtig. Mehr ist nicht gleich besser. Die Komplexität und der Wert der anstehenden Aufgabe helfen Peter, die richtigen Prioritäten zu setzen. Wie lassen sich diese Eigenschaften quantifizieren? Auf keinen Fall. Das echtes Spiel in eine Vermutung. Und für eine größere Effektivität ist es notwendig, viele Menschen daran zu beteiligen. Dies ist das Entwicklungsteam, das über den Umfang der Arbeiten und Interessenten informiert. Es versteht sich jedoch, dass alle auf diese Weise erhaltenen Daten ungefähre Schätzungen sind. Genaue Zahlen gibt es hier nicht. Zunächst wird es Misserfolge geben. Aber mit zunehmender Erfahrung nehmen ihre Anzahl und ihr Umfang ab.

Mögliche Risiken

Um Probleme zu vermeiden, ist es notwendig, auf eine Reihe von Fragen ehrliche Antworten zu geben. Das:

1. Tun wir die richtigen Dinge? Dies ist ein Geschäftsrisiko.
2. Können wir umsetzen, was wir brauchen?
3. Wird das Projekt auf dieser Plattform funktionieren. Dies ist ein technisches Risiko.
4. Reicht das Geld und haben wir Zeit? Dies sind Risiken hinsichtlich Umsetzungsbedingungen und Kosten.

In diesem Fall ist Wissen erforderlich. Sie können als Gegensätze von Risiken gesehen werden. Wenn ein erhebliches Maß an Unsicherheit feststeht, erwerben wir Wissen - zum Beispiel erstellen wir Schnittstellenprototypen oder technische Experimente. Und da wir sie bereits besitzen, treffen wir Entscheidungen über die Richtung, in die wir uns bewegen sollten.

Wie lernt man?

Die IT-Branche entwickelt sich extrem schnell, und um am Ende nicht zu verlieren, ist es notwendig, ständig zu lernen, Fähigkeiten und Arbeitseffizienz zu verbessern. Daher sind die Themen Training und Umsetzung aktueller denn je. Wo anfangen? Die meisten die beste Weise- dies ist eine Zusammenarbeit mit einem Unternehmen, in dem Agile bereits angewendet wird. Das Training wird in diesem Fall von Leuten durchgeführt, die nicht vom Hörensagen wissen, was agile Entwicklung ist. Aber das ist leider nicht immer möglich. Meistens ist ein externer Spezialist beteiligt, der weiß, was Agile ist. Die Umsetzung dieses Ansatzes erfolgt unter seiner Aufsicht. Die Dienste eines solchen Spezialisten kosten zwar Geld. Aber wenn Sie wirklich bekommen wissender Mensch, dann lohnen sich alle Ausgaben fürstlich. Tatsächlich spielt in der modernen Welt die Effizienz der Mitarbeiter eine wichtige Rolle.

Was steht für die Zukunft an?

Methoden der Softwareentwicklung entwickeln sich ständig weiter. Suche nach neuen Wegen und Möglichkeiten, um die Effizienz von Aktivitäten und Arbeit zu verbessern. Es ist ziemlich problematisch zu sagen, was die Zukunft für uns bereithält. Wahrscheinlich wird das flexible Entwicklungssystem mit Automatisierungstools integriert Herstellungsprozesse. So können beispielsweise Probleme auch weit entfernt vom Firmenstandort gelöst werden. Die Zukunft wird in vielerlei Hinsicht durch Neues bestimmt Informationstechnologie. Denn wenn sie entstehen, müssen Sie neue Methoden der Arbeit mit ihnen beherrschen. Und in diesem Fall gibt es eine in einem Kreislauf geschlossene Entwicklung.

Abschließend

Damit endete der Ausflug in die flexiblen.Aber es sei daran erinnert, dass Theorie eine Sache ist und Praxis eine ganz andere. Ständig neu entstehende Informationstechnologien fordern die große Entwicklergemeinde heraus. Wie können Sie Ihr Team effizienter machen? Die Antwort auf diese Frage findet jeder selbst. Die hier präsentierten Informationen können verwendet werden, um das Rückgrat zu bilden. In der Praxis müssen Sie jedoch mit dem bestehenden Modell arbeiten und den Stand der Dinge auf einen Stand bringen, der den bestehenden Herausforderungen entspricht. Dann wird das Team in der Lage sein, seine Ziele effektiv zu erfüllen.

Im modernen Management wird das „agile“ Managementmodell in drei verschiedenen Kontexten betrachtet, die (jeder auf seine Weise) definieren, was Agilität ist.

Drei Bände Agile Bedeutung

Im ersten, engeren Sinne wird dieser Begriff seit den frühen 2000er Jahren im Bereich der Softwareentwicklung verwendet, als sich Branchenexperten im US-Bundesstaat Utah in einem Bergresort versammelten, um die Methoden und Praktiken zur Erstellung von Softwareprodukten zu diskutieren sind gefragt. Endbenutzer. Das Ergebnis dieses Treffens war das Agile Manifest für die Softwareentwicklung mit 12 Prinzipien, die sich zunächst auf das enge Tätigkeitsfeld der Autoren bezogen, aber potenziell auf einige andere Geschäftsprojekte ausgedehnt werden könnten.

In der zweiten, weiter gefassten Bedeutung des Begriffs werden die Prinzipien von Agile auf die Führung nahezu aller Unternehmen angewendet und als Bausteine ​​beispielsweise im Konzept des „Lean Startup“ (Lean Startup) verwendet. In diesem Sinne wird das Agile Modell als eine flexible Projektentwicklungsmethodik verstanden, die einem charakteristischen Muster in mehreren Schritten folgt.

1. Die Projektarbeit erfolgt in Iterationen – kurzen Zyklen (Sprints). (Im Falle der Softwareentwicklung reichen diese Zyklen von 1 Woche bis 1 Monat).
2. Am Ende jedes Zyklus wird ein Produkt veröffentlicht, das bereits im Unternehmen eingesetzt werden kann. Bei Software kann eine Anwendung oder nur ein Teil davon zu einem solchen Produkt werden, aber auch „rohe“ Software kann und soll in der Praxis ausprobiert werden.
3. Das Produkt wird vom Kunden oder von Benutzern getestet, die eine ständige Beziehung zu den Entwicklern pflegen. Rückmeldung. Während des gesamten Projekts (alle Iterationen) wird ein kundenorientierter Ansatz angewendet.
4. Alle Kommentare werden schnell in die Überarbeitung aufgenommen, und Änderungen, die es Ihnen ermöglichen, die Entwicklung des Produkts auf dem Weg dorthin sofort zu korrigieren, sind willkommen, da Sie dadurch keine globalen Systemfehler akkumulieren können.

In einem dritten, noch umfassenderen Sinne ist Agile Teil des Managementmodells, das in Toyota-Fabriken verwendet wird, und ist heute eine der grundlegenden Komponenten des Managements fast jeder erfolgreichen Produktion. Die Grundlagen von Agile in diesem Kontext sind ähnlich wie die Grundlagen des Technologieverständnisses in anderen Kontexten.

Schnelles Feedback bei der Einrichtung des endgültigen Produktionsformats in Toyota-Werken wurde von jedem Arbeiter gegeben, der einen Stopp des Förderbands einleiten und Anpassungen für die Neukonfiguration vornehmen konnte Produktionszyklus. Auf produktionsweiter Ebene kann die agile Transformation eine Umrüstung der gesamten Produktionstätigkeit nach sich ziehen, wenn das Produkt das Ergebnis einer Live-Antwort auf die aktuellen Bedürfnisse des Kunden ist. Wenn also ein werksseitig produziertes Kunststoffbecken und Kundenfeedback den Bedarf an Eimern demonstriert, dann ist eine schnelle Anpassung mit paralleler Anpassung von Nuancen (Griffform, -größe, -farbe) gerade im agilen Managementstil (wenn andere Prinzipien befolgt werden).

Prinzipien des agilen Managements

Agilität im Projektmanagement als Geschäftsprozessmanagementmodell wird von Tausenden von Teams auf der ganzen Welt verwendet, und die folgenden sind überall präsent: Unterscheidungsmerkmale dieser Ansatz:

1. Entscheidend für die Produktindividualisierung ist der Konsument und der Grad seiner Beteiligung an der Entstehung des Ergebnisses.
2. Teams müssen hocheffektiv und kohärent sein, um Entscheidungen treffen zu können.
3. Stufenweise und zyklische Arbeit wird zur Grundlage des Prozesses. Das Projekt wird in kleine Teile gegliedert, die bis zu einem bestimmten Termin vor Abschluss des Gesamtprojekts fertiggestellt werden.
4. Der Fokus der Leistungsbewertung liegt darauf, häufig Projektzwischenstände darzustellen.
5. Bei ihrer Arbeit stützt sich das Team auf das Pareto-Gesetz, wonach 20 % der Bemühungen 80 % der Effizienz ergeben, was es erlaubt, nicht jeden einzelnen Zyklus zur Perfektion zu bringen, bevor das Ergebnis dem Verbraucher präsentiert wird. Das Produkt verbessert sich natürlich mit jeder neuen Iteration.
6. Es wird davon ausgegangen, dass eine Phase abgeschlossen sein muss, bevor mit der nächsten fortgefahren werden kann.

Der "flexible" Ansatz ist zur Grundlage für eine Reihe von methodischen Praktiken geworden, die sich voneinander unterscheiden, aber die Ideen von Agile beinhalten: Scrum, Kanban, Lean, Crystal usw. Die Scrum-Methodik wird beispielsweise fast immer berücksichtigt Verbindung mit Agile als einzelnes Projektmanagementsystem für die Softwareentwicklung.

Die Scrum-Methode zeigt, wie „agil“ im konkreten Betrieb umgesetzt werden kann. So wird beispielsweise die Arbeit mit Projektanforderungen über vier „Artefakte“ umgesetzt:

• Das Product Backlog beinhaltet die Bildung einer Anforderungsliste, die nach einer einzigen Vorlage (User Story) erstellt und nach Prioritäten sortiert wird. Wenn keine Anforderungen vorliegen, endet das Projekt.
• Sprint Backlog sind die Anforderungen des nächsten Sprints (Stufe), unterteilt in Aufgaben ohne die Möglichkeit, während des Sprints neue Anforderungen hinzuzufügen. Zusagen für die nächste Stufe, die vom Team mit der Führungsart Agile getroffen werden, werden auf dem Board festgehalten (sog. Kanban).
• Sprint Goal – das übergeordnete Ziel des Sprints – eine Richtlinie für alternative Entscheidungen.
• Sprint-Burndown-Diagramm - "Burndown-Diagramm". Es zeigt, wie weit das Team während der Etappe fortgeschritten ist.

Das agile Projektmanagement-Format ist nicht für jeden und nicht immer geeignet. Staatliche Strukturen, deren Tätigkeit auf einer unveränderlichen Gesetzgebung basiert und die in ihren Zielen und ihrer Umsetzung konservativ sind, bedürfen einer solchen Optimierung nicht.

Häufige Fehler bei der agilen Implementierung und Nachteile des Ansatzes

Derselbe Faktor, der in einigen Fällen berücksichtigt wird starker Punkt Ansatz kann bei anderen zu Problemen führen. "Flexibilität" verursacht also oft eine Unschärfe des Fokus. In Ermangelung einer methodischen Grundlage kommt es zum Verlust von Bezugspunkten und zur Substitution des Primären durch das Sekundäre. Um solchen „Verzerrungen“ vorzubeugen, verwenden sie vorgefertigte Methoden oder eigene Entwicklungen, die Inhalt und Ablauf der Arbeiten während der Projektdurchführung strenger regeln. Allerdings kann hier auch das Agile-Management Fehler machen.

Häufige Implementierungsfehler sind:

Bei allen Schwierigkeiten bei der Umsetzung eines agilen Vorgehens im Allgemeinen ist es effektiver als traditionelle „träge“ Branchen, wenn es darum geht, schnell ein neues kundenorientiertes Produkt zu schaffen. Während die traditionelle Produktion in Bürokratie versinkt, sorgt der agile Ansatz für einen natürlichen Fluss unmittelbar nach dem Start des Projekts.

Für den Anfang. Scrum und Agile – was ist der Unterschied? Kurz gesagt, Agile ist eine Philosophie, eine Familie flexibler Ansätze für die Softwareentwicklung. Scrum ist ein solcher Ansatz. Er hat einen Bruder – Kanban. Es ist auch der Ansatz, der in Agile verwendet wird.

Elena Truskova sagt:

Diese Woche habe ich an einem zweitägigen Agile/Scrum-Training (ausgesprochen „agile“ und „scrum“) teilgenommen. Es wurde viel abstruse und nicht so abstruse Literatur über flexible Softwareentwicklungsmethoden geschrieben, ich habe viel gelesen. Aber erst nach zwei Tagen Eintauchen in das Thema hatte ich endlich ein grundlegendes Verständnis für das Thema, aus dem ich diese Notiz schreibe.

Agile und Scrum helfen, den Prozess der Teamarbeit so zu organisieren, dass regelmäßig und häufig ein für den Benutzer interessantes Produkt veröffentlicht wird.

In manchen Banken verkürzte sich dank Agile der Weg einer Idee zum Anwender von zwei Jahren auf sechs Monate – in anderen Unternehmen wurde ein sechsmonatiger Entwicklungszyklus auf drei komprimiert. In unserer hektischen Zeit stimmt das Wettbewerbsvorteil besonders für kleine Spieler.

Scrum-Prinzipien lassen sich auf absolut alles anwenden: zum Beispiel, um an einem kreativen Produkt zu arbeiten. Das ist natürlich nicht „kanonisch agil“, Scrum-Evangelisten knirschen mit den Zähnen, aber Ihre Prozesse bewegen sich fröhlicher. Dame oder gehen?

Einiges von Agile und Scrum kann sogar in die Einzelarbeit übernommen werden. Sorgen Sie für die regelmäßige Veröffentlichung von Beiträgen, messen Sie die Belastung des Ausführenden, bewerten Sie zukünftige Aufgaben zeitlich und vergessen Sie nicht, die Qualität der geleisteten Arbeit zu analysieren - schauen Sie, es wurde bereits an alles für uns gedacht. Es bleibt zu implementieren.

Agil

(Englisch agil – „agil, schlau, schlagfertig“)

Flexibilitätskonzept:

Ersetzen Sie das Wort "Entwicklung" durch Ihre Art der Tätigkeit - und diese Prinzipien werden nah und verständlich.

„Ein funktionierendes Produkt ist der Hauptindikator für Fortschritt“, „Einfachheit als Kunst, unnötige Arbeit zu minimieren“ und „Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“ – klingt das vernünftig?

Gedränge

(engl. scrum – zerquetschen im Kampf um den Ball im Rugby)

An dieser Stelle sei daran erinnert, dass dies meine persönliche und subjektive Sicht auf Scrum ist. Hier reflektiere ich die Anwendbarkeit von Scrum-Elementen sowohl in kreativen Projekten fernab der IT, als auch in individuelle Arbeit(z. B. über einem Blog). Viele genaue Einzelheiten dazu werden weggelassen werden müssen; Ich versuche, den Text einfach zu halten und den Leser nicht mit Terminologie zu überfüttern.

Die Starrheit von Scrum liegt in der Struktur. Es gibt eine Reihe von Ansätzen, die zusammen besser funktionieren als einzeln. Ziehen Sie etwas heraus und verwenden Sie es für Sie, ich hoffe, niemand verbietet es.

Scrum findet in der Regel dort statt, wo es ein bestimmtes Produkt gibt, das für Anwender und Kunden einen Mehrwert hat, und man auf dem Weg zum Ziel schnellstmöglich verstehen muss, ob wir in die richtige Richtung laufen oder den Kurs korrigieren müssen. Das Scrum-Format ermöglicht es Ihnen, häufiger die nächste Version zu veröffentlichen, regelmäßiges Feedback zu erhalten und das Produkt schnell zu verfeinern sowie den Arbeitsprozess zu verbessern.

Wenn Sie im Team arbeiten, fordert Scrum von allen Prozessbeteiligten das Streben nach Austauschbarkeit, die Fähigkeit, eine hängende Aufgabe „aufzuheben“, wenn ein Nachbar krank ist, den Austausch von Fähigkeiten und die gemeinsame Verantwortung für das Produkt. In Scrum gibt es wenig Individualismus. Entscheidungen werden gemeinsam (nach strengen Grundsätzen) getroffen, niemand kann sie unter Druck setzen und zwingen, eine andere Lösung zu wählen, wenn das Team sicher ist, dass sie sich für die richtige entschieden haben.

Ein solches Vertrauen in Scrum zu haben, ist nicht beängstigend, da jeder Marsch genau einen Sprint dauert (ein klarer Zeitraum, normalerweise zwischen einer und vier Wochen). Nach dem Sprint kommt ein Moment der Analyse: Wie haben wir ihn überstanden? Was könnte beim nächsten Mal noch besser gemacht werden?

Selbst wenn wir alle selbstbewusst in die falsche Richtung gelaufen sind, haben wir daher am Ende des Sprints die Möglichkeit, dies zu korrigieren und das zu beheben, was uns in die falsche Richtung führt. Das Team in Scrum organisiert und optimiert sich selbst.

Team im Scrum

Die Standardgröße eines Scrum-Teams beträgt 7 plus oder minus 2 Personen. Das ist fünf vor neun. Es gibt Scrum-Skalierung: Sie können ein System der Arbeit an einer gigantischen Aufgabe aus 25 Teams aufbauen. Aber die Grundeinheit von Scrum ist das Team.

Jedes Team hat:

• Teilnehmer (im Fall von IT - Entwicklern, wer sind diese sieben Personen, die Sie haben - entscheiden Sie selbst)
• Produkteigentümer (Product Owner, Product Owner). Seine Rolle: den Markt und den Anwender verstehen, Aufgaben in der Sprache der Wirtschaft und der Anwender formulieren, das Bewusstsein dafür im Auge behalten, in welche Richtung sich Wert und Nutzen entwickeln sollen, Aufgaben für die Produktentwicklung erfinden und auswählen. So etwas wie ein Produkt- (nicht ein Team-) Leiter.
• Scrum Master (Scrum Master, Scrum Evangelist). Seine Rolle: Den Prozess verfolgen, das Innenleben des Teams beobachten, Menschen motivieren, Hindernisse aus dem Weg räumen. Quasi wie ein Trainer.
  Um das Team herum gibt es Benutzer und Stakeholder (Stakeholder, Kunden). Der Product Owner wendet sich an diese Personen, um sich beraten zu lassen.

Gerätesprint

Scrum-Arbeit besteht aus Sprints. Alle Sprints sind gleich aufgebaut. Es wird davon ausgegangen, dass das Team mit jedem nächsten Sprint kooperativer und effizienter wird. In Scrum lernt man aus seinen Fehlern, aber schnell – bei jedem Sprint analysiert man, was man genau gemacht hat und wie man es beheben will.

Der Product Owner hat eine Liste mit Geschäftsideen, um die Benutzer bei Laune zu halten. Es heißt „Product Backlog“ (eine Liste von Produktideen). Darin werden Ideen nach Wichtigkeit und Bedeutung sortiert.

Jeder Sprint hat ein Sprint Backlog (Sprint Backlog, Aufgabenliste für einen Sprint) – eine sortierte Liste von Ideen, die das Team für den nächsten Sprint beschlossen hat. Die Bedeutung von Scrum ist, dass das Team selbst die Komplexität jeder Aufgabe bewertet und entscheidet, welche Aufgaben in den nächsten Sprint aufgenommen werden.

Die Aufgabe im Sprint hat ein dem Team bekanntes Gewicht (es ist bekannt, wie lange es dauern wird), ein Performer hängt daran, es ist verständlich und wichtig. Wenn Sie nicht wissen, wie lange eine Aufgabe dauern wird, müssen Sie sie in kleinere Teile aufteilen.

Am Anfang ihres Lebens plant das Team immer schlecht. Dies ist eine objektive Realität. Aber sie führt Statistiken darüber, was sie in einem Sprint schafft, und plant im Laufe der Zeit genauer. Dabei hilft ihr das letzte Meeting des Sprints – eine Retrospektive. Dort können Sie die Schwachpunkte des ausgehenden Sprints besprechen und Wege finden, es anders zu machen.

In der Regel passen 5 plus oder minus 2 Ideen in einen Sprint. Wenn die Ideen zu groß sind, teilt das Team sie auf, sodass in jedem Sprint etwas Kleines zu zeigen ist.

Ideen werden in Scrum als User Stories (User Stories, Geschichten über Benutzer) bezeichnet und wie folgt formuliert: „Ich mag (Rolle?) möchte (was?), um (warum?)“. So sieht das Team nicht nur die Funktionalität, sondern auch die Bedeutung seiner Erstellung und zwar für eine bestimmte Rolle: Benutzer, Kunde, Käufer.

Das Ergebnis eines Sprints ist immer etwas zu zeigen. Zeigt die Arbeit des Teams an der Demo am Ende des Sprints.

Der Scrum-Prozess ähnelt meiner Meinung nach der Arbeit an einem Team-Blog. Ein solcher Prozess würde helfen, die Regelmäßigkeit zu wahren, die Expertise der Autoren zusammenzubringen und nicht so viel zu rekrutieren, dass Sie es nicht können.

Sprint-Struktur

Der Sprint beginnt mit der Planung: Das Team setzt sich zusammen und bespricht: Wir nehmen diese Idee, wir nehmen jene nicht. In der IT kann sich dieser Prozess einige Stunden hinziehen, weil die Diskussion bis ins Detail geht. Im Falle der Arbeit mit einem Blog kann dies zu einer Diskussion von Themen und einem Plan von Artikeln führen, die dann zum Hinsetzen und Schreiben übrig bleiben – um zu verstehen, was wir schreiben, wann und warum.

Jeden Tag gibt es ein Stehmeeting (Stand Up Meeting, Stehmeeting) für 15 Minuten. Wichtig ist, das im Stehen zu tun: Wenn jemand spricht, treten die anderen beredt von einem Fuß auf den anderen und kratzen sich am Ohr. Sie können einen Gegenstand verwenden, sodass jeweils nur ein Teilnehmer spricht, und ihn im Kreis herumgeben.

Jeder Stand-up-Teilnehmer beantwortet abwechselnd drei Fragen:

• Was ich gestern gemacht habe
• was werde ich heute tun
• was mich bremst

Alle Detailgespräche, die damit verbunden sind, sprengen die Grenzen des Stand-up. Stand-up ist ein Punkt, an dem Sie Probleme erkennen oder herausfinden können, dass ein Kollege und ich aus irgendeinem Grund zur gleichen Zeit dasselbe tun, was bedeutet, dass einer von uns etwas anderes tun kann.

Generell sollte die Einhaltung all dieser klaren Verhaltensregeln dem Scrum Master obliegen. Das sind in der Regel Technologie-Ideologen, die daran glauben und bereit sind, einen Prozess zur maximalen Effizienz der gemeinsam verbrachten Zeit aufzubauen. Ohne einen Scrum Master verkommen Prozesse auf das Möglichste, weil man faul und sparsam ist.

Am Ende des Sprints gibt es eine Demo (Demo, Demonstration), die zeigt, was wir während des Sprints erstellt haben, ein Sprint-Review (Sprint-Review, Sprint-Review) mit einer Überarbeitung des Produkt-Backlogs und einem Gespräch darüber, WAS wir tun, sowie eine Retrospektive (retro) – was wir den ganzen Sprint nicht optimal gemacht haben und weiter verbessern wollen – darüber, WIE wir es machen.

„Wenn ich acht Stunden Zeit hätte, um einen Baum zu fällen, würde ich sechs Stunden damit verbringen, eine Axt zu schärfen.“ (Holzfäller und Präsident Abraham Lincoln zugeschrieben)