Wie erklären Sie einem „agilen“ Team, dass es die von ihm geschriebene Software noch planen muss?

Diese Woche bei der Arbeit wurde ich wieder agiler . TDD, Shared Ownership, Ad-hoc-Entwicklungsmethode, bei der nie etwas anderes als ein paar User-Stories auf einer Karte geplant wurden Denken oder Sorgfalt und die architektonische Kopplung des gesamten Produktionscodes an den ersten Test, der in den letzten Monaten in den Kopf geraten ist, erreichen das Ende eines Veröffentlichungszyklus und siehe da, das Hauptmerkmal, das wir nach außen hin entwickelt haben, ist zu langsam Gebrauch, Buggy, labyrinthisch komplex und völlig unflexibel.

Während dieses Prozesses wurden "Spikes" erstellt, aber nie dokumentiert und es wurde nie ein einziger architektonischer Entwurf erstellt (es gab keinen FS, also was solls, wenn Sie nicht wissen, was Sie entwickeln, wie Sie ihn planen oder erforschen können ?) - Das Projekt ging von Paar zu Paar über, wobei sich jeder immer nur auf eine einzelne User Story konzentrierte und das Ergebnis unvermeidlich war.

Um dies zu lösen, ging ich vom Radar, ging zum (gefürchteten) Wasserfall, plante, codierte und tauschte das Paar im Grunde genommen nicht aus und versuchte so viel ich konnte, alleine zu arbeiten - wobei ich mich auf solide Architektur und Spezifikationen konzentrierte, anstatt auf Unit-Tests, die wird später kommen, sobald alles festgehalten ist. Der Code ist jetzt viel besser und ist tatsächlich vollständig verwendbar, flexibel und schnell. Bestimmte Leute scheinen es mir wirklich übel genommen zu haben, dies zu tun, und haben sich alle Mühe gegeben, meine Bemühungen (möglicherweise unbewusst) zu sabotieren, weil dies gegen den heiligen Prozess der Beweglichkeit verstößt.

Wie erklären Sie als Entwickler dem Team, dass es nicht "unagil" ist, ihre Arbeit zu planen, und wie fügen Sie die Planung in den agilen Prozess ein? (Ich spreche nicht von IPM. Ich spreche davon, mich an ein Problem zu setzen und ein End-to-End-Design zu entwerfen, in dem angegeben ist, wie ein Problem ausreichend detailliert gelöst werden sollte, damit jeder, der an dem Problem arbeitet, weiß, was Architektur und Muster, die sie verwenden sollten, und wo der neue Code in den vorhandenen Code integriert werden soll)

Ich denke (und ich werde hier vielleicht ein bisschen aus dem Häuschen sein), dass ALLE Projekte einen klassischen Wasserfall haben sollten: Die anfängliche Analyse- und Spezifikationsphase ist von wesentlicher Bedeutung. Sie müssen wissen, was Sie tun, und Sie müssen es schriftlich haben. Es ist schwierig und zeitaufwändig, die Anforderungen schriftlich festzuhalten, und es ist leicht, sie schlecht zu machen. Das ist der Grund, warum so viele es überspringen - jede Ausrede wird genügen: "Oh, wir sind agil, also müssen wir das nicht tun." Vor Agile war es einmal: "Oh, ich bin wirklich schlau und weiß, wie man das löst, also müssen wir das nicht tun." Die Wörter haben sich ein wenig geändert, aber das Lied ist im Wesentlichen das gleiche.

Das ist natürlich alles Bull: Sie müssen wissen, was Sie tun sollen - und eine Spezifikation ist das Mittel, mit dem Entwickler und Kunde kommunizieren können, was beabsichtigt ist.

Wenn Sie wissen, was Sie zu tun haben, skizzieren Sie eine Architektur. Dies ist der Teil, bei dem das Gesamtbild stimmt. Hier gibt es keine magische Lösung, keinen richtigen Weg und keine Methodik, die Ihnen hilft. Architekturen sind die SYNTHESE einer Lösung und stammen zum Teil aus inspiriertem Genie und zum Teil aus hart erarbeitetem Wissen.

