Ein Rückstand von "Bite-Size" -Aufgaben parallel zum "Haupt" -Feature-Rückstand?

Nach mehr als zwei Jahren in einer hochsilbernen Entwicklungsabteilung mit dem Namen "einsamer Wolf" haben wir uns für Agile SCRUM entschieden. Groß. Ich mag Agile; Als Entwickler bleiben Sie fokussiert, beschäftigt und produktiv, ohne dass unzählige Stakeholder Ihnen Projekt für Projekt in die Quere kommen, mit der Erwartung, dass sie alle gestern fertig sind.

Es gibt jedoch einen Aspekt der Umstellung auf SCRUM im Vergleich zu unserem aktuellen "Modell", den die Leute außerhalb der Entwicklungsabteilung meines Erachtens nicht im Geringsten mögen werden. Das ist ihre derzeitige Fähigkeit, kleine Änderungen "während Sie warten" zu veranlassen. Ein großer Teil unserer Entwicklung ist nur für den Eigenverbrauch bestimmt, und wir befinden uns größtenteils alle im selben Gebäude. Daher ist es seit Jahren üblich, dass ein Abteilungsleiter oder Manager an einem anderen Ort zum "Codebasis-Eigentümer" einer bestimmten Anwendung kommt und nach kleinen Dingen fragt (manchmal nicht so klein, aber wir sind ziemlich gut darin, keine drei Aufgaben zu übernehmen. Wochenprojekte basierend auf diesen "Drive-bys"). Sogar unser Chef gibt manchmal Dinge weiter, die auf diese Weise zu ihm gebracht wurden. Sehr oft, wenn wir gerade in der fraglichen Codebasis arbeiten, können wir einfach die Quelldatei öffnen.

Mit einer grundlegenden Agile SCRUM-Methodik würden diese Optimierungen entweder als Fehler protokolliert (wir haben eine in einer zuvor konsumierten Story festgelegte Anforderung nicht erfüllt) oder als neue kleine Storys (wir haben alle angegebenen Anforderungen erfüllt, diese Anforderungen waren jedoch unvollständig, vage oder falsch , oder sie haben sich nach der Auslieferung geändert, sobald die Benutzer die neuen Funktionen gesehen haben). In beiden Fällen wäre die überwiegende Mehrheit höchstens Einzeiger, wenn nicht Nullen, und hätte eine relativ niedrige Priorität (das System ist in seinem aktuellen Zustand verwendbar, aber es wäre so viel kühler, wenn ...), dass es unwahrscheinlich wäre, dass dies der Fall ist in einen Sprint gebracht, wenn der Rückstand von oben nach unten gearbeitet wird.

Diese Möglichkeit wurde bei einem Entwicklertreffen als Quelle für aktiven Widerstand gegen unseren Agile-Prozess von anderen Abteilungen angesprochen, die dies als weniger "agil" als unsere derzeitige Fähigkeit ansehen, auf Anfrage kleine Änderungen vorzunehmen. Es ist ein berechtigtes Anliegen, IMO; Die Stakeholder, die hinter der PO stehen, sind sich nicht immer einig, was am wichtigsten ist, da sie nicht alle den gleichen Standpunkt vertreten. In der Regel treffen jedoch nur die Manager die endgültige Entscheidung zeigt im Product Backlog.

Dann wurde eine Lösung vorgeschlagen, die vorläufig "Bonbonglas" genannt wurde (ein anderer Begriff, der weggeworfen wurde, war "Sauciere"). Von den "kleinen Jungs" in den verschiedenen Abteilungen angeforderte kleine Änderungen, die keine Fehler in einer vorhandenen Story sind und die nach Einschätzung des Konsenses oder der Zustimmung des Teams weniger als die Hälfte eines Entwicklertages in Anspruch nehmen Eine sofortige, signifikante, positive Auswirkung auf das Benutzererlebnis wird nach Ansicht des Endbenutzers parallel zum primären Rückstand auf eine Liste gesetzt. Sie würden als "Geschichten" identifiziert, aber vom primären Rückstand der "großen" Geschichten, die der Priorisierung unterliegen, getrennt gehalten. Wenn wir zu irgendeinem Zeitpunkt während des normalen Sprints in einem Bereich des Systems arbeiten, in dem eine dieser Änderungen vorgenommen werden kann, Wenn wir den Tweak trivial machen, können wir den Tweak in den Sprint bringen und ihn neben der größeren Story codieren. Dies tundarf die Fertigstellung der größeren Geschichte oder einer anderen engagierten Arbeit nicht gefährden. Die PO hätte auch Zugriff auf diese Liste, und wenn sie an einer bevorstehenden User Story arbeiten würden, die die Grundfunktionen des Tweaks berührt, könnten sie diese als Anforderung in die Story einbinden, und dann würden wir die Anforderung wie gewohnt erfüllen andere. Dies sollte die Wahrscheinlichkeit erhöhen, dass an Optimierungen früher als später gearbeitet wird.

