Agile Analyse. Mythen und Wirklichkeit

I Einführung

Der Stand muss bewegt werden! Es gibt keine Jahreszeit, so dass ein paar Leute nicht shandarah.
Jetzt verwechselt mit der Toilette, dann mit einer Strandhütte ...
(x / f Merkmale der nationalen Fischerei)

Ende des Jahres, Zusammenfassung, Ausfüllen von Fragebögen und anderen Vor-Urlaubs-Lametta von IT-Funktionären. Zum x-ten Mal fällt mir der Blick auf die endgültigen Fragebögen von IT-Unternehmen, mit denen Trends bei den Ansätzen zur Produktentwicklung ermittelt werden sollen. Und jedes Mal, wenn Sie Fragen beantworten wie: „Sie verwenden immer noch die Wasserfallmethode (Wasserfallmodell) oder Sie praktizieren immer noch (wie alle fortgeschrittenen Menschen) Agile (flexible Methoden).“ Wenn Sie vom Autor dieser Umfrage herausfinden, was er unter Agile versteht, passen seine Erklärungen irgendwie nicht sehr gut in die Umrisse des Manifests (Agile Manifesto). Er denkt zum ersten Mal wirklich über viele Prinzipien nach und genau diese Prinzipien bringen ihn direkt zum Stillstand. Aber nach ein wenig Verwirrung wird schwere Artillerie mit Stahlbeton verwendet, um unsere Position zu untermauern: "Wir arbeiten nicht am Wasserfall, also agil."

Die These der flexiblen Methodik selbst klingt so guttapercha, dass viele versuchen, irgendetwas hineinzudrücken, oder besser gesagt, was für sie am vorteilhaftesten ist. Allmählich wurde es zu einem modischen Bildschirm, der alle Arten von Fehlern und sogar Schlampereien bei der Herstellung von IT-Produkten abdecken kann und gleichzeitig, als ob er auf dem Wellenkamm bleiben möchte, in einem Trend. Als wären wir nicht so - aber so eine Technik.

Lassen Sie uns gemeinsam noch einmal versuchen, die wichtigsten Artefakte und Prinzipien in den Regalen zu sortieren und die heilige Bedeutung, die ursprünglich in diesem Konzept festgelegt war, von der zu trennen, in die einzelne fahrlässige Populisten sie verwandeln. Wir vergleichen auch die Ansätze von Agile mit anderen Methoden, um die Linie, die sie trennt, genauer zu verstehen oder umgekehrt - kombiniert sie. Versuchen wir gleichzeitig herauszufinden, wo die Verwendung agiler Prinzipien am besten geeignet ist und wo sie nicht ganz angemessen ist.

II Hintergrund für die Entstehung von Softwareproduktentwicklungstechniken

Die Geschichte ist wie eine Fleischpaste: Es ist besser, nicht zu sehen, wie sie gekocht wird.
Aldous Huxley

Lassen Sie uns aus Gründen der Objektivität in die Geschichte eintauchen und die Umstände spüren, auf denen verschiedene Prinzipien und Methoden für die Entwicklung von Softwareprodukten, einschließlich flexibler Produkte, gereift sind.

1. Mythen und Realität über Wasserfall

Wie bereits in der Einleitung erwähnt, wurde der Antagonismus (Opfergabe) für Agile (1) als Wasserfalltechnik gewählt, die in ihrer reinen Form im letzten Jahrhundert zur Zeit von Lochkarten und Bandlaufwerken relevant war und erstmals in einem Artikel von W.W. Royce ( WW Royce), veröffentlicht 1970.

Ein solcher Vergleich hilft zweifellos jeder anderen Methode, im Vergleich dazu frisch und innovativ auszusehen. Einige Redner präsentieren das Wasserfallmodell aus Gründen der Überzeugung nicht als iterativen, sondern als einmaligen, monolithischen Arbeitsstrom einer aufeinanderfolgenden Phase: Analyse der Anforderungen, Design, Implementierung, Test, Integration und Support. Besonders berührt hat mich der Satz über Entwicklungsmethoden, der in dem Artikel bis zur Ajail-Zeit beobachtet wurde: „Früher wurden Produkte sofort als Ganzes hergestellt. Dazu haben wir uns an die Kette gehalten: Idee → Leistungsbeschreibung → Design → Programmierung → Testen → Release. “ Entschuldigen Sie, aber Royce verwendete in seinem Ansatz ein iteratives Entwicklungsmodell. Die Idee auf zynische Weise zu vereinfachen ist einfach nicht mehr ethisch, insbesondere wenn man bedenkt, dass zwischen Wasserfall und Agile kein Vakuum bestand, sondern eine ziemlich lange Evolutionskette.

Obwohl fairerweise muss ich zugeben, dass das meiste, was über Wasserfall gesagt wurde, im Allgemeinen nicht weit von der Wahrheit entfernt ist. Wenn das Team irgendwann feststellte, dass das Ergebnis nicht den Erwartungen entsprach, „beendete“ es entweder das Produkt, das nicht ganz richtig war, oder warf den größten Teil der Arbeit in den Warenkorb und startete den Prozess fast von Anfang an, um tatsächlich ein neues Produkt zu erstellen. Warum ist die Technik trotz einiger Absurdität eines solchen Ansatzes nach heutigen Maßstäben lange Zeit ein beliebtes Flaggschiff in der Welt der Softwareentwicklung geblieben?

