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

50

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)


quelle
26
Der erste Absatz klingt wie ein Schimpfen gegen Agilität. Der Rest klingt immer noch ein bisschen nach Schimpfen, nur gegen den Rest Ihres Teams. Möglicherweise möchten Sie umschreiben.
1
+1 sehr daran interessiert, wie die Leute dies auf eine pragmatische Weise lösen, mit der Sie das Beste aus Wasserfall und Agilität herausholen können. Übrigens: Agilität ist nicht gleichbedeutend mit "kein Design", aber Design ist in der Regel das erste Opfer im unerbittlichen Sprintzyklus ...
Marjan Venema
5
Naja bis zu einem gewissen Grad habe ich es mit "agil" bis zum Hals gehabt. Agile scheint jeden davon abzuhalten, eine anständige Codezeile zu schreiben, und alles beginnt mit der agilen Prämisse "Wir dokumentieren nicht", die sich aus "Wir planen nicht" ergibt. Ich möchte Agilität nicht hassen, aber soweit ich das beurteilen kann, ist es im besten Fall kontraproduktiv und im schlimmsten Fall gefährlich, wenn die Leute dazu ermutigt werden, ihre Software nicht zu planen.
9
@ Marjan Venema - das ist mein Anliegen. Ich bin sicher, dass Agilität niemals "kein Design" bedeutete, wie "Nicht vorzeitig optimieren", sondern "keinen effizienten Code schreiben". Aber das scheint die Interpretation des Massenmarktes zu sein. Die Art und Weise, wie Agile Kommunikation betont, ist großartig und eine wirklich erfrischende Veränderung, aber in einer agilen Welt scheint mir die Software selbst eher ein nachträglicher Einfall zu sein.
9
Es ist offensichtlich, dass Sie mit einer schlechten Anwendung von agilen Prinzipien frustriert sind, aber dies scheint wie ein Schimpanse, der sich als Frage verkleidet. Um es klar auszudrücken: Agile bevorzugt das "Reagieren auf eine Umstellung nach einem Plan", was bedeutet, dass "während die Gegenstände auf der rechten Seite einen Wert haben, schätzen wir die Gegenstände auf der linken Seite mehr". Es ist sicherlich möglich, zu wenig Wert darauf zu legen , einem Plan zu folgen , was hier der Fall zu sein scheint.
Rein Henrichs

Antworten:

51

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.]

schnell_nun
quelle
11
+1. +10 wenn ich könnte. Wenn Sie keine gute Vorstellung davon haben, was Sie letztendlich bauen - was nur aus einer Vorentwurfsarbeit resultieren kann, selbst wenn Sie diesen Entwurf später modifizieren - dann lautet das Entwicklungsparadigma, dem Sie folgen, "throw" scheiß an die wand und schau was klebt ".
Ant
5
-1. Ich mag detaillierte Spezifikationen nicht, weil die Leute / Kunden ihre Meinung ständig ändern, was Spezifikationen und Vorentwürfe sinnlos macht, ganz zu schweigen von Verschwendung. Anstatt Zeit damit zu verschwenden, "Anforderungen zu sammeln" und so weiter, sollten Sie eine funktionierende Software erstellen, die Sie Ihrem Kunden so schnell wie möglich zeigen, damit Sie echtes Feedback für den nächsten Schritt erhalten. Anstatt Vermutungen und Spekulationen anzustellen. Was "Spezifikationen sind Kommunikationsmittel" betrifft: Ich spreche lieber mit meinen Kunden und arbeite iterativ, aber hey, jeder für sich, denke ich.
Martin Wickman
6
+1. +10 wenn ich +1 könnte. Ich bin total verrückt nach der Gebäudesoftware, weil es einfach so ist, als würde man eine Gebäude-Analogie erstellen. Ja, Software ist nicht physisch, ja, richtig gemacht, sie kann sehr modular und entkoppelt sein. Es ist jedoch sehr schwierig, es in hohem Maße modular und entkoppelt zu gestalten. Das kostet Zeit und Planung. Mir ist klar geworden, dass es in der Softwareentwicklung immer zwei Lager geben wird: diejenigen, die Planung für eine Zeitverschwendung halten, und diejenigen, die dies nicht tun. Und du weißt, ich habe auch gemerkt, dass die Leute nicht das Lager wechseln, na ja nicht wirklich. Ich habe in einer stark geplanten Umgebung gearbeitet und ...
6
Ich stimme dir zu, aber was du beschreibst, IST wirklich agil. Agile sagt "no big design up-front", nicht "no design". Dies wurde als Reaktion auf riesige starre Mega-Enterprise-Wasserfall-Monsterprojekte aus früheren Zeiten gesagt. Nicht als Ausrede, keine gute Architektur für Ihren Code zu entwerfen und zu finden. Der Punkt ist, Wochen oder Monate nicht damit zu verbringen, ALLES zu entwerfen, bevor Sie mit dem Codieren beginnen, da das Design falsch ist. Je weiter Sie es bemerken und korrigieren, desto besser. Erhalten Sie schnelles Feedback, wiederholen, verbessern usw.
Sara
5
Kai - Ich sehe Agile als eine Ausrede, keine Spezifikation zu machen, keine Planung, nur einzutauchen. Und das ist einfach falsch.
quick_now
36

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.

