it-swarm-eu.dev

Agil für den Solo-Entwickler

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

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

Ich erinnere mich, dass ich eine These über Cowboy-Entwicklung gelesen habe, die für Solo-Entwickler unerlässlich ist, aber ich kann mich nicht erinnern, wo ich sie gefunden habe.

66

Nach der Antwort von Klez (alle guten Vorschläge) würde ich Folgendes vorschlagen:

  • Produktstau beibehalten
    Ein Product Backlog ist im Grunde eine Liste aller Elemente, die Sie zu einem bestimmten Zeitpunkt für dieses Produkt ausführen möchten.
  • Aufrechterhaltung eines Sprint-Burndowns und eines Produkt-Burndowns
    Ein Sprint-Burndown beginnt mit einer Liste aller Aufgaben, die Sie in diesem Sprint ausführen möchten (eine Teilmenge Ihres Produkt-Backlogs, die über einen festgelegten Zeitraum abgeschlossen werden soll - z. B. 2 Wochen), zusammen mit der Schätzung von die Arbeit erforderlich. Wenn Sie Dinge markieren, markieren Sie sie als erledigt. Dadurch wird die verbleibende Arbeit für diesen Sprint reduziert (oder abgebrannt).
    In ähnlicher Weise verfolgt ein Produkt-Burndown die verbleibende Arbeit für den gesamten Produktstau
  • Übernahme 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 etwa doppelt so komplex wie Aufgabe C ist, stellen Sie sicher, dass die "Punkte" für Aufgabe A im Verhältnis zu diesen Erwartungen korrekt sind.
    Der Schwerpunkt liegt nicht darauf, den Arbeitsaufwand richtig zu erraten, sondern die Schätzungen miteinander in Einklang zu bringen.
    Die Geschwindigkeit ist ein Maß dafür, wie viele "Punkte" Sie in einem Sprint erzielen. Wenn Ihre relative Schätzung Konsistenz gewährleistet, kann diese Geschwindigkeit verwendet werden, um zu schätzen, welche Aufgaben Sie in den kommenden Sprints wahrscheinlich erledigen werden. Beachten Sie jedoch, dass die Geschwindigkeit ständig geändert werden sollte.
39
Damovisa
  • Begrenzen Sie die laufenden Arbeiten (zusätzlich zum Zeitboxen). Selbst wenn Sie eine iterative Methode verwenden (im Gegensatz zu Kanban), nehmen wir an, dass Ihre Geschwindigkeit 8 Punkte pro Iteration beträgt. Arbeiten Sie nicht an allen 8 gleichzeitig. Es ist in Ordnung, WIP entweder durch die Anzahl der Storys oder durch Story-Punkte zu begrenzen.
  • Lassen Sie automatisierte Abnahmetests für alle Ihre User Stories durchführen. Automatisieren Sie so viel wie möglich im Allgemeinen.
  • Err auf der Seite, User Stories zu klein zu machen. Als Faustregel gilt, dass das Verhältnis der größten zur kleinsten Geschichte 3: 1 beträgt. Wenn Sie eine Story in Scrum unterschätzen und sie sich als zu groß herausstellt, können mehrere Entwickler sie schwärmen, um sie wieder in Gang zu bringen. Aber du hast nicht genug Leute.
  • Wenn Sie in einem Teamkontext mit normaler Größe zögern würden, einen Spike von einer User Story zu trennen, führen Sie den Spike im Einzel- oder Kleinteamkontext ohne zu zögern aus. Dies hilft, Geschichten kleiner und vorhersehbarer zu halten.
  • Rückblicke sind für Agile im Allgemeinen wichtig, daher erhält Kanban (das wäre Personal Kanban) hier zusätzliche Punkte, da sein Rückblickprozess datengesteuerter ist. Es ist schwer, Triple Nickels zu spielen, wenn man nicht genug Leute hat.

Diese Dinge gelten wahrscheinlich sowohl für Solo-Situationen als auch für Situationen mit kleinen 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

21
azheglov
  • Arbeiten Sie entweder an genau definierten Sprints oder wählen Sie bewusst einen Kanban-Ansatz. Nicht versehentlich in Kanban landen
  • Fehler zuerst, Funktionen zweitens.
  • Konzentrieren Sie sich weiterhin auf Value vs. Feature Bloat. (YAGNI über Vergoldung)
  • Retrospektiven sind ebenso wertvoll. Und genauso wichtig ist es, Prozessänderungen in kleinen Stücken vorzunehmen. Entscheiden Sie nicht, dass Sie heute auf einmal TDD, Mock und IoC starten, es sei denn, Sie haben wirklich keine externen Funktionen für die Bereitstellung von Geldautomaten. Bringen Sie einen nach dem anderen herein.

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

9
MIA

Agile funktioniert für Einzelpersonen genauso gut wie für Teams. Es geht darum, einen Prozess zu finden, der für Sie funktioniert, und es Ihnen zu ermöglichen, sich an veränderte Umstände anzupassen, sobald Ihr Projekt bereits gestartet wurde. Es geht auch darum, Ihren Kunden regelmäßig einen Mehrwert zu bieten, unabhängig davon, ob die Software tatsächlich "fertig" ist oder nicht.

Agile Prozesse sind sehr iterativ. Die Arbeit erfolgt in kurzen TimeBoxen/Sprints/Zyklen/Iterationen. Einige Entwurfsarbeiten sind möglicherweise im Vorfeld erforderlich, können jedoch überarbeitet werden, wenn Sie mehr darüber erfahren, wozu Sie ein System benötigen. Unit-Tests sind das Rückgrat fast aller agilen Entwicklungsmethoden und geben Ihnen einen Hinweis darauf, 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 erstellen und alle Tests häufig ausführen und wenn Sie am Ende jedes Sprints Arbeitscode liefern , du bist schon agil.

3
S.Robins

Beeindruckend. Ich würde versuchen, einen Freund am Haken zu halten, den ich anrufen konnte, wenn ich in Schwierigkeiten war - und über das Codierungsproblem sprechen. Sie wissen, was ich meine ... nur das laute Erklären eines Problems bringt in 90% der Fälle eine Lösung für my mind.

1
codeyoung