Scrum für den DBA?

Ist das Agile/Scrum. Was ist es?

Nein. Das ist Command and Control, verkleidet als Scrum.

Wie passt Scrum auf diese Weise für den Produktions-DBA?

Scrum ist für Arbeit gedacht, die schwer einzuschätzen ist, aber ein gemeinsames Ziel hat, auf das hingearbeitet werden kann. Was Sie beschreiben, ist eher eine Sammlung unterschiedlicher Aufgaben, die entweder geplant oder vollständig ad-hoc sind. Etwas wie Kanban würde viel besser passen.

Auch sooooo viele Scrum-Fehler:

Für alles, was getan wird, werden Punkte vergeben. 1 Punkt entspricht 1 Stunde, 1/2 Punkt entspricht 1/2 Stunde und so weiter.

Punkte in Scrum werden nicht vom Management vergeben, sondern von denen, die die Aufgaben erledigen. Auch Punkte haben keine Übersetzung in Stunden. Im Idealfall haben sie am Ende so etwas wie eine Korrelation.

So wird der DBA jeden Tag gefragt, was im Daily Scrum gemacht wird

Dies ist kein Daily Scrum, sondern ein Statusbericht. Ein tägliches Gedränge ist für das Team, um sich zu synchronisieren und zu entscheiden/zu bestimmen/zu teilen, was getan werden soll. Es ist Sache des Teams, dem Scrum Master Probleme mitzuteilen. Es kommt dem Team zugute, nicht irgendjemand anderem.

Der Manager (der auch ein Scrum Master ist (nein, ist er nicht) ) sagt: Alles, was Sie tun, ist, das Skript einzurichten und das Backup loszulassen. Sie tun nichts, bis die Sicherung abgeschlossen ist. Was sollte der DBA tun? Also keine Punkte für die Überwachung der Server/Datenbanken, da es sich um einen 24*7-Job bzw. einen vollen 8-Stunden-Job für den DBA handelt.

Damit liegt er nicht ganz falsch. Ein Großteil dieser Arbeit kann automatisiert werden. Dennoch müssen Sie Aufgaben nach dem Aufwand planen, der in Ihrer aktuellen Situation erforderlich ist, und nicht nach dem Aufwand, der bei maximaler Automatisierung erforderlich ist. Auch für den Kontextwechsel und die verbleibenden manuellen Schritte muss eine gewisse Zeit einkalkuliert werden.

Ist in Scrum/Sprint die Zeit wirklich mit der Fibonacci-Reihe (0,1,2,3,5,8,13,21 usw.) verbunden, Punkte, die auf die eine oder andere Weise mit der Zeit verbunden sind?

Was Sie beschreiben, ist eine Hilfe , um die Punkte des Rückstands zu schätzen. Die Idee hinter der Verwendung von Fibonacci-Zahlen ist, dass sie dabei helfen, die größere Unsicherheit zu demonstrieren, die der Schätzung größerer Aufgaben innewohnt. Es ist nicht notwendig, dies so zu tun, WENN Sie verstehen, dass Schätzungen auf höherer Ebene weniger zuverlässig sind und dass eine große Aufgabe von X Punkten höchstwahrscheinlich nicht in N Teilaufgaben mit insgesamt X Punkten zerfallen wird.

Aber wieder. Das sind Punkte, keine Stunden! Das Schätzen in Stunden vermittelt dem Uninformierten eine falsche Genauigkeit. Die Leute sind im Allgemeinen schlecht darin, absolute Werte wie Stunden zu schätzen, aber das Management ist wirklich gut darin, sie zu erfassen. Die Menschen sind jedoch viel besser darin, relative Werte einzuschätzen (z. B. ist das Reinigen Ihrer Wohnung mehr oder weniger Arbeit als das Reinigen Ihres Autos?). Die Vorhersagekraft von Scrum ergibt sich nicht aus genauen Schätzungen, sondern aus konsistenten Schätzungen und der Fähigkeit, vergangene Schätzungen mit tatsächlichen Ergebnissen zu vergleichen.

Klingt für mich nach vielen roten Fahnen. Als Professional Scrum Trainer habe ich einige beängstigende Passagen gelesen. Anfangen:

Ja, Scrum und DBA-Arbeit können gut zusammenpassen.

Erstens Schätzung.

Beim Sprint werden Planungsarbeiten geplant und optional geschätzt. Nicht etwas, was Sie während des Daily Scrum tun. Und während relative Schätzungstechniken für Prognosen nützlich sind, sind sie irgendwie nutzlos, um die tatsächliche Arbeit zu planen, insbesondere wenn Sie eine klare Vorstellung von der benötigten Zeit haben.

Sich wiederkehrende Aufgaben anzusehen und sicherzustellen, dass sie Teil des Sprint-Plans sind, ist etwas, das in Scrum passt, es würde während der Sprint-Planung erfolgen. Für diese Dinge, insbesondere wenn die Arbeit bekannt ist, würde ich sie einfach von Ihrer Kapazität für anspruchsvollere Aufgaben abziehen.

Stündliche Schätzungen in direktem Zusammenhang mit Story Points sind ein klarer No-Go-Bereich, insbesondere wenn eine direkte Korrelation von 1 Punkt = 1 Stunde besteht. Es gibt jede Menge Dokumentation zu Story Points, also belasse ich es dabei.