Bei jedem dieser Schritte wird es eine Iteration geben: Sie finden Dinge falsch oder fehlen und können sie reparieren. Das ist Debuggen. Es ist nur getan, bevor irgendein Code geschrieben wurde.

Einige sehen diese Schritte als langweilig oder nicht erforderlich an. In der Tat sind diese beiden Schritte die wichtigsten, um ein Problem zu lösen - machen Sie diese falsch und alles, was folgt, wird falsch sein. Diese Schritte sind wie die Fundamente eines Gebäudes: Verstehen Sie sie falsch und Sie haben einen schiefen Turm von Pisa.

Sobald Sie das WAS (das ist Ihre Spezifikation) und das WIE (das ist die Architektur - das ist ein übergeordnetes Design) haben, haben Sie Aufgaben. Normalerweise viele von ihnen.

Sprengen Sie die Aufgaben, wie Sie möchten, und weisen Sie sie zu, wie Sie möchten. Verwenden Sie die Methode der Woche, die Sie mögen oder die für Sie funktioniert. Und erledigen Sie diese Aufgaben, indem Sie wissen, wohin Sie wollen und was Sie tun müssen.

Auf dem Weg dorthin gibt es falsche Pfade, Fehler, Probleme mit der Spezifikation und der Architektur. Daraus ergeben sich Dinge wie: "Nun, all diese Planungen waren damals Zeitverschwendung." Welches ist auch Stier. Es bedeutete nur, dass Sie WENIGER Fouls haben, mit denen Sie sich später befassen müssen. Wie Sie Probleme mit den High-Level-Sachen der frühen Tage finden, FIX THEM.

(Und hier ein Nebenproblem: Ich habe immer wieder die Versuchung gesehen, eine teure, schwierige oder sogar unmögliche Spezifikation zu finden. Die richtige Antwort lautet: "Ist meine Implementierung fehlerhaft oder Ist die Spezifikation defekt? "Denn wenn ein Problem durch Ändern der Spezifikation schnell und kostengünstig behoben werden kann, sollten Sie dies tun. Manchmal funktioniert dies mit einem Kunden, manchmal nicht. Aber Sie werden nicht wissen, ob Sie das tun frag nicht.)

Schließlich müssen Sie testen. Sie können TDD oder etwas anderes verwenden, aber dies ist keine Garantie dafür, dass Sie am Ende das getan haben, was Sie versprochen haben. Es hilft, aber es garantiert nicht. Sie müssen also den Abschlusstest durchführen. Das ist der Grund, warum Dinge wie Verifikation und Validierung in den meisten Ansätzen des Projektmanagements immer noch große Bedeutung haben - sei es die Entwicklung von Software oder die Herstellung von Bulldozern.

Fazit: Du brauchst das ganze langweilige Zeug. Verwenden Sie Dinge wie Agile als Hilfsmittel, aber Sie können altmodisches Denken, Spezifizieren und architektonisches Design nicht beseitigen.

[Würden Sie ernsthaft damit rechnen, ein 25-stöckiges Gebäude zu errichten, indem Sie 1000 Arbeiter vor Ort einsetzen und ihnen sagen, dass sie Teams bilden sollen, die ein paar Arbeiten erledigen sollen? Ohne Pläne. Ohne statische Berechnungen. Ohne ein Design oder eine Vision, wie das Gebäude aussehen sollte. Und nur mit dem Wissen, dass es ein Hotel ist. Nein - hätte ich nicht gedacht.]

Ich bin immer noch erstaunt, dass viele Leute denken, TDD bedeute, zuerst Komponententests zu schreiben. Nein, dies bedeutet, dass Sie Tests schreiben müssen, bevor Sie den Code schreiben. Der Test kann tatsächlich ein Unit-Test, ein Integrationstest, ein End-to-End-Test und natürlich ein Leistungstest sein (Sie werden wahrscheinlich keinen Leistungstest vor dem getesteten Code schreiben, aber das bedeutet nicht, dass Sie ihn überhaupt nicht schreiben sollten). Die erforderliche Art des Tests sollte aus der Definition für die User Story ersichtlich sein. Wenn eines der Akzeptanzkriterien für die User Story besagt, dass die Funktion bei 50 gleichzeitigen Benutzern innerhalb von 500 ms das Ergebnis liefern soll, kann die User Story erst dann als abgeschlossen betrachtet werden, wenn Sie einen Leistungstest durchgeführt haben, der nachweist, dass dieses Akzeptanzkriterium erfüllt ist. Sobald Sie den automatischen Test durchgeführt haben, können Sie jeden Tag überprüfen, ob er verstrichen ist, indem Sie weitere Funktionen hinzufügen.

