Wie lässt sich Scrum für ein Team mit definierten Rollen einsetzen?

Einige Hintergrundinformationen

Ich bin Teil eines firmeninternen Softwareentwicklungsteams. Es besteht aus

• 5 Entwickler (mit Erfahrungen von 2 bis 5 Jahren, ich bin einer von ihnen)
• 3 Implementierungsmitarbeiter (sie übernehmen die Softwarebereitstellung und -schulung)
• und 1 Projektmanager.

Wir entwickeln viele kleine bis mittlere Projekte, deren Zeitrahmen sich normalerweise überschneiden. Die Entwicklung geht so:

1. "Kunde" gibt uns eine Reihe von anfänglichen Anforderungen
2. Wir entwickeln das System nach dieser Spezifikation
3. Präsentieren Sie das System "Client"
4. "Kunde" gibt uns zusätzliche Anforderungen basierend auf dieser Präsentation
5. Wiederholen Sie 2-4, bis "client" keine neuen Anforderungen mehr hat oder das Bereitstellungsziel nahe ist
6. Richten Sie das System ein und stellen Sie es bereit

Dies, zusammen mit der Tatsache, dass es der "Kunde" ist, der die Fristen die meiste Zeit abwickelt (was eine rote Fahne ist, wie ich hier in Programmierern und PM.SE sehe), und wir folgen keinen bestimmten Entwicklungsmethoden zu Cowboy-Codierung, nahezu nicht zu wartendem Code und Fehlern, die unter anderem durch die Produktion gelangen. Aus diesem Grund haben wir uns für eine Agile-basierte Methodik wie Scrum entschieden.

Warum Scrum?

Es war die Initiative unseres Managers, und angesichts unserer gegenwärtigen Situation scheinen sich alle einig zu sein.

Das Problem mit Scrum

Einige Elemente von Scrum stehen im Widerspruch zu unserem aktuellen Setup, auf das wir nicht ohne weiteres eingehen können, insbesondere der "Alleskönner" -Natur agiler Entwickler. Das Bereitstellungsteam kann nicht programmieren, und die Entwickler verfügen über unterdurchschnittliche Kommunikations- und Schulungsfähigkeiten. Und diese Aufstellung wird sich in Kürze nicht wirklich ändern.

Die Frage

Würde dies die Wirksamkeit von Scrum als Methodik beeinträchtigen? Müssten andere Änderungen vorgenommen werden, um dies auszugleichen? Oder wäre es besser, den Gedanken ganz aufzugeben und über eine andere Methodik nachzudenken?

Eigentlich ist Ihre derzeitige Arbeitsweise nicht so weit von Scrum entfernt, wie Sie vielleicht denken.

In Scrum erhalten Sie auch einen ersten Satz von Anforderungen, setzen diese um und demonstrieren das Ergebnis. Basierend auf der Demonstration können neue Anforderungen an Sie gestellt werden oder die Stakeholder können entscheiden, dass das Produkt gut genug ist, dass keine weitere Entwicklung erforderlich ist.
In Ihrer Situation könnte dem "Kunden", über den Sie gesprochen haben, die Rolle des Product Owner in Scrum zugewiesen werden (diese Rolle wird anscheinend bereits ausgefüllt, indem die Prioritäten innerhalb eines Projekts festgelegt und entschieden werden, wann es für die Einführung bereit ist).
Eine große Änderung könnte die Länge einer Iteration sein. In Scrum sollte eine Iteration zwischen 1 und 4 Wochen dauern.

Was die Zusammensetzung des Teams und den Trugschluss anbelangt: Bei Scrum muss nicht jeder ein Allrounder sein. Scrum setzt lediglich voraus, dass das Team als Ganzes über alle erforderlichen Kompetenzen verfügt, um das Produkt aus einer Liste von Anforderungen auf etwas zu bringen, das bereitgestellt wurde / werden kann.
In Ihrer Situation konnte ich leicht ein Team pro Projekt sehen, das aus einem oder mehreren Entwicklern (die hauptsächlich Implementierungs- und Testarbeiten ausführen) und einem Mitglied des "Implementierungspersonals" besteht, das sich hauptsächlich auf die Erstellung der Handbücher und Schulungsmaterialien für die Features konzentriert Die Entwickler implementieren jetzt.

Nachdem der Kunde / Product Owner grünes Licht für die Bereitstellung gegeben hat, wird die Arbeit für das Scrum-Team größtenteils erledigt, sodass die Entwickler zu einem anderen Projekt wechseln können (und nur auf Anfrage verfügbar sind, um Probleme nach der Bereitstellung zu beheben) und die Implementierung durchführen können Die Mitarbeiter können auf die Durchführung der Schulungen und die Unterstützung des Roll-outs umsteigen.

Die Tatsache, dass es Fristen gibt, ist kein wirkliches Problem, solange genügend Flexibilität besteht, welche Funktionen in dieser Version benötigt werden.

Sie fragen nach Alternativen, also sage ich eXtreme Programming (XP). Insbesondere denke ich, dass die Paarprogrammierung Ihnen hier helfen könnte.

