Scrum für einen einzelnen Programmierer? [geschlossen]

Ich werde als "Windows-Experte" in meiner sehr kleinen Firma bezeichnet, die aus mir selbst, einem Maschinenbauingenieur, der in einer Vertriebs- und Schulungsrolle arbeitet, und dem Präsidenten der Firma, der in einer Design-, Entwicklungs- und Supportrolle arbeitet.

Meine Rolle ist ebenso allgemein, aber in erster Linie entwerfe und implementiere ich alles, was für die Programmierung unseres Produkts erforderlich ist, damit unsere Produkte auf den jeweils aktuellen Windows-Versionen ausgeführt werden können.

Ich habe gerade einen allgemeinen Überblick über das Scrum-Paradigma in einem Webcast gesehen. Meine Frage lautet: Lohnt es sich, mehr über diese Herangehensweise an die Produktentwicklung zu erfahren, da meine Entwicklungsaufgaben in der Regel auf einem sehr hohen Niveau ausgeführt werden, z. B. "Internationalisieren und Lokalisieren des Produkts"?

Wenn ja, wie würden Sie vorschlagen, Scrum für die Verwendung von nur einem Programmierer anzupassen? Welche Tools, Cloud-basiert oder anderweitig, wären zu diesem Zweck nützlich?

Wenn nicht, welchen Ansatz würden Sie einem einzelnen Programmierer vorschlagen, um seine Bemühungen von Tag zu Tag zu organisieren? (Vielleicht reduziert sich die Frage auf diese einfache Frage.)

Scrum lernen: ja. Wenn Sie nur etwas darüber lernen möchten, erweitern Sie Ihre allgemeinen Fähigkeiten. (aber ein Hauch davon "Scrum-Ban" ist wahrscheinlich das, wonach Sie suchen ...)

Scrum ist ein nettes Framework, aber ein zentraler Grundsatz ist "Iterationen (Sprints) sollen eine feste Dauer haben". Ich habe diese Arbeit noch nie in sehr kleinen Teams gesehen, die mehr von Interrupts getrieben sind als nicht. Wenn Sie sich wirklich für eine feste Zeitspanne (1 Woche?) Anmelden und sich verpflichten können, ist Scrum ein cooles Framework. Wenn Sie es nicht können ... dann ist Scrum eine gute Lernhilfe, da es einige gute Konzepte hat, die sich gut auf andere Dinge übertragen lassen ... wie ...

Rückstand - Scrum oder nicht, führen Sie eine priorisierte Liste der Dinge, die Sie tun müssen. Ich mag Excel (oder Google Doc Spreadsheet ...) Vielleicht gefällt Ihnen etwas anderes. Ich würde ein sehr kleines Tool behalten, wenn Sie ein sehr kleines Team sind. (Tabellenkalkulation >> Textverarbeitung, weil Sie leicht sortieren können.)

Trennung von Planen und Festlegen - Planen Sie in einer abstrakten Notation (Punkte) und seien Sie konsistent (8 Punkte sind etwa 2x eine 4-Punkte-Geschichte und 4x eine 2-Punkte-Geschichte) in Stunden. Verändere die Punkte nicht.

Verpflichtung - Seien Sie für andere sichtbar, wenn Sie sich verpflichten, und halten Sie sich an Ihre Verpflichtungen

Rückblick - Überlegen Sie nach Ihrer Abgabe, was besser gemacht werden könnte.

usw. usw.

Scrum ist leicht zu verstehen, dass es ein guter Ausgangspunkt sein könnte. Wenn es Ihnen gefällt, würde ich die Verwendung der Variante "Scrum-Ban" in Betracht ziehen - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Nichts anderes erscheint mir als "so gut dokumentiert" mit einer einigermaßen aktiven Community, die dies unterstützt.

