Wie kann Scrum an eine Volunteer-Umgebung angepasst werden?

Ich bin kürzlich einem jungen Hackerspace beigetreten, der gerade dabei ist, sich selbst einzurichten. Wir haben das Glück, dass es in diesem Bereich einige interne Projekte gibt, an denen gearbeitet werden muss, und dass es nicht an Freiwilligen mangelt, die daran arbeiten.

Es gab einige Diskussionen darüber, wie diese Projekte organisiert werden sollen. Meine letzte Berufserfahrung war bei Scrum, daher überlege ich, einen Scrum-Ansatz für unsere Softwareprojekte zu entwickeln, bin mir aber nicht sicher, ob er gut dazu passt.

Obwohl ich gesehen habe, dass Scrum für kleine Vollzeit-Teams gut funktioniert, ist die Art dieser Organisation anders:

• Die Mitglieder sind Freiwillige . Einige sind Vollzeitstudenten. Andere arbeiten hauptberuflich. Wir können von niemandem einen konstanten Beitrag erwarten, da das wirkliche Leben Vorrang hat.
• Während so ziemlich jeder über jahrelange Erfahrung im Schreiben von Software verfügt, haben dies nicht viele Mitglieder professionell oder in Teams getan.
• Es gibt keinen Product Owner . Die Anforderungen für diese Projekte werden von einem Ausschuss festgelegt. Die Mitglieder dieses Ausschusses werden auch an der Umsetzung arbeiten. Dies bedeutet, dass wir keinen einzigen, engagierten Product Owner haben.
• Wir haben keine Fristen (weich oder hart). Die Projekte werden erledigt, wenn sie erledigt sind.

Dies sind ziemlich bedeutende Unterschiede, aber ich bin nicht überzeugt, dass sie die Anwendung von Scrum blockieren werden. Ich denke, dass uns kleinere Optimierungen über diese Hürde bringen könnten:

• Wenn wir Sprints ändern, um eine feste Story-Point-Größe, aber eine flüssige Dauer (Zeit) zu haben, können wir dennoch von iterativen Veröffentlichungen profitieren, ohne unrealistischen Übermittlungsdruck auf freiwillige Entwickler auszuüben.
• Wir können Burndown-Diagramme und Geschwindigkeitsberechnungen umgehen. Wenn ich das richtig verstehe, sind dies Tools und Metriken, die als Brücke zwischen dem Entwicklerteam und dem Management fungieren. Sie dienen dazu, den Fortschritt in einer Form zu melden, die sowohl für die Entwickler als auch für die Stakeholder von Bedeutung ist. In Anbetracht dessen, dass wir niemandem Bericht erstatten müssen (keinem Projektmanager, keinem Product Owner und keinen externen Stakeholdern), glaube ich, dass wir dies insgesamt fallen lassen können.

Dinge, von denen wir meiner Meinung nach profitieren könnten, die keine Optimierung erfordern:

• Die Besprechung (en) zum Sammeln von Anforderungen . Hier sitzen alle an einem Tisch und diskutieren User Stories, skizzieren UI-Mocks und erstellen ein Product Backlog.
• Sprint- Rückblicke . Dies wird eine interessante Möglichkeit für uns sein, uns auf einen Entwicklungsprozess zu konzentrieren, der für uns als Team von Freiwilligen funktioniert.

Dinge, bei denen ich mir nicht sicher bin:

• Wie sollen tägliche Stehübungen behandelt werden? Ich frage mich, ob sie in unserer Umgebung überhaupt einen hohen Stellenwert haben würden. Mein Verständnis des Stand-up-Rituals ist, dass es die Kommunikation unterstützt, indem es Informationen auf natürliche Weise im gesamten Team verbreitet. In Anbetracht der Tatsache, dass unsere Sprints wahrscheinlich eine viel geringere Komplexität als ein durchschnittlicher Sprint aufweisen, besteht möglicherweise weniger Bedarf, mit den Fortschritten / Entwicklungen aller anderen Teammitglieder Schritt zu halten.
• Sollte ich auf XP- Dinge wie Continuous Integration, Code Reviews und TDD drängen ? Ich bin besorgt, das wird viel verlangen. Ich wäre eher versucht, diese Konzepte in zukünftige Projekte einfließen zu lassen, wenn die Leute mit Scrum vertraut sind und im Team arbeiten.

Meine Fragen:

Kann Scrum an ein freiwilliges Umfeld angepasst werden?
Und geht mein geplanter Ansatz bislang in die richtige Richtung?

Schauen Sie in Kanban. Es ist angemessener als SCRUM für Ihre Einschränkungen.