Wenn Sie Menschen mit unterschiedlichen Fähigkeiten zusammenbringen, spielt es keine Rolle, welche Fähigkeiten Sie haben: Kaffee kochen, testen, trainieren usw. Sie können die Fähigkeiten im Team verbreiten.

Aber um ehrlich zu sein, es hört sich nicht so an, als ob SCRUM für Sie so weit weg wäre. Ein Teil von SCRUM ist es, flexibel zu sein und das Beste für Ihr Team zu finden. Ein Teil von XP ist es, Ihr Team zu respektieren und sich anzupassen. Vielleicht haben wir in 100 Jahren einen besser ausgebildeten Beruf mit harten und schnellen Regeln (obwohl ich das bezweifle), aber im Moment tun wir nur, was für Sie funktioniert. Das Wichtigste ist, Rückkopplungsschleifen zu haben. Wenn etwas nicht funktioniert, muss das Team darüber diskutieren und neue Dinge ausprobieren, bis es etwas findet, das funktioniert.

Wie lässt sich Scrum für ein Team mit definierten Rollen einsetzen?

Mach es einfach. Laut dem Scrum-Guide ist jeder ein Entwickler, aber hier auf der Erde bringen verschiedene Leute verschiedene Dinge auf den Tisch. Ich wurde fast gelyncht, als ich vorschlug, dass einige Leute wirklich Tester sind, während andere die Software schreiben.

Einige Dinge, die Sie vielleicht ansprechen möchten:

Sprints

Es hört sich so an, als hätten Sie eine erste Entwicklungsphase, gefolgt von einer Reihe von scheinbaren Sprints. Überlegen Sie, ob Sie das auflösen wollen. Der Kunde wird nicht nur etwas früh sehen, sondern erhält auch ein besseres Gefühl für Entwicklungsmeilensteine, sobald diese eintreten.

Feste Termine

Dies taucht immer wieder auf und ist in der Tat ein hartnäckiger Dorn im Auge der Entwickler, an denen ich derzeit arbeite. Scrum legt Schätzungen für den Sprint fest - mehr nicht. Ja, Sie könnten das Ziel nach einer Reihe von Sprints treffen, aber sobald der Kunde frühe Versionen im Auge hat, wird sich der Umfang wahrscheinlich erheblich verschlechtern. Dies ist an sich kein Problem, aber der Kunde sollte darauf hingewiesen werden, dass weitere Arbeiten in späteren Sprints stattfinden werden und über die bekannten Anforderungen hinausgehen.

Ihre Situation passt möglicherweise besser zu Kanban, da Sie mit der Situation beginnen und von dort aus iterieren können. Dies bedeutet, dass Sie keine Big-Bang-Einführung haben, die Ihre aktuellen Projekte stört. Beginnen Sie einfach mit der Visualisierung von Aufgaben an einer Tafel und der Übernahme einiger Praktiken wie Rückblicke und tägliche Besprechungen.

Man muss ein bisschen vorsichtiger sein als bei Scrum, weil es nicht so vorschreibend ist: Es tendiert dazu, zu dem zurückzukehren, was vorher war, anstatt eine richtige agile Denkweise zu vermitteln.

Scrum funktioniert nicht gut mit separaten Projekten, die sich überschneiden, da für den gesamten Sprint keine stabile Gruppe von Mitarbeitern an einem Projekt arbeitet. Daher werden Konzepte wie Ausführlichkeit usw. Sie wahrscheinlich nur deprimieren.

Es ist jedoch ein nützliches Konzept, zunächst die Story zu betrachten, die dem Kunden die besten Kosten / Nutzen bringt, und sie einschließlich vollautomatischer Tests in einer Qualität umzusetzen, die für die Bereitstellung ausreicht, bevor an der nächsten Story gearbeitet wird. Ebenso muss der gesamte Code, der für eine Story geschrieben wurde, von einem anderen Entwickler überprüft werden, bevor die Story als „erledigt“ betrachtet wird.

Ich gehe davon aus, dass Ihre Implementierungsmitarbeiter Schulungs- und Referenzdokumente schreiben müssen. Diese können für jede Story geschrieben werden (erster Entwurf), bevor der Code geschrieben wird, und werden so zu Abnahmetests.

Ich gehe davon aus, dass Sie zu Beginn eines jeden Projekts feststellen werden, dass der Einsatz der Implementierungsmitarbeiter für die Entwickler die größte Hilfe darstellt, da sie sich zu 100% für die Bereitstellung des vorherigen Projekts einsetzen. Überlegen Sie sich daher, ob die Implementierungsmitarbeiter an der Erstellung der Storys und der Benutzerdokumentation für das nächste Projekt arbeiten können, während die Entwickler den Code für das aktuelle Projekt schreiben.

Möglicherweise funktioniert die „verhaltensorientierte Entwicklung“, bei der das Implementierungspersonal das in den Tests verwendete Beispiel schreibt.

Es gibt also ein bisschen Scrum, das Ihnen helfen wird, aber versuchen Sie, sich von Scrum zu lehnen, anstatt Scrum zu verwenden.