Wie können Kommunikation und Peer-Reviews in einem verteilten Scrum-Team erleichtert werden?

Da niemand viele Ratschläge zu Softwareprodukten gegeben hat, möchte ich nur darauf hinweisen, dass Team Foundation Server 2012 Preview für weniger als 5 Benutzer kostenlos ist und eine großartige Ressource für die Verwaltung verteilter Teams und die Erleichterung der Kommunikation darstellt.

Um einige der Möglichkeiten hervorzuheben, wie es Ihnen helfen kann:

• Codeüberprüfungen anfordern – Alle Änderungssätze können zurückgestellt und zur Codeüberprüfung an einen anderen Entwickler gesendet werden. Die Benutzeroberfläche ist sehr glatt und der Workflow wird verfolgt, indem automatisch ein Arbeitselement für Sie erstellt wird. Sobald die Codeüberprüfung abgeschlossen ist, können Sie den Änderungssatz aus dem Regal nehmen und ihn mit Ihrer aktuellen Version der Lösung zusammenführen (stellen Sie sich vor, dass dies einem typischen Verzweigungs- und Zusammenführungsszenario sehr ähnlich ist). Wenn Sie eine Codeüberprüfungsrichtlinie durchsetzen möchten, ist dies eine sehr gute Möglichkeit, dies zu tun. Sie können eine Richtlinie für das geschlossene Einchecken festlegen, die eine abgeschlossene Codeüberprüfung vor dem Einchecken erfordert, um dem Änderungssatz zugeordnet zu werden.

• Webzugriff - Es wurde gegenüber der Version 2010 erheblich verbessert, wodurch es viel nützlicher wird. So ziemlich alles, was Sie für ein agiles Sprint-Planning benötigen, ist vorhanden. Priorisieren und verwalten Sie Ihren Rückstand neu, weisen Sie Arbeitsaufgaben, Burndown-Diagramme und vieles mehr zu.

Um Ihre Fragen konkret zu beantworten:

1) Kollaborative Sprint-Planung und Sprint-Review. Normalerweise ist dies am besten in der Mitte der Woche zu tun, weil Sie möchten, dass alle ständig dort sind. Verbringen Sie die erste Hälfte des Tages mit Frühjahrsrückblick und Retrospektive und die zweite Hälfte mit der Sprintplanung (passen Sie nach Bedarf an, vielleicht benötigen Sie für beides nur einen halben Tag). Auf diese Weise erledigen Sie einen Großteil des Verwaltungsaufwands an einem einzigen Tag. Versuchen Sie, während dieser Besprechungen so unauffällig wie möglich zu sein. Schreiben Sie Ihrem Team nicht vor, wie lange etwas dauern soll, sammeln Sie deren Meinung dazu, wie lange sie glauben, dass jede User Story dauern wird, schlagen Sie das von Ihrer Backlog-Priorität ab und fügen Sie dem aktuellen Sprint eine akzeptable Menge an Arbeit hinzu. Ich betrachte Projektmanager eher als Projektvermittler als alles andere. Ihre Aufgabe ist es, Ihre Entwickler in die Lage zu versetzen, ihre zu tun,

2) TFS 2012, wie oben beschrieben

3) Codeüberprüfungsanfragen sind großartig. Möglicherweise müssen Sie sie durchsetzen, indem Sie zunächst eine Richtlinie für das kontrollierte Einchecken erstellen, aber irgendwann können Sie sich hoffentlich davon entfernen, da Ihr Team ihren Vorteil in einer verbesserten Codequalität sieht. Für die Dokumentation ist gesorgt, da die Überprüfung als Arbeitselement Teil der Quellcodeverwaltung ist, also immer vorhanden ist. Dies kümmert sich auch um das Problem, Code-Review-Zeit für Entwicklungszeit zu opfern. Die Code-Review-Zeit wird buchstäblich zu einem Teil der Entwicklungszeit, und Ihr Team wird nicht das Gefühl haben, dass Sie es von seiner Arbeit wegnehmen, um etwas anderes zu tun.

Und noch eine letzte Anmerkung: Ich ziehe es vor, Teamdokumente in die Quellcodeverwaltung zu verschieben, anstatt in Share Point. 2012 wird TFS Änderungen erkennen, die von außerhalb von VS vorgenommen wurden, sodass sie einfach eingecheckt und gewartet werden können. Ich finde, dass ein einziges Repository es dem Team erleichtert, den Überblick über die gesamte Dokumentation zu behalten.

Sie kommunizieren nicht um der Kommunikation willen. Sie setzen kein Kommunikationsmittel ein, wenn Sie keine Botschaft zu übermitteln, keine Botschaft zu empfangen, keinen Boten oder kein Publikum haben.