Um dieses Phänomen zu verstehen, werden wir in die Atmosphäre der damaligen Rechenzentren (CC) eintauchen. Ich möchte Sie daran erinnern, dass in diesen fernen, fernen Zeiten der Weg vom Design der Entwickler bis zur Ausführung seines Computers lang und dornig war. Er durchlief die bereits vergessenen Datenaufbereitungsgeräte, die Lochkarten mechanisch stanzen und liebevoll „Barmales“ genannt werden. Diese Operation wurde nicht von den Entwicklern selbst durchgeführt, sondern von speziell geschulten Personen. Nachdem diese Lochkarten unter Berücksichtigung der Funktionsfähigkeit des Computers die geschätzte Packung mit perforierten Pappkartons in der Reihenfolge ihrer Priorität erhalten hatten, wurden sie in ein spezielles Gerät (wiederum speziell geschulte Personen) gelegt, das den Code las, und erst danach hatte er die Möglichkeit, vom Prozessor ausgeführt zu werden. Wenn sich jedoch eine der Lochkarten im Deck beim Lesen verklemmt hat, sollten Sie den Vorgang zum erneuten Lesen des gesamten Decks wiederholen. Und Gott bewahre, ein Fehler wurde im Code manifestiert. Es war notwendig, erneut auf die Hilfe von „Barmaley“ zurückzugreifen, einen Teil der Lochkarten zu unterbrechen und, ohne sie mit Stellen im Deck zu verwechseln, den gesamten Vorgang von Anfang an noch einmal zu wiederholen. Mit solchen Reizen war die Arbeit der damaligen Programmierer die ganze Zeit über gepunktet. Natürlich kamen schnelle Änderungen der Anforderungen an das entwickelte Produkt im Laufe seiner Implementierung mit einem solchen Ansatz nicht in Frage. Hohe Qualitätsanforderungen an das zu entwickelnde Produkt und der streng regulierte Produktionsprozess waren für alle damaligen Teams.

2. Was ist, wenn nicht Wasserfall?

Aber die Zeit verging und alles änderte sich. Personal Computer wurden allmählich zur Kapsel für die digitale Welt und verdrängten riesige rasselnde Monster im Hinterhof. Die Anzahl der von Prozessoren pro Zeiteinheit ausgeführten Operationen hat sich um mehrere Größenordnungen erhöht, und die Geschwindigkeit der Eingabe- / Ausgabeoperation von Informationen schien einfach „kosmisch“ zu sein. Programmierer erhielten direkten und sofortigen Zugriff auf die Ausführung des Codes, der gerade über die Tastatur eingegeben wurde - Computerressourcen, ohne den Ort zu verlassen. Jetzt ist es viel einfacher geworden, Änderungen an der Software vorzunehmen, und es ist einfach lächerlich, sich vorzustellen, dass jemand anderes weiterhin in seiner reinen Form nach der Waterfall-Methode arbeitet.

Natürliche Selektion und Anpassungsbedarf zwangen die Techniken zur Mutation. Darüber hinaus haben die meisten von ihnen ein iteratives Entwicklungsmodell von ihren Vorgängern ausgeliehen. Die Ausführungszyklen wurden einfach erheblich reduziert und verbessert.

Aber dann kam ein anderes Unglück auf. Bisher unerreichte Möglichkeiten haben es von der Automatisierung einzelner Produktionsabschnitte bis zur Automatisierung ganzer Unternehmen und sogar zur vollständigen Übernahme der Branche ermöglicht. Mit solchen Betriebsvolumina und Ressourcenmengen war es nicht möglich, Softwareentwicklungsmethoden einfach zu vereinfachen. Im Gegenteil, sie sind noch umfassender und formalisierter geworden.

Eine der bekanntesten Techniken, die ein iteratives Entwicklungsmodell verwenden, ist Rational Unified Process (RUP). Es wurde in der zweiten Hälfte der neunziger Jahre bei Rational Software entwickelt und implementiert.

Der Begriff RUP verbirgt nicht nur eine Softwareentwicklungsmethode, sondern auch eine Reihe von Tools, mit denen Sie Entwicklungsprozesse verwalten können. Im Rahmen dieses Themas ist es besonders interessant festzustellen, dass die RUP-Methodik (2) einen abstrakten allgemeinen Prozess beschreibt, auf dessen Grundlage eine Organisation oder ein Projektteam ihren eigenen einzigartigen Softwareentwicklungsprozess erstellen kann, der auf ihre eigenen Bedürfnisse ausgerichtet ist. Wie sagen Sie, ist dieser Ansatz nicht flexibel?

Bei weiteren Analysen und Vergleichen kann festgestellt werden, dass einige der Hauptmerkmale von RUP teilweise auch von der Wasserfalltechnik übernommen wurden.

1. Zyklischer Ansatz zur Softwareproduktion . Der Lebenszyklus des RUP-Projekts ist in 4 Phasen und 9 Arbeitsprozesse unterteilt.
2. Iterativer Entwicklungsprozess . Das RUP-Projekt besteht aus einer Folge von Iterationen mit einer empfohlenen Dauer von 2 bis 6 Wochen.
3. Obligatorische Entwicklung der Anforderungen . RUP verwendet Anwendungsfälle oder Anwendungsfälle, um Anforderungen zu beschreiben. Jeder Anwendungsfall ist eine Beschreibung des Szenarios der Benutzerinteraktion mit dem System, das eine bestimmte Benutzeraufgabe vollständig ausführt.
4. Ein inkrementeller Ansatz, der darauf abzielt, die Produktfunktionalität schrittweise zu erhöhen. Die Haupteinheit der Iterationsplanung ist der Anwendungsfall, mit dem Sie die erforderlichen Änderungen an den Anforderungen, Entwurfsentscheidungen und der Implementierung während des Projekts vornehmen können.

Wir achten besonders auf den letzten Punkt. Es heißt, dass das Vorhandensein detaillierter Anforderungen, die in einer bestimmten Form erstellt wurden, lediglich die Möglichkeit bietet, Änderungen an Entwurfsentscheidungen und der Produktimplementierung während des Projekts effektiv vorzunehmen. Einschließlich in den späten Phasen des Projekts.

RUP wird oft fälschlicherweise als Schwergewichtsprozess mit einem hohen Maß an Formalismus angesehen. Dies ist jedoch nicht ganz richtig, da der RUP-Prozess an die Besonderheiten einer bestimmten Organisation und eines bestimmten Projekts angepasst werden kann (und sollte). Selbst wenn das Team ein kleines Softwareprodukt übernimmt, das weiterentwickelt, skaliert oder in andere Systeme integriert werden muss, kann RUP alle auftretenden Herausforderungen problemlos bewältigen.