Dies löste bei denen von uns mit ScrumMaster-Training die Reaktion von "äh-äh" aus. Es gibt einen Rückstand. In zwei Rückständen wird die Frage gestellt, welches Element Nr. 1 wirklich das wichtigste ist, welche Elemente der Liste die tatsächliche Geschwindigkeit bestimmen und in welchen der beiden Rückstände eine Story tatsächlich gehört (jede Abgrenzung von Größe / Komplexität wird einige Fälle haben, die relativ abnehmen beliebig nach der einen oder anderen Seite). "Lass den Prozess funktionieren", sagten wir; Wenn die Änderung für die Endbenutzer wirklich von Bedeutung ist, verursachen sie genug Lärm, damit die Abteilungsleiter Zeit- und Geldentscheidungen an Bord treffen können.

Ich dachte, ich würde die Frage zu Wort kommen lassen: Wäre Ihrer Meinung nach eine parallele Liste von "Bite-Size" -Geschichten nützlich, um kleine, nützliche, aber letztendlich weniger prioritäre Änderungen zu beschleunigen, oder ist dies insgesamt eine bessere Entscheidung? sie in den Hauptstau zu bringen und den grundlegenden Prozess ihre Einbeziehung in einen Sprint bestimmen zu lassen?

Ich werde über einige Punkte sprechen, die Ihnen hoffentlich helfen werden, Ihren Weg zu finden:

1. Bei " SCRUM " geht es darum, agil zu sein. Gesunder Menschenverstand ist erforderlich. Wenn die Änderung nur wenige Minuten dauert, brauchen Sie meines Erachtens keinen Rückstand. Wenn es mehr als 2 Stunden sind, denke ich, sollten Sie es sich noch einmal überlegen. Es sollte nicht alles getan werden, was "leicht zu gewinnen" ist. In SCRUM arbeiten Sie nach Prioritäten. Ich denke, dass die PO die Informationen darüber erhalten muss, was Sie durch die Hinzufügung und den damit verbundenen Aufwand gewinnen. Nur dann kann die Bestellung entscheiden, ob es wichtig ist oder nicht. Der Wechsel zu SCRUM ist manchmal mit vielen Fragen verbunden, und Entwickler werden oft sagen, "aber das dauert nur ein paar Stunden". Na und? Wenige Stunden sind Zeit, nicht alles, was kurz ist, muss einbezogen werden.
2. Ich habe einmal bei einem Projekt gearbeitet, bei dem wir einen "technischen Rückstand" hatten . Dieser Rückstand enthielt Elemente, die von den Entwicklern zur Verbesserung des Produkts vorgeschlagen wurden. Diese Elemente hatten keinen expliziten Benutzerwert (aber einen impliziten Benutzerwert). Beispiel: Refactoring einer Komponente im Code. Wir hatten die Änderung, den Aufwand und den Gewinn beschrieben (in diesem Fall können Sie dem Benutzer nichts präsentieren. Wenn diese Umgestaltung jedoch dazu führt, dass neue Funktionen schneller entwickelt werden, ist dies definitiv ein Gewinn für den Benutzer). Unser PO entschied, dass wir während der Version 10% jedes Sprints (im Durchschnitt) in solche Gegenstände investieren sollten. Als der PO vor jedem Sprint über den Rückstand des bevorstehenden Sprints entschied, stellte er sicher, dass wir 10% der Enginerring-Rückstandselemente hatten. Also 2 Versionsstau -> 1 Sprintstau.
3. Puffer - Wenn Menschen anfangen, in SCRUM zu arbeiten, vergessen sie oft, dass wir als Softwareentwickler in eine Welt der Unsicherheit geraten. Angenommen, Sie haben einen Sprint von 15 Tagen, dh Sie haben zusätzliche 30 Stunden für Besprechungen, für Dinge, die zu lange gedauert haben, und ja, auch für die Kleinen Dinge, die zu unbedeutend sind, um sie sich zu merken, aber Teil unserer täglichen Arbeit sind.
4. Konzentriert bleiben - Last but not least ist es in SCRUM wichtig, konzentriert zu bleiben. Entscheiden Sie, wie viel und welche Priorität Sie insgesamt haben, um in solche Aufgaben zu investieren, und denken Sie daran, diese Zeit und Mühe zu investieren. Driften Sie nicht, um an "kleinen Dingen" zu arbeiten, nur weil sie klein sind. Sie haben eine PO, die Ihnen bei der Entscheidung hilft, und Sie haben Ihren gesunden Menschenverstand.
5. Bleiben Sie agil - und vergessen Sie am Ende nicht, verschiedene Methoden auszuprobieren, um das Problem anzugehen. Fragen Sie sich, ob dies tatsächlich der beste Weg ist. Verbessere den Weg.