Edit: SCRUM ist (grob gesagt) ein geordneter Rückstand mit Sprints und Zeremonien, um sicherzustellen, dass das Volumen der laufenden Arbeiten unter Kontrolle bleibt und am Ende jedes Sprints etwas Solides bleibt. Wenn Sie die Zeremonien und die Sprints hinter sich lassen, erhalten Sie Kanban: einen geordneten Rückstand und eine starke Betonung darauf, die laufenden Arbeiten direkt zu begrenzen und sicherzustellen, dass alles, was mit "erledigt" markiert ist, erledigt wird, anstatt am Ende Stabilität aufzuerlegen jeder Sprint.

Sie erhalten immer noch die agilen Vorteile: Veröffentlichung zu jeder Zeit, Flexibilität, ein gewisses Maß an Vorhersehbarkeit - obwohl SCRUM Sie in diesem Aspekt ein wenig weiterbringen kann - und ohne die Zeremonien oder Aspekte von SCRUM, die nicht gut zu einem lockeren, verteilten Team ohne Engagement passen . Der Fang? Um die Zeremonien zu beenden, ist mehr Disziplin erforderlich. Sie müssen also WIRKLICH auf Tests, Codequalität und den aktuellen Stand der Arbeiten achten und sicherstellen, dass der obere Rand des Auftragsbestands (Dinge, die für die Abholung durch die Leute bereit sind) ausreichend ausgearbeitet ist.

Sie könnten einen Abstimmungsrückstand haben, obwohl in einem Freiwilligen-Umfeld einige Leute nur daran arbeiten, was sie wollen.

(Und ja, alle Ideen zu TDD, CI, Reviews und Peer-Programmierung sind gute Ideen).

Um die Unterschiede anzusprechen, die Sie zuerst notieren:

• Dass Ihre Mitglieder Freiwillige sind, bedeutet nicht, dass Sie sie nicht um eine Verpflichtung bitten können. Insbesondere bei der relativ kurzen Dauer eines Sprints in Scrum muss es jedem Mitglied möglich sein zu wissen, wie viel Zeit es in den nächsten Wochen für das Projekt aufwenden kann. Wenn die Teammitglieder für einen unterschiedlichen Zeitraum zur Verfügung stehen, wird die Planung für jeden Sprint etwas schwieriger, da es schwieriger ist, zu bestimmen, wie viele Storypoints realistisch sind, Scrum jedoch nicht durchführbar wird.
• Der Product Owner ist dafür verantwortlich, die Vision (und Anforderungen) der Stakeholder für das Produkt zu konsolidieren und an das Entwicklungsteam weiterzuleiten. Der konsolidierende Teil wird wahrscheinlich bereits vom Lenkungsausschuss abgedeckt. Für den Kommunikationsteil können sie nur eines ihrer Mitglieder als ihren primären Sprecher delegieren. Dieser wird dann für alle praktischen Zwecke der Produkteigentümer sein.
• Keine externe Frist zu haben, ist für Scrum kein wirkliches Problem. Es kommt nur mehr auf den Stolz des Teams an, das Produkt fertigzustellen. Scrum selbst hat eine natürliche Frist für jeden Sprint.

In Bezug auf Ihre vorgeschlagenen Anpassungen, insbesondere bei der Arbeit mit Freiwilligen, würde ich dringend empfehlen, die feste Sprintlänge einzuhalten. Auf diese Weise wissen die Freiwilligen genau, für welchen Zeitraum sie ihr Engagement aufgeben.

Ich würde auch Burndown-Charts nicht sofort loswerden. Sie können auch für das Team selbst hilfreich sein, um zu sehen, wie sie sich engagieren. Ich würde es dem Team überlassen, zu entscheiden, ob sie behalten oder fallen gelassen werden. Gleiches gilt für die Geschwindigkeitsberechnungen. Insbesondere aufgrund der großen Variation der verfügbaren Mannstunden pro Sprint können sie sich bei der Schätzung zukünftiger Sprints als sehr nützlich erweisen (insbesondere, wenn Sie die Anzahl der pro Mannstunde erreichten Punkte berechnen).

In Bezug auf tägliche Stand-ups sind sie in Ihrer Umgebung immer noch nützlich, wenn Sie nur wissen möchten, was jeder tut oder Probleme damit hat (und das ist unabhängig von der Komplexität). Es ist jedoch möglicherweise schwieriger, einen täglichen Standup zu realisieren, sodass Sie dort möglicherweise Kompromisse eingehen müssen.

Die von Ihnen erwähnten XP-Praktiken können unabhängig von der Verwendung von Scrum eingeführt oder nicht eingeführt werden und können auch während einer Retrospektive vorgeschlagen werden.

