Das Buch „Pure Agile. Die Grundlagen der Flexibilität

Hallo habrozhiteli! Wir haben der Druckerei eine weitere Neuheit übergeben! Fast zwanzig Jahre sind vergangen, seit das Agile Manifest erschienen ist. Der legendäre Robert Martin (Onkel Bob) erkannte, dass es an der Zeit war, den Staub von den Prinzipien von Agile abzuschütteln und erneut über den flexiblen Ansatz nicht nur für die neue Generation von Programmierern, sondern auch für Spezialisten aus anderen Branchen zu berichten. Der Autor der Bücher „Clean Code“, „Ideal Programmer“, „Clean Architecture“, die von IT-Mitarbeitern geliebt wurden, war der Ursprung von Agile. Pure Agile beseitigt das Missverständnis und die Verwirrung, die die Verwendung von Agile im Laufe der Jahre schwieriger gemacht haben als der ursprüngliche Plan. Im Wesentlichen ist Agile nur eine kleine Auswahl von Methoden und Werkzeugen, die kleinen Teams von Programmierern bei der Verwaltung kleiner Projekte helfen, aber zu großartigen Ergebnissen führen.denn jedes Großprojekt besteht aus einer Vielzahl von Bausteinen. Fünf Jahrzehnte Arbeit mit Projekten aller erdenklichen Typen und Größen ermöglichen es Onkel Bob zu zeigen, wie Agile tatsächlich funktionieren sollte. Wenn Sie die Vorteile von Agile verstehen möchten, suchen Sie nicht nach einfachen Möglichkeiten - Sie müssen Agile korrekt verwenden. In Pure Agile erfahren Sie, wie Sie dies für Entwickler, Tester, Manager, Projektmanager und Kunden tun.

Auszug. Das erste was man wissen muss

Was müssen Sie als Erstes über das Projekt wissen? Bevor Sie den Namen des Projekts oder die Anforderungen dafür herausfinden, bevor Sie überhaupt Bewegungen ausführen, müssen Sie weitere Informationen einholen. Dies sind natürlich die Fristen. Nachdem die Daten ausgewählt wurden, müssen sie festgelegt werden. Es macht keinen Sinn, die Begriffe zu diskutieren, da sie im Zusammenhang mit objektiven Geschäftsgründen festgelegt werden. Wenn der September fällig ist, ist es nicht nur das. Vielleicht ist im September eine Art Ausstellung oder Hauptversammlung geplant, oder vielleicht gehen die Mittel einfach zur Neige. Was auch immer der Grund sein mag, es hat einige wichtige Hintergründe. Und der Grund wird sich nicht einfach ändern, weil für einige Entwickler das Aufgabenvolumen überwältigend erscheint.

Gleichzeitig können sich die Anforderungen in einem kontinuierlichen Stream ändern, der nicht behoben werden kann.

Und dafür gibt es auch einen Grund: Kunden wissen oft nicht genau, was sie wollen. Sie scheinen zu wissen, welches Problem sie lösen müssen, aber die Umsetzung dieses Wissens in Projektanforderungen ist immer schwierig. Daher werden die Anforderungen ständig neu bewertet und überarbeitet. Neue Funktionen wurden hinzugefügt.

Einige alte verschwinden. Die Benutzeroberfläche ändert sich schnell - in Wochen, wenn nicht Tagen.

So sieht die Welt der Softwareentwicklung aus. In dieser Welt sind die Fristen festgelegt und die Anforderungen ändern sich ständig. Und irgendwie müssen Entwickler im Zusammenhang mit all dem das Projekt erfolgreich abschließen.

Sammlung

Das kaskadierende Modell prophezeite uns einen Weg, diese Aufgabe zu umgehen. Um zu erklären, wie verführerisch und ineffektiv es gleichzeitig war, werde ich ein Treffen als Beispiel anführen.

Es war der erste Mai. Big Boss rief Untergebene in den Konferenzraum.

Der Chef begann: „Wir haben ein neues Projekt. Es ist notwendig, es bis zum 1. November fertig zu stellen. Wir haben noch keine Anforderungen. Sie werden uns in den nächsten Wochen bekannt gegeben. Wie lange dauert die Analyse des Projekts? “

Wir begannen uns fragend anzusehen. Alle schwiegen und hatten Angst, zu viel zu sagen. Niemand hatte eine Ahnung, was er antworten sollte. Jemand murmelte: "Wir haben also keine Anforderungen, wovon sollen wir ausgehen?"

