Sind wir agil oder agil?

Was ist das Hauptproblem in der Softwareentwicklung (oder vielleicht in irgendeinem Job)? Als ich meinen Kollegen eine Frage stellte, erhielt ich unterschiedliche Antworten: Änderungen der Anforderungen, Nichtübereinstimmung der Erwartungen, Codequalität, Interaktion mit anderen Teams ... für mich selbst zusammengefasst - Kommunikation ist eines der wichtigsten Probleme.

Während der Kommunikation versteht jeder alles auf seine Weise und interpretiert es anders als gesagt. Der Kunde behält ein bestimmtes Bild im Kopf, das er in Wörter und Bilder umwandeln möchte. Der Entwickler, der diese Wörter hört, wandelt sie in seinem Kopf in eine Art eigenes Bild um. Und in dieser Kette kann es viele Glieder geben.

Um dieses Problem zu lösen, schreiben die Leute einen detaillierten ToR. Aber löst das das Problem? Die gleichen Fragen wurden meines Erachtens von Bob Martin und Martin Fowler zusammen mit seinen Kollegen gestellt, als sie im Februar 2001 das Agile Manifest verfassten. Lassen Sie uns versuchen, es gemeinsam zu diesem Thema und im Agile-Manifest herauszufinden.

Die Geschichte

Im Winter 2000 gab es ein Treffen der Leiter der sogenannten Extreme Programming, sie diskutierten Entwicklungsmethoden und begannen infolgedessen, einige Light-Methoden anzubieten. Nur wenige Leute waren interessiert (ich möchte niemanden beleidigen), höchstwahrscheinlich machten sie mehr Witze zu diesem Thema. Ein Jahr später organisierten jedoch mehrere Außenstehende dieses Treffens ihre eigenen. Alles begann mit der Tatsache, dass Bob Martin (er schrieb das berühmte Buch über die Qualität des Codes) einen Newsletter an die Leiter des letzten Treffens schrieb - lassen Sie uns zusammenkommen und reden. Eigentlich nichts Konkretes. Für einige Zeit stritten sie sich um Ort und Zeit. Infolgedessen versammelten sie sich am 11. Februar 2001 in Utah in einem Skigebiet. 17 Personen aus dem Entwicklungsbereich, darunter Bob Martin, Martin Fowler und andere. Sie tranken, Fowler ging Skifahren und nach Diskussionen entstand das Agile Manifest .

Grundsätzlich kann das Wichtigste buchstäblich durch eine Textseite vermittelt werden, die hier gelesen werden kann .
Aber wie alles, was kurz und sorgfältig durchdacht war, war es für mich persönlich nicht einfach, dies einfach durch Lesen zu verstehen. Lassen Sie uns daher im Detail überlegen, was die Menschen, die das Agile-Manifest unterzeichnet haben, im Sinn hatten.

Agile Prinzipien

Das heißt, ohne die Wichtigkeit dessen zu leugnen, was richtig ist,
Trotzdem schätzen wir das, was links ist, mehr.

Dies ist ein sehr wichtiger Aspekt, der beim Lesen eines Manifests und in der Tat bei jedem Arbeitstag immer berücksichtigt werden muss. Lassen Sie uns die wichtigsten Manifest-Aussagen diskutieren.

Menschen und Interaktion sind wichtiger als Prozesse und Werkzeuge

Auf den ersten Blick scheint dies ein Aufruf zu sein, alle Jira-Projekte, Bug-Tracker, Zeitlogger und andere Tools sowie alle konfigurierten Prozesse wegzuwerfen. Was einfacher sein könnte, ist mündlich mit Kollegen zu diskutieren, was jemand tut. Wenn nur alle glücklich wären. Aber es sieht ein bisschen utopisch aus, oder?

Dieses Prinzip legt nahe, dass es beim Aufbau des Entwicklungsprozesses von irgendetwas wichtig ist, sich daran zu erinnern, warum es für wen und zu welchem ​​Zweck getan wird. Es macht wenig Sinn, einen Prozess zum Wohle des Prozesses selbst zu erstellen. Weil die Arbeit letztendlich von Menschen erledigt wird, von Ihnen und mir. Was wird passieren, wenn der ganze Funke, das ganze Interesse an unseren Augen durch die Aufgabe im Yutrek oder die Fehler im Jir ersetzt wird? Es ist wertlos für einen gut organisierten Prozess, der vollständige Sicherheit vor dem Kunden bietet, aber keine echten Entwicklungsprobleme löst. Bürokratische (formale) Details können leicht zum Verlust von Personen in einem Projekt führen. Ich denke eher, dass dies auch für die Planung gilt. Wann haben Sie das letzte Mal geplant, was sich am Ende als mindestens 60-70 Prozent herausstellte?

Meiner Meinung nach könnte dieses Prinzip des Manifests so klingen:

Prozesse für Menschen, nicht Menschen für Prozesse

Wie schlägt das Manifest vor, dass wir der Umsetzung dieses Prinzips näher kommen?