Es überrascht mich, dass niemand darauf hingewiesen hat, aber Ihr Projekt scheint die meisten Open-Source-Projekte zu sein. Wenn Sie sich populärere Open-Source-Projekte ansehen, finden Sie möglicherweise Anregungen. Und ich denke, Sie sollten SCRUM vergessen und aus der Perspektive der allgemeinen Beweglichkeit darüber nachdenken.

Bei Agile dreht sich alles um Kommunikation und Zusammenarbeit. Es gibt einen Grund, warum es in Agile Manifesto 2 von 4 Punkten gibt, die darüber sprechen.

Individuen und Interaktionen über Prozesse und Werkzeuge

Zusammenarbeit der Kunden bei Vertragsverhandlungen

Und wie Sie Ihr Projekt beschreiben, ist es schwierig, mit jedem, der an dem Projekt arbeitet, persönlich zu kommunizieren, was sowohl von Agile als auch von SCRUM gefördert wird. Daher möchte ich mich zunächst darauf konzentrieren, Kommunikationskanäle für das gesamte Team (sowohl für Freiwillige als auch für das Produktkomitee) einzurichten. Dinge wie Wiki, Foren, Videokonferenzen und das richtige Backlog, Aufgaben- und Fehlerverfolgungssystem sind großartige Möglichkeiten, um sicherzustellen, dass jeder weiß, was passiert und was getan werden muss.

Das zweite, was ich bemerken möchte, ist, nicht nur die technologischen Teile von Agile zu durchstreifen. Viele glauben (ich selbst eingeschlossen), dass sie es sind, die agiles Arbeiten ermöglichen, nicht die Prozessseite der Dinge. Die Codeüberprüfung ist wichtig und die meiste Open-Source-Arbeit besteht darin, dass jemand, der mit der Projektüberprüfung vertraut ist, die Commits / Pushs überprüft, um sicherzustellen, dass die Qualität hoch genug ist. TDD wird praktisch für jedes agile Projekt vergeben. Es stellt sicher, dass keine Änderungen am Code die vorherige Funktionalität beeinträchtigen, was in Ihrem Fall noch wichtiger ist, wenn Freiwillige nicht die Mühe haben, die Fehler und Irrtümer anderer zu beheben. Dies erleichtert auch die Codeüberprüfung, da der Prüfer in Tests sehen kann, welche Funktionalität hinzugefügt wurde, und indem er sie ausführt, stellt er sicher, dass die Funktionalität tatsächlich wie vorgesehen funktioniert. Die kontinuierliche Integration entspricht der von TDD.

Das Letzte ist, dass ich glaube, dass Sie mindestens wenige Leute haben sollten, die Vollzeit an dem Projekt arbeiten. Diese Personen sollten bestimmte Rollen haben:

• Product Owner : Obwohl es nett ist, dass Sie ein ganzes Komitee dafür haben, sollte es eine Person geben, die dafür verantwortlich ist, die Worte dieses Komitees in Spezifikationen oder User Stories zu interpretieren und sicherzustellen, dass sie ordnungsgemäß implementiert werden.
• Coordinator & Scrum Master : Diese Person sollte für den gesamten Prozess verantwortlich sein und sicherstellen, dass jeder über die wichtigen Vorgänge im Projekt Bescheid weiß. Außerdem unterhält er das Wiki und die Tools zum Verfolgen von Aufgaben und Fehlern. Wenn jemand eine Frage zum Projekt hat, ist dies die erste Person, die er fragen sollte.
• Hauptentwickler und Architekt : Die Person, die den Code am besten kennt. Er überprüft den Code und stellt sicher, dass die Qualität des Codes für eine agile Entwicklung ausreicht.

Sie können es nicht so anpassen, wie Sie es beschreiben, und es trotzdem SCRUM nennen. Meiner Meinung nach können Sie Scrum wie folgt für das beschriebene Setup verwenden.

