Hier ist das Problem: Wir haben entfernte Teammitglieder. Die meisten von uns befinden sich in West-Washington, aber einige wenige in Texas, und wir verlieren die Teilnahme von Teammitgliedern, weil wir alles auf dem Computer erledigen, entweder lokal oder über Skype for Business und Bildschirmfreigabe.
Nach meiner Erfahrung als Scrum-Master war das effektivste Mittel, um Beteiligung und Investitionen in den Prozess zu gewinnen, Jobs, bei denen wir gedruckte Geschichten verwendeten und sie in einer ungefähr horizontalen Linie parallel zum Boden mit Rückstandspriorität an die Wand des Konferenzraums klebten Reihenfolge. Wir brachten Geschichten in den Sprint, indem wir sie von der Wand lösten und sie unterhalb der unsichtbaren Linie wieder anbrachten. Auf diese Weise konnten wir jederzeit visuell sehen, was im Sprint war, indem wir uns im Raum umsahen. Mit diesem visuellen Hinweis könnten die Entwickler all diese Informationen in ihrem eigenen Tempo verarbeiten und möglicherweise Abhängigkeitsprobleme oder sogar fehlende Geschichten identifizieren. Wir würden Story Points zählen und mit unserer Velocity vergleichen, um zu sehen, wie wir abschneiden.
Dann Aufgaben durch das Anbringen von Haftnotizen mit groben Umrissen, einer Stundenschätzung und wer die Aufgabe erledigen würde. Die Gruppenmitglieder sahen sich alle Geschichten an, baten manchmal um Klärung oder besprachen die grobe Umsetzung und identifizierten fehlende Aufgaben oder Aufgaben, die unterschätzt wurden.
Die eigentliche Frage: Ich suche nach einer alternativen Benutzeroberfläche, die diese „Pulldown“-Metapher auf asynchrone Weise nachahmen kann, die für mehrere Benutzer geeignet ist, sodass entfernte Personen eine Geschichte abrufen oder Aufgaben hinzufügen können.
Wir haben versucht, ein gemeinsames OneNote-Notizbuch zu verwenden, das in einer verteilten Arbeitsgruppe tatsächlich ziemlich gut funktionierte. Jede Story war eine eigene Notizseite, die zwischen zwei Begrenzungsnotizseiten verschoben werden konnte: Die Grenze „In/Out of Sprint“ und die Grenze „Benötigt Story-Entwicklung“ für abgelehnte Storys und Storys, deren Größe angepasst werden musste. Das Exportieren von Storys nach OneNote war mühsam und zeitaufwändig, und das Importieren dieser Storys und Aufgaben zurück in TFS war mühsam.
Da wir uns verpflichtet haben, TFS als Unternehmensstandard zu verwenden, suche ich nach einem Framework, das als Frontend für TFS fungiert.
Haben Sie versucht, Trello dafür zu verwenden? Obwohl wir keine "festen" Remote-Mitarbeiter haben, haben wir mehrere Teammitglieder, die monatelang außerhalb des Büros arbeiten. Wir haben das „Product Backlog“ für jedes Produkt, das der PO pflegt und wir (als Team) gehen dies während unserer Sprintplanung durch und ziehen Stories in das „Sprint Backlog“ und schätzen entsprechend ein.
Wir begannen mit physischen Whiteboards und Haftnotizen, aber das Fotografieren des aktuellen Zustands der Tafel wurde ziemlich mühsam, da der Außendienstmitarbeiter oft dieselbe Geschichte aufgriff wie jemand im Büro, was zu Doppelarbeit führte.
Persönlich mag ich JIRA nicht, und so funktioniert Trello für uns gut, mit Echtzeit-Updates (wenn jemand seine Änderungen auf einer Karte gespeichert hat, wird es für alle anderen angezeigt). Wir haben also separate Listen für jede der Spalten, die wir auf dem Whiteboard hatten (Sprint-Rückstand, in Bearbeitung, QA usw.). Wenn jemand eine Karte aufnimmt, weist er sich ihr zu und verschiebt sie in die entsprechende Spalte (normalerweise ist der erste Schritt Rückstand -> in Entwicklung). Wir verwenden dann die Trello-zu-TFS-Brücke , aber ich habe in der Vergangenheit Zapier verwendet, um bei der Synchronisierung zwischen den beiden zu helfen. Sie müssen immer noch die Kapazität für jede Geschichte ermitteln und mit Ihrer Gesamtgeschwindigkeit vergleichen - Sie sagen nicht, wie Sie verwalten dies derzeit.
Ich glaube immer noch, dass Sie die Kommunikation zwischen den Teams brauchen, also verwenden Sie immer noch Skype und Bildschirmfreigabe, wenn Sie Ihre Sprint-Planungssitzung durchführen, aber Trello gleichzeitig zu haben, sollte sicherstellen, dass Ihre Entwickler so fortfahren können, als ob sie alle am selben Ort wären.
Ich weiß nicht, wie Sie die Sprint-Planung im Büro durchführen, aber ich neige dazu, sie in einem vom Büro getrennten Raum zu haben (weniger PCs, weniger Ablenkungen für Entwickler) und Trello auf den Projektor zu stellen und dann Skype/Google zu verwenden Hangouts für alle, die nicht physisch teilnehmen können.
Trello kann etwas kniffliger werden, wenn Sie an mehr als einem Produkt arbeiten (wie es mein Team tut). Wir müssen diesen Workflow noch glätten, aber es ist in der Regel ein Trello-Board, das mit einem TFS-Projekt synchronisiert wird. Dies ist möglicherweise nicht der Fall für Ihr Team, und es ist immer noch etwas, das ich in meinem eigenen Team verbessern möchte, aber insgesamt ist dies der Arbeitsablauf, der meiner Meinung nach im Moment am besten für uns funktioniert.
Ich habe eine Reihe von Kunden, die Remote-Teams haben. Sie finden VSTeamServices sehr nützlich. Es wird von Teams erstellt, die in drei Zeitzonen arbeiten.
Sie erhalten 5 Benutzer kostenlos und können nach Bedarf skalieren.
https://www.visualstudio.com/en-us/explore/agiletools-vs
Es gibt nur sehr wenige teamorientierte agile Tools, die gut sind. Ich mag Trello für Einzelpersonen, aber es fehlt die Teamunterstützung. Und Jira ist ein Autounfall.
Ich schlage vor, dass Sie jedes Tool ausprobieren und sehen, was für Sie und Ihr Team funktioniert.
Bernstein