Es klingt eher so, als ob Ihre Akzeptanzkriterien nicht korrekt definiert wurden und Sie Ihre Leistung daher nicht testen konnten. Es kann dennoch vorkommen, dass eine Anwendung eine schlechte Leistung erbringt, wenn Sie sie in der realen Umgebung bereitstellen und unter hoher Last verwenden. Sie kann jedoch auch immer als Ausfall von Anforderungen betrachtet werden (wenn die Anforderung nicht definiert ist, berücksichtigt der Entwickler dies bei der Arbeit nicht der Code) oder das Entwicklungsteam (unzureichende Prüfung gegen definierte Anforderungen).

Eine weitere interessante Sache ist, dass sich die Entwickler in Ihrem Team auf die Einzelbenutzer-Story konzentrieren. Bei Agile geht es um Kommunikation. Entwickler sollten daher mitteilen, welche User Stories erforderlich sind und wie sie sich auf den Rest der Anwendung auswirken - Zusammenarbeit ist ein Muss. Test sollte dies ebenfalls abdecken. Wenn ein Entwickler die erforderliche Funktionalität für eine andere User Story verletzt, sollte dies in automatisierten Tests sichtbar sein. Wenn Sie immer noch das Gefühl haben, dass dies nicht ausreicht oder nicht funktioniert, können Sie ein Architektur-Meeting einführen, bei dem das gesamte Team zusammenarbeitet und die Architektur der Anwendung diskutiert. In der Regel ist es ausreichend, ein solches Treffen einmal pro Woche abzuhalten.

Viele Dinge aus dem Wasserfallprozess werden durch Kommunikation und automatische Tests ersetzt. Niemand sagt, dass Sie keine hochwertige Dokumentation oder Design schreiben können! Sie können und viele Teams zum Beispiel Wiki dafür verwenden.

[Unser Produkt] war zu langsam im Gebrauch, war fehlerhaft, wurde labyrinthisch komplex und völlig unflexibel.

Das hat nichts mit Agilität zu tun, es ist ein Zeichen dafür, dass Programmierer ihre Arbeit nicht richtig machen.

Eine Grundidee von Agile ist, dass das Team die vollständige Kontrolle über den Prozess hat. Das heißt, sie müssen sich über den Umfang der Planung, Dokumentation, Tests und den Umgang mit Refactoring einigen. All diese Kräfte sind großartig, aber sie gehen mit Verantwortung einher, und hier ist wahrscheinlich Ihr Team gescheitert. Sie akzeptierten ihre Freiheit, vernachlässigten aber ihre Verantwortung.

Am Ende geht es nur darum, die Codequalität zu erklären und sich auf einen Weg zu einigen, um sie zu erhöhen und auf diese Weise beizubehalten. Eigentlich gelten die normalen Programmierpraktiken.

Pro-Tipp: Verwenden Sie Ihre "Definition of Done", um dies zu erzwingen. Stellen Sie sicher, dass alle einverstanden sind, und platzieren Sie es für alle sichtbar. Verwenden Sie es als strengen Pförtner, um zu entscheiden, ob eine Geschichte abgeschlossen ist oder nicht. Es ist sogar möglich, dieser Liste nicht-funktionale Anforderungen (wie Leistung) hinzuzufügen.

Ja. Ihre Teamkollegen sind Idioten. Dein Projekt hat wegen Agile gescheitert. Besser fühlen? Okay, lass uns weitermachen. : P

Ich denke, Sie und Ihr Team werden in der Lage sein, effektiver darüber zu kommunizieren, was schief gelaufen ist, wenn Sie sich weniger auf die Namen Ihrer Capital-M-Methoden als vielmehr darauf konzentrieren, warum die von Ihnen geschriebene Software so langsam und fehlerhaft war. Verwenden Sie die Begriffe " Agil" oder " Wasserfall" überhaupt nicht. Sie sind eindeutig emotional in Ihrem Büro belastet.