Zweitens, tägliches Gedränge

Das tägliche Scrum dient dazu, den Fortschritt in Richtung des Ziels des Sprints zu verfolgen und den kommenden Tag zu planen. Nicht für "Scoring Point", es wäre mir egal, wie viele Punkte etwas wert ist. Wenn deine Arbeit für den nächsten Tag geplant ist, dem Erreichen des Sprintziels nichts mehr im Wege steht und du dich produktiv fühlst, wäre das das Wichtigste.

Es ist auch ein Moment für das Team, um zusammenzuarbeiten, um einen Plan für die nächsten 24 Stunden zu erstellen. Nicht für einen Moment, um einem Manager den Status zu melden. Der Manager kann den Fortschritt der Arbeit verfolgen, indem er sie visualisiert und durch die Sprint-Überprüfung, zu welchem ​​Zeitpunkt die Arbeit demonstriert und überprüft wird. In Ihrem Fall würden Sie Ihre Arbeit selten direkt demonstrieren, es sollte als Teil anderer Dinge, die in der Umgebung landen, oder durch die Lösung von Problemen, die sich auf Benutzer der Umgebung ausgewirkt haben, offensichtlich sein.

Drittens, die Art der Arbeit

Die Art und Weise, wie Ihre Rolle als DBA oben beschrieben wird, ist ziemlich traditionell. Die Förderung von Schemas zwischen Umgebungen lässt sich recht gut automatisieren.

Viele Überwachungen können so konfiguriert werden, dass sie Warnungen auslösen, ohne dass viel Personal erforderlich ist, um die eigentliche Überwachungsaufgabe auszuführen. Die Zeit, die zum Erweitern von Laufwerken und Zuweisen von Ressourcen erforderlich ist, kann automatisiert werden, oder sicherzustellen, dass Ihnen bei der Erweiterung mehr Speicherplatz zugewiesen wird, ist eine einfache Möglichkeit, den Aufwand für diese Art von Jobs zu reduzieren, indem Sie ihre Häufigkeit reduzieren und optional ihre Auswirkungen begrenzen.

Der Vorgang des Sicherns und Wiederherstellens kann nach einem Zeitplan konfiguriert werden. Manuelle Sicherungs- oder Wiederherstellungsvorgänge können oft auch an andere Mitglieder des Teams delegiert werden und erfordern möglicherweise nicht die Arbeit eines DBA. Gleiches gilt für die Einführung neuer Tool-Versionen, das Platzieren des Installationsprogramms auf einer Freigabe und entweder das Signalisieren von Teammitgliedern, bei Bedarf ein Upgrade durchzuführen, oder die Verwendung von Remote-Verteilungstechniken können diese Dinge einfach auf Desktops, Server usw. verteilen.

Wie geht es weiter

Versuchen Sie, die Arbeit, die automatisiert oder delegiert werden kann, kritisch zu betrachten. Verbringen Sie Ihre Zeit mit der Arbeit, die eigentlich komplex ist und Ihre spezifischen Fähigkeiten erfordert. Arbeiten Sie mit anderen Mitgliedern des Scrum-Teams zusammen, um sicherzustellen, dass sie viele der weniger komplexen Aufgaben ausführen können.

Nutzen Sie die Retrospektive, um Ihre Arbeit und die Arbeit anderer zu analysieren und zu sehen, wo Optimierungen möglich sind.

Arbeiten Sie mit dem Team zusammen, um die Notwendigkeit loszuwerden, „Punkte zu sammeln“. Bei Scrum geht es nicht darum, so viele Aufgaben wie möglich zu erledigen, sondern so wenig wie möglich zu tun, um die meiste Arbeit zu erledigen.

Tricks, um operative Arbeit mit Entwicklung zu verbinden

Teams, die mehr operative Arbeit in ihrem Backlog haben, führen oft ein Product Backlog und einen operativen Kalender. Das Produkt-Backlog enthält Arbeiten, die anfallen, weil neue Funktionen bereitgestellt oder Änderungen an der Umgebung vorgenommen werden. Probleme, die bei wiederkehrenden Inspektionen erkannt werden, können zur Untersuchung und Lösung im Produkt-Backlog landen. Der Betriebskalender enthält alle Arbeiten, die nach einem Zeitplan anfallen und weit im Voraus geplant werden können.

Andere Teams kombinieren Scrum und Kanban. Die Entwicklung neuer Features und größere Änderungen werden über das Product Backlog geplant. Wiederkehrende Arbeiten werden größtenteils automatisiert und Vorfälle werden über eine „Prioritätsspur“ behandelt, die Kanban verwendet und nicht zu Beginn jedes Sprints geplant wird. Im Laufe der Zeit wird das Team lernen, wie viel Zeit für Ad-hoc-Arbeit reserviert werden muss. Diese Arbeitsweise entfernt sich von wiederkehrenden Aufgaben und kalenderbasierten langfristigen Plänen und übernimmt die Arbeit, während sie für einen Teil der Arbeit anfällt. Andere Arbeiten werden durch das Product Backlog geordnet und die Geschwindigkeit des Teams kann verwendet werden, um wahrscheinliche Zeitpunkte zu prognostizieren, zu denen diese Arbeit übernommen wird (in welchem ​​​​Sprint).