Agile für die Solo-Entwickler

Question

Wie würde jemand Agile-Prozess-Konzepte als solo-Entwickler?Agile scheint nützlich für erste Anwendungen entwickelt und in einem schnelleren Tempo, aber es scheint auch sehr team-orientiert...

Answer 1

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

Ich erinnere mich, dass ich eine These über Cowboyentwicklung gelesen habe, das für Solo -Entwickler wesentlich agil ist, aber ich kann mich nicht erinnern, wo ich sie gefunden habe.

Answer 2

Weiter, um die Antwort von klez - (alle gute Vorschläge), ich würde vorschlagen, die folgenden:

• Halten Sie ein product backlog
  Ein product backlog ist im Grunde eine Liste aller Elemente, die Sie wollen zu vervollständigen irgendwann für dieses Produkt.
• Die Aufrechterhaltung eines sprint burndown und ein Produkt burndown
  Ein sprint-burndown-beginnt mit einer Liste aller Aufgaben, die Sie sich entschieden haben, in dieser sprint (eine Teilmenge der product backlog abgeschlossen werden, die über einen festgelegten Zeitraum - z.B.2 Wochen) zusammen mit der Schätzung der erforderlichen arbeiten.Als Sie mark die Dinge aus, die Sie markieren Sie Sie als erledigt;damit reduzieren (oder brennt), die verbleibenden Arbeit für den sprint.
  Ebenso ein Produkt burndown-tracks die verbleibenden Arbeit für die ganze Produkt-backlog
• Die Annahme der Begriffe der relativen Einschätzung und Geschwindigkeit
  Relative Schätzung ist eine Schätzung Technik verwendet, die die anderen Aufgaben (oder Geschichten) als Leitfaden.Zum Beispiel, wenn Sie wissen, Eine Aufgabe ist einfacher als Aufgabe B und etwa doppelt so Komplex wie die Aufgabe C sind, möchten Sie sicherstellen, dass die "Punkte" für die Aufgabe Ein richtig waren im Verhältnis zu den Erwartungen.
  Die Betonung liegt nicht darauf, richtig zu raten, die Menge der Arbeit erforderlich, aber halten Schätzungen im Einklang mit jeder andere.
  Geschwindigkeit ist ein Maß dafür, wie viele "Punkte" Sie erledigen in einem sprint.Wenn Ihre relativen Einschätzung ist die Gewährleistung von Kohärenz, diese Geschwindigkeit kann verwendet werden, um abzuschätzen, welche Aufgaben, die Sie wahrscheinlich zu tun bekommen in der kommenden sprints.Beachten Sie aber, dass die Geschwindigkeit sollte werden ständig überarbeitet.

Answer 3

• Begrenzen Sie die Arbeit in Arbeit (Zusätzlich zum Zeitboxing). Selbst wenn Sie eine iterative Methode verwenden (im Gegensatz zu Kanban), sagen wir an, Ihre Geschwindigkeit beträgt 8 Punkte pro Iteration. Fangen Sie nicht an, an allen 8 gleichzeitig zu arbeiten. Das WIP durch die Anzahl der Geschichten oder die Story -Punkte zu begrenzen ist in Ordnung.
• Haben Sie automatisierte Akzeptanztests für alle Ihre Benutzergeschichten. Automatisieren Sie so viel wie möglich im Allgemeinen.
• Irren Sie sich auf der Seite, wenn Sie Benutzergeschichten zu klein machen. Machen Sie als Faustregel die Verhältnis der größten zur kleinsten Geschichte 3: 1. Wenn Sie eine Geschichte in Scrum unterschätzen und sich zu groß herausstellen, können mehrere Entwickler sie schwärmen, um sie wieder auf den richtigen Weg zu bringen. Aber du hast nicht genug Leute.
• Wenn Sie im Kontext regulärer Teams zögern würden, ob Sie einen Spike von einer Benutzergeschichte teilen möchten-im Solo- oder Kleinmannschaftskontext, ohne zu zögern die Spike. Dies hilft, Geschichten kleiner und vorhersehbarer zu halten.
• Retrospektiven sind im Allgemeinen in Agile wichtig, sodass Kanban (das persönliche Kanban) hier zusätzliche Punkte erzielt, da sein retrospektiver Prozess datenbetrieben ist. Es ist schwer, dreifache Nickel zu spielen, wenn Sie nicht genug Leute haben.

Diese Dinge gelten wahrscheinlich sowohl für Solo- als auch für Kleinmannschaft (2 oder 3 Entwickler) Situationen.

Hinzugefügt: Schließlich, nachdem ich diese Antwort geschrieben hatte, fand ich dieses Konferenzgespräch und war sehr beeindruckt: Personal Kanban: Optimierung des einzelnen Coders

Answer 4

• Arbeiten Sie entweder an gut definierten Sprints oder wählen Sie absichtlich einen Kanban -Ansatz. Enden nicht versehentlich in Kanban
• Bugs zuerst, zeigt zweitens.
• Konzentrieren Sie sich noch auf Value vs. Feature Bloat. (Yagni über Goldbeschichtung)
• Retrospektiven sind genauso wertvoll. Und genauso wichtig, führen Sie Prozessänderungen in kleinen Stücken vor. Entscheiden Sie nicht, dass Sie heute anfangen, TDD, Mock und IOC in einer Aufnahme zu gehen, es sei denn, Sie haben wirklich keine externen Funktionen, um Geldautomaten zu liefern. Bring eins nach dem anderen ein.

Letztendlich definiere ich Agile wirklich als "das zu tun, was für Ihr Team und Kunden sinnvoll ist und nicht an alten Praktiken festhält, weil sie zufällig so aussehen, als hätten sie in der Vergangenheit gearbeitet."

Answer 5

Agile funktioniert genauso gut für Einzelpersonen wie für Teams. Es geht darum, einen Prozess zu finden, der für Sie funktioniert, und Sie können sich an sich ändernde Umstände anpassen, sobald Ihr Projekt bereits gestartet wurde. Es geht auch darum, Ihrem Kunden regelmäßig Wert zu bieten, unabhängig davon, ob die Software tatsächlich "fertig" ist oder nicht.

Agile Prozesse sind stark iterativ. Die Arbeiten erfolgen in kurzen Zeitboxen/Sprints/Zyklen/Iterationen. Einige Entwurfsarbeiten können im Voraus erforderlich sein, können jedoch überarbeitet werden, wenn Sie mehr darüber erfahren, was Sie für ein System benötigen. Unit -Tests sind das Rückgrat nahezu aller agilen Entwicklungsmethoden und geben Ihnen einen Hinweis darauf, ob Ihre Software funktioniert und ob Ergänzungen/Änderungen an Ihrer Software die vorhandene Codebasis durchbrechen.

Wenn Sie sich an BDD/TDD einhalten, lassen Sie Ihre Anforderungen mit dem Wind ändern und können Ihre Funktionsprioritäten entsprechend anpassen. Wenn Sie Ihr gesamtes System erstellen und alle Tests häufig ausführen und am Ende jedes Sprint Arbeitscode liefern , du bist schon agil.

Answer 6

Wow. Ich würde versuchen, einen Freund am Haken zu halten, den ich anrufen konnte, wenn ich in Schwierigkeiten war - und durch das Codierungsproblem zu sprechen. Sie wissen, was ich meine ... nur der Akt, ein Problem laut zu erklären, bringt eine Lösung für eine Lösung mein Machen Sie 90% der Fälle.