Viel Glück :)

Programmier-Frameworks wie Agile und SCRUM sollen Disziplin und Struktur in die Entwicklung einbringen. Disziplin und Struktur scheinen jedoch die Antonyme für Spaß und Kreativität zu sein. In der Regel müssen Sie härter arbeiten, um Disziplin aufzubauen und aufrechtzuerhalten. Es ist sehr schwierig, ein Gleichgewicht zwischen diesen gegensätzlichen Konzepten zu finden. Frameworks meiden daher das Thema.

Bei meinem letzten Projekt stellten wir fest, dass die Entwickler jeden Tag ein wenig Zeit brauchten, um ihre Köpfe aufzufrischen oder zu reinigen. Ihnen wurde budgetierte Zeit (0,5 Stunden / Tag oder 2,5 Std./Woche) eingeräumt, in der sie alles tun konnten Grund (mit der Möglichkeit, auf etwas bei der Arbeit angewendet zu werden). Um die Dinge diszipliniert zu halten, wurden sie gebeten, ihre Aktivitäten zu dokumentieren, damit sie Anerkennung für Leistungen usw. erhalten konnten. Ein bestimmtes Budget für "das Bonbonglas" passte in unsere Zeitpläne und verhinderte, dass die Dinge außer Kontrolle gerieten.

Übrigens nannten wir unser Projekt "Coolness" und es war die Quelle vieler guter Ideen und Verbesserungen in diesem Unternehmen.

Sie sollten die kleinen Geschichten im Hauptstau behalten.

Ich stehe ähnlichen Problemen gegenüber, wie Sie sie beschreiben, obwohl ich kein Scrum verwende. Ich sehe, dass Sie vor Herausforderungen wie Priorisierung und Effizienz stehen .

Es hört sich so an, als ob nach Ihrer "alten Art" implizit jeder befugt war, seine Aufgabe zur aktuellen "obersten Priorität" zu machen, wenn er das Büro eines Entwicklers besuchte. Dies hat einige Vorteile. Der Anforderer hat das Gefühl, beantwortet zu werden, und sowohl der Anforderer als auch der Entwickler erhalten einen "schnellen Gewinn".

Der Nachteil ist, dass das häufige Einfügen dieser Aufgaben die mit dem Produktbesitzer vereinbarten Aufgaben mit höchster Priorität verlangsamt oder beeinträchtigt. (Randbemerkung: Oft unterschätzt jeder die Zeit, die für diese "schnellen" Korrekturen benötigt wird.)

Ich habe die Erfahrung gemacht, dass der Versuch, eine Aufgabe mit niedriger Priorität unter Druck zu setzen, die Vorteile der Priorisierung untergräbt. Als Entwickler bestätigt mir die Priorisierung, dass ich an dem arbeite, woran der Product Owner mich arbeiten lassen möchte. Die Produktbesitzerin sollte entscheiden, ob sie die zusätzliche Arbeit und das Risiko (so gering sie auch sein mag) übernehmen möchte, eine "nice to have" -Anforderung einzureichen.