Ladislav Mrnka
quelle
7
+1 ausgezeichnete Antwort. Die Geschichte ist das Ziel - es ist die Spitze des Eisbergs, ein Platzhalter für ein zukünftiges Gespräch, der erste Schritt auf dem Weg; es ist nicht die ganze reise! Die Testbeschreibungen sind die Anforderungen, Anwendungsfälle und Akzeptanzkriterien kombiniert. Design wird nicht ignoriert, Design beschränkt sich auf die Story und die Tests, macht aber so viel Design, wie Sie brauchen . Wer das Design überspringt und behauptet, das sei der agile Weg, versteht es entweder nicht (lies das XP-Buch noch einmal), will es nicht (Cowbow-Coding yee-haw!) Oder ist einfach nur faul . Und Agile einen schlechten Namen geben.
Steven A. Lowe
16

[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.

Martin Wickman
quelle
1
"Sie haben ihre Freiheit akzeptiert, aber ihre Verantwortung vernachlässigt." Vielleicht sollte ein Banner an der Wand hängen. "Haben Sie Ihre Verantwortung zusammen mit Ihrer Freiheit akzeptiert?"
Andy Dent
Gute Antwort, darf ich vorschlagen, hinzuzufügen, dass das DoD, wenn Sie es auf diese Weise als Vertrag verwenden, auch im Nachhinein eine zentrale Rolle spielt? Wie hat uns dieses DoD geholfen oder gehindert, einen Mehrwert für unsere Kunden zu schaffen?
Graham Lee
11

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.

PeterAllenWebb
quelle
9

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.

jhocking
quelle
9

+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.

Rechnung
quelle
1
Das ist eigentlich die schlechteste Definition von Agilität, die ich gelesen habe. Entwickler müssen keine zusätzlichen und nicht im Abspann aufgeführten Arbeiten ausführen. Auch arbeiten nur Idioten in ihrer eigenen Zeit. Die für das Testen des Codes aufgewendete Zeit ist gut investierte Zeit.
BЈовић
Konnte nicht mehr zustimmen, Agile, wenn in das Biest verwandelt, dass es oft auf Unternehmensebene von Bürokratie wird, ist das schlimmstmögliche Agile. In einer Umgebung ohne Unternehmen mit anderen Bandfarben würde das Team diese Dinge entweder als Storys oder vor dem Festlegen von Storys ausführen. Wenn Agile zu einem Indikator für Unternehmenskennzahlen wird, ist Flexibilität in der Regel das erste, was Sie tun müssen.
Bill
4

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.

Richard
quelle
Ich neige dazu, das auch zu denken. Ich bin mir sicher, dass es bei Real Agile nicht darum geht, nichts zu planen, sondern dass dies nur eine Interpretation davon ist.
Es gibt eine Welt voller Unterschiede zwischen Groß- und Kleinschreibung und Agilität.
Aaronaught
Pssst ... sag den agilen Leuten das nicht, denn so machen es fast alle Wasserfall-Leute, weil es funktioniert. Sie glauben immer noch, dass ALLE Wasserfallentwickler monolithische Dokumente erstellen, ohne bis zum Ende Code zu schreiben, und bei jedem Schritt ist alles falsch, weil es keine Implementierung gibt.
Dunk
4

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.

Robin Vessey
quelle
3

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.

Dave
quelle
Klingt für mich so, als ob die Weiterentwicklung des Projekts genau das war, was es getan hat. "Rückblick mit dem Team" ist eigentlich keine Lösung, es ist nur ein Weg, die Lösung zu verschieben und die Verantwortung zu verteilen.
Aaronaught
Das Team ist bereits für das Ergebnis verantwortlich. Was sie brauchen, ist, dass jemand sagt: "Wir sind durcheinander, wie ändern wir unsere Methodik?" Dann reparieren sie es.
Dave
2
Ich habe den Eindruck, dass dieses spezielle Team seine Mitglieder dazu bringen muss, selbst zu denken, anstatt blind einem Prozess zu folgen, den sie nicht verstehen. Sprechen bringt nichts, wenn es sich bereits um eine Echokammer handelt.
Aaronaught
2

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

T-Karte

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.

Pureferret
quelle
1

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.

Peter K.
quelle