Meine F&E-Organisation folgt einer agilen (Scrum) Entwicklungsmethodik. Eines der Entwicklungsteams arbeitet hauptsächlich an Punkten, die wirklich problematisch sind, wenn es um die Sicherheit während der Sprintplanung geht. Das bedeutet, dass sie sich hauptsächlich mit Leistungsproblemen befassen, die untersucht und gelöst werden müssen.
Von diesem Team wird erwartet, dass es mit den anderen Teams zusammenarbeitet und dabei der Agile-Methodik folgt. Der Manager des Teams findet es schwierig, da während der Sprintplanung sehr wenig Gewissheit über die Aufgaben seines Teams besteht. Darüber hinaus treten während des Sprints heiße Probleme auf, die eine schnelle Reaktion des Teams erfordern.
Wie könnte dieses Team in diesem Kontext richtig arbeiten? Wie sollen sie ihre Arbeit planen? Sollten sie Zeit für unerwartete Probleme einplanen? Sollten sie ihre Arbeit in Forschungs- und Lösungsteile aufteilen und diese separat planen? Irgendwelche anderen Ideen?
Erstens eignet sich Agilität aufgrund der Unsicherheit und der Möglichkeit, Anforderungen zu ändern, gut für Forschungsprojekte.
Agile ist eher eine Reihe von Richtlinien als eine strenge Methodik voller Regeln. Passen Sie es individuell an Ihr Projekt und Ihre Prozesstoleranz an. Ich würde vorschlagen, dass Sie die folgenden Praktiken anwenden (von denen Sie einige bereits erwähnt haben):
Auch hier geht es bei Agilität um vage Schätzungen der Arbeit im Vergleich zur abgeschlossenen Arbeit in der Vergangenheit. Es geht nicht darum, die Anzahl der Stunden, Minuten oder Sekunden festzulegen, die etwas dauern wird. Solange Sie sagen können: „Diese letzte Aufgabe X war ähnlich und hat Y Punkte, also hat diese Aufgabe auch Y Punkte“, wird Ihre Geschwindigkeit konsistent sein, unabhängig von den genauen Zahlen, mit denen Sie Aufgaben zeigen.
Geteilte Arbeit scheint jedoch natürlich und passt am besten zu den Teams.
Wir arbeiten an einwöchigen Iterationen. Wann immer es eine Aufgabe gibt, die recherchiert werden muss (was bedeutet, dass das Team keine Ahnung hat, wie ein Problem gelöst werden soll, und die Unsicherheit hoch ist), entscheiden wir, wie viele Stunden wir für eine iterative Aufgabe aufwenden möchten, dh . 4 Std. Das bedeutet, dass während der Iteration jemand eine solche Aufgabe übernimmt und nicht mehr als 4 Stunden für die Recherche aufwendet. Was auch immer die Ergebnisse sind, nach Abschluss werden sie auf einem Demonstrationstreffen präsentiert und das Ergebnis wird in der nächsten Planungssitzung verwendet.
Natürlich bringen manchmal die ersten paar Stunden, die für die Recherche aufgewendet werden, zu wenig Wissen, sodass die Recherche in späteren Iterationen fortgesetzt wird. Auch mit Zeitbegrenzung. In unserem Team ist diese Situation jedoch selten. Normalerweise reichen die ersten paar Stunden aus, um zu sagen, worum es bei der Aufgabe geht und wie man damit umgeht.
Natürlich hängt die Anzahl der Stunden, die für die First-Step-Recherche benötigt werden, vom Geschäftsbereich ab. Vielleicht würde es Tag oder länger sein. Oder vielleicht eine Stunde. Bitte bedenken Sie jedoch, dass ausreichend gute Ergebnisse recht schnell sichtbar sind.
Eine Idee ist, historische Daten zu verwenden und zu versuchen, solche Dinge zu planen, also haben wir so viele Wartungsprobleme, so viele Brände zu löschen und einige "normale" Arbeiten zu erledigen. Sie können solche Dinge auch einplanen, also arbeiten wir, egal was passiert, nicht mehr als 50 % der Zeit an der Wartung, da wir auch neue Funktionen fertig haben wollen.
Eine andere Idee ist die Verwendung von Kanban , was wirklich eine Methode ist, die für solche Situationen sehr gut geeignet ist. In diesem Fall versuchen Sie nicht wirklich, eine Art Iteration oder wie auch immer Sie einen Zeitraum von ein paar Wochen nennen, zu planen. Sie reagieren einfach auf das, was gerade höchste Priorität hat.
Tatsächlich funktioniert ein solcher Ansatz für Wartungsteams ziemlich gut. Sie können auch Ihre eigene Lösung optimieren, damit die Dinge in der Prioritätsspur liegen, wo Super-Duper-Aufgaben mit hoher Priorität behandelt werden und so weiter. Es ist also ziemlich einfach, auf sich ändernde Umgebungen zu reagieren.
rwong
Brucezepplin