Vergoldete Software
Das erste Mal, dass ich eine Vergoldung als Beschreibung für Software sah, war in einem Artikel von Barry Boehm, in dem er die folgende Ursache anführte:
Vergoldung. Feste Anforderungsspezifikationen im Vorfeld des Designs trugen tendenziell zur Vergoldung der Software bei. Benutzer, die nach ihren Anforderungen gefragt wurden, stellten häufig die Frage: „Ich weiß nicht, ob ich diese Funktion benötige oder nicht, aber ich kann sie auch für alle Fälle angeben.“
In seiner Beschreibung empfiehlt er die Verwendung von Methoden, die in seiner Forschung beschrieben wurden, einschließlich des Spiral-Software-Lebenszyklusmodells, in dem Projekte darauf abzielten, eine Reihe von Prototypen pro Zyklus zu erstellen, und mit zunehmender Spirale ein Produkt mit allen Funktionen. Spirale hatte weit verbreiteten Einfluss unter Software-Forschern und war eine wichtige Brücke zwischen Wasserfall und Agile. Eine kritische Einschränkung der Spirale ist, dass jedes Mal, wenn die Spirale umrundet wird, die Zyklen länger und teurer werden.
Wie bei Agile versucht Spiral, die Vergoldung zu vermeiden, indem der Zeitrahmen enger gefasst und das Projekt so lange terminiert wird, dass die Teams die Anforderungen erfüllen können. Gleichzeitig ist es kurz genug, um sich vom ersten Tag bis zum Liefertag auf das Ziel konzentrieren zu können. Eine Möglichkeit, die Agile-Methoden wie Scrum überlegen sind, besteht darin, dass Scrum für einen Zeitraum sprintet, der mit Iterationen nicht länger wird. Dem Papier zufolge scheint das Projektmanagement mehr Einfluss auf die Vergoldung zu haben als einzelne Entwickler.
Talent für Time Boxing
Es ist sehr wichtig, in der Lage zu sein, Zeit zu setzen, aber es ist keine binäre Fähigkeit. Sie haben es nicht oder es fehlt. Sie sind besser oder weniger gut damit. Egal, ob es von Ihrem Chef oder von Ihnen kommt, ich würde es vorziehen, wenn niemand sagen würde, dass Sie die Vergoldung nicht aufhalten können. Das klingt persönlich, durchdringend und dauerhaft.
Mithilfe einer Ursachenanalyse können möglicherweise mehrere Probleme identifiziert werden. Ich bin mir ziemlich sicher, dass sie nicht alle auf Sie zeigen werden und dass andere in Ihrem Team ähnliche Bedürfnisse sehen werden, um ihre agilen Fähigkeiten zu verbessern, es sei denn, Sie arbeiten mit Psychopathen. Wenn Sie jemanden ohne Probleme kennen, kennen Sie ihn nicht sehr gut. Wenn Sie jemanden kennen, der denkt, er müsse sich nicht verbessern, kennt er sich selbst nicht sehr gut.
Ich hoffe, dass Verbesserungen, die Sie identifizieren, Dinge sind, die Sie mit Ihrem eigenen Bewusstsein und der Hilfe des Teams lösen können. Ich denke jedoch, dass das hier nicht endet. Ich erwarte vom Vorgesetzten oder Manager, der Ihre Bewertungen verfasst, dass er auch seine Untergebenen coachen kann, um erfolgreich zu sein. Dies ist besonders kritisch, wenn die Organisation einen revolutionären Wandel durchläuft, wie den Wechsel von geplant zu agil (oder ad-hoc zu agil).
Schneller und schmutziger oder riskanter Prototyp?
Ich hatte einen Manager, der immer darum gebeten hatte, dass Aufgaben auf bestimmte Weise ausgeführt werden.
Schnell und dreckig, aber eine Sache der Schönheit.
Er wusste, wie albern das war, und das gehörte zu seinem schiefen Sinn für Humor. Viele Leute sagen so etwas und meinen es todernst. Irgendwo gibt es einen Kompromiss oder eine Gelegenheit, das Problem mit einer verbesserten Technologie oder einem verbesserten Ansatz zu lösen.
Was können wir opfern, um in unsere Zeitbox zu passen?
In Kapitel eins von Extreme Programming Explained , zweite Ausgabe, spricht Kent Beck darüber, was es braucht, um sich schnell zu bewegen. Seine Antwort lautet: "Sie tun nur das, was Sie tun müssen, um Mehrwert für den Kunden zu schaffen."
Risiko
In der ersten Ausgabe desselben Buches identifiziert Beck Böhms Ansichten zur Risikokontrolle etwas genauer als kritisch für seine Methodik, indem er sagt:
"Risiko ist das Grundproblem der Softwareentwicklung"
In beiden Editionen listet und beschreibt Beck acht allgemeine Risiken, gefolgt von der Behauptung, dass XP (oder vielleicht auch Agile) jede auf eine bestimmte Art und Weise anspricht. Für mich läuft die meiste Erklärung darauf hinaus, kleinere Schritte und schnellere Iterationen zu verwenden, damit wir die Dinge wieder auf Kurs bringen können, bevor die Risiken zu groß werden, um sie in den Griff zu bekommen.
Mentalität der Suffizienz
Beck diskutiert Ressourcen im Kontext einer Geschichte über die Berg- und Waldbevölkerung und stellt ein Konzept vor, das sich "Mentalität der Suffizienz" nennt. Im Kontext Ihrer Situation fragt er: "Wie würden Sie es tun, wenn Sie genug Zeit hätten?" Nur dieses eine erste Kapitel, das als Buchvorschau verfügbar ist, kann eine Menge Anlass zum Nachdenken darüber geben, wie XP (und andere agile Methoden) Einschränkungen wie die Zeit berücksichtigen.
Zwang könnte das Symptom sein, nicht die Krankheit
Vor Jahren habe ich mir ein Buch über Aufschub angesehen, in dem festgestellt wurde, dass viel Aufschub aus Angst herrührt. Wenn Sie nicht anfangen, machen Sie keinen Fehler und werden möglicherweise nicht kritisiert. Zwang und Perfektionismus geben etwas, von dem unser moralischer Sinn sagt, dass es besser ist als Aufschub, aber wahrscheinlich das gleiche Ergebnis hat. Denken Sie daran, dass Sie vielleicht ein Problem mit dem Aufschieben in einer anderen Form haben?
Kritik und Wettbewerb
In agilen Methoden wie Scrum waren die Chancen, wegen Aufschubs kritisiert oder bestraft zu werden, nie höher. Das ist ein Teufelskreis. Ich zögere, weil ich kritisiert werde, ich werde kritisiert, weil ich zögere. Bei täglichen Scrum-Meetings sind wir immer in Alarmbereitschaft, da wir immer einen Tag oder weniger Zeit haben, dem Team zu berichten, was wir erreicht haben.
In einem idealen Team bietet Scrum täglich die Möglichkeit, den Aufschub zu korrigieren. Fehler sollten keine Zeit haben, groß zu werden, bevor Hilfe eintrifft. Teams sind nicht immer dort, wo sie vertrauensvoll sein sollten. Daher müssen Führungskräfte im Team möglicherweise Kritik oder Angst vor Kritik proaktiv angehen, um Fortschritte zu erzielen.
In unserer Arbeitswelt muss sich jede Person in einem Team auch mit anderen messen. Es ist ein bisschen schizophren, an ein Team zu glauben, das die Arbeit und den Ruhm für Leistungen teilt, dann aber einen jährlichen Leistungsmanagementprozess anwendet, der 20% seiner Mitglieder belohnt, 10% oder mehr der Mitglieder bestraft oder ausweist, und gibt vor, dass die 70-prozentige Mehrheit ihr Bestes gibt, ohne Anreize zu setzen. Ich denke, dies ist ein großer Elefant im Raum WRT, der die Teamarbeit fördert, und um auf Kent Becks Geschichte Bezug zu nehmen, es zeigt tiefe kulturelle Verbundenheit mit dem Wesen der Bergmenschen.
Der Weg nach vorn
Als Mitglied eines agilen Teams wäre es gut, mit anderen darüber zu sprechen, was funktioniert. Wenn Ihr Team TDD verwendet, um seine Komponententests mit einem Tool zu automatisieren, lassen Sie sich von der Person coachen, die es am besten kann. Wenn Ihr Vorgesetzter oder Vorgesetzter ein Problem mit Ihrem Dokumentationsansatz hat, finden Sie heraus, was ihm gefällt oder wer es so macht, wie es ihm gefällt, und befolgen Sie deren Ansatz. Wenn es auf die reine Codierungsgeschwindigkeit ankommt, untersuchen Sie, was erforderlich ist, um schneller zu codieren.
Führungskräfte können Schritte in die richtige Richtung unternehmen, indem sie gewünschte Verhaltensweisen modellieren, z. B. offen über ihre eigenen Probleme (die von niemand anderem) sprechen, Hilfe anbieten und diese mitverfolgen und einen Dialog darüber führen, wie das Team zu einem agilen Marinestil übergehen kann (dh kein Mensch) zurück gelassen). Nicht jeder im Team hat die gleichen Fähigkeiten. Es kann angebracht sein, die Paarung von Teammitgliedern zu untersuchen oder Aufgaben und Rollen zuzuweisen, die die komplementären Stärken der beteiligten Personen hervorheben können. Die Planung des Ausbaus oder der Verbesserung von Fähigkeiten sollte sowohl für den Vorgesetzten als auch für den Untergebenen ein lohnender Teil der Arbeit sein, muss jedoch früh und häufig erfolgen, um effektiv zu sein.