„Stell dir vor, dass sie es sind! Schrie der Chef. "Sie wissen, wie alles funktioniert." Sie sind Experten! Ich brauche keine genauen Daten. Ich muss nur irgendwie den Zeitplan ausfüllen. Denken Sie daran, dass Sie das Projekt sicher vergessen können, wenn es länger als zwei Monate dauert. “

Jemand murmelte fragend: "Zwei Monate?" Der Chef stimmte den Bedingungen zu: „Großartig! Genau das, was ich dachte. Jetzt sag mir, wie viel das Design kostet? “

Und wieder erstarrten alle verwirrt, der Raum war voller toter Stille. Wir zählen. Und wir erkennen, dass bis zum ersten November nur sechs Monate. Die Schlussfolgerung bietet sich an. "Zwei Monate?" - du fragst.

"Das stimmt! - Der große Chef lächelte strahlend. - Wie ich dachte. Und wir haben noch zwei Monate Zeit für die Umsetzung. Danke an alle, du bist frei! "
Viele Leser haben sich wahrscheinlich daran erinnert, dass ihnen so etwas schon passiert ist. Wer hatte das nicht, na ja, Sie haben Glück!

Analysephase

Nehmen wir also an, wir haben den Konferenzraum verlassen und uns in den Büros verteilt. Was macht man als nächstes? Die Analysephase beginnt - das heißt, Sie müssen etwas analysieren. Aber was genau nennen wir Analyse?

Wenn Sie Bücher zum Thema Analyse in der Softwareentwicklung lesen, werden Sie feststellen, dass jeder Autor seine eigene Definition gibt. Es besteht kein Konsens darüber, was Analyse ist. Es kann die Schaffung einer strukturellen Zerlegung von Anforderungen sein. Oder vielleicht - Erkennung und Spezifikation von Anforderungen. Es kann die Erstellung eines grundlegenden Datenmodells oder -objekts usw. sein. Die beste Definition für Analyse lautet: Genau das tun Analysten.

Natürlich gibt es offensichtliche Dinge. Wir müssen die Größe des Projekts bewerten, um Indikatoren für die wichtigsten technischen, wirtschaftlichen und personellen Ressourcen zu prognostizieren. Sie müssen sicherstellen, dass der Arbeitsplan durchführbar ist. Dies ist das kleinste, das das Unternehmen von uns erwartet. Was auch immer als Analyse bezeichnet wird, genau das wollten wir in den nächsten zwei Monaten tun.

Dies ist eine Art günstige Phase des Projekts. Jeder surft ruhig im Internet, führt kleine Transaktionen durch, trifft sich mit Kunden und Benutzern, zeichnet schöne Grafiken, einfach ausgedrückt, hat Spaß.

Dann passiert am ersten Juli ein Wunder. Die Analyse ist abgeschlossen.

Warum denken wir so? Weil es schon der erste Juli ist. Wenn die Analysephase gemäß dem Zeitplan am 1. Juli abgeschlossen sein soll, wird diese Phase am 1. Juli abgeschlossen. Wir sind nicht zu spät, oder? Deshalb werden wir eine kleine Party mit Luftballons und feurigen Reden veranstalten und unseren Übergang von der Analysephase zur Entwurfsphase feiern.

Design-Phase

Was nun? Natürlich werden wir entwerfen. Aber was ist Design ?

Wir wissen etwas mehr über die Software-Design-Phase. In dieser Phase teilen wir das Projekt in separate Module auf und entwerfen die Schnittstellen zwischen diesen Modulen. In dieser Phase gehen wir auch davon aus, wie viele Teams wir benötigen und wie diese Teams miteinander verbunden werden. Im Allgemeinen muss der Arbeitsplan präzisiert werden, um einen plausiblen realisierbaren Umsetzungsplan zu erstellen.

Natürlich ändert sich zu diesem Zeitpunkt etwas unerwartet. Neue Funktionen wurden hinzugefügt. Alte Funktionen verschwinden oder passen sich an. Und es wäre schön, zurückzublicken und die Änderungen erneut zu analysieren, aber Zeit ist Geld. Deshalb versuchen wir auf jede erdenkliche Weise, Änderungen am Design vorzunehmen.

