Ich verwende Scrum seit Ewigkeiten für meine eigenen Projekte, die normalerweise in Teilzeit (einige Stunden pro Woche - vielleicht bis zu 10 Stunden pro Woche) und normalerweise solo (obwohl gelegentlich Teams von bis zu 3-4 Personen enthalten sind) sind ).
Ich mag bestimmte Vorteile, die ich durch die Verwendung von Scrum erhalte:
Einige Probleme, mit denen ich zu kämpfen habe:
Der Versuch, Geschwindigkeit für die Kapazitätsplanung zu verwenden ("wie lange dauert es für ...") ist fast unmöglich. Abgesehen davon, dass die Arbeit in kleinere Teile zerlegt wird, ist es tatsächlich meistens Overhead.
Gibt es eine Optimierung oder einen besseren Weg, um in einer solchen Situation eine sinnvolle Geschwindigkeit zu erzielen? Längere Sprints können funktionieren (durchschnittlich besser, z. B. ein Monat), aber ich bin mir immer noch nicht sicher, ob meine Geschwindigkeit tatsächlich aussagekräftig ist.
Ich habe festgestellt, dass „Scrum“ für verschiedene Menschen sehr unterschiedliche Dinge bedeuten kann. Was es für mich von anderen agilen Prozessen unterscheidet, ist der Fokus auf Commitment-basierten Sprints. Da Sie die Bereitstellung sprintbasierter Ergebnisse nicht als wichtigen Vorteil für diese Projekte aufgeführt haben, ziehen Sie möglicherweise mehr Nutzen aus anderen leichtgewichtigen agilen Prozessen, als sich an die von Scrum vorgeschriebenen Aktivitäten zu halten.
Das Schätzen von Geschichten kann einen begrenzten Nutzen haben. Ich habe festgestellt, dass es, wenn Sie gut darin sind, Geschichten klein und ungefähr gleich groß zu halten, genauso gut funktioniert, Geschichten anstelle von Punkten zu zählen oder allen Geschichten den gleichen Punktwert zuzuweisen, sobald Sie glauben, dass sie gut definiert sind. Ich hatte sogar Teamprojekte, die in dieses Muster fielen, und wir verbrachten „Schätzungs“-Aktivitäten damit, Geschichten angemessen klein zu machen, anstatt über Punktzahlen zu diskutieren.
Um eine nützliche Geschwindigkeit zu erhalten, sollten Sie meiner Meinung nach versuchen, die Punkte oder Geschichten zu messen, die pro Stunde über jede Iteration hinweg geliefert werden. Das sollte einen Großteil der Variabilität beseitigen, die Sie sehen. Wenn die Zeit, die Sie für jede Iteration aufwenden, sehr unterschiedlich ist, können Sie kein Fertigstellungsdatum prognostizieren, aber Sie sollten in der Lage sein, ungefähr zu prognostizieren, wie viele Arbeitsstunden noch verbleiben.
Viele Tools beinhalten die Möglichkeit, die Teamstärke pro Iteration anzupassen, um diese Art von Änderungen zu berücksichtigen. Mit Pivotal Tracker können Sie beispielsweise einen Prozentsatz der normalen Teamstärke für jede Iteration festlegen, wodurch Sie Teammitglieder im Urlaub, reduzierte Arbeitszeiten oder andere Abweichungen berücksichtigen können. Alternativ können Sie eine Iteration als X Arbeitsstunden anstatt als Y Tage zählen, und eine Iteration kann 1 bis 3 Wochen dauern, aber Sie erhalten eine nützlichere geschätzte Anzahl von Iterationen, die im Projekt verbleiben.
Der Wert von Scrum beginnt mit einem Entwickler. Team von mindestens 3 Personen und ist ab 5 Personen tatsächlich spürbar. Wenn Sie der einzige Entwickler sind, würde ich mich nicht mit Scrum beschäftigen, Sie können sich davon inspirieren lassen, aber es läuft wirklich auf eine gute Feature-Priorisierung und persönliche Verwaltung hinaus.
Das Schätzen von Geschichten scheint Verschwendung zu sein, besonders wenn ich der einzige Entwickler bin, gibt es kein Konzept für eine Veröffentlichung/ein Ziel/eine Frist
Hier bekommen Sie vielleicht am meisten für Ihr Geld. Es mag wie Zeitverschwendung erscheinen, aber wenn Sie Ihre Schätzungen vornehmen, können Sie sehen, wie viel Sie für jeden Sprint übernehmen sollten.
Anstelle von Story Points können Sie Stunden für Ihre Schätzungen verwenden. Ich weiß, dass Punkte im Allgemeinen die akzeptierte Wahl sind, aber wenn Sie keine regelmäßigen Stunden einhalten, weiß ich nicht, wie Ihre Geschwindigkeit auf etwas Sinnvolles zurückgeführt werden kann.
Irgendwann wird niemand eine akzeptable Antwort für Sie haben – wenn der Umfang Ihrer Arbeit so klein wird, dass jede Abweichung in Ihrem persönlichen Zeitplan jede Metrik bedeutungslos macht, dann können Sie nicht viel dagegen tun …
Sie können Agile erfolgreich einsetzen, wenn Sie eine oder mehrere Personen sind. Barnaby Golden hat es mir einmal erzählt
Sie können Agilität mit Teams jeder Größe übernehmen, da dies ein Ansatz für die Softwareentwicklung ist.
Wenn es um Scrum geht, wird es, wie Sie bereits erwähnt haben, für Teams mit mindestens 3 Personen empfohlen; Auch die Verwendung von Kanban mit nur einer Person kann zu Ergebnissen führen, die weit von den Erwartungen entfernt sind.
Dennoch hatte jemand das Bedürfnis, eine Agile-Methodik für Solo-Entwickler namens Cowboy zu entwickeln - was meiner Meinung nach Ihren Bedürfnissen entspricht, wenn man bedenkt, dass Sie die meiste Zeit nur einer sind und bestimmte Agile- und Scrum-Praktiken mögen. Diese Methodik, wie sie im Artikel behauptet wird
lehnt sich stark an agile Praktiken sowie an XP, Scrum, AUP und Real an.
Durch die Verwendung von Cowboy werden Sie im Grunde genommen
Um mehr darüber zu erfahren, lesen Sie die Seiten 18-24 des Dokuments .
Asche999
Jona