Ich würde gerne auch die Crystal-Methoden von Alistair Cockburn empfehlen (http://alistair.cockburn.us/Crystal+methodologies+main+foyer und http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Klein / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), aber es beinhaltet viel mehr Lesen und Graben.

In XP finden Sie weitere Informationen zu bestimmten Vorgehensweisen. Ich würde daher auch sagen, lesen Sie das Buch: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= books & ie = UTF8 & qid = 1304359834 & sr = 1-1

Abschließende Lesehinweise: Solange Sie dem Agile-Manifest zustimmen und die folgenden Grundsätze befolgen: http://agilemanifesto.org/principles.html Sie sollten in einem anständigen Zustand sein.

Persönliche Empfehlung: TDD einführen (nicht verhandelbar, IMHO) Rückstand aufrechterhalten (gemäß Scrum) Immer nach Priorität sortieren und sortieren Zwei Elemente haben die gleiche Priorität.) Machen Sie Ihre Build-Umgebung in der Lage, in 5 bis 10 Minuten zu erstellen, zu testen und bereitzustellen (für Lab-Umgebungen). Zeigen Sie Ihren Kunden (intern und extern) die Ergebnisse der Fertigstellung einer Story Ihr Kunde stimmt zu. Ziehe Geschichten vom oberen Rand des Stapels und bearbeite sie, während du die aktuelle Geschichte abschließt. Lasse nicht mehr als zwei Dinge gleichzeitig offen. Beende eine Ablenkung, bevor du eine andere beginnst.

hoffe das hilft

Sie können einige in Scrum angewandte Vorgehensweisen anwenden, wie z. B. Product Backlog, Priorisierung, relative Schätzung, inkrementelle Auslieferung. Die Verwendung von Scrum als Prozess zur Verwaltung der Produktentwicklung durch ein Team von selbstorganisierten funktionsübergreifenden Mitgliedern ist jedoch wahrscheinlich kein Weg für eine One-Man-Show .

Die Frage ist, ob Sie Ihre Arbeitselemente in kleine Teile zerlegen können, die schrittweise geliefert werden können. Wenn Sie die meisten Übungen nicht anwenden, ist dies nicht sinnvoll. Auch bei Scrum geht es um eine gute Zusammenarbeit mit dem Product Owner / Kunden. Es sollte nicht so aussehen: "Hier hast du eine Aufgabe und kommst zurück, wenn sie erledigt ist."

Ich werde zwar nichts für oder gegen 1-Mann-Srum sagen, aber ich werde sagen, dass ein 1-Mann-Kanban-Pull-System sehr gut funktioniert. Kanban kombiniert mit automatisierten Unit-Tests hat mich viel produktiver und "dokumentierter" gemacht. Obwohl es sich bei beiden Methoden nicht wirklich um Methoden handelt, sondern um mehr Werkzeuge (und zwar sehr unterschiedliche), zwingen mich beide, große Soloprojekte in mundgerechte Stücke zu zerlegen, und geben mir eine Art Ritual, um mich zu ermutigen, jeweils mehr Dinge zu erledigen Tag. Es gibt nichts Schöneres, als auf "Alle Tests ausführen" zu klicken und zu sehen, wie jedes Element grün wird ... nichts anderes, als eine Karte aus der Spalte "In Bearbeitung" auf meinem Kanban-Board in "In Prüfung" zu verschieben (oder ganz vom Board zu entfernen). .

Ich denke, das eigentliche Problem beim Solo-Arbeiten ist, dass Sie aus mehreren Methoden auswählen können, die wirklich für Gruppen von Entwicklern gedacht sind, und sie so anpassen, dass sie am besten zu Ihnen passen. Das Endziel ist wirklich nur, Sie verantwortlich, produktiv und glücklich zu halten. Wer weiß, wie man das besser macht als Sie selbst (mit ein bisschen von hier und ein bisschen von dort).

Ich habe es versucht, als ich einmal alleine gearbeitet habe. Die Dinge, die gut funktionierten, waren:

