Ich habe gerade mit ein paar Kollegen darüber diskutiert, aber wir sind noch nicht zu einem Ergebnis gekommen. Wir haben eine Reihe von Projekten, die mithilfe von Scrum aktiv gepflegt und entwickelt werden, mit festen zweiwöchigen Sprints, TFS-Backlog-Integration usw.
Wir haben auch ein separates Projekt namens Mobiltec.Framework, das als Erweiterung des standardmäßigen .Net-Frameworks gedacht ist (die meisten unserer Projekte sind C#-Projekte). Dieses Hilfsprojekt soll jedes andere Projekt im Unternehmen mit allgemeiner Funktionalität unterstützen, die nicht an ein bestimmtes Produkt gebunden ist, und befindet sich in einem eigenen TeamProject in TFS, unabhängig von anderen Projekten.
Wir sind gerade dabei, damit neu anzufangen, in einer Migration auf TFS 2013, und ich habe mich sofort gefragt:
Welche TFS-Prozessvorlage werde ich damit verwenden?
Dies ist offensichtlich spezifisch für TFS, aber ich denke, die Frage ist allgemein genug: Was ist die beste Methode, um ein solches On-Demand-Utility-Projekt zu entwickeln? Scrum macht für mich absolut keinen Sinn dafür. Funktionen werden selten hinzugefügt, und es ist ziemlich stabil. Es gibt kein Sprint-Konzept, und wir haben überhaupt kein spezielles Team, das das Projekt abwickelt (jeder Entwickler im gesamten Unternehmen könnte theoretisch Dinge hinzufügen, wenn sie nicht produktspezifisch sind).
Ich denke, es sollte immer noch eine Art Backlog mit Aufgaben / User Stories geben, die darauf abgebildet sind, um zumindest zu verfolgen, was getan wird, aber ich sehe nicht, wie ich das in die gesamte agile Pipeline integrieren sollte. Sollte ich die „Iterations“-Idee einfach komplett ignorieren (sowohl konzeptionell als auch in TFS) und einfach direkt aus der Hauptquelle entwickeln und veröffentlichen und dabei User Stories und Bugs erstellen?
Gibt es ein Beispiel für ein Projekt wie dieses, bei dem die Funktionalitäten alle nach Bedarf sind und es kein intrinsisches Konzept von Sprints oder Iterationen gibt, auf dem ich unser Projekt aufbauen könnte?
In Team Foundation Server 2013 sind standardmäßig 3 Vorlagen für Teamprojekte verfügbar
Alle von ihnen sind agil genug, um Ihren Anforderungen gerecht zu werden, aber ich denke, die ersten beiden sind bequemer. Die Scrum-Vorlage soll die von der Scrum-Organisation definierte Scrum-Methodik unterstützen. Wenn Ihr Projekt jedoch keinen Wert in iterativer und inkrementeller Weise liefern sollte, konfiguriert durch Sprints und Iterationen, steht es Ihnen frei, diese überhaupt nicht zu konfigurieren.
In TFS 2013 gibt es für jedes Teamprojekt einen Befehl „Zeitplan und Iterationen konfigurieren...“. Sie können diesen Teil ohne Konfiguration belassen und die Scrum-Vorlage nur zum Schreiben und Verfolgen von Arbeitselementen verwenden.
Das einzige, was Sie brauchen, ist, dass beim Erstellen eines neuen Arbeitselements die Iteration das Projekt selbst sein sollte. Wenn Sie beispielsweise eine Aufgabe für Mobiltec.Framework erstellen, ist die Iteration der Aufgabe Mobiltec.Framework und nicht Mobiltec.Framework->Release 1->Sprint 1. Dadurch können Sie Abfragen mit einer Klausel „Iteration-> >Mobiltec.Framework' und haben alle User Stories, Bugs, Tasks an einem Ort.
Außerdem können Sie hiermit jede Projektvorlage an Ihre Bedürfnisse anpassen .
Außerdem können Sie in TFS 2013 verschiedene Teams haben, die an demselben Projekt arbeiten, und Sie können den Beitrag jedes Teams zum Projekt sehen.
Hoffe das hilft
Diese Frage wirft für mich eine große Frage auf - ist dies tatsächlich ein Projekt an sich oder etwas, das als Teil anderer Projekte geändert wird? Wenn letzteres der Fall ist, benötigt es möglicherweise nichts anderes als die Quellcodeverwaltung.
Wenn man das TFS-Element aus dieser Frage entfernt, ist Kanban eine agile Methode ohne Timeboxing, die angewendet werden könnte. In diesen Situationen müssen Sie eher auf die agilen Prinzipien als auf Prozesse achten und eine Lösung finden, die Ihren Anforderungen entspricht. Sie könnten dies angehen, indem Sie mit etwas Ähnlichem wie Scrum beginnen und das Timeboxing entfernen, wenn Ihre Erfahrung darin liegt, aber Sie müssen überlegen, wie Sie sicherstellen, dass Sie im Projekt vorankommen (falls dies wichtig ist).
Ich würde vorschlagen, einen Blick auf die MS Kanban 1.0- Vorlage zu werfen. Das ist eher ein kontinuierlicher Bereitstellungsprozess als ein iterationsbasierter Ansatz.
Sie können die jedem Rückstand beigefügten Kanban-Tafeln für einen kontinuierlichen Prozess verwenden.
https://msdn.microsoft.com/en-us/library/jj838789.aspx
Ein kleines Problem:
In VSO (ich habe nicht auf dem neuesten lokalen TFS getestet) funktionieren diese Boards mit Story-/Feature-/Epic-Elementen (Agile-Prozess) und Feature-/Backlog-Elementen (Scrum-Prozess). Das bedeutet, dass sich die Aufgabentafeln, die einzelne Aufgaben pro Story-Swimlane anzeigen, immer noch in Iterationen / Sprints befinden.
Wie andere gesagt haben, scheint Kanban basierend auf Ihren Kriterien eine gute Lösung zu sein. Ich würde Ihnen auch dringend raten, Tools und Verwaltungssoftware zu ignorieren, wenn Sie zuerst überlegen, wie Sie am effektivsten arbeiten können. :)
Bearbeiten: Ich denke, dass das Beginnen mit einem bestimmten Tool oder einer bestimmten Technologie die anfängliche Sicht auf die Arbeit zu stark einschränkt und die potenziellen Ansätze einschränkt. Es wird auch oft (leider) ein Zwang bleiben und das Team wird sich eher daran halten als umgekehrt. Ein klassisches Beispiel ist das Management oder die Stakeholder, die eine bestimmte Ansicht der geleisteten Arbeit haben möchten, z. B. ein Dashboard, und von allen Teams innerhalb der Organisation verlangen, ein „standardisiertes“ Projektmanagement-Tool zu verwenden, das ihnen diese Ansicht zeigt. Der Workflow dieses Tools und die lokalen Teamansichten/-daten werden dann dem Team aufgezwungen und schränken es ein, was sogar seine Kultur und sein Selbstbild als Organisation beeinflussen kann (ganz zu schweigen von den Command-and-Control-/Mangel an Vertrauensproblemen, die es aufweist ). Indem Sie ohne Werkzeugbeschränkungen beginnen, Das Team kann sich eine großartige Möglichkeit einfallen lassen, seine Arbeit lokal zu verwalten und anzuzeigen und sie dann in ein anderes Tool zu übersetzen, indem es einmal pro Woche synchronisiert wird usw., sodass die Anforderungen beider Parteien erfüllt werden. Hoffe, das hilft bei der Klärung. :)
Meiner Meinung nach müssen Sie eine benutzerdefinierte Vorlage erstellen und diese ein wenig abstreifen. Nehmen Sie eine agile Vorlage. Belassen Sie nur zwei Artikeltypen, genau wie im Kanban: „Karte“ und zum Beispiel „Bug/Problem“ nur zur Typentrennung. Dann haben Sie, wie bereits erwähnt, nur eine Iteration, die Projektwurzel ist. Als nächstes erstellen Sie einen Parkstatus „Ausstehend/Rückstand“ und andere Status für in Bearbeitung (Prozessschritte zum Liefern von Artikeln). Denken Sie, dass dies den grundlegenden einfachen Utility-Ansatz abdeckt, da Sie Kanban auf jeden Fall benötigen.
saakisch
Julealgon
Aziz Scheich