• Motivierte Fachkräfte sollten an dem Projekt arbeiten.
• Direkte Kommunikation ist am praktischsten und effektivsten.
• Die besten Anforderungen und architektonischen Lösungen kommen von selbstorganisierenden Teams.
• Das Team muss seine Arbeit ständig analysieren und den Prozess optimieren.

Was entwickelt das Team im Allgemeinen? Produkt für den Kunden.

Ein funktionierendes Produkt ist wichtiger als eine umfassende Dokumentation

Wenn es so interpretiert wird, denke ich, dass viele zustimmen werden. Aber was sehen Sie hier noch? Persönlich sehe ich hier, dass ein Produkt, das funktioniert und pünktlich funktioniert, wichtiger ist als perfekt geschriebener Code. Dies sind in vielerlei Hinsicht grausame und beängstigende Worte, daher sollte ich das nicht sagen. Aber während meiner gesamten Karriere, als ich von verschiedenen Menschen lernte, wurde ich immer mehr von dem Gedanken überzeugt - wenn ich zwischen einem Projekt wähle, das in Bezug auf Code und Architektur ideal ist, und einem Projekt, das innen nicht sehr schön ist, aber der Welt zugute kommt, werde ich das zweite wählen. Und ja, ich werde es nach besten Kräften verbessern.

Und hier sollten Sie einen Moment nachdenken. Aber was kann getan werden, um diese Probleme weniger häufig zu machen? Damit wir uns nicht zwischen der Umgestaltung eines Moduls und der Entwicklung einer neuen Funktion entscheiden müssen?

• Ein funktionierendes Produkt sollte so oft wie möglich freigegeben werden.
• Ein funktionierendes Produkt ist ein Schlüsselindikator für den Fortschritt.
• Die kontinuierliche Beachtung von technischer Exzellenz und Qualität erhöht die Flexibilität des Projekts.
• Einfachheit und Minimierung sind notwendig.

Achten Sie auf den Punkt über technische Exzellenz. Wenn wir den Code in guter (notwendiger) und ausreichender Qualität halten, können wir Änderungen der Anforderungen und dementsprechend Änderungen des Codes viel leichter tolerieren.

Ich erinnere Sie daran, dass alle Prinzipien keine Negative sind. Das eine schließt das andere nicht aus. Hier geht es um Priorisierung. Alles ist wichtig - das Produkt, die Qualität des Codes und die Dokumentation. Aber was soll man wählen, wann soll man wählen? Wenn das Produkt in einem gewissen Gleichgewicht zwischen Qualität und Produkt arbeitet, ist es einfacher, Priorität einzuräumen, ohne die Qualität zu leugnen.

Als Beispiel aus meinem Leben erinnere ich mich an die Arbeit an einem Bankprojekt für einen russischen Kunden. Die Arbeiten wurden unter Beteiligung von Analysten und ausschließlich zur volumetrischen TK durchgeführt. Einmal alle sechs Monate ging der Manager in die Zentrale des Kunden und zeigte die Ergebnisse der Arbeit. Es ist leicht zu erraten, dass die Ergebnisse in der Regel erheblich von den Erwartungen des Kunden abwichen. Der Buchhalter des Kunden, der das neue System zum ersten Mal sah und allgemein wusste, dass es erstellt wurde, war entsetzt - es gab nichts Vergleichbares zu seinem üblichen Arbeitsprozess im neuen System. Das bringt uns zum nächsten Thema.

Die Zusammenarbeit mit dem Kunden ist wichtiger als die Aushandlung von Vertragsbedingungen

Sie müssen mit dieser Aussage sehr vorsichtig sein. Denken Sie auch hier daran, dass die rechte Seite der Aussage nicht geleugnet wird. Im Gegenteil, wir sagen, dass der Vertrag wichtig ist. Nur wenn wir die Vertragsbedingungen und die Zusammenarbeit, die richtigen langfristigen Partnerschaften, abwägen, wird die Beziehung wichtiger. Ohne den zweiten zu leugnen. Ich mache darauf aufmerksam, weil wir in der realen Welt leben und manchmal mit sehr unterschiedlichen Kunden arbeiten müssen. Es gibt Fälle, in denen der Kunde für seine eigenen egoistischen Zwecke die Naivität ausnutzen und auf Kosten des Vertrags Bedingungen ausschließen kann, die für Entwickler nicht akzeptabel sind.

Wenn wir jedoch in einem Vakuum über einen bestimmten abstrakten guten Kunden sprechen, ist es wichtiger, eine langfristige Beziehung aufrechtzuerhalten, die zu neuen Projekten führt.

Wie kann das Verständnis und die Einhaltung der Erwartungen während des gesamten Projekts erreicht werden?

• Während des gesamten Projekts müssen Entwickler und Vertreter des Custom Business täglich zusammenarbeiten.
• Direkte Kommunikation ist am praktischsten und effektivsten.

Gleichzeitig sollte man auf keinen Fall vergessen, die Vereinbarungen zu ihrer eigenen Sicherheit zu bestätigen. Es gibt übrigens (zum Glück selten) Kunden, die sich generell weigern, nach den Vereinbarungen zu zahlen.

Unabhängig vom Kunden ist die Aktivität des Entwicklers immer nützlich.
Ich würde auch alleine hinzufügen, dass dies in beide Richtungen funktionieren sollte.