3. Der Sturz der Fundamente

Und dann noch mehr. Nachdem wir die Zeit des Aufkommens von PCs in unserer Welt übersprungen haben, wenden wir uns dem Erscheinungsbild aller Arten von Werkzeugstudios, Visualisierungs- und Modellierungswerkzeugen, automatischen Anwendungserstellern usw. zu. Bei all diesen Hilfsprogrammen, mit denen Sie beispielsweise ein Element mit der Maus auf das Diagramm ziehen und dort ablegen und den Anwendungscode für das Endprodukt automatisch ändern können, wurde die Rolle der Softwareentwicklungstechniken abgewertet. Mit solch fortschrittlichen Tools, die Zeit oder Ressourcen fehlen, können Sie einige Workflows der Methodik aufgeben und gleichzeitig nichts verlieren. Zumindest kurzfristig. Diese Freiheiten und, wie sich herausstellte, die Straflosigkeit bei angemessener Professionalität der Darsteller führten die verzweifeltsten Köpfe zur Proklamation eines neuen IT-Trends - "Flexible Entwicklungsmethoden".

Hier an dieser Stelle aus der roten Linie betone ich noch einmal eine sehr wichtige These, vielleicht die Schlüsselthese - „mit gebührender Professionalität“! Das heißt, hochklassige Spezialisten, die Dutzende von groß angelegten abgeschlossenen Projekten hinter ihren Köpfen haben und in der Lage sind, das Klassendiagramm eines kleinen Moduls in ihren Köpfen in 20 Minuten zu skizzieren, schätzen sofort die Prozesse, die ihren Zustand ändern, kritische Abhängigkeiten vorschlagen usw. beschlossen, dass sie in einigen Fällen auf die obligatorische Verabschiedung der verabschiedeten Vorschriften verzichten können. Gleichzeitig wird das Projekt in deutlich kürzerer Zeit mit akzeptabler Qualität zum erwarteten Ergebnis gebracht. Ist es gut oder schlecht? Auf den ersten Blick ist es einfach wunderbar. Auf der zweiten Seite ist nicht alles so einfach. Wir werden die Vor- und Nachteile etwas später analysieren.

Auf jeden Fall schlecht hier ist eine andere. Jung und gewagt, von der Seite betrachtet, stellt sich die Frage: "Aber was, war das möglich?" Sie haben nie Qualitätsanforderungen in ihren Augen gesehen, sie können keine Diagramme lesen, aber jetzt brauchen sie sie nicht mehr. Das ist alles! Die Anforderungen sind jetzt storniert! Diagramme, Modellierungsprozess - dort im Ofen. Nur Code, Code und Kommunikation. Als Bonus können sie ihre Kommentare im Code für zukünftige Generationen derselben Frechheit hinterlassen.

Auf diesem kann die historische Exkursion abgeschlossen und sozusagen näher an den Körper herangeführt werden ...

III Analyse des Phänomens flexibler Methoden

Jede Entität sollte in Bezug auf die Logik analysiert werden, bevor sie in den Mund genommen wird.
Woody Allen.

1. Definitionen flexibler Methoden

Da es Adjayl seit vielen Jahren gibt, sollten wir die verfügbaren Informationen nutzen und zunächst die Definitionen und Meinungen überprüfen, die das Netzwerk übersteigen. Und nachdem wir uns bereits von ihnen verabschiedet haben, werden wir zum Hauptartefakt übergehen - dem Manifest der flexiblen Softwareentwicklung.

Das erste, was in einer Suchmaschine unter dem Begriff Agile gefunden wurde:

Die flexible Entwicklungsmethodik (Agile Softwareentwicklung, Agile Methoden) ist eine Reihe von Ansätzen für die Softwareentwicklung, die sich auf die Verwendung iterativer Entwicklung, die dynamische Bildung von Anforderungen und deren Sicherstellung aufgrund der ständigen Interaktion in selbstorganisierenden Arbeitsgruppen, die aus Spezialisten verschiedener Profile bestehen, konzentrieren.

Die folgenden wichtigen Punkte können von dieser Definition unterschieden werden:

1. Verwenden eines iterativen Ansatzes . Hier gibt es nichts Neues. Ich habe noch nichts über Softwareentwicklungsmethoden gehört, die dieses Prinzip leugnen.
2. Die Bedarfsbildung erfolgt schrittweise im Zuge der Produktentwicklung . Dies ist ein wesentlicher Unterschied zu vielen anderen Techniken. In gewisser Weise bietet es einen Vorteil, in gewisser Weise führt es grundlegende Einschränkungen ein. Wir werden später beide diskutieren;
3. Nutzung der ständigen engen Interaktion aller Teammitglieder , einschließlich des Kunden. Die meisten anderen Methoden achten natürlich auf Teamarbeit, auch mit Kunden, aber die Positionierung dieser Kommunikation als zusätzliche Projektressource, die einen absoluten Vorteil bietet, ist exklusiver.
4. Selbstorganisierendes Team . Es wird davon ausgegangen, dass jede Iteration mit einer Nachbesprechung und einer konstruktiven Änderung des Prozesses endet, was zur kontinuierlichen Entwicklung des Teams beiträgt. Ähnliche Techniken sind höchstwahrscheinlich aus früheren Techniken entlehnt. Zum Beispiel übt es RUP.

Im Prinzip haben wir nicht viel aus dieser Beschreibung herausgefunden. Kommen wir also zu den Erläuterungen:

Die meisten flexiblen Methoden zielen darauf ab, Risiken zu minimieren, indem die Entwicklung auf eine Reihe von kurzen Zyklen reduziert wird, die als Iterationen bezeichnet werden und normalerweise zwei bis drei Wochen dauern. Jede Iteration für sich sieht aus wie ein Softwareprojekt in Miniaturform und umfasst alle Aufgaben, die zur Minimierung der Funktionalität erforderlich sind: Planung, Anforderungsanalyse, Design, Programmierung, Test und Dokumentation.

