„Alles ist Gift, alles ist Medizin; beide werden durch die Dosis bestimmt. “
Paracelsus
Es ist üblich, die Geschichte von
Agile ab Februar 2001 zu zählen, als ein ziemlich seltsames Dokument geboren wurde -
Agile Manifesto . Im Großen und Ganzen besteht der Text des Dokuments aus philosophischen Beweisen (zum Beispiel „Einfachheit - die Kunst, nicht zu viel zu arbeiten“) und kontroversen Aussagen (zum Beispiel „die besten technischen Anforderungen, Design und Architektur werden von einem selbstorganisierten Team erhalten“). Aber dieses Dokument ist nicht so sehr inhaltlich seltsam (man weiß nie, woran man in einem Skigebiet denken könnte), sondern in der epischen Natur der nachfolgenden Veränderungen in der Softwareentwicklungsbranche. In kürzester Zeit tauchten viele Techniken auf, die die „flexible“ Entwicklungsmethode implementieren, die feierlich um die Welt marschiert und die Köpfe der Auftragnehmer und die Geldbörsen der Kunden erfasst. Adepten präsentieren diese Bewegung als eine Art magische Pille, die alles entscheidet. Es kam zu dem Punkt, dass ein
edler Spender, ein ehrlicher Programmierer, bereits unanständig geworden ist, eine Beteiligung an der Softwareentwicklung gemäß der traditionellen
Ausrichtung der Methodik zuzugeben. Versuchen wir, die Ursachen und Folgen des Phänomens zu verstehen, indem wir
Scrum als häufigste Manifestation von Agile verwenden.
Lassen Sie uns zunächst versuchen zu verstehen, was wirklich Neues im Agile-Wrapper im Allgemeinen und in Scrum im Besonderen ist.
Scrum im alten Ägypten
Ich werde mir erlauben, zu behaupten, dass es immer eine flexible Methodik im Allgemeinen und die Scrum-Methodik im Besonderen gegeben hat, obwohl sie nicht genannt wurden. Sie wurden überhaupt nicht angerufen, waren aber einfach die natürlichste und effektivste Art, ihre internen Projekte durchzuführen (das Schlüsselwort hier ist „intern“).
Zum Beispiel plante der alte ägyptische Pharao den Bau einer Pyramide und ... es begann. Besprach die Idee mit den Priestern (Stakeholdern) und beauftragte seinen Butler, für das Projekt verantwortlich zu sein (Product Owner). Der Angestellte fand einen kompetenten Maurer (Scrum Master). Der Maurer stellte Assistenten (Scrum-Team) ein, ging zum Sklavenmarkt und bewertete Sklaven (Arbeitstools: PC, Server, Software für die Entwicklung usw.).
Da der Pharao ihm monatlich einen Bericht über den Baufortschritt befahl, begann der Maurer (mit Assistenten) eine monatliche Bauvorführung (Demo) für den Butler durchzuführen. Während der Show wurde nicht nur besprochen, was bereits getan wurde (Rückblick), sondern auch ein Plan für den nächsten Monat (Sprint) erstellt. Um nichts zu verpassen, diskutierte der Cupbearer einen Monat lang die User Stories mit den Priestern und schrieb sie in ein spezielles Pergament (Backlog), aus dem die Wunschliste in den Plan für den nächsten Monat fiel. Gut und so weiter. Ich weiß nicht, wie Aufkleber, Scrum Board und Burndown-Diagramme damals ausgesehen haben. Jeder kompetente Leiter wählt die bequemsten Tools für die Verwaltung und Überwachung des Projekts aus. Details sind hier nicht wichtig, Hauptsache, die Technik funktioniert.
Das heißt, Ich denke, dass alle Manager zu jeder Zeit eine flexible Technik verwendet haben, um ihr internes Produkt (auf eigene Gefahr und eigenes Risiko) zu erstellen, weil:
- kompetent genug, um das Endergebnis zu entwerfen;
- kompetent genug, um den Prozess zu kontrollieren;
- genug Macht über untergeordnete Prozessteilnehmer haben;
- Das Verhältnis von Begriff, Kosten und Qualität der Arbeit ist für sie kein Dogma und kann bei Bedarf geändert werden (da „er sein eigener Meister ist“).
- und vor allem sind sowohl das Endergebnis als auch der Prozess, um es zu erreichen, in den gleichen Händen und verfolgen ein kommerzielles Interesse.
Für den externen Kunden gilt jedoch keines der Elemente in dieser Liste. Daher wurde für externe (benutzerdefinierte) Projekte nie eine flexible Technik verwendet (Ausnahmen bestätigen nur die Regel). Immerhin waren die Menschen einfach und intolerant, denn bei einem offensichtlichen Übermaß an Fristen und Schätzungen hätten sie ihre Köpfe verkürzen können.
Scrum heutzutage
Die einzige Neuheit des modernen Scrum ist die Tatsache, dass es für die Implementierung externer (benutzerdefinierter) Projekte verwendet wird. Der Versuch, diese Seite des Problems nicht herauszuhalten, weil das Ziehen einer Schnur die wahre Motivation der Marktteilnehmer hervorheben kann. Tatsächlich sind das agile Manifest und alle Argumente von Scrum reine Propaganda der Interessen des Auftragnehmers, um des Anstands willen, verschleiert im Kampf um alles Gute gegen alles Schlechte. Das ist das Genie der Lösung, die es uns ermöglicht, den Kunden davon zu überzeugen, das Ergebnis für den Prozess zu opfern!
Was ändert sich also, wenn der Product Owner ein Mitarbeiter eines anderen und nicht seines eigenen Unternehmens ist? Der Hauptunterschied besteht darin, dass das Endergebnis und der Prozess seiner Erreichung nun auf verschiedenen Seiten der „Barrikade“ liegen und jede der Parteien nur ihr eigenes kommerzielles Interesse verfolgt. Das Ergebnis ist wichtig für den Kunden und der Prozess ist wichtig für den Auftragnehmer. Es kann nicht anders sein - schließlich "nichts Persönliches, das ist nur Geschäft."
Agile ist für IT-Marktteilnehmer von Vorteil, da es ihnen folgende Möglichkeiten bietet:
- Geld mit dem Prozess verdienen und nicht für das Ergebnis verantwortlich sein;
- Reduzieren Sie die Kosten für kompetentes Managementpersonal (diese sind teuer, aber Sie müssen jetzt nichts entwerfen und müssen keine TK schreiben, und der Prozess steuert jetzt den Product Owner des Kunden).
Und da dies rentabel ist, können Programmierteams mit dem Rückgrat hochqualifizierter und systemorientierter Fachleute direkt vor unseren Augen zu Farmen gemieteter Encoder der mittleren Hand werden.
Versuchen Sie, sich an die Stelle einer Person zu setzen, die ein Team von Bauherren beauftragt, seine Wohnung zu reparieren, und versucht, die Bedingungen und Kosten für Reparaturen vom Teamleiter zu erhalten. Als Antwort hört er:
- Wir sind kreative Menschen, also werden wir "wie es geht" arbeiten, aber Sie zahlen für jede Arbeitsstunde des Teams und der Materialien.
- Wir werden kein gemeinsames Projekt und keinen gemeinsamen Plan durchführen, wir werden es auf dem Weg herausfinden (wenn wir etwas falsch machen, werden wir es für die von Ihnen bezahlte Zeit und zusätzliche Materialien wiederholen).
- Wir werden alle zwei Wochen die Ergebnisse unserer Arbeit zeigen und über unsere Probleme sprechen. Dann werden wir gemeinsam die nächsten zwei Wochen planen.
Es ist unwahrscheinlich, dass jemand einem solchen Angebot zustimmt, und Kunden von IT-Mitarbeitern stimmen dem zu! Das macht lebensspendende Propaganda!
Die Kunden sind nicht nur davon überzeugt, unvorhersehbaren Terminen und Kosten zuzustimmen, sondern verlagern auch die Verantwortung für Fehler darauf. Die Qualifikation des Kunden erlaubt es in der Regel nicht, die Anforderungen für das Endergebnis zu formalisieren und den Prozess professionell zu steuern. Daher kann es immer verwirrt und abgelenkt sein (in Abwesenheit einer allgemeinen TK), viele sekundäre Probleme zu lösen (die am häufigsten aufgrund des Mangels an langfristiger Planung auftreten).
Die Folgen agiler Anbetung
Glauben Sie nicht, dass die Qualität von Softwareprodukten proportional zur weit verbreiteten Verbreitung von Agile in der Branche ist? Woher kommt die Qualität, wenn der gesamte Prozess durch die einfachste und schnellste Lösung von Problemen geschärft wird? Und vorausschauendes Denken ist methodisch offiziell verboten!
Denken Sie nicht, dass Softwareprodukte zunehmend zu „Patchwork-Quilts“ werden, wenn Sie überrascht sind, dass verschiedene Abschnitte derselben Software von völlig unterschiedlichen Personen erstellt zu werden scheinen? Und selbst auf einem Programmbildschirm können unterschiedliche Designstile, unterschiedliche ergonomische Ansätze und unterschiedliche Algorithmen für die Funktion ähnlicher Steuerelemente gemischt werden. Es gibt jedoch keine TK und Style Guide für das Produkt. Wer also vertrauter ist, wird dies tun! Und QA-Mitarbeiter sind wie alle anderen von den Sprint-Fristen betroffen.
Worum geht es bei alledem?
Aus all dem scheint es, dass ich ein leidenschaftlicher agiler Hasser bin. Das ist aber überhaupt nicht! Und ich habe nicht versucht, jemanden zu beleidigen! Er versuchte nur, die Worte des großen Paracelsus im Epigraph klarer zu veranschaulichen.
Eine flexible Methodik eignet sich gut für interne kleine und sogar mittlere Projekte. Die Größe des Projekts ist nur durch die Fähigkeit eines bestimmten Leiters begrenzt, „den Wald hinter den Bäumen nicht zu verlieren“, d. H. die Fähigkeit, sowohl alle Details als auch das gewünschte Ergebnis im Auge zu behalten, ohne es „auf Papier“ zu systematisieren.
Eine flexible Methodik ist für externe Projekte nur begrenzt geeignet. In diesem Fall gelten für den Product Owner des Kunden dieselben Anforderungen wie für den internen Projektmanager. Das heißt, diese Person sollte ein echter IT-Experte sein und keine Sekretärin, die in Teilzeit eine vorübergehende Belastung übernimmt. Er sollte in der Lage sein, die Qualifikationen des eingestellten Teams zu überprüfen und die Qualität des zu entwickelnden Produkts ständig zu überwachen. Darüber hinaus sollte das zu entwickelnde Produkt (im Falle höherer Gewalt) den Austausch des Entwicklungsteams ermöglichen. Nur in diesem Fall können wir erwarten, dass es nicht „beleidigend und schmerzhaft für ziellos gelebte Jahre“ sein wird.
Wie Sie sehen, hat Agile seinen Platz in der Sonne, ist jedoch im Bereich der Vertrags-IT-Entwicklung sehr begrenzt. Was tun, wenn Ihr Projekt nicht in die Kategorie Agile-geeignet fällt?
Ist es für Sie nicht verdächtig, dass eine flexible Methodik nur in der Entwicklung von Vertragssoftware Fuß gefasst hat? Nun, sie machen keine U-Boote, Flugzeuge oder Autos auf Scrum. Die Weisheit unserer Vorfahren lehrt uns, dass selbst eine normale Hundehütte nicht ohne eine Entwurfsphase (Bleistiftskizze mit Abmessungen) und die Erstellung eines ToR (Liste der Materialien und Werkzeuge) zusammengestellt werden kann. Alles, was Sie sehen (vom Hocker bis zum Raumschiff), wurde nach dem guten alten
„Wasserfall“ geschaffen . Warum machst du nicht dasselbe? Und denken Sie daran - alles wird gut!
PS
Alles, was gesagt wird, basiert auf meiner beträchtlichen persönlichen (19 Jahre) Erfahrung in der Vertragswebentwicklung, die sowohl traditionelle (Wasserfall) als auch progressive (Scrum) Ansätze verwendet. Das Motiv für das Schreiben des Artikels war die moralische Qual der Betrachtung des nächsten „Wunders feindlicher Technologie“, das unter den Bündnissen des großen Frankensteins für eine angesehene westliche Gesellschaft zusammengeschustert wurde.
