Mein Team, das aus Netzwerkarchitekten und Entwicklern besteht, hat Scrum in den letzten Monaten ausgeführt, und das größte Problem, das wir haben, ist, wie wir die BAU-Arbeit aufzeichnen sollen.
Wir betrachten BAU-Arbeit als Dinge, die wiederholbar sind (z. B. Bereitstellung eines neuen Benutzerkontos), die wir von Zeit zu Zeit tun müssen und die überhaupt nichts mit unserem Projekt zu tun haben. Wir können diese Aufgaben nicht an Personen außerhalb des Projekts übertragen, da wir ein kleines Team sind und alltägliche Aufgaben außerhalb des Projekts erledigen.
Wir verwenden ein JIRA-Projekt, um unsere Sprints auszuführen, und haben darüber nachgedacht, Trello oder ein anderes JIRA-Projekt zu verwenden, um unsere BAU-Arbeit zu verfolgen. Wir haben noch keines davon implementiert, da wir noch über mögliche Optionen nachdenken und noch keine Erfolgskriterien identifiziert haben.
Ich habe drei Varianten je nach Art der Unterbrechung von Aufgaben gesehen:
Wenn die Arbeit sehr gleichmäßig verteilt ist, ziehen Sie sie einfach vorher von der Kapazität ab.
Jeder Entwickler im Team hat während jedes Sprints ein einstündiges Einzelgespräch mit seinem direkten Vorgesetzten. Jeder Entwickler muss seine Stundenzettel ausfüllen. In diesem Sprint gibt es eine geplante Feueralarmübung für alle Mitarbeiter im Gebäude.
Wenn die Arbeit vorhersehbar ist, machen Sie eine Geschichte daraus, schätzen Sie sie ein und fügen Sie sie in den Sprint ein.
Nach dem Rollout der neuen Bibliothek benötigt das Schwesterteam Hilfe bei der Implementierung in ihr eigenes Produkt. Fragen oder Schwierigkeiten sind noch nicht bekannt, werden sich aber ergeben, sobald sie ihre Arbeit aufnehmen.
Wenn zufällige Anfragen in zufälliger Frequenz und zufälliger Qualität auftauchen, brauchen Sie jemanden, der das rote Fledermaus-Telefon beantwortet, wenn es klingelt.
Entscheiden Sie sich für eine einzelne Person pro Sprint, die all diese Anfragen bearbeitet . Ihre Arbeit wird wahrscheinlich ständig unterbrochen. Sie produzieren möglicherweise nichts in Richtung des Ziels dieses Sprints. Aber zumindest hielten sich die Unterbrechungen in Grenzen und der Rest des Teams konnte sich auf den anstehenden Sprint konzentrieren. Darüber hinaus ist es einfacher zu messen, wie viel Zeit für diese Aufgaben verloren wurde, als sie an verschiedene Personen zu vergeben und anschließend eine Zahl zu ermitteln.
jede Art von Unterstützungsarbeit.
Mein erster Gedanke ist, dass Scrum für diese Situation nicht geeignet ist und etwas wie Kanban angemessener ist. In Fällen, in denen ein Großteil der Arbeit plötzlich auftretende BAU-Arbeit ist, haben Sie nicht die Vorteile, eine Sprint-Kadenz planen und am Ende regelmäßig eine Reihe von wertschöpfenden Arbeiten liefern zu können. Geringe Mengen an ungeplanter BAU-Arbeit bedeuten, dass Sie am Ende ohnehin mehr Arbeit ziehen, während viele ungeplante und dringende BAU-Arbeiten dazu führen, dass Sie Ihren Plan nicht zu Ende führen können. Ein kontinuierlicher Wertschöpfungsfluss basierend auf Dringlichkeit und Priorität mit Just-in-Time-Planung der Arbeit scheint besser geeignet zu sein. Sie können wählen, ob Aktivitäten wie die Überprüfung der gelieferten Arbeit und Retrospektiven zur Verbesserung des Prozesses in regelmäßigen Abständen oder Just-in-Time durchgeführt werden sollen.
Ein möglicher Bereich, in dem Sie Scrum anwenden können, ist, wenn Ihre Service-Level-Erwartungen für die BAU-Arbeit größer sind als Ihre Sprint-Kadenz. Das heißt – unabhängig davon, wann die BAU-Arbeit hereinkommt, muss der Großteil davon der geplanten Sprint-Arbeit nicht vorgreifen. Es muss möglicherweise immer noch einige kritische Fälle geben, aber denken Sie an Softwareentwicklungsteams, die ein System in der Produktion warten – diese Produktionsbrände, die geplante Arbeiten verhindern, sollten die Ausnahme und nicht die Regel sein.
Unabhängig von der Lösung würde ich für die Verwendung eines einzigen Tools plädieren. Sichtbarkeit ist wichtig, und wenn sich die BAU-Arbeit auf Ihre Projektarbeit auswirkt, wäre es schwieriger, dies sichtbar zu machen, wenn die Arbeit in zwei separaten Tools verfolgt würde.
Nathan Cooper