Agile funktioniert manchmal. Diesmal hat es für Ihr Team nicht funktioniert. Einige Leute werden sagen, das liegt daran, dass Sie Agile falsch gemacht haben. Schließlich funktioniert Agile. Wenn Sie es richtig gemacht hätten, hätte es funktioniert, richtig? Wie auch immer.

Es hört sich nicht so an, als wäre jemand anderer Meinung, dass ein Fehler aufgetreten ist, aber Sie werden beim nächsten Mal keine Freunde gewinnen, keine Menschen beeinflussen oder es besser machen, wenn Sie einer Methode die Schuld geben. Das hatte wahrscheinlich wenig mit dem zu tun, was tatsächlich schief gelaufen ist.

Konzentrieren Sie sich stattdessen darauf, die direktesten Fehlerursachen zu ermitteln, und arbeiten Sie mit dem Team zusammen, um sicherzustellen, dass sie nicht erneut auftreten. Dies erfordert menschliche Fähigkeiten.

Wenn Sie von den Fähigkeiten der Mitarbeiter sprechen, sollten Sie sich nicht wundern, dass Ihr Team es nicht zu schätzen wusste, dass Sie sie schlecht aussehen ließen, indem Sie all ihre Arbeit erledigten und es besser machten als sie. Wenn Sie dies "unter dem Radar" tun, haben Sie möglicherweise einige Beziehungen beschädigt, die Sie neu aufbauen müssen, um ein effektives Mitglied des Teams zu werden.

Ich denke, der beste Weg, um eine Situation wie diese zu betrachten, besteht darin, die langfristige Gesamtleistung des gesamten Teams zu berücksichtigen. Diesmal haben Sie vielleicht die Woche gespart, aber auf lange Sicht haben Sie es für Ihr Unternehmen vielleicht besser gemacht, indem Sie ein besseres Team aufgebaut haben .

Ich erzähle Ihnen all diese Dinge, aber ich denke, Sie kennen die meisten wahrscheinlich bereits und könnten sie jemand anderem erklären, wenn Sie dieser Situation nicht so nahe wären.

Wenn Sie Ihren Diskussionen ein markantes Zitat hinzufügen möchten, hatte Eisenhower ein gutes:

"Pläne sind nichts; Planung ist alles."

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Er meinte, dass Sie damit rechnen sollten, Ihre Pläne zu ändern, und nicht zu viel Wert in den vorhandenen Plan legen sollten, aber gleichzeitig wird der Planungsprozess Ihre Energien in entscheidender Weise scharf fokussieren. Sie müssen Pläne erstellen, bevor Sie sie testen und verfeinern können.

+1 Dies ist die beste Beschreibung von Enterprise Agile, die ich in letzter Zeit gelesen habe.

Jeder, der mit Agile zurechtkommt, weist darauf hin, dass es nie so gemeint war, aber sobald jeder in die Metriken verstrickt ist, bekommt man genau das von einem Team, das keine Leidenschaft für die Qualität des Produkts hat und von dem keiner besessen ist Testabdeckung vor allem oder Einhaltung der wöchentlichen Lieferfristen, unabhängig davon, in welche Ecke sie alle anderen versetzt haben, denn das ist alles, was wöchentlich bis zur Managementebene reicht.

Ich habe das noch nie mit weniger als einer Re-Orgel behoben gesehen. Wenn Sie ein mittelständisches Unternehmen sind, das nichts Besonderes hat, um wirklich leidenschaftliche Menschen anzulocken, kann dies nicht behoben werden, es sei denn, das nächste Management ändert manchmal die Methodik.

Agile scheint nur in Organisationen gut zu funktionieren, in denen sich das Entwicklerteam genug um ein gutes Produkt kümmert, trotz der zusätzlichen, nicht im Abspann aufgeführten Arbeit, die erforderlich ist. Tatsächlich müssen sie genug Sorge tragen, um es in ihrer eigenen Zeit gut zu machen, um Verbesserungen zu kämpfen (und bereit sein, in einigen TDD-Fällen eine Menge zusätzlicher Zeit für Wiederholungstests aufzuwenden).