Aber wir haben den gleichen Ansatz bereits in der guten alten RUP in Betracht gezogen. Das heißt, hier gibt es auch nichts grundlegend Neues.

Die meisten der Definitionen, die ich gefunden habe, sind auch abstrakt und vage. Es gibt nur sehr wenige Informationen, die es Ihnen ermöglichen, Flexibilität sofort zu nutzen. Hier eröffnet sich jedoch ein weiterer ebenso wichtiger Aspekt des Ansatzes, der Klarheit in die Oberflächlichkeit bringt, durch die sich das gesamte betrachtete Thema zieht. Hier ist ein Beispiel:

Agile beinhaltet keine Praktiken, sondern definiert die Werte und Prinzipien, die Teams leiten. Agile ist eine Familie von Entwicklungsprozessen, nicht der einzige Ansatz für die Softwareentwicklung, und wird vom Agile Manifest definiert.

Agilität ist eine Denkweise mit einem eigenen Wertesystem. Es ist ähnlich wie Philosophie, Religion oder Kultur - die gleichen Einstellungen, an die eine Person glaubt und die ihr Verhalten beeinflussen.

Anscheinend gibt es gerade aus diesem Grund unzählige Streitigkeiten um flexible Methoden. In der Vorstellung, was man wirklich fühlen kann, steckt nicht viel. Anscheinend können Sie aus diesem Grund etwas Eigenes (fast jedes) als unkonventionell bezeichnen - flexible Methoden, ohne in Unprofessionalität zu geraten. Meiner Meinung nach ist dies akzeptabel, wenn Sie im Trend sein möchten, nennen Sie Ihren Entwicklungsansatz so modisch wie möglich, wenn nur der Entwicklungsprozess und das Endprodukt selbst nicht darunter leiden würden.

Ich erinnere mich an einen Fall aus meiner Praxis, als ein großes IT-Unternehmen vor einem neuen Großprojekt beschloss, seine technologischen Prozesse zu verbessern. Hierzu wurde (gemäß Empfehlungen) ein Spezialist für flexible Methoden eingeladen, auf dessen Schultern diese verantwortliche Mission beauftragt wurde. Nachdem er einen sehr kurzen Vortrag über die Denkweise und das Wertesystem von Agil gelesen hatte, begann er herauszufinden, wie die Dinge bei der Produktion von Software im Unternehmen wirklich sind. Wir haben gemeinsam mit dem Unternehmensteam Fehler und Inkonsistenzen in vorhandenen Prozessen festgestellt und die am besten geeigneten Methoden und Methoden zu deren Lösung ausgewählt. Glücklicherweise waren diese Mängel für niemanden ein Geheimnis, und eine Reihe von Gründen verhinderten, dass sie überwunden wurden. Zum Beispiel: Zeitmangel, Widersprüche zwischen Teams, die verschiedenen Managementbereichen untergeordnet sind, Angst, Verantwortung zu übernehmen usw. Da diese gesamte Veranstaltung vom Top-Management des Unternehmens unterstützt wurde und der eingeladene Spezialist ein wirklich erstklassiger IT-Experte war, wurden die ausgearbeiteten Innovationen fast pünktlich und mit einem sehr sensiblen, positiven Effekt umgesetzt. Das ist nur das Manifest flexibler Methoden, mit denen sie nichts zu tun hatten. Infolgedessen waren die meisten Mitarbeiter des Unternehmens weiterhin zuversichtlich, dass sie jetzt vollständig zu Agile gewechselt sind und alles andere aufgegeben haben. Dies alles ähnelt sehr einem Märchen darüber, wie ein Soldat Brei aus einer Axt kochte, schlau die Zutaten herausholte, die er von den Besitzern benötigte, und den Geschmack des Gerichts verbesserte. Das ist nur die Axt ist nicht gekocht.

Da wir jedoch hier sind, um das Agile-Phänomen unvoreingenommen zu analysieren, werden wir unsere Studie fortsetzen. Fahren wir mit der ursprünglichen Quelle fort - dem Ajail-Manifest:

2. Lassen Sie uns die Hauptideen des Agilen Manifests analysieren

Schlüsselideen:

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

Beginnen wir mit einer Fliege in der Salbe. Für mich persönlich sind alle Punkte umstritten. Gehen wir in die richtige Reihenfolge:

Punkt 1 . Meiner Meinung nach war einer der Hauptgründe für das Erscheinen von Ajail, wie ich oben schrieb, die rasche Entwicklung von Automatisierungssystemen für Softwareentwicklungsprozesse, die es ermöglichten, die Vorschriften zu vernachlässigen. Das heißt, es ist nur die Verdrängung der monotonen menschlichen Arbeit durch Roboterprozesse, die es uns ermöglicht, zuverlässigere und vorhersehbarere Ergebnisse zu erzielen, einschließlich der Aufrechterhaltung einer qualitativ hochwertigen Interaktion der Prozesse selbst. In Bezug auf „Menschen - das Wichtigste“ ist dies meiner Meinung nach nur ein Slogan, der dazu beiträgt, die menschliche Eitelkeit der sentimentalsten Teammitglieder zu amüsieren.

Aber fairerweise stelle ich fest, dass diese Slogans, die im Nachhinein in die Hände klatschen und andere Gefühle gegenüber jungen Mitarbeitern zeigen, durchaus gültig sind und sogar (am Anfang) den Teamgeist steigern. Es ist wichtig, dass es keine Leere und Enttäuschung gibt, wenn das Verständnis des Urlaubs weg ist.