1. Habe Iteration behoben. Damit Sie Ihren Fortschritt messen können. Dies gilt nicht nur für das Management, sondern auch für das Team, um zu „wissen“, wie sie sich verhalten.
2. Bitten Sie die Freiwilligen, die Kapazitäten zu Beginn der Iteration zu teilen. Das gesamte Team muss sich dem widmen, was die Mitglieder verpflichten, ansonsten kann ein bestimmtes Mitglied das Team verlassen, um professioneller zu arbeiten.
3. Keine Frist zu haben ist in Ordnung. Scrum erzwingt nicht, dass jedoch das, was Sie am Ende jeder Iteration tun, möglicherweise versandbereit sein sollte. Auf diese Weise können Sie entscheiden, was Sie als Nächstes tun möchten, je nachdem, was Sie bis dahin getan haben (was funktioniert).
4. Es kann auch funktionieren, wenn kein Product Owner vorhanden ist. Sie können eine Art Abstimmungssystem einrichten, um Rangrückstände zu stapeln und erledigte Arbeiten zu akzeptieren / abzulehnen.
5. Das Sammeln von Anforderungen ist nicht Teil von Scrum. Du kannst es tun, wo immer du willst. Schließen Sie dies jedoch nicht als Teil des Iterationsbereichs ein. Habe dafür separate Kapazitäten. Planen Sie für eine Iteration nur die Arbeiten, für die die Anforderungen klar sind, z. B. das Team kennt die Akzeptanzkriterien.
6. Retrospektive sind gut. Starten Sie Scrum so wie es ist, aber verwenden Sie dann die Retrospektive, um zu sehen, was funktioniert und was nicht. Möglicherweise müssen Sie die Iterationsgröße ändern. Möglicherweise müssen Sie einige Freiwillige loswerden, die alle anderen ziehen.
7. Täglicher Status muss sein. Dies gibt dem Team die Möglichkeit, sich miteinander zu synchronisieren, dh, es richtet seine Bemühungen so aus, dass keine Aufgabe unnötigerweise blockiert wird, weil das Ergebnis eines anderen Mitglieds nicht verfügbar ist.
8. XP ist gut. Haben Sie eine strenge Definition von basierend auf XP getan, zB geht kein Code ein, es sei denn, überprüft. Weniger tun, um mehr zu tun

Ich könnte einen anderen Ansatz vorschlagen. Da Sie es mit Freiwilligen zu tun haben, müssen Sie einige Dinge beachten. Ihr Team wird wahrscheinlich einen hohen Umsatz haben, das Leben wird in die Quere kommen und die Leute werden abgelenkt. Von denen, die noch übrig sind, werden ein paar beständig, aber nicht sehr viel beitragen. Dann haben Sie endlich die Hardcore-Gruppe, die sich wirklich für das Projekt einsetzt. Ich mache hier eine Menge Annahmen über Ihre Belegschaft, und wenn Sie der Meinung sind, dass meine Einschätzung nicht die Personen widerspiegelt, mit denen Sie zusammenarbeiten, können Sie den Rest ignorieren.

Jetzt brauchen Sie eine Strategie, mit der Menschen, die nicht viel arbeiten, in der Lage sind, ziemlich autonom zu arbeiten. Sie haben nur so viel Zeit, sich dem zu widmen, und Sie möchten nicht, dass sie den Großteil davon ausgeben in Kommunikation. Die Leute, die mehr involviert sind, sollten für die Integration und das Herauslösen einiger der komplexeren Ideen verantwortlich sein.

Dies lässt mich an einen Entwicklungsprozess denken, der sich mehr auf Drahtrahmen und Prototypen konzentriert.

Sie können einen Pool von Arbeitselementen zur Verfügung stellen und Benutzer dazu ermutigen, für diese Elemente Wire-Frames zu schreiben. Sie können diese als Tracer Bullets (vom Pragmatic-Programmierer entlehnte Terminologie) verwenden, um die Idee zu verfeinern und den Menschen Anregungen zu geben, auf denen sie aufbauen können. Von dort aus können Sie die erfolgreichen Ideen in Prototypen umwandeln. Dies sind wiederum sehr kleine Projekte, die den Menschen helfen sollen, mehr über die Projekte zu erfahren. Danach haben Sie jetzt einen kleineren Teil solider Ideen, die von einer Vielzahl von Leuten erstellt wurden, die Sie an einen Teil des Teams weitergeben können, der etwas aktiver ist, und die daran arbeiten können, diese Ideen in Ihr System zu integrieren.

Ich denke Kanban würde besser für diese Situation passen.

Scrum hat ein paar Dinge, die nicht passen. Das Timing oder Umfang Messungen sind nicht erforderlich und jeder Entwickler hat die gleiche Produktvision aus den Sitzungen. Rechenschaftspflicht und ein kurzer Plan mit Beständigkeit sind Geschäftsziele.

Kanban bietet ziemlich viele der gleichen Vorteile wie Scrum ohne seine Nachteile. Es kann Ihnen ein schnelles Prototyping ermöglichen. Die Prototypen können vor Besprechungen ausgeführt werden. Es gibt auch TDD für änderbaren Code und Regressionstests. Die Paarprogrammierung kann Neulingen und Nicht-Stammgästen den Einstieg in die Codebasis erleichtern, indem Wissen übertragen wird.

Kanban hat auch einzigartige Vorteile. Wenn die Vision, was die Benutzer tun, parallel entwickelt wird, funktioniert Kanban gut. Ein Beweis dafür ist der Erfolg von Programmen für kleine Unternehmen. Auch für die Tage mit wenigen Freiwilligen wie drei Leuten würde Kanban immer noch gut funktionieren. Scrum wäre trotz seines geringen Gewichts zu viel gelbes Klebeband.