Und dann passiert ein neues Wunder. Am ersten September vervollständigen wir plötzlich das Design. Und warum? Ja, weil. Der erste September. Nach dem Arbeitsplan hätten wir schon fertig sein sollen. Kein Grund zu zögern.

Also noch eine Party. Luftballons und Reden. Und wir brechen zur nächsten Stufe auf - der Implementierung.

Es wäre großartig, ein solches Schema noch einmal aufzustellen. Oh, wenn es auf die gleiche Weise möglich wäre, die Implementierungsphase abzuschließen! Aber so wird es nicht funktionieren. Denn nach Abschluss der Implementierung muss das gesamte Projekt abgeschlossen werden. Analyse und Design tragen keine Früchte in binärer Form. Sie haben keine eindeutigen Kriterien für die Vollständigkeit.

Es gibt keinen objektiven Weg zu wissen, ob sie in der Realität gehalten werden. Daher stellte sich heraus, dass diese Phasen pünktlich abgeschlossen wurden.

Implementierungsphase

Die Implementierung hat jedoch nur unterschiedliche Kriterien für die Vollständigkeit. Hier ist es nicht mehr möglich, genau herumzuspielen und das imaginäre Ergebnis als gültig zu bezeichnen.
In der Implementierungsphase fehlt die Mehrdeutigkeit der Aufgaben vollständig. Wir schreiben einfach den Code. Und wir müssen den Code in Eile schreiben und unsere Zunge herausstrecken, weil vier Monate einfach in den Wind geworfen wurden.

In der Zwischenzeit ändern sich die Projektanforderungen weiter. Neue Funktionen wurden hinzugefügt. Alte Funktionen verschwinden oder passen sich an. Wir müssten zurückgehen, eine neue Analyse durchführen und Änderungen am Design vornehmen, aber ... es bleiben nur noch zwei Wochen. Und in einem beschleunigten Tempo treiben wir all diese Änderungen in den Code.

Wenn wir uns den Code ansehen und ihn mit dem Entwurfsergebnis vergleichen, stellen wir fest, dass wir in der Entwurfsphase fehl am Platz gewesen sein müssen, da der Code selbst wenig mit dem zu tun hat, was ursprünglich in den wunderbaren Grafiken dargestellt wurde. Aber es gibt keine Zeit zum Nachdenken, weil die Uhr tickt und Überstunden immer mehr werden.

Um den 15. Oktober herum sagt jemand: "Hey, wie ist das Datum heute?" Wann soll ich es nehmen? " Und hier verstehen wir, dass nur noch zwei Wochen übrig sind und wir bis zum 1. November niemals fertig sein werden. Und plötzlich stellen unsere Kunden zum ersten Mal fest, dass es einige Probleme mit dem Projekt gibt.

Stellen Sie sich ihre Empörung vor. „Und im Stadium der Analyse war es unmöglich, darüber zu sagen? Hätten Sie dann nicht die Größe des Projekts schätzen und den Arbeitsplan sorgfältig berechnen sollen? Und warum haben sie es in der Entwurfsphase nicht gesagt? War es dann nicht notwendig, das Projekt in Module aufzuteilen, die Arbeit im gesamten Team zu verteilen und die Humanressourcen zu berechnen? Warum erfahren wir zwei Wochen vor Ablauf der Frist alles? “

Und sie haben Recht, nicht wahr?

Überlebensmarathon

Und der Überlebensmarathon beginnt. Kunden sind wütend. Die Interessengruppen sind auf das Äußerste gekommen. Der Druck steigt. Wir machen Überstunden. Jemand verlässt das Projekt. Nur die Hölle!

Und schon um den März trauern wir zur Hälfte mit dem Ergebnis, dass nur die Hälfte die Anforderungen der Kunden erfüllt. Jeder ist verärgert. Jeder gibt auf. Und wir schwören uns, dass dies beim nächsten Mal nicht passieren wird. Nächstes Mal werden wir alles mit Bedacht tun. Das nächste Mal werden die Analyse und das Design in gutem Glauben durchgeführt.

Ich nenne es den außer Kontrolle geratenen Prozess. Wir werden das nächste Mal noch besser mit einer Methode arbeiten, die nicht funktioniert.

»Sie können auf der Website des Herausgebers vorbestellen .

Nach Zahlung der Papierversion des Buches wird das PDF per E-Mail gesendetmit den ersten 105 Seiten des Buches.