Punkt 2. Die Entwicklung ist nur ein kurzer Moment im Leben eines automatisierten Systems, und dann beginnt der harte Alltag seines Betriebs, seiner Modernisierung und der Erweiterung von Möglichkeiten. Haben Sie jemals versucht, ein gutes Softwareprodukt ohne Dokumentation zu warten? Was passiert darin und warum genau und vor allem, wie kann es korrigiert werden, damit es etwas anders funktioniert? Und wenn es mit anderer Software interagiert, was kann dann allgemein daran geändert werden und was kann nicht berührt werden? All dies ähnelt einem Spaziergang auf einem Minenfeld.

Und hier fügen wir das Prinzip der schrittweisen Entwicklung hinzu. Ohne Dokumentation, da noch festgestellt werden muss, in welchem ​​Entwicklungsstadium sich das Produkt im Allgemeinen befindet.

Aus Gründen der Objektivität sollte jedoch beachtet werden, dass es mit hoher Wahrscheinlichkeit erforderlich sein kann, den Code zu ändern oder zu ändern, wenn ein Team einem Kunden ein fertiges Produkt liefert, das aus einem Haufen von Modulen zusammengesetzt, auf einem Haufen verschiedener Geräte installiert und sogar unter einer "nicht untergeordneten" Last installiert ist. Manchmal können Änderungen zahlreich und tiefgreifend sein. Und hier liegt es definitiv nicht am Formalismus, es ist notwendig, das Gesicht des Teams zu retten. Während dieser Zeit können Sie die Dokumentation auf bessere Zeiten verschieben und den Code dringend bearbeiten. Ich möchte darauf hinweisen, dass es viel bequemer ist, dies zu tun, wenn eine anständige Dokumentation vorliegt, die in der Entwicklungsphase erstellt wurde und eine Beschreibung der Funktionsweise zum Zeitpunkt der Einführung enthält.

Punkt 3. Nun, für den Anfang versteht der Punkt nicht die Opposition. Aber ist die Vereinbarung der Vertragsbedingungen keine Zusammenarbeit mit dem Kunden? Wenn der Kunde infolge der Klärung der Vertragsbedingungen mit dem Entwicklungsteam in der Lage ist, den Arbeitsaufwand zu verstehen, die Kosten seiner Implementierung grob zu realisieren und sich vor allem das Ergebnis vorzustellen, das er in einigen wirklich greifbaren Indikatoren (automatisierte Geschäftsfunktionen, Layoutmodelle usw.) erzielen kann. .). Schließlich fällt es ihm leichter, eine Entscheidung zu treffen: ob er dieses bestimmte Produkt benötigt, ob er bereit ist, seine Produktion zu finanzieren usw. Ist das nicht eine Zusammenarbeit?

Aber was ist mit der Zusammenarbeit? Nur herzliche Gespräche fürs Leben ohne Verpflichtungen? Ob es Ihnen gefällt oder nicht, wenn das Projekt kommerziell ist, müssen in erster Linie alle Parteien ihre Ziele im Projekt erreichen. Und die Vertragsbedingungen - legen Sie genau diese Ziele und Wege fest, um sie zu erreichen. Zum Zeitpunkt der Ausarbeitung und Genehmigung des Vertrags beginnen beide Parteien zu erkennen, dass von ihnen erwartet wird, dass sie Partner und den Grad der Verantwortung erhalten, wenn das vereinbarte Ergebnis nicht erreicht wird. Der Vertrag ist in diesem Fall für beide ein Motivator und ein Mittel zur Beilegung von Meinungsverschiedenheiten. Am schrecklichsten sind schließlich nicht Extreme, sondern Unsicherheit.

Kein Vertrag - keine Verantwortung, kein vollständiges Verständnis dessen, was sich aus dem Abschluss des Projekts ergeben sollte. Dieser Ansatz passt zu Ihnen - viel Glück.

Punkt 4. Wir haben oben bereits gesagt, dass es für ein Team professioneller Entwickler keine besonderen Schwierigkeiten gibt, Änderungen an der Implementierung eines Produkts in nahezu jeder Phase vorzunehmen, wenn es moderne Tools zum Entwerfen und Entwickeln von Software gibt. Dies ist ein normaler Prozess, der in größerem Maße von der Tiefe des Verständnisses des Teams und des Produkts abhängt, das es entwickelt. In diesem Fall geht es daher nicht so sehr um die Bereitschaft des Teams, Änderungen vorzunehmen, sondern darum, wer für all diese Exzesse bezahlen wird. Hier tritt der qualitativ ausgearbeitete Vertrag in den Vordergrund, der bestimmt, wer und in welchen Fällen durch die Reformation materielle Verluste erleidet. Ob die Entwickler auf eigene Kosten das, was sie missverstanden haben, neu erstellen oder der Kunde, der nicht richtig erklärt hat, was er brauchte.

3. Diskutieren Sie die Prinzipien des Agilen Manifests

Da wir offen für das Thema sein wollen, lassen Sie uns zumindest kurz auf die Prinzipien eingehen, die das Agile Manifest erklärt:

• Kundenzufriedenheit durch frühzeitige und ununterbrochene Lieferung wertvoller Software;
• Änderungen der Anforderungen auch am Ende der Entwicklung begrüßen (dies kann die Wettbewerbsfähigkeit des resultierenden Produkts erhöhen);
• häufige Lieferung von Arbeitssoftware (jeden Monat oder jede Woche oder häufiger);
• enge, tägliche Kommunikation des Kunden mit den Entwicklern während des gesamten Projekts;
• Das Projekt wird von motivierten Personen durchgeführt, die über die erforderlichen Arbeitsbedingungen, Unterstützung und Vertrauen verfügen.
• Die empfohlene Methode zur Übermittlung von Informationen ist ein persönliches Gespräch (von Angesicht zu Angesicht).
• Das Ausführen von Software ist das beste Maß für den Fortschritt.
• , ;
• ;
• — ;
• , ;
• . .

Die meisten der oben genannten Methoden widersprechen anderen Methoden nicht und sind sehr ratsam.