Offensichtlich ist es Ihnen wichtig, ein gutes Produkt zu versenden. Offensichtlich geht es ihnen darum, eine Reihe von Drehbüchern durchzuarbeiten und einen Gehaltsscheck zu erhalten, um das durch sie verursachte Durcheinander fortlaufend zu beseitigen.

Ich würde nach weniger irritierenden Jobs suchen, egal ob agil oder nicht.

Wenn Sie sich voll und ganz mit Agilität beschäftigen, gibt es viele Orte, die noch andere Methoden anwenden. Fast alles, was zum Beispiel auf Angebot oder Vertrag steht.

Ich benutze eher eine Art Hybrid. Der Gesamtplan ist Wasserfall, aber es ist wendig in der Ausführung.

Ich vermute, wenn die Situation so schlimm ist, wie Sie sagen, verwendet Ihr Team nicht wirklich Agile, sondern ist nur faul oder undiszipliniert. Bei Agile geht es nicht darum, nicht zu planen, sondern nur darum, flexibel und agil zu sein.

Wir haben die gleichen Probleme mit einigen Mitarbeitern.

Grundsätzlich ist "Ich weiß es nicht, bis ich es schreibe" eine Lieblingsaussage. Umgekehrt haben wir gemeinsam mit dem Kunden die zu erbringenden Leistungen mit Freigabepunkten definiert. Der letzte ist "schreibe jetzt den Code um X zu machen".

Wenn wir "Schreiben von Design / Testen / Planen usw." im selben Sprint haben wie "Mache den lustigen und interessanten Code", dann passiert der erste Teil niemals ...

ABER wenn ich "platziere, kannst du keinen lustigen und interessanten Code machen, bis du gesagt hast, was du bauen willst und der Client sich abgemeldet hat", dann

• du bekommst zuerst murrende Akzeptanz und ein paar Tränen und ich musste viel dafür tun, die Lücken auszufüllen und mir zusätzliche Mühe zu machen ...
• Wenn Sie sie dann fragen, "wie war der Prozess?", ist es besser, die erste Version auf Papier zu versuchen
• dann haben Sie die Testfälle, die die Entwickler sehen können, und Sie können genau auf die Erwartung hinweisen, "was bedeutet getan".
• Dann haben Kunden, die die Entwicklung abzeichnen, eine um 80% geringere Ablehnungsrate ...
• Außerdem sehen Sie, wie alle Entwickler herumlaufen, die die Designdokumente in der Hand halten und über die Entwürfe miteinander sprechen.
• Dann erarbeiten Sie, wie Sie den Projektplan in mundgerechte Stücke aufteilen und daraus einen Prozess machen.

Der agile Teil kommt, wenn der Kunde dann vom Plan abweicht und Sie sich innerhalb eines 2-wöchigen Zyklus NICHT am Sitz Ihrer Hose vorbeifliegen und es auf dem Weg nachholen können.

In unserem Fall wurde das "Big Design Upfront" in 9 Stufen (tatsächliche Produktionsfreigaben) mit durchschnittlich 5 Teilschritten unterteilt. Die Designer und Entwickler halten Schritt miteinander, wobei die Designer 1-3 Unterschritte vor den Entwicklern sind ... zu weit und Entdeckungen in der Entwicklung brechen zu viel vom Design ab, zu eng und optimieren die Designkosten so, wie sie waren bereits "in Stein gemeißelt" in der Entwicklung implementiert. Jede Unterstufe ist 2-4 Sprints wert für 1 Entwickler.

In kleineren Projekten muss nur derselbe Entwickler zuerst entwerfen> abmelden> rechnen> entwickeln> abmelden> rechnen ... in Zyklen.

Das Problem mit der Testbenennung

Das Testen hat viele Gesichter, formal gibt es etwa 7 Kategorien von Tests mit jeweils Unterabschnitten ... eine dieser späteren ist "Write Automated Unit Tests".