Wenn ich Stakeholder auffordere, Prioritäten zu setzen, werde ich oft gefragt: "Können Sie das einfach unterdrücken?". Der implizite Wunsch ist, dass ich die neue Aufgabe magisch erledige, ohne die derzeit höchste Priorität zu beeinträchtigen.

Was mir häufig passiert, ist, dass Stakeholder LargeImportantProject und SmallLessImportantTask anfordern. Das Dilemma ist, sollte SmallLessImportantTask auf die Fertigstellung von LargeImportantProject warten (oder eine Straßensperre haben)? Es gibt Kompromisse, und ich habe die Erfahrung gemacht, dass der Produktbesitzer entscheiden muss. (Wenn der Product Owner nicht entscheidet, muss das Entwicklungsteam raten.)

Ein Ziel von scrum (und des Projektmanagements im Allgemeinen) ist es, Hindernisse für Aufgaben mit höchster Priorität zu vermeiden. Wenn Sie effizienter werden, haben Sie weniger Platz für zusätzliche "schön zu haben" -Aufgaben.

Die Effizienz kann beängstigend sein, aber ich habe gesehen, dass die Vorteile die Kosten in zweierlei Hinsicht überwiegen.

1. Wenn Sie effizienter werden, steigern Sie die Kapazität Ihres Teams, um wertvolle Arbeit zu erledigen.
2. Wenn eine Anfrage wirklich ein "nice to have" ist, ist es wahrscheinlich absolut legitim, dass die Anfrage wartet, bis wichtigere Geschäftsprioritäten angesprochen werden.

Meiner Meinung nach; Ihr Problem ist die Art und Weise, wie Aufgaben im Backlog priorisiert werden. Zum Beispiel könnte "Priorität" sowohl die Wichtigkeit als auch die Geschwindigkeit berücksichtigen, mit der es abgeschlossen werden kann. Etwas, das nicht so wichtig ist, aber in 10 Minuten erledigt werden kann, hat möglicherweise eine höhere Priorität als etwas Wichtigeres, dessen Implementierung mehrere Wochen in Anspruch nimmt.

Ich habe jetzt eine Weile in Agile gearbeitet. Ich kann nur folgendes sagen: Es gibt Situationen, in denen es absolut falsch ist, auf einer Methodik zu bestehen und alles, was sie beinhaltet. Sie müssen AGIL sein, und die Anpassung einer Methodik an bestimmte Situationen ist, IMO, ein Muss.

Wie Avi oben sagte - "SCRUM" handelt von Agilität. Gesunder Menschenverstand ist erforderlich. Wenn die Änderung nur wenige Minuten dauert, brauchen Sie meines Erachtens keinen Rückstand.

Wenn die Änderung einige Zeit in Anspruch nimmt, bedeutet dies, dass sie nicht "harmlos" ist und gut dokumentiert werden sollte.

Aufgrund Ihrer ersten Frage und der anschließenden Klarstellung habe ich festgestellt, dass Ihre Schwachstellen sind

• Ständig wechselnde Anforderungen
• Unfähigkeit für Entwickler, sich auf andere Bereiche der Anwendung zu konzentrieren, z. Wir sind Helden in einem Teil der Anwendung, möchten aber keinen anderen berühren.
• Unterschiedliche Architekturansätze, Lösungen, Frameworks werden übernommen
• Der Prozess zum Sammeln von Anforderungen scheint nicht zu funktionieren

Wenn Scrum anfangs korrekt eingehalten wird, sollten viele dieser Probleme behoben und, was noch wichtiger ist, andere Probleme in den Vordergrund gerückt werden, die behoben werden sollten.

- Sich ständig ändernde Anforderungen

Ein einziger Rückstand, in den alles eingespeist wird und der korrekt priorisiert wird, sollte bedeuten, dass das Team während der Entwicklungsphase nicht die Hauptlast der sich ändernden Anforderungen tragen sollte. In einem sehr dynamischen Umfeld sollten kleinere Sprints von 1 bis 2 Wochen sicherstellen, dass sich die Prioritäten in relativ kurzer Zeit noch ändern lassen.

- Unfähigkeit für Entwickler, sich auf andere Bereiche der Anwendung zu konzentrieren, z. Wir sind Helden in einem Teil der Anwendung, möchten aber keinen anderen berühren.