1. Alle Workitems auf einem Whiteboard haben. Ich konnte sehr schnell sehen, was für eine hervorragende Arbeit es gab; wo Abhängigkeiten und Blockaden waren. Außerdem schauten viele Leute in meinem Forum vorbei und lasen es - und wir unterhielten uns darüber. Ich denke, es hat ihnen geholfen zu verstehen, was "der Aussenseiter" den ganzen Tag tat ;-)
2. Die Burn-Down-Tabelle war auch großartig. Ich habe gerade Excel dafür verwendet. Dadurch konnte ich in diesem Umfeld besser einschätzen. Es gab mir einen großartigen Überblick darüber, wohin ich mit der Iteration unterwegs war. Mein Manager, der keine technische Person war, liebte dies auch, da er all die verschiedenen Dinge in einer Funktion sehen konnte und wo sie sich befanden.
3. Tägliche Stand-ups. So gut ich konnte. Jeden Morgen aktualisierte ich alle Arbeitselemente und die Burn-Down-Tabelle und notierte alle Hindernisse, die behoben werden mussten.
4. Automatisiertes Testen und kontinuierliche Integration (MSTest / TFS), vorzugsweise TDD, helfen jedem Entwicklerteam bei der Verwendung einer beliebigen Methodik - was hier jedoch erwähnenswert ist.
5. Kurze Iterationen (1 Woche) haben mir wirklich geholfen, mich darauf zu konzentrieren, etwas zu liefern.
6. Das Aufrechterhalten eines Auftragsbestands war großartig, da ich ihn in den Kontext aller anderen Arbeiten stellen und den Product Owner dazu bringen konnte, die Prioritäten neu zu setzen, als ich neue Arbeiten bekam.

Was nicht funktioniert hat war:

1. Wenn Sie alleine arbeiten, wird die Zusammenarbeit mit Gleichgesinnten nie einen solchen Schub bringen. oder das Gefühl von Wettbewerb und Konzentration, das von einem Team mit wirklich guter Moral und Kultur ausgeht. Wenn Sie nicht weiterkommen, müssen Sie sich keine Gedanken mehr machen. Daher kann ein Scrum-Meister solche Blockaden im täglichen Aufstehen nicht beseitigen.
2. Es gibt keinen Scrum Master - also gibt es niemanden, der Unterbrechungen aufhält. Ich hatte große Probleme mit Leuten, die ständig Fragen zu anderen Dingen stellten und meinen Fluss brachen. Unter einem guten Scrum Master wird so etwas abgefangen und man kann weitermachen. Ich wollte nie unhöflich zu Leuten sein (vielleicht bin ich weich), also war es ein Problem. Auch ohne einen Scrum Master können Sie den Prozess leicht abschweifen.

Es war eine interessante Übung, aber ich hörte nach einer Weile damit auf. Ich denke, die Vorteile von Scrum sollten im Gegensatz zu traditionellen Wasserfallteams gesehen werden. Aber beide sind irgendwie umstritten, wenn Sie alleine sind. Es gibt keine Kommunikations- oder Kollaborationsprobleme - Sie arbeiten sich nur durch die festgelegten Aufgaben und sind fertig.

Ich denke, jeder sollte ein Backlog führen und TDD machen.

Elemente von Agile / Scrum / Kanban, die meiner Meinung nach in einer einzigen Entwicklerwelt Sinn machen:

1. Haben Sie ein Board, in dem Sie Ihre User Stories / Active-Backlog-Items auf Karteikarten wie Kanban organisieren.

2. Lassen Sie sich von Nicht-Entwicklern auf den Wert dieser Prinzipien einladen:

   • Geben Sie mir Zeit, um zu arbeiten, ohne meine Prioritäten zu ändern oder Mikromanagement (der Punkt der Sprints). Geben Sie mir Zeit und ich werde versuchen, vorher genau herauszufinden, wie viel ich tun kann, und ich werde mein Bestes tun, um so viel zu tun.

   • Wenn ich etwas brauche (ich werde blockiert) und ich zu dir komme und du es nicht für mich sortieren kannst, muss der Sprint möglicherweise abnormal abgebrochen werden. (Das heißt nur, wir brauchen einen neuen Plan.)

   • Niemand ändert irgendetwas in der Mitte des Sprints. Oder wir brechen den Sprint einfach ab und erstellen einen neuen. Wenn dies häufig vorkommt, sinkt die Produktivität.

   • Die Kommunikation zwischen Beteiligten kann in regelmäßigen, täglichen Stand-up-Meetings stattfinden, in denen die meisten der gleichen Dinge wie bei einem normalen Scrum kommuniziert werden, einschließlich der Erfolge Ihrer Entwickler für diesen Tag. Im Grunde können Sie Dinge melden, die länger gedauert haben als Sie gedacht haben oder die gut gelaufen sind, sowie alle Anpassungen, die Sie an Ihren Implementierungsplänen vornehmen. (Ich habe vier neue Fehler gefunden und sie protokolliert. Ich denke, sie sind wichtiger als diese optionale Funktion. Ich denke, ich werde die Zeit darauf verwenden, sie zu beheben und diese optionale Funktion zu entfernen.)

