Wie handhabt man den Zugriff auf Ressourcen in einem Scrum-Team, das zuvor ein hierarchisches Team war?

Aus dem, was ich in letzter Zeit über Scrum gelesen und gelernt habe, sowie aus dem jahrelangen Lesen der großartigen Fragen und Antworten auf dieser Website geht hervor, dass ein Scrum-Team ein Team von Gleichen ist, in dem es keine Hierarchie gibt und Wissen intensiv geteilt wird.

Ist es immer noch möglich, dass einige Mitglieder des Teams einen bestimmten Zugriff auf eine Reihe von Ressourcen haben, die andere nicht haben? Beispielsweise kann ein Datenbankexperte im Team SQL-Abfragen für die Live-Produktionsdatenbank ausführen, aber man möchte möglicherweise nicht, dass jeder im Team dies kann, der nicht in SQL geschult ist. Ist das eine korrekte Denkweise, oder würden wir allen im Team uneingeschränkten Zugriff gewähren und sie warnen, keine Sachen zu beschädigen?

Was ist mit einfacheren Dingen wie dem Instant-Messaging-System Slack des Teams? Es ist wohl viel schwieriger, Slack (oder Sqwiggle, gitter.im oder jedes andere Instant-Messaging-System) zu knacken. Würde erwartet, dass jeder Administrator dieses Systems ist, oder würde eine bestimmte Person als Administrator fungieren?

Ich mache mir Sorgen über solche Dinge, weil sie versehentlich einen Teil der Prä-Scrum-Hierarchie beibehalten könnten, die vor dem Wechsel zum Scrum-Framework vorhanden war. Was ist der beste Weg, diese Dinge in einem neuen Scrum-Team anzugehen, das zuvor kein Scrum war?

Antworten (2)

Funktionsübergreifende Teams, Vertrauen und Risikomanagement

Es gibt wirklich eine Reihe von Problemen, die in Ihrer Frage verborgen sind. Lassen Sie mich versuchen, sie der Reihe nach anzusprechen, obwohl die Reihenfolge eigentlich nicht wichtig ist.

  1. Ein agiles Team muss funktionsübergreifend sein, aber das bedeutet nicht, dass jeder im Team die gleichen Fähigkeiten oder Zugriffsrechte hat. Solange das Team über alle erforderlichen Fähigkeiten und Passcodes verfügt, reicht dies für ein agiles Framework aus.
  2. Agile Teams bauen auf Vertrauen auf. Wenn die Nachricht lautet: „Wir vertrauen Bob das Root-Passwort nicht an“, dann liegt ein grundlegendes Problem mit der Zusammensetzung oder dem Entwicklungsprozess Ihres Teams vor. Wenn es jedoch um eine Aufgabentrennung geht (wie es in einigen Umgebungen unabhängig vom Framework der Fall ist), ist es völlig in Ordnung, Teams sich selbst organisieren zu lassen, um die Tatsache zu berücksichtigen, dass ein Teil des Zugriffs auf einer Need-to-know-Basis erfolgt.
  3. Agile Teams sind für die Selbstorganisation und das Selbstmanagement verantwortlich. Wenn das Risiko besteht, dass jemand im Team einen kritischen Dienst versehentlich außer Gefecht setzt, sollte das Team über Backups, Rollback-Pläne, Disaster-Recovery-Pläne und andere Eventualitäten verfügen, bevor es jemanden auffordert, etwas Gefährliches zu tun, unabhängig von seinem Level der Geschicklichkeit. Dies ist auch eine großartige Gelegenheit für ein funktionsübergreifendes Training!

Ich war in agilen Teams, in denen jeder das Root-Passwort hatte und jeder in die Produktion pushen konnte. Alle Systeme waren jedoch Puppetized, und unsere Infrastruktur war vollständig versioniert. Das Risiko war daher minimal.

Ich war auch in Teams, in denen das Team vollen Zugriff auf die Entwicklung hatte, aber keinen auf QA oder Produktion. Das war auch in Ordnung, da unsere funktionale Verantwortung an diesen Grenzen aufhörte.

Die Aufgabentrennung ist zwar nicht das DevOps-Ideal, widerspricht aber keinem der agilen Prinzipien, wenn sie richtig implementiert wird. Wenn eine Aufgabentrennung erforderlich ist, legen Sie einfach die Anforderungen fest und lassen Sie Ihr Team sich um die Implementierungsdetails herum organisieren.

Nichts in Scrum sagt, dass alle gleich sein müssen. Ein Scrum-Team muss mindestens über alle Fähigkeiten und Berechtigungen verfügen, die erforderlich sind, um in jedem Sprint ein fertiges Softwareinkrement zu liefern.

Solange es also Teammitglieder mit den richtigen Berechtigungen gibt, sollte das ausreichen.

Andererseits sollte ein Scrum-Team auf seinen „Truck-Faktor“ achten und sicherstellen, dass Fähigkeiten und Wissen im Team verteilt werden. Wenn Sie also nur eine Person mit den Fähigkeiten und Berechtigungen zum Ändern von Produktionsdatenbanken haben, wird dringend empfohlen, dass er sich mit einem anderen Entwickler zusammenschließt, um dieses Wissen zu verbreiten und im Laufe der Zeit sozusagen ein paar Kopien der Schlüssel zum Schloss zu verteilen .

Um zu verhindern, dass die alte Hierarchie wieder auftaucht, sprechen Sie über die Ambitionen des Teams und lassen Sie es Wege finden, um die Fähigkeiten, das Wissen und die Berechtigungen zu verbreiten. Retrospektiven sind ein guter Ausgangspunkt, aber es kann sein, dass Ihr Team einige richtungsweisende Hinweise (auch bekannt als Einschränkungen) erhalten muss, die ihm sagen, dass bestimmte Dinge nicht länger erwünschtes Verhalten sind.

Sie haben Fachwissen vermittelt. Können Sie den Zugang zu Dingen ansprechen, die kein Spezialwissen erfordern?
Wenn nicht viel schief gehen kann, lassen Sie das Team etwas soziale Kontrolle ausüben, um sicherzustellen, dass das Team den durchgeführten Aktionen zustimmt. Stellen Sie sicher, dass sie kommunizieren
Soziale Kontrolle? Sie meinen so etwas wie die Person, die die Schlüssel hält, zu verwanzen, damit sie diese Schlüssel weitergibt, wenn das Team dem zugestimmt hat?
Oder die Änderung beim Daily Scrum erwähnen, schnell prüfen, ob es jemanden gibt, der dagegen ist. Oder erwähnen Sie die nachträglich vorgenommene Änderung, damit sie bei Bedarf rückgängig gemacht werden kann.
Wie handhabt man den Zugriff auf Ressourcen in einem Scrum-Team, das zuvor ein hierarchisches Team war?
AntwortenHierDatenschutz-Bestimmungen1y, 0v