Agil für den Solo-Entwickler

Wie würde jemand als Einzelentwickler agile Prozesskonzepte umsetzen? Agile scheint nützlich zu sein, um Anwendungen schneller zu entwickeln, aber es scheint auch sehr teamorientiert zu sein ...

• Durch testgetriebene Entwicklung
• Durch die Entwicklung in kleinen Sprints
• Durch viel Kontakt mit dem Kunden

Ich erinnere mich, eine These über Cowboy-Entwicklung gelesen zu haben, die für Solo-Entwickler essentiell agil ist, aber ich kann mich nicht erinnern, wo ich sie gefunden habe.

Auf die Antwort von Klez (alles gute Vorschläge) schlage ich folgendes vor:

• Aufrechterhaltung eines Produkt-Backlogs
  Ein Produkt-Backlog ist im Grunde eine Liste aller Elemente, die Sie zu einem bestimmten Zeitpunkt für dieses Produkt ausführen möchten.
• Beibehalten eines Sprint-Burndowns und eines Produkt-Burndowns
  Ein Sprint-Burndown beginnt mit einer Liste aller Aufgaben, die Sie in diesem Sprint ausgeführt haben (eine Teilmenge Ihres Produkt-Backlogs, die über einen festgelegten Zeitraum - z. B. 2 Wochen - ausgeführt werden soll) die Schätzung der erforderlichen Arbeit. Wenn Sie Dinge markieren, markieren Sie sie als erledigt. Dadurch wird die verbleibende Arbeit für diesen Sprint reduziert (oder abgebrannt).
  In ähnlicher Weise protokolliert ein Product Burndown die verbleibende Arbeit für den gesamten Product Backlog
• Anwenden der Konzepte der relativen Schätzung und Geschwindigkeit Die
  relative Schätzung ist eine Schätztechnik, die die anderen Aufgaben (oder Geschichten) als Leitfaden verwendet. Wenn Sie beispielsweise wissen, dass Aufgabe A einfacher als Aufgabe B und ungefähr doppelt so komplex wie Aufgabe C ist, stellen Sie sicher, dass die "Punkte" für Aufgabe A im Verhältnis zu diesen Erwartungen korrekt waren.
  Der Schwerpunkt liegt nicht auf der korrekten Abschätzung des erforderlichen Arbeitsaufwands, sondern darauf, die Schätzungen miteinander in Einklang zu bringen.
  Die Geschwindigkeit ist ein Maß dafür, wie viele "Punkte" Sie im Sprint erzielen. Wenn Ihre relative Schätzung für Konsistenz sorgt, können Sie anhand dieser Geschwindigkeit abschätzen, welche Aufgaben in den kommenden Sprints wahrscheinlich erledigt werden. Beachten Sie jedoch, dass diese Geschwindigkeit ständig überarbeitet werden sollte.

• Beschränken Sie die laufende Arbeit (zusätzlich zum Time-Boxing). Selbst wenn Sie eine iterative Methode verwenden (im Gegensatz zu Kanban), nehmen wir an, dass Ihre Geschwindigkeit 8 Punkte pro Iteration beträgt. Beginnen Sie nicht mit allen 8 gleichzeitig. Es ist in Ordnung, WIP entweder durch die Anzahl der Storys oder die Anzahl der Story-Punkte zu begrenzen.
• Automatische Abnahmetests für alle Ihre User Stories. Automatisieren Sie so viel wie möglich.
• Err auf der Seite, User Stories zu klein zu machen. Als Faustregel gilt, dass das Verhältnis von größter zu kleinster Story 3: 1 ist . Wenn Sie eine Story in Scrum unterschätzen und sie sich als zu umfangreich herausstellt, können mehrere Entwickler darauf zugreifen, um sie wieder auf den richtigen Weg zu bringen. Aber du hast nicht genug Leute.
• Wenn Sie in einem Team mit normaler Größe zögern, einen Spike von einer User Story abzuspalten, können Sie den Spike im Solo-Kontext oder im Small-Team-Kontext ohne zu zögern durchführen. Dies hilft, Geschichten kleiner und vorhersehbarer zu halten.
• Rückblicke sind im Allgemeinen wichtig für Agilität, daher erhält Kanban (das wäre persönliches Kanban) hier zusätzliche Punkte, da sein retrospektiver Prozess datengesteuerter ist. Es ist schwer, Triple Nickels zu spielen, wenn man nicht genug Leute hat.

Diese Dinge gelten wahrscheinlich sowohl für Einzelpersonen als auch für kleine Teams (2 oder 3 Entwickler).

HINZUGEFÜGT: Irgendwann, nachdem ich diese Antwort geschrieben hatte, fand ich diesen Konferenzvortrag und war sehr beeindruckt: Persönliches Kanban: Optimierung des individuellen Codierers

• Arbeiten Sie entweder mit genau definierten Sprints oder wählen Sie bewusst einen Kanban-Ansatz. Komme nicht aus Versehen nach Kanban
• Bugs zuerst, Features an zweiter Stelle.
• Konzentrieren Sie sich weiterhin auf Value vs. Feature Bloat. (YAGNI über Vergoldung)
• Retrospektiven sind ebenso wertvoll. Und ebenso wichtig ist es, Prozessänderungen in kleinen Stücken vorzunehmen. Entscheide dich nicht, dass du heute anfängst, TDD, Mock und IoC auf einmal zu nutzen, es sei denn, du hast wirklich keine externen Funktionen, um Geldautomaten bereitzustellen. Bringen Sie einen nach dem anderen ein.

Letztendlich definiere ich Agile wirklich als "das zu tun, was für Ihr Team und Ihre Kunden Sinn macht, und nicht an alten Praktiken festzuhalten, weil sie so aussahen, als hätten sie in der Vergangenheit gearbeitet."

Agile funktioniert für Einzelpersonen genauso gut wie für Teams. Es geht darum, einen für Sie geeigneten Prozess zu finden und Sie in die Lage zu versetzen, sich an veränderte Umstände anzupassen, sobald Ihr Projekt bereits begonnen hat. Es geht auch darum, Ihren Kunden regelmäßig einen Mehrwert zu liefern, unabhängig davon, ob die Software tatsächlich "fertig" ist oder nicht.

Agile Prozesse sind hochgradig iterativ. Die Arbeit erfolgt in kurzen TimeBoxen / Sprints / Zyklen / Iterationen. Einige Konstruktionsarbeiten sind möglicherweise im Vorfeld erforderlich, können jedoch überarbeitet werden, wenn Sie mehr darüber erfahren, was ein System tun muss. Unit-Tests sind das Rückgrat nahezu aller Agile-Entwicklungsmethoden. Sie geben Aufschluss darüber, ob Ihre Software funktioniert und ob Ergänzungen / Änderungen an Ihrer Software die vorhandene Codebasis beschädigen.

Wenn Sie sich an BDD / TDD halten, lassen Sie zu, dass sich Ihre Anforderungen mit dem Wind ändern, und können Sie Ihre Funktionsprioritäten entsprechend anpassen, wenn Sie Ihr gesamtes System aufbauen und alle Tests häufig ausführen und wenn Sie am Ende jedes Sprints Arbeitscode bereitstellen Sie sind bereits agil.

Beeindruckend. Ich würde versuchen, einen Freund am Haken zu halten, den ich anrufen kann, wenn ich in Schwierigkeiten bin - und das Codierungsproblem durchsprechen. Weißt du, was ich meine? Allein die Tatsache, dass ich ein Problem laut erkläre, bringt mir in 90% der Fälle eine Lösung in den Sinn.