Ich habe als einzelner Entwickler viel gearbeitet, und ich kann mit Sicherheit sagen, dass das Vertrauen zwischen dem einzelnen Entwickler und seinen Vorgesetzten / Vorgesetzten, die keine Entwickler sind, und eine gute Kommunikation die Schlüssel sind, keine Methodik. Aber Sie können immer effektiver sein, wenn Sie guten Grundsätzen folgen.

Ich habe einen Blog darüber gelesen und denke, er kann dir bei deiner Frage helfen.

Erster Teil: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Zweiter Teil: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Möglicherweise finden Sie weitere Informationen in diesem Blog.

Ich bin in keiner Weise verbunden; nur etwas, das ich in meinen Favoriten hatte. Hoffe es kann dir helfen.

Ja. Und denken Sie daran, dass das Scrum keine ausgefallenen Tools beinhalten muss. Es kann sich lediglich um ein einfaches 15-minütiges Stand-up-Meeting handeln, bei dem alle darüber sprechen, woran sie arbeiten. Der Vorteil von Scrum ist, dass jeder weiß, was los ist, und dass es einfacher ist, Probleme zu lösen, bevor sie auftreten, und Probleme auf der Straße zu antizipieren.

Vielen dieser Antworten fehlt ein wichtiger Punkt.

Ein Scrum-Team muss nicht nur aus Programmierern bestehen.

Einer Ihrer Kollegen macht "Design" / "Entwicklung" und einer "Vertrieb".

Vielleicht kann Ihr Vertriebskollege ein Product Owner (Proxy) sein. Welche Erwartungen hat der Kunde?

Das Design und die Entwicklung Ihres anderen Kollegen klingen für mich wirklich nach Scrum-Team-Disziplinen. Die Scrum-Entwicklung erfolgt nicht stufenweise, sondern vertikal (Anforderungen ausbügeln, Design und Implementierung in einem Sprint).

Sie könnten den Scrum-Prozess mit Ihnen dreien machen.

Was braucht es, um dies zu erreichen? Scrums Sprint-Planungstreffen gehen der Frage nach, was das ist. Was erwartet der Produktbesitzer, damit es als erledigt betrachtet wird?

Während eines Sprint-Planungsmeetings können Sie Ihren Kollegen den Kontext erläutern, warum es technisch schwierig sein könnte, das Produkt zu internationalisieren und zu lokalisieren.

Unzählige Gründe, Scrum Imho zu verwenden.

Ich würde vorschlagen, Kanban auszuprobieren und mit den Grundlagen zu beginnen: Visualisierung und Begrenzung des Work-in-Progress (WIP).

Selbst wenn Sie es später einstellen, werden Sie dabei agiler. Und während Kanban für die "normale" Softwareentwicklung gut ist, übertrifft Kanban +, ein Flow-basierter Prozess (im Gegensatz zu Iterationen), andere Prozess-Tools, wenn Sie eine Situation haben, in der sowohl neue Funktionen als auch Wartung entwickelt werden müssen.

Ich schließe mich der Empfehlung von David Andersons Kanban-Buch an, und Sie können sich auch meine Folien von einem lokalen Treffen ansehen, in denen erklärt wird, warum und wie man mit einfachem Kanban oder mit crisp.se/kanban für ein kurzes Intro anfängt .

Für Ihren Kontext habe ich ein paar Gedanken:

