Wir haben den Arbeitsablauf unserer Gruppe mit großem Erfolg auf einen Scrum-basierten Ansatz umgestellt. Wir erledigen Dinge, die Menschen sind engagierter und wir konzentrieren uns mehr auf die tatsächlichen Bedürfnisse unserer Benutzergemeinschaft.
Da wir an Prozessen statt an Tools arbeiten mussten, verwenden wir physische Karten auf einem Backlog Board und einem Task Board. Das funktioniert ziemlich gut, obwohl wir wahrscheinlich irgendwann zu einer elektronischen Version wechseln werden, da wir anfangen, mehr Remote-Teammitglieder zu bekommen.
Dies funktioniert sehr gut für User Stories in der richtigen Größe. Doch wie gehen wir mit Dingen um, die eigentlich zu klein für eine User Story sind? Manchmal handelt es sich dabei um Bugs/Defekte oder manchmal nur um wirklich kleine Funktionsanfragen oder Verbesserungen. Zum Beispiel hängt unsere Gitorious-Installation ein überflüssiges san Repository-Namen an, wenn man einen Klon erstellt. Es wäre schöner, wenn nicht.
Man könnte für so etwas User Stories schreiben (was wir auch tun), aber a) es fühlt sich übergewichtig und überhaupt nicht „agil“ an und b) solche Stories werden unweigerlich unter größeren, wichtigeren Dingen eingeplant, obwohl sie re oft Low Hanging Fruits (geringer Aufwand für kleine, aber spürbare Ergebnisse).
Oder man könnte einen separaten Issue-Tracker haben. Das geht jedoch plötzlich von einem Ort, um nach Arbeit zu suchen – dem Scrum Task Board – zu zwei Tools. Gibt es eine gute Möglichkeit, diese Dinge zu integrieren, damit sie nicht gegeneinander wirken?
Oder man könnte diese Dinge einfach aus dem Prozess herauslassen und sie sich gegenseitig durch den Raum zurufen. Es besteht die ernsthafte Gefahr, dass dies zum De-facto - Prozess wird, wenn ich dies nicht behebe. Wenn dies funktioniert, ist es im Grunde in Ordnung, aber es ist problematisch, weil a) es die Produktivität stören kann, wenn Menschen durch ungeplante Unterbrechungen von ihrer anderen Arbeit abgelenkt werden, und b) wenn diese Probleme nicht sofort behoben werden, können sie es (wie der Titel der Frage) bekommen fallen gelassen.
Wir haben eine Karteikarte auf unserem Board, die dauerhaft im Backlog sitzt und mit "Technical Debt" beschriftet ist. Jedes Teammitglied kann sich eine Haftnotiz schnappen und TD aufschreiben, von denen es glaubt, dass wir sie sammeln. Wenn sie beispielsweise wissen, dass eine Codierungsentscheidung später zu Komplikationen führen könnte, kleben wir sie auf die Karte für technische Schulden.
Zu Beginn jedes Sprints überprüfen wir alle angesammelten Haftnotizen. Wenn wir das Gefühl haben, dass es Schulden gibt, die wir im neuen Sprint abbauen können, und es an sich keine richtige Geschichte ist, fügen wir diese als Aufgaben hinzu. Wir überprüfen auch noch einmal, ob sich die eingezogenen Schulden auf die Stories auswirken, an denen im Sprint gearbeitet werden soll.
Ziemlich oft landen einige der "Kleinigkeiten", die Sie erwähnt haben, in der TD-Sektion. Wir neigen dazu, in jedem Sprint eine Handvoll von ihnen auszuschalten, nur um sicherzustellen, dass wir den Überblick behalten. Wir weisen ihnen keine Punkte zu (da es sich um Aufgaben handelt, nicht um Geschichten), aber große Arbeitsstücke werden vermieden, es sei denn, sie sind absolut kritisch.
Ich persönlich bevorzuge Haftnotizen. Es ist taktiler und interaktiver als ein Softwaretool (obwohl ich zu meiner eigenen Vernunft eine Tabelle pflege). Das Team neigt dazu, sie aus Neugier durchzumischen, wenn sie am Brett sind. Ich bezweifle, dass sie sich die Zeit nehmen würden, ein Softwaretool an ihrem Schreibtisch zu durchsuchen.
Sie sagen, Sie müssen an Prozessen statt an Tools arbeiten. Im Allgemeinen sind bei erfolgreichem Scrum die Einzelpersonen und Interaktionen noch wichtiger als die Prozesse und die Tools. Wenn sich das Team also nur gegenseitig auf Fehler hinweist und das funktioniert, warum nicht weitermachen?
Im Moment bietet Ihnen die leichte Art der Interaktionen wahrscheinlich viele Vorteile - vielleicht die Reaktionsgeschwindigkeit, das Gefühl, Teil eines Teams zu sein, und die Tatsache, dass es nicht aufgeschrieben wird, sondern muss behoben werden, bevor die Leute es vergessen.
Was erhoffen Sie sich angesichts der Vorteile von den Prozessen? Möchten Sie die Qualität verfolgen (denken Sie daran, dass die leichtgewichtige Kommunikation ohnehin dazu beiträgt, sie zu verbessern)? Für wen und was interessiert sie wirklich? Wen interessieren die kleinen Dinge, die verfolgt werden?
Oder fallen die Kleinigkeiten tatsächlich weg? Wenn ja, haben Sie die Auswirkungen dem Team mitgeteilt und sie gebeten, Lösungen zu finden? Sie könnten tatsächlich in Betracht ziehen, zwei Tools oder eine etwas umfangreichere Dokumentation zu haben, die es wert ist, für eine höhere Qualität in Kauf genommen zu werden - aber Sie werden es nicht wissen, es sei denn, Sie fragen die Jungs vor Ort, und sie werden besser als jeder andere wissen, wie die Balance ist Hier.
Es geht darum, Prioritäten zu setzen und Ihre Arbeit zu visualisieren.
Ihr Scrum Board muss nicht nur auf große Storys beschränkt sein. Und bitte versuchen Sie nicht, Arbeit ohne geschäftlichen Wert zu bemessen. Viele vergessen, dass die Velocity den „Geschäftswert“ messen soll, der aus dem Product Backlog geliefert wird.
Dies bedeutet, dass es durch all das andere "Zeug" oder "Overhead" begrenzt ist. Aber das bedeutet nicht, dass Sie nicht ALLE Arbeitslisten zusammenführen, wenn es darum geht, die Arbeit zu priorisieren.
Ein Team, mit dem ich zusammengearbeitet habe, hat sich entschieden, zwischen jeder Geschichte ein paar Fehler zu beheben. Diese befinden sich auf unserem Board, Stack-Ranked, aber ohne Größe. Unsere PO priorisiert sie zusammen mit den Geschichten. Wir beobachten dann unsere Fehlertrends, um zu messen, ob wir unsere Technologieschulden in einem gewünschten Tempo halten oder abbauen, während wir die Benutzergeschichten liefern.
Wir haben zwar eine Haftnotiztafel, aber wir verwenden auch Rally, was uns ermöglicht, ein priorisiertes Backlog und eine priorisierte Fehlerliste zu haben, die es uns ermöglicht, diese während der Planung zu einem Sprint-Backlog zusammenzuführen. Wir fügen auch andere "Kleinigkeiten" wie fehlende Unit-Tests oder CI hinzu. Wir haben eine weitere Reihe von Arbeitsvereinbarungen, wenn ein Problem mit „Schweregrad 1“ auch während des Sprints behandelt werden muss. Es kommt auch auf die Tafel.
Alles, was wir sehen wollen, kommt auf die Tafel und wird priorisiert. Es ist großartig für alle, weil wir uns nicht in einem ständigen Konflikt zwischen Tech-Schulden und Business-User-Storys befinden. Wir gleichen sie in jedem Sprint mit Hilfe unseres PO aus und lernen viel darüber, wie wir all unsere Arbeit verwalten.
Ich denke, Lunivore und Durzagott geben einige großartige Ratschläge. Die Verfolgung der technischen Schulden ist sehr intelligent. Wenn etwas nicht mehr als 1 bewertet, müssen Sie nicht wirklich überplanen.
Ein paar Gedanken, um auf dem aufzubauen, was sie gesagt haben (lesen Sie ihre Beiträge, wenn Sie es noch nicht getan haben).
1- Was ist Ihr Unternehmenswert? Sie erwähnen, wie viele dieser Dinge niedrige Priorität haben. Eine Sache, die mir aufgefallen ist, ist, dass wir bei unserer Konzentration auf den Benutzerwert manchmal die Benutzerkosten vergessen. Wenn Sie einem Fehler einen Wert zuweisen, geht es nicht darum, was er dem Benutzer bringt, sondern darum, welche Auswirkungen es für den Benutzer hat, wenn er darauf stößt. Dies ist ein Anti-Wert und muss berücksichtigt werden.
2- Laden Sie niemals zu 100 % auf. Viele Agilisten fördern dieses Konzept. Lassen Sie Ihre Teams nicht so viele Geschichten aufhäufen, dass sie keine Flexibilität haben. Irgendwas wird schief gehen, das tut es immer. Lassen Sie im Sprint etwas ungeplante Zeit, um diese Spitzen zu bewältigen.
3- Jetzt beheben vs. später beheben: Der ScrumShortcut-Blog hat einen wirklich guten Beitrag dazu. Das Konzept ist, dass, wenn Sie ein Problem finden, bevor die Story als „Fertig“ markiert ist, es sofort behoben wird. Es ist Teil der Akzeptanzkriterien für die Geschichte und es ist nicht fertig, bis es behoben ist. Wenn der Fehler nach dem Sprint gefunden wird, dann planen Sie ihn im Backlog ein (durzagotts Idee des Tech Debt-Bereichs funktioniert hier hervorragend.)
Fassen Sie sie (solche Geschichten/Aufgaben) zusammen, um einen Klumpen zu bilden, der zu Ihrem Team passt, entsprechend den relevanten Funktionsbereichen. Setzen Sie sie dann in Beziehung und priorisieren Sie sie entsprechend dem Geschäftswert.
Dies würde viel technisches Verständnis und die Fähigkeit der Techniker erfordern, Unternehmen/PO davon zu überzeugen und zu überzeugen, dass diese Geschichten (z. B. langfristige technische Schulden, Fähigkeit, bei Bedarf mehr zu automatisieren, Komponententests , Leistungsoptimierungen usw haben geschäftliches Gewicht.
Ein Scrum ist aus meiner Sicht ein theoretisches Modell, das in Ihrer eigenen konkreten Situation angepasst werden muss. Sie haben Richtlinien zu befolgen, Regeln und Verantwortlichkeiten wie zum Beispiel den Scrum Master; Sie können sie jedoch ändern, wenn Ihr Team der Meinung ist, dass es anders besser funktionieren würde. Ich würde es einfach halten; Treffen Sie sich mit Ihren Kollegen und vereinbaren Sie, wie Sie Ihre täglichen Arbeitsabläufe am besten organisieren: Was behalten Sie bei oder was ändern Sie an diesem Modell? Erfinde etwas, das perfekt zu dir und dem, was du tust, passt. Ich bin sicher, dass Sie alle tolle Ideen haben. Teilen Sie sie einfach miteinander. Ihre Motivation und Lebensqualität am Arbeitsplatz werden deutlich steigen. Sie werden viel Spaß am Innovieren haben. Ich denke, dass das Ziel jedes Managementmodells darin besteht, sich an ein bestimmtes Arbeitsumfeld anzupassen. Ich Ihre Frage,
Zsolt
Ben K