Ein Teil Ihrer Kommunikation ist die Analyse, wer, was, wo, wann, warum und wie Kommunikation durchgeführt werden muss, dh BEDÜRFNIS. Wenn Sie feststellen, dass sie es nicht wollen, dann brauchen sie es vielleicht nicht ... oder sie brauchen die Botschaft, die Sie zu diesem Zeitpunkt auf diese Weise übermitteln, nicht.

Kommunikation ist einer der größten kritischen Erfolgsfaktoren für den Projekterfolg und es ist sehr, sehr schwierig, sie richtig hinzubekommen. Die Herausforderung besteht darin, die Methoden an das Projektumfeld, die Kultur, die Dynamik und die Persönlichkeiten anzupassen, die Sie an Bord haben. Und Ihr gesamter Entwurf liest sich, als hätten Sie diese Herausforderung nicht gemeistert.

Das erste, was Sie tun müssen, ist, sich das Fachwissen an Bord zu holen, wie man diese Dinge macht. Es gibt Berater, die sich ausschließlich auf diesen Bereich spezialisiert haben. Der zweite Schritt ist die Durchführung einer Stakeholder-Analyse, bei der Sie die meisten der oben genannten 5W- und H-Fragen beantworten würden. Wenn Ihre Analyse richtig durchgeführt wurde und Sie die Konsequenzen dieser Analyse anwenden, sollte die Kommunikation fließen. Schritt drei: Anpassungen.

Hier noch ein Tipp: Erforschen Sie Persönlichkeitstypen und angeborene Verhaltensweisen. Es gibt einen oder zwei Persönlichkeitstypen, die von hochtechnischer Arbeit angezogen werden. Mit diesem Typ oder diesen Typen sind konsistente Verhaltensweisen verbunden, und Sie müssen darauf eingehen, wenn Sie möchten, dass sich Ihre Kommunikation verbessert. Belohnung und Bestrafung werden sehr wenig bewirken.

Während ich dem Kommentar der ersten Antwort im Allgemeinen zustimme (Sie wollen nicht rein strafend sein; Sie brauchen positive Anreize usw.), ist es möglich, Menschen ohne explizite Belohnungen zu motivieren, sich in diese Richtung zu bewegen.

1. Worüber das Management mit den Entwicklern spricht, ist das, worüber sie denken. Wenn das Management nur über Fristen spricht, werden die Entwickler darauf hinarbeiten. Wenn Sie anfangen, sich wöchentlich mit Ihren Entwicklern zu treffen, um den Prozess/die Tools von Code-Reviews zu besprechen, werden Sie feststellen, dass sie anfangen, mehr darüber nachzudenken und sich an dem Prozess zu beteiligen. Wenn Ihre Entwickler so etwas wie meine Entwickler sind, sind die Meetings allein eine Bestrafung (ohne explizit jemanden oder das Team als Ganzes zur Bestrafung aufzurufen). :) Schon ein kurzes 20-30-minütiges Meeting einmal pro Woche hilft ihnen, mehr über den Prozess nachzudenken und zu verstehen, dass das CMM-Ziel wichtig ist. Und im Laufe der Zeit wird das Reden über den Prozess zu Verbesserungen im Prozess führen, und DAS ist es, wo Sie hinwollen. Den Entwicklern die Kontrolle zu geben, um den Prozess zu verbessern, ist ein großer positiver Anreiz. Stellen Sie nur sicher, dass Sie klare Ziele für die Ergebnisse festlegen, und lassen Sie sie herausfinden, wie sie dorthin gelangen.