Aber nicht immer können diese Prinzipien wirklich in der Praxis angewendet werden. Zum Beispiel ist ein Kunde weit davon entfernt, immer mit einem Team zusammenzuarbeiten, um Lösungen zu besprechen. Er hat oft keine Zeit und manchmal kein besonderes Verlangen. Dann brauchen Sie einen Profi - einen Analysten, der in der Lage ist, unauffällig präzise Linien zu ziehen, der auf Vertrauen beruht und all seine psychologischen „kleinen Dinge“ nutzt, um nützliche Informationen daraus zu ziehen und sie reibungslos und reibungslos zu kämmen, um sie in der für die Implementierung am besten geeigneten Form an das Entwicklungsteam weiterzuleiten. Es ist interessant, wenn dies passiert und die Arbeit des Teams nicht mehr als flexibel angesehen wird.

Aus dem gleichen Grund ist es nicht immer möglich, häufige Lieferungen zu organisieren. Und dieser Prozess kann ernsthaft durch eine Reihe integrierbarer Module beeinträchtigt werden, die von verschiedenen Teams entwickelt wurden und gleichzeitig auf derselben Ausrüstung (Module) zusammengebaut werden können. Dies ist sehr problematisch. Ja, und bei bestimmten Geräten kommt es vor, dass die Lieferung direkt näher an der Lieferung erfolgt. Dies muss ebenfalls berücksichtigt werden.

Und es gibt eine Zwietracht in der Aussage über „die besten technischen Anforderungen, Design und Architektur“, obwohl die Prinzipien von Agile im Prinzip keine Dokumentation und all diesen Jazz begrüßen. Wenn Sie einen formalen Ansatz zur Dokumentation „beleidigen“, ist es unwahrscheinlich, dass er sich als der beste herausstellt (Volksweisheit).

Aus meiner Sicht wirft es auch einen Kritikpunkt auf den Rang der besten Methode zur Übermittlung von Informationen - "persönliches Gespräch (von Angesicht zu Angesicht)". Meiner Meinung nach ist die Übertragung von Informationen in einem Projekt viel effizienter, beispielsweise mithilfe eines Task-Trackers oder eines Wiki-Systems, ohne natürlich die persönliche Kommunikation auszuschließen.

IV Anwendung agiler Methoden

Bei Innovationen müssen Sie sowohl hartnäckig als auch flexibel sein.
Wenn Sie nicht stur sind, werden Sie sich weigern, zu früh zu experimentieren.
Wenn Sie nicht flexibel sind, schlagen Sie Ihren Kopf gegen die Wand und sehen keine andere Lösung für das Problem, das Sie lösen möchten.
Jeffrey Preston

Wenn so viele kritische Bewertungen während der Überprüfung entstanden sind, wie funktioniert das alles?
Der Erfolg von Agile trägt offenbar zur Effektivität der Methodik in kleinen Projekten und zur Gemeinsamkeit (Gleichzeitigkeit) der Verwendung aller oben genannten Punkte bei.

1. Vorteile der Verwendung von Agile

Durch die Verwendung von User Stories kann das Entwicklungsteam in Gesprächen mit dem Kunden das erforderliche Verständnis erreichen. Für den Kunden wird der Schwellenwert für die Eingabe des Themas verringert, es ist für ihn einfacher, mit dem Inhalt des Projekts zu arbeiten, Prioritäten zu setzen, Ungenauigkeiten zu korrigieren usw. Darüber hinaus haben auch Projekt-, Produkt- und andere Teammanager, die sich mit Anforderungsspezifikationen auf der Grundlage einfacher User Stories auskennen, die Möglichkeit, Aufgaben in einem Projekt viel einfacher zu jonglieren und die Kundenerwartungen zu verstehen.

Durch die häufige Lieferung von Prototypen können große Diskrepanzen zwischen den Erwartungen des Kunden und den von den Darstellern der Lösungen angebotenen Optionen vermieden werden. Mit jeder neuen Version bringen sie sich immer mehr näher. Drawdowns in der Ausführungszeit und dementsprechend auch finanzielle Verluste sind nicht groß und vorhersehbar, sie können direkt in den Projektplan aufgenommen werden.

Es sieht ungefähr so ​​aus: Der Kunde erwartet einige neue Funktionen, deren Funktionen er selbst nicht vollständig repräsentiert. Es besteht eine „enge Zusammenarbeit“, wodurch der Auftragnehmer eine Pilotlösung anbietet, die in der Regel die Erwartungen des Kunden, über die das Team informiert wird, nicht vollständig erfüllt. Diese Folge fördert eine neue „enge Zusammenarbeit“, wodurch der Auftragnehmer Anpassungen am Prototyp vornimmt und das Produkt erneut dem Kunden präsentiert. Und so im Kreis, bis eine bestimmte Funktion den Kunden vollständig überzeugt oder bis sie in Zusammenarbeit so „überfüllt“ ist, dass es nicht angenehm ist, darin zu bleiben. Wenn die Komplexität des Produkts und die Anzahl der automatisierten Funktionen es Ihnen ermöglichen, 3-6 solcher Zyklen durchzuführen, um das vollständige und bedingungslose Glück des Kunden zu gewährleisten, warum dann nicht?ziemlich praktikables Schema.

Das einzige, worauf ich mich konzentrieren möchte, ist ein grundlegender Punkt, der oft ohne gebührende Aufmerksamkeit bleibt - die Notwendigkeit, Dokumente (zumindest nachträglich) zu korrigieren, deren technische Lösung durch Versuch und Irrtum erreicht wurde. Dies ist sowohl für den Kunden wichtig, der anschließend ein neues Team einstellen kann, um das Produkt fertigzustellen oder zu skalieren, als auch für das Team selbst, das zum einen in der Lage ist, die Lösung oder ihre Teile zu replizieren, und zum anderen, wenn es für die Aktualisierung des Produkts eingestellt wird schneller und besser, sich dem Prozess anzuschließen.

2. Kleine Projekte - eine komfortable Umgebung für Agile