Dies führt uns zu einer logischen Fortsetzung - Änderungen in Arbeit und Plänen. Nur wenige Menschen nehmen gerne Änderungen vor, es liegt in der Natur des Menschen, wenn Sie darüber nachdenken. Jedes System strebt einen bestimmten Punkt des Gleichgewichts und der Unveränderlichkeit an. Aber es ist Entwicklung, die immer mit Bewegung und Veränderung verbunden ist.

Die Bereitschaft zur Veränderung ist wichtiger als die Befolgung des ursprünglichen Plans.

Die Existenz eines Plans als solcher wird nicht geleugnet. Im Gegenteil, der Plan ist wichtig. Umso wichtiger ist es, darauf vorbereitet zu sein, wenn wir irgendwann feststellen, dass dieser Plan in der aktuellen Umgebung nicht mehr funktioniert.

Ein Beispiel aus der Praxis meiner Kollegen ist ein Projekt zur Steuerinspektion eines der GUS-Länder. Das staatliche Projekt, im Wesentlichen TK, Gesetzgebung, es gab keine Rede von Agilität. Das Team musste jedoch in dem Moment Flexibilität zeigen, in dem der Staat im Land des Kunden seine Steuergesetzgebung so änderte, dass das Projekt in der geplanten Form überhaupt keinen Sinn ergab. Ich musste die technischen Spezifikationen ändern und das fast abgeschlossene Projekt wiederholen, damit der Kunde es verwenden konnte. Andernfalls hätte die Arbeit keinen Sinn, außer vielleicht für das Einkommen als solches.

Vielleicht ist dies nicht das aufschlussreichste Beispiel, da die Änderungen durch externe Faktoren hervorgerufen wurden. Andererseits kann der Kunde aufgrund externer Faktoren einfach auf die Notwendigkeit kommen, die Anforderungen zu ändern. Andernfalls erhält er keinen Wettbewerbsvorteil.

Dies alles berührt ein etwas schmerzhaftes Thema für mich. Aber was ist, wenn wir ein Projekt für ein ganzes Jahr durchführen und dann ein Jahr später der Kunde sagt: Okay, Sie sind großartig, und jetzt werden wir all dies in das Archiv aufnehmen, wir werden es nicht verwenden und wir werden ein neues Projekt starten. Ich bin ziemlich schmerzhaft, ich hatte eine ähnliche Erfahrung. Aber wirklich - was ist passiert? Die geleistete Arbeit half dem Kunden zu verstehen, dass der gewählte Pfad falsch ist. Oder unwirksam. Um einen Wettbewerbsvorteil zu erzielen, müssen Sie anders arbeiten und ein anderes Projekt durchführen. Und dieses Wissen hat er mit unserer Hilfe erhalten.

Welche Aspekte unserer Arbeit werden dazu beitragen, diese Ecken zu glätten und die Flexibilität weniger erschreckend zu machen?

• Regelmäßige und frühzeitige Softwarebereitstellung.
• Änderungen sind auch in späteren Phasen willkommen.
• Änderungen verschaffen dem Kunden einen Wettbewerbsvorteil.

Gleichzeitig leben wir in der realen Welt mit realen Menschen, in denen kein Urteil, einschließlich dieses, zum Absoluten erhoben werden sollte. Ja, Änderungen sind willkommen, wenn sie zu einem Mehrwert für das Endprodukt führen. Es ist jedoch wichtig, das Gleichgewicht zu halten. Wenn wir endlos Änderungen vornehmen, werden wir niemals ein Produkt in der Produktion veröffentlichen. Daher sollten Sie irgendwann sagen: Stoppen Sie, wir veröffentlichen das Produkt, überprüfen alles in der Praxis und beginnen mit der Erstellung der zweiten Version, die diese Änderungen enthält. Jedes Mal mit dem Kunden klären - welchen Wert er in dieser oder jener Änderung sieht.

Ich habe kürzlich den Satz auf Facebook gelesen.

Wenn Sie sich für Ihr Produkt nicht schämen, sind Sie zu spät auf den Markt gekommen

Ganz genau spiegelt das Wesentliche des oben Gesagten wider. Wir müssen nach einem bestimmten Gleichgewichtspunkt suchen, an dem das Produkt in Bezug auf Änderungen für die nächste Version bereit ist und an dem wir noch nicht allzu viel Aufwand für geringfügige Änderungen betreiben.

Anstatt zusammenzufassen

Die Schöpfer des Agilen Manifests schreiben keine Regeln vor und auch nicht umgekehrt. Sie werfen jedoch wichtige Fragen in unserer Arbeit auf - das Zusammenspiel von Menschen, Entwicklern und Kunden, die Bereitschaft zur Veränderung. Diese Prinzipien sind von Natur aus wichtig. Angesichts der unbestreitbaren Bedeutung von Dokumentation, Verträgen, Prozessen und Planung sind die menschliche Interaktion, die Bereitschaft zu wertvollen Veränderungen und die Bereitstellung von etwas Nützlichem für die Welt umso wichtiger.