• Sichtbarkeit ist der Schlüssel, verwenden Sie also lieber ein physisches Whiteboard als ein digitales Tool, wenn Sie es nicht dauerhaft auf einem (großen) Bildschirm anzeigen können (wenn Sie sich am selben Ort befinden).
• Beginnen Sie mit Ihrem aktuellen Prozess
• Beginnen Sie nur mit Ihrem Einflussbereich, einschließlich Upstream- und Downstream-Übergabephasen (Warteschlange für Sie werden, z. B. für Entwickler bereitgestellte Features oder Warteschlange für Sie, z. B. fertige Features, für den Verkauf bereit).
• Wenn Ihre Kollegen daran interessiert sind, die Visualisierung vor- oder nachgelagert zu erweitern, umso besser. Vielleicht sehen Sie am Ende den gesamten Wertstrom (oder das Netzwerk) für Ihr Unternehmen, dh wie der Wert vom Konzept zum Geld fließt
• Minimieren Sie Multitasking (!), indem Sie WIP begrenzen. Wenn der Arbeitsfluss für Ihre Kollegen sichtbar ist, sollten sie verstehen, warum und leicht erkennen, was sich auf Ihrem Teller befindet
• vielleicht ist es sinnvoll, die arbeit in 3 oder 4 arbeitsarten (dienstleistungsklassen) zu unterteilen, die unterschiedliche anforderungen stellen: zb. Bugs, kritische Probleme, Arbeit mit harten Fristen, Arbeit ohne Fristen
• Beobachten Sie, wie Ihre Arbeit abläuft, z. B. wenn Sie irgendwo Engpässe haben oder die Arbeit blockiert ist oder Sie für die Arbeit in vorhersehbaren Mustern "ausgehungert" sind. Dies ist auf lange Sicht einfacher, wenn Sie ein digitales Tool verwenden. Lesen Sie einige meiner letzten Folien.
• den arbeitsfluss schritt für schritt verbessern

Wenn Sie heute etwas ausprobieren möchten, während Sie Ihre Entscheidung treffen, würde ich empfehlen, ein persönliches Kanban an der Wand oder am Fenster oder am Schrank neben Ihnen zu probieren , wie ich es letzte Woche getan habe ...

Nachdem ich alle anderen Antworten hier gelesen habe, denke ich, dass die einfache pragmatische Antwort lautet:

Verwenden Sie Prozesse, Techniken oder Methoden, um etwas zu LERNEN, das Ihnen dabei hilft, Ihre Arbeit besser zu machen.

Nun könnte dies bedeuten, Ihre Aufgaben - jeden Tag - religiös zu priorisieren.

Es könnte bedeuten, den Rückstand zu klären.

Es könnte bedeuten, Fortschritte zu melden - an Ihren Chef (auch wenn es ihm egal ist ... es ist eine gute Sache, wenn Sie sich gedanklich eine Bestandsaufnahme machen, wo Sie sich gerade befinden).

Sie können alle Arten von Methoden oder Techniken anwenden, weil Sie damit letztendlich besser arbeiten können, was bedeutet, dass Sie nachts besser schlafen.

Tun Sie Dinge, die funktionieren (für Sie, unter Ihren gegenwärtigen Umständen), und verwerfen Sie Dinge, die dies nicht tun.

Es sei denn, Sie haben Folgendes festgelegt

• Mittel zum Organisieren und Priorisieren der eingehenden Anforderungen.

• So schätzen Sie den Aufwand genau ein, damit Sie wissen, was Sie in einer Iteration tun können

• Iterationen und kontinuierliche Verbesserung - Das Konzept von Iterationen, bei denen man ständig prüft und anpasst, ist von unschätzbarem Wert. Diese Praxis fördert das Experimentieren und baut auf kontinuierlichem Lernen auf. Gedränge in der Kirche, Seite 4

• Sie können zwar kein tägliches Scrum-Meeting durchführen, aber Sie können sich zumindest an die Aufgabe erinnern, die Sie heute ausführen werden. Tägliche Scrum-Meetings werden verwendet, damit die Teams sich über ihre Aktivitäten austauschen können.

• Reflexion nach einem Sprint - in Scrum heißt es Sprint Retrospective. Am Ende jeder Iteration können Sie darüber nachdenken, was nach der Iteration passiert ist, und überlegen, was schief gelaufen ist und wie Sie es verbessern können tun

Ich würde vorschlagen, dass Sie einen minimalistischen Ansatz verfolgen und durch kontinuierliche Verbesserung ein Scrum erhalten, das gut zu Ihren Anforderungen passt.

Scrum ist kein Scrum, wenn Sie es nicht an Ihre Bedürfnisse anpassen und an Ihre aktuelle Situation anpassen können.