Ein Scrum-Team, das gut zusammenarbeitet und sich gegenseitig unterstützt, das Wissen innerhalb des Teams austauscht und die Herausforderung sucht, an anderen Teilen der Anwendung zu arbeiten, wird sicherstellen, dass das Wissen über die Anwendung geteilt wird. Einige Praktiken wie das Programmieren von Paaren können Menschen dabei helfen, ihre Angst vor der Arbeit an Code, mit dem sie nicht vertraut sind, zu überwinden und gleichzeitig dieses Wissen zu erlernen und weiterzugeben. Dies kann einige Sprints dauern, bevor das Wissen über die Anwendung zwischen den Teams verteilt wird und die Mitarbeiter in einem beliebigen Bereich der Anwendung problemlos arbeiten können. Dies kann auch dadurch gefördert werden, dass man es Leuten ermöglicht, Aufgaben eines Boards zu übernehmen, dh selbst zu entscheiden, was sie arbeiten möchten.

- Unterschiedliche Herangehensweisen an Architektur, Lösungen und Rahmenbedingungen

Scrum erleichtert eine bessere Kommunikation, erleichtert Teamarbeit und Entscheidungsfindung und bietet einen besseren Einblick in das, was vor sich geht. Dies wiederum sollte die organisatorischen Entscheidungen hinsichtlich der Verwendung von Frameworks, Architekturlösungen usw. erleichtern, und die Verwendung eines Scrum-of-Scrums-Mechanismus kann dazu beitragen, dies in der gesamten Organisation durchzusetzen.

- Prozess der Anforderungserfassung

Auch hier gilt: Wenn Sie sich strikt an Regeln halten und eine Anforderung nicht klar definiert und bereit ist, damit das Team verstehen und abschätzen kann, was zur Erfüllung der Anforderung erforderlich ist, sollte sie nicht in den Sprint einbezogen werden. Nehmen Sie eine weitere Anforderung an, die hohe Priorität hat und genau definiert wurde. Dann wissen Sie, dass Sie diese erfüllen können! Möglicherweise wird der Prozess zum Sammeln von Anforderungen nicht sofort behoben, die erforderlichen Änderungen werden jedoch erzwungen, um diesen Prozess zu beheben.

Um Ihre erste Frage zu beantworten, sollte es keine zwei getrennten Rückstände geben. Zu jeder Zeit ist es im besten Interesse aller, dass die Entwickler und die Organisation zuerst an den Elementen mit der höchsten Priorität arbeiten. Prioritäten sollten hauptsächlich auf dem Geschäftswert basieren, und es ist durchaus möglich, dass viele der kleinen Optimierungen und Anforderungen den Geschäftswert erhöhen. Lassen Sie den Produktbesitzer das entscheiden.

Ich bin seit über 7 Jahren ein Scrum-Meister und habe bei der Einführung von Scrum in vielen verschiedenen Teams und Unternehmen mitgewirkt. Meiner bescheidenen Meinung nach und aufgrund meiner Beobachtungen habe ich das Gefühl, dass Sie, wenn Scrum zum ersten Mal in Ihre Organisation eingeführt wird, dem Buch folgen sollten. Nicht abweichen Scrum erfordert Disziplin, um sich an die Praktiken und Prozesse halten zu können. Es ist zu einfach, Ausnahmen zu machen, um bestimmte Umstände zu berücksichtigen, und wenn dies zu früh getan wird, führt dies zu einer Abnutzung der damit verbundenen Vorteile und Werte. Mach die Grundlagen, mach sie wirklich gut. Werden Sie ein Experte für die Grundlagen und verstehen Sie, warum diese vorhanden sind, und ändern Sie dann den Prozess, um besser zu passen und die kontinuierliche Verbesserung in Ihrer Organisation voranzutreiben.

Es gibt sehr gute Gründe, dies als "agil" zu bezeichnen. Wir müssen also bereit sein, den Prozess zu ändern, aber es gibt einen signifikanten Unterschied zwischen einem selbstgesteuerten, selbstorganisierenden Team, das den Prozess versteht, und der Diskussion von Änderungen, die vorgenommen werden könnten der Prozess, im Gegensatz zu einem Team, das gerade erst anfängt, den Weg von Agile oder Scrum zu beschreiten. Es ist, als würde man versuchen zu rennen, bevor man kriechen kann ...