2. Machen Sie sich die Dinge so einfach wie möglich. Aus diesem Grund müssen Sie mit den Entwicklern zusammenarbeiten, anstatt ihnen nur einen Prozess aufzuzwingen. Sie kennen die Tools besser als Sie (insbesondere wenn es um Code-Reviews geht). Schaffen Sie eine laborähnliche Umgebung, in der jeder experimentieren kann, um den Prozess zu verbessern und zu vereinfachen. Vereinfachen, vereinfachen, vereinfachen. Wenn der Tool-Overhead für eine Codeüberprüfung 2 Minuten beträgt, werden Sie viel mehr Aktion erhalten, als wenn der Tool-Overhead 15 Minuten beträgt. Entwickler werden zu lächerlichen Extremen gehen, um sich 15 Sekunden zu sparen, wenn sie etwas mehr als einmal am Tag tun müssen. Beispiel: Wir haben Subversion in meinem vorherigen Shop verwendet. Um Code-Reviews durchzuführen, musste der Rezensent die geänderten Dateien per E-Mail an den Rezensenten senden, der sie im Dateisystem speichern musste, darauf achten musste, aktuelle Dateien nicht zu überschreiben, einen Diff durchzuführen, Löschen Sie dann sorgfältig die überprüften Dateien, ohne seine bestehende Arbeit zu vermasseln. Dann fand jemand heraus, dass wir Subversion-Patch-Dateien für Code-Reviews verwenden könnten. Plötzlich war der Prozess das Versenden der Patch-Datei, der Prüfer speichert die Patch-Datei und lädt sie in ihren Client, der zeigt, welche Dateien und Änderungen geändert wurden. Es bestand keine Gefahr, dass ihre aktuellen Quelldateien überschrieben wurden, und sie konnten nach der Überprüfung bereinigen oder nicht bereinigen. Es spielte keine Rolle. Entwickler waren nicht glücklicher, sich an Code-Reviews zu beteiligen, aber sie waren weniger unglücklich darüber. Und um nicht zu untertreiben, jemand hat sich eine Verbesserung einfallen lassen; die Verbesserung wurde sofort umgesetzt; Die Entwickler fühlten sich besser, weil sie den Prozess verbessern durften. Dann fand jemand heraus, dass wir Subversion-Patch-Dateien für Code-Reviews verwenden könnten. Plötzlich war der Prozess das Versenden der Patch-Datei, der Prüfer speichert die Patch-Datei und lädt sie in ihren Client, der zeigt, welche Dateien und Änderungen geändert wurden. Es bestand keine Gefahr, dass ihre aktuellen Quelldateien überschrieben wurden, und sie konnten nach der Überprüfung bereinigen oder nicht bereinigen. Es spielte keine Rolle. Entwickler waren nicht glücklicher, sich an Code-Reviews zu beteiligen, aber sie waren weniger unglücklich darüber. Und um nicht zu untertreiben, jemand hat sich eine Verbesserung einfallen lassen; die Verbesserung wurde sofort umgesetzt; Die Entwickler fühlten sich besser, weil sie den Prozess verbessern durften. Dann fand jemand heraus, dass wir Subversion-Patch-Dateien für Code-Reviews verwenden könnten. Plötzlich war der Prozess das Versenden der Patch-Datei, der Prüfer speichert die Patch-Datei und lädt sie in ihren Client, der zeigt, welche Dateien und Änderungen geändert wurden. Es bestand keine Gefahr, dass ihre aktuellen Quelldateien überschrieben wurden, und sie konnten nach der Überprüfung bereinigen oder nicht bereinigen. Es spielte keine Rolle. Entwickler waren nicht glücklicher, sich an Code-Reviews zu beteiligen, aber sie waren weniger unglücklich darüber. Und um nicht zu untertreiben, jemand hat sich eine Verbesserung einfallen lassen; die Verbesserung wurde sofort umgesetzt; Die Entwickler fühlten sich besser, weil sie den Prozess verbessern durften. Es bestand keine Gefahr, dass ihre aktuellen Quelldateien überschrieben wurden, und sie konnten nach der Überprüfung bereinigen oder nicht bereinigen. Es spielte keine Rolle. Entwickler waren nicht glücklicher, sich an Code-Reviews zu beteiligen, aber sie waren weniger unglücklich darüber. Und um nicht zu untertreiben, jemand hat sich eine Verbesserung einfallen lassen; die Verbesserung wurde sofort umgesetzt; Die Entwickler fühlten sich besser, weil sie den Prozess verbessern durften. Es bestand keine Gefahr, dass ihre aktuellen Quelldateien überschrieben wurden, und sie konnten nach der Überprüfung bereinigen oder nicht bereinigen. Es spielte keine Rolle. Entwickler waren nicht glücklicher, sich an Code-Reviews zu beteiligen, aber sie waren weniger unglücklich darüber. Und um nicht zu untertreiben, jemand hat sich eine Verbesserung einfallen lassen; die Verbesserung wurde sofort umgesetzt; Die Entwickler fühlten sich besser, weil sie den Prozess verbessern durften.

Einsetzen. Vereinfachen. Wiederholen.

Im Allgemeinen werden die Leute nichts tun, wenn nichts für sie dabei ist. Wenn es also keine negativen Folgen für ihr aktuelles Verhalten und keine Belohnung/Auszahlung für das Durchlaufen des Peer-Review-Prozesses gibt, werden sie weiterhin tun, was sie tun. Es reicht nicht aus, nur ein Werkzeug zu finden, um etwas zu tun, Sie brauchen Motivation.

Es ist leicht, negative Konsequenzen zu ziehen, wenn zB keine Peer-Reviews durchgeführt werden. Nehmen Sie das Produkt einfach nicht an, wenn es keinem Peer-Review unterzogen wurde, und machen Sie den Hersteller für die Verzögerung seiner Leistung verantwortlich. Oder erzwingen Sie eine Überarbeitung, die ohne Peer-Review aufgefallen wäre.

Aber nur zu bestrafen reicht nicht aus und ist langfristig kontraproduktiv für die Motivation des Teams. Sie müssen das gute Verhalten belohnen. Look & Feel & Form dieser Belohnung hängen von den Motivatoren des Produzenten ab.