Bei kleinen Projekten können wir durch die Verwendung von User Stories anstelle der vollständigen Anforderungen für das entwickelte Produkt die Kommunikation mit dem Kunden vereinfachen und komfortabler gestalten. Aufgrund der häufigen Interaktion mit dem Kunden und der Einfachheit der Kommunikationsform wäscht sich das Team nicht, sodass beim Skaten akzeptable Anforderungen an die Funktionalität des Produkts gestellt werden. Ohne komplexe Algorithmen und die Integration in andere Software kann dies ohne großen Verlust geschehen. Problemdomänenebene - Schließen Sie User Stories und Lösungsdomänen - Kommentare im Code.

Mit einem Team von Fachleuten können Sie sich nicht die Mühe machen, die Architektur der Lösung und die Spezifikationen der Produktanforderungen zu erarbeiten. Sicherlich haben sich so etwas wie das Team oder seine Mitglieder bereits entschieden und sie haben die entsprechenden Vorlagen und Best Practices hinter sich.

Wenn dieses Produkt einmalig ist und nicht geplant ist, es zu entwickeln, ist dies völlig ausreichend.

3. Wie kann ich Agile in mittelgroßen Projekten verwenden?

Die Verwendung von Agile in mittelgroßen Projekten kann ebenfalls sehr effektiv sein.

In größeren Projekten kann eine Vielzahl von Automatisierungsplattformen verwendet werden, die mit vorgefertigten Vorlagen, Best Practices, Selbstdokumentationstools usw. ausgestattet sind. Dies vereinfacht formale Prozesse, einschließlich Design, Modellierung und Dokumentation, erheblich. Die in solchen Fällen vorgestellten Lösungen werden meistens mit einer begrenzten Anzahl von Verbesserungen und Änderungen dupliziert.

Der größte Effekt kann erzielt werden, wenn frühere ähnliche Entscheidungen dokumentiert werden. Auf dieser Basis können Sie mehr Zeit investieren, um nicht den gewünschten Prototyp zu entwerfen und zu modellieren, sondern zusammen mit dem Kunden auszuwählen. „Probier es an, zieh es an und geh. Nicht drücken? ". Es ist wichtig, dass auch neue, implementierte Lösungen gut dokumentiert sind. In diesem Fall erhält das Team eine Reihe von Blöcken und Anweisungen zum Zusammenbau verschiedener Modelle, die zukünftigen Kunden zur Auswahl angeboten werden können.

In diesem Arbeitsmodell ist es wichtig zu verstehen, dass Agile die Bedeutung des Dokumentationsprozesses nicht leugnet, sondern lediglich die Entstehung verzögert und dem Produkt selbst Priorität einräumt (wenn möglich in der aktuellen Situation). Die Dokumentation kann bereits nach Erhalt eines nachhaltigen Produkts erstellt werden, um die erzielten Ergebnisse zu konsolidieren und, wie oben erwähnt, dazu beizutragen, in Zukunft nicht den Faden des Verständnisses der Systemregeln zu verlieren.

4. Wie Sie Agile effektiv in großen Integrationsprojekten einsetzen können

In großen und komplexen Projekten, in denen eine qualitativ hochwertige Dokumentation gepflegt wird, gibt es eine architektonische Vorstellung vom Produkt und dem Herstellungsprozess. "Teile" des Produkts können an kleine Teams ausgelagert werden. Diese Übertragung erfolgt nach einer detaillierten Untersuchung der allgemeinen Architektur und der Vorbereitung allgemeiner Anforderungen für neue Subsysteme. Und jetzt können diese relativ kleinen Teile mit Agile sehr effektiv implementiert werden.

Das gleiche Schema gilt für kleine Verbesserungen oder die schrittweise Entwicklung eines großen komplexen Systems, insbesondere wenn Sie Forschungsarbeiten durchführen müssen.

Eine weitere Option für die Verwendung von Agile in großen Projekten kann im Falle einer Notlieferung des Produkts an den Kunden effektiv angewendet werden. Angesichts des kritischen Mangels an Zeit und Ressourcen für die Verfeinerung und Korrektur ist es gerade die Flexibilität des Ansatzes, die dazu beitragen kann, ein Fiasko zu verhindern. In solchen Situationen ist diese spezielle Methodik meiner Meinung nach optimal.

In diesem Abschnitt sollten die vorhandenen Methoden erwähnt werden, die auf Agile basieren, sich jedoch auf die Lösung großer Probleme konzentrieren.

Agile Unified Process (AUP) ist eine vereinfachte Version des von Scott Ambler entwickelten Unified Process (UP). Diese Softwareentwicklungsmethode kombiniert Elemente flexibler Methoden und eines einheitlichen Prozesses. AUP umfasst insbesondere die Entwicklung durch Testen (TDD), die Verwendung flexibler Modellierung (English Agile Modeling) und Datenbank-Refactoring sowie flexibles Änderungsmanagement.

OpenUP ist eine iterativ inkrementelle Methode der Softwareentwicklung. Positioniert als leichte und flexible Version von RUP. OpenUP unterteilt den Projektlebenszyklus in vier Phasen: die Anfangsphase, die Verfeinerungs-, Entwurfs- und Übertragungsphase. Der Lebenszyklus des Projekts stellt sicher, dass Stakeholder und Teammitglieder während des gesamten Projekts mit Einarbeitungs- und Entscheidungspunkten versorgt werden. Auf diese Weise können Sie die Situation effektiv überwachen und rechtzeitig Entscheidungen über die Akzeptanz der Ergebnisse treffen. Der Projektplan definiert den Lebenszyklus und das Endergebnis ist die endgültige Anwendung.

5. Wie man Agile nicht benutzt

Ein ebenso wichtiger Abschnitt, für den vielleicht die gesamte Analyse in Betracht gezogen wurde.