Es ist ein schlechter Name, "Test First Development" zu haben, nur weil Entwickler verstehen, was "Tests" in diesem Kontext bedeuten. Sie sehen Tests als Schreiben des eigentlichen Codes für den Test gegen die Schnittstelle für die Implementierung. Wenn es überhaupt nicht wirklich so ist ... können Sie dies tun, wenn es um das Schreiben des Codes geht, aber es ist wirklich "das Design gegen Use Cases und User Stories validieren, BEVOR Sie anfangen, den Code zu schreiben" ... wenn dies richtig gemacht wird, werden viele entfernt von den Problemen, die normalerweise während der Entwicklung entdeckt werden, während es noch in der weitaus billigeren "Papier, das weggeworfen werden kann" -Version ist.

Eines der Schlüsselelemente von Agile ist die Idee der kontinuierlichen Verbesserung und die Idee, dass das gesamte Team das Projekt besitzt. Der richtige Ansatz wäre es gewesen, die Probleme mit dem Team zu überprüfen und das Team entscheiden zu lassen, wie sie behoben werden sollen.

Ein einzelnes Teammitglied, das alle Prinzipien von Agile hinter sich lässt und die Dinge auf seine Weise erledigt, kann dazu führen, dass eine kleine Menge Code gut funktioniert, aber das gesamte Projekt wird dadurch nicht wirklich positiv beeinflusst.

Eine Möglichkeit, sie zum Laufen zu bringen , besteht darin, eine T-Map zu erstellen , die Ihr gesamtes Sprint-Backlog abdeckt

Jedes Team hat einen Faden, jeder Sprint ist eine Periode. Es hängt alles zusammen (hier scheint Ihr Team umzufallen). Pin dies irgendwo und Magnete bekommen, um die Paare / Subteams darzustellen. Sie können sogar Rennen fahren. Aber jeder weiß, wo sie und die anderen Teams sind. Legen Sie hier Abhängigkeiten an, wenn es welche gibt.

Hier geht es darum, den gesamten Prozess zu vermitteln, ihn aber auch in Sprints zu zerlegen. Auch wenn dort nur der erste Sprint stattfindet und die anderen Zeiträume leer sind, sollte dies eine hervorragende Roadmap für den Abschluss des Projekts sein.

Sie haben zwei Probleme: Nicht genügend Form für die Anforderungen und schlechte Architektur.

Bedarf

Sie benötigen sowohl ein Gesamtziel als auch eine detaillierte Roadmap, um dorthin zu gelangen.

In der Welt der Wasserfälle ist das Endziel die funktionale Spezifikation, und der Fahrplan, wie man dorthin kommt, ist der Projektplan.

In der agilen Welt besteht eine Möglichkeit darin, sie in einer epischen User Story festzuhalten. Dann sind die Roadmaps die detaillierten User Stories, die das Detail des Epos ausarbeiten.

Ich war mit dieser Geschichte nie ganz zufrieden, weil die epische Geschichte nie genug Fleisch einfängt, um die ganze Idee zu vermitteln. Also, was ich tendenziell verwendet habe, ist ein Dokument mit hohen Systemanforderungen in Verbindung mit einer epischen User Story oder zwei. Danach sind die detaillierten User Stories die Roadmap.

Das Schöne an einem Systemanforderungsdokument ist, dass dann die Akzeptanzkriterien für viele User Storys herausgezogen werden können.

Stellen Sie sich das Dokument mit den hohen Systemanforderungen als "Einzelblatt" vor, das das Marketing möglicherweise verwendet, um das Produkt an einen technisch versierten Kunden zu verkaufen.

Die Architektur

Eines der Dinge, die Ihnen das "Einzelblatt" gibt, ist, dass es dem System, das Sie entwerfen, Grenzen setzt. So können Sie frühzeitig fundierte Entscheidungen über die zu verwendende Architektur treffen.

Wenn Ihr Team so ein Dokument schon früh gehabt hätte, müssten Sie sich nicht die Mühe machen, das System später neu zu entwerfen.

Ein drittes Problem ist die schlechte Kommunikation. Kommunikation ist eine Einbahnstraße (oder eine Einbahnstraße zwischen mehreren Personen). Dies ist jedoch nur ein menschliches Versagen und erfordert (manchmal) übermenschliche Anstrengungen, um es richtig zu machen.