1. Der Anführer in meinem Anti-Rating ist die Situation, in der sie versuchen, Agile oder vielmehr einige seiner Prinzipien zu verwenden, um keine spezifischen Ziele zu erreichen, die sie sicherstellen können, sondern einfach #CRAFTLY. Da dies ein Trend ist, ist er in aller Munde. Zum Beispiel teilte jemand positive Bewertungen auf der IT-Party, ein wenig kurzlebig und sogar arrogant, aber es gab ein Gerücht, ein Gefolge erschien. Und jetzt haben sie sich bereits Anhänger von Agile genannt und fühlen sich mit den anderen in Verbindung - sie gehören einem bestimmten Elite-Club an. All dies trägt zur offensichtlichen Einfachheit der Methodik und zu den verschwommenen Umrissen ihrer Grenzen bei. Implementierungen nach diesem Prinzip erfolgen gedankenlos und formal. Menschen setzen formal und prinzipienlos Prinzipien um, die den Formalismus reduzieren sollen.
   
   Zum Beispiel einer der jüngsten Fälle. In einer Firma, die Retrospektiven durchführte, wurden sie von den Timlids verboten. Hier ist so ein Chip. Unerwartet. Erster Gedanke: Nun, vielleicht haben sie Recht, damit die Behörden keinen Druck auf das Team ausüben, wenn Probleme usw. besprochen werden. Aber die Timlids sind beleidigt, sie sind ratlos und wollen es herausfinden. Ich habe versucht, mich davon zu überzeugen, dass es vielleicht besser ist. Hauptsache, Sie erhalten eine Wunschliste mit einer Liste, was geändert, was verbessert werden muss usw. Und hier wurde ein schreckliches Geheimnis gelüftet. Und aufgrund dieser Zusammenkünfte entstehen keine Ergebnisse und Wünsche zur Verbesserung der Prozesse. Meine Herren IT_shniki, und warum dann so eine Retrospektive? Einfach einander loben und den Teamgeist stärken? A, sagen wir, und B. sagten. Schließlich besteht der Hauptzweck dieses methodischen Prozesses darin, "das Team systematisch mögliche Wege zur Verbesserung der Effizienz zu analysieren und den Stil ihrer Arbeit entsprechend anzupassen."
2. Die zweite Situation in meinem Ranking ist, wenn Teams beschließen, bei der Vorbereitung von Anforderungen in Projekten mit komplexen Verhaltens- oder logischen Algorithmen zu sparen. Das heißt, wenn die User Story nur eine kleine Spitze des Eisbergs des Problems ist und ihr Hauptteil nicht sichtbar ist und eine detaillierte, gründliche Analyse und Gestaltung für die Implementierung erfordert. Was passiert damit?
   
   Vor Arbeitsbeginn verstehen weder der Kunde noch die Entwickler annähernd, wie viel Arbeit sie erledigen müssen. Und dementsprechend: Entweder zahlt der Kunde, zahlt und zahlt, jedes Mal, wenn er ihm erklärt, dass sich alles als viel schwieriger herausgestellt hat und die Arbeit jetzt noch nicht sichtbar ist und endet. Und schließlich wird es schade sein, aufzuhören und allmählich an dem strengen Verständnis zu nagen, dass sich dieses "goldene" Produkt niemals auszahlen wird. Entweder werden die Entwickler, die sich bereit erklärt haben, die Arbeiten für einen bestimmten Zeitraum abzuschließen, das Produkt auf eigene Kosten fertigstellen und neu erstellen, bis dem Kunden die Vorstellungskraft ausgeht, oder er hat Mitleid mit den Opfern eines flexiblen Ansatzes.
3. Einen ehrenwerten dritten Platz belegt die Situation, in der das Team in einem großen multifunktionalen Projekt (und plötzlich auch in einem Integrationsprojekt) beschließt, bei der Ausarbeitung der Lösungsarchitektur zu sparen und einzelne User Stories in kurzen Iterationen zu implementieren. Mit hoher Wahrscheinlichkeit wird es nach 3-5 Iterationen vorkommen, dass Sie beim Versuch, eine neue Funktion zu erstellen, die gesamte vorherige Funktion wiederholen müssen, da die Grundprinzipien, auf denen diese Funktion hätte basieren sollen, nicht berücksichtigt wurden. Schlimmer noch, wenn sich nach der 10. Iteration herausstellt, dass die ausgewählten Technologien nicht alle Bedürfnisse des Kunden erfüllen und erneut von vorne beginnen müssen. Vielleicht durch Ändern des Befehls.
4. Die Situation, in der ein scharfes und unglaublich flexibles Startup in die Freiflächen eines schleppenden Marktsegments einbricht, fiel nicht unter die ersten drei. Ein Start-up, es ist auch ein Startup, das keine Fundamente, Bindungen, Bindungen und gleichzeitig Stabilität und Stabilität hat. Und einfach gesagt, es gibt fast keine Dokumentation, das Team ist nicht harmonisch und ändert sich oft. Der Markt zerreißt das Team buchstäblich und fordert immer mehr neue Lösungen im Einsatzbereich, und alle nachfolgenden Projekte fallen vor unseren Augen einfach auseinander. In den meisten Fällen erklärt sich dies aus der Tatsache, dass das Team die Prozesse der industriellen Softwareproduktion , der Organisation der Lieferung und der Produktunterstützung nicht versteht.

Zusammenfassend

Bei der Vorbereitung dieses Artikels habe ich versucht, Teams, die sich für den agilen Ansatz interessieren, dabei zu unterstützen, die Herausforderungen, denen sie sich auf die eine oder andere Weise stellen sollten, hervorzuheben und zu formalisieren sowie mögliche Lösungen zu finden, um sie zu überwinden. Ich habe versucht, das Thema so tolerant wie möglich zu betrachten, sowohl für Apologeten für die Einführung einer oder mehrerer Methoden aus dieser Gruppe als auch für Gegner, die den Heiligenschein der Flexibilität entlarven und sich vernünftigerweise weigern wollen, ihn zu verwenden.

Ich hoffe, dass die Analyse Teams dabei helfen wird, andere Methoden zu verwenden, um bei Bedarf den agilen Ansatz zu nutzen.