Mein Unternehmen hat Scrum vor zwei Jahren eingeführt, und ich denke, wir haben es ziemlich erfolgreich eingesetzt. Ich stehe gerade vor der Aufgabe, einen Teil unserer Entwicklungsorganisation umzustrukturieren, und ich wollte mir Input holen.
Wir haben derzeit 3 Produktteams, die webbasierte, kundenorientierte Anwendungen entwickeln. Wir haben auch ein API-Team, das eine interne API entwickelt, die die anderen Teams verwenden. In den kommenden 2-3 Monaten wird der Rückstand des API-Teams immer kürzer, da das Team die meisten der von den Produktteams geforderten Funktionen geliefert hat. Die Arbeit der Produktteams wird über diesen Punkt hinaus fortgesetzt.
Jemand muss fortfahren und die interne API unterstützen. Diese Arbeit würde beinhalten:
Wir erwägen einige Optionen, wie wir die Teams umstrukturieren können, um dies besser zu unterstützen:
Ich würde gerne weitere Vorschläge hören, die wir möglicherweise vermissen, und auch einen Einblick erhalten, der auf Erfahrungen basiert, die jemand mit einer der oben genannten Methoden gemacht haben könnte (gut oder schlecht). Mein Ziel ist es, eine Struktur zu schaffen, die teamübergreifende Abhängigkeiten (und Blöcke) reduziert und gleichzeitig eine gewisse Überwachung der API bietet.
Alle Links zu zusätzlicher Lektüre, die ich zu diesem Thema machen sollte, sind ebenfalls sehr willkommen.
Danke dir
Ich würde das API-Team überhaupt nicht ändern. Sobald Sie eine Gruppe von Menschen haben, die effektiv zusammenarbeiten, ist es im Allgemeinen am besten, sie zusammen zu lassen.
Erwägen Sie stattdessen, langsam Nicht-API-Arbeiten in ihren Rückstand aufzunehmen, beginnend mit einem niedrigen Mix und stetig steigernd, bis sie ein voll funktionsfähiges Produktteam werden, das auch die API-Experten sind. Dadurch kann diese Fähigkeit vollständig zusammengestellt bleiben, während das Team auch in anderen Funktionen eingesetzt wird. Sie finden es möglicherweise hilfreich für Cross-Training, wenn jemand die Plätze vom API-Team zu einem Produktteam tauschen möchte, aber dies sollte optional und wirklich ein freiwilliges Verhalten auf beiden Seiten sein.
Ich würde wahrscheinlich Lösung 3 wählen, der Grund dafür ist, dass Sie ein klares und definiertes Eigentum an dem Produkt festlegen müssen. Dadurch wird sichergestellt, dass die erforderliche Arbeit erledigt wird (wie von Trevor hervorgehoben) und unnötige Konfliktszenarien minimiert werden.
Der zweite Lösungsvorschlag könnte funktionieren, hängt jedoch stark von den beteiligten Teams, ihrer Motivation und Arbeitsbelastung ab.
Ein Aspekt, der bei der Umstrukturierung Ihrer Entwicklungsgruppen zu berücksichtigen ist, ist die psychologische Wirkung auf Ihre Teammitglieder. Die Reduzierung eines Teams, das es gewohnt ist, ein Rückgrat für die anderen Teams zu sein, kann zu einem Rückgang der Motivation führen. Die Leute, die in der Kerngruppe zurückgelassen werden, sehen es vielleicht so, als ob Sie denken, dass sie nicht so produktiv oder so gut sind wie ihre Kollegen, die in den neuen Produktteams arbeiten mussten.
Ich würde empfehlen, sich mit dem FIRO-Gruppendynamikmodell vertraut zu machen und zu erfahren, wie sich eine Änderung auf Ihre Teammitglieder auswirkt.
Obwohl dies zugegebenermaßen nicht mein Fachgebiet ist, klingt es so, als hätten Sie die Entscheidung fast getroffen, da die Optionen 1 und 3 im Grunde gleich sind. Da es 3 unabhängige Teams gibt, die sich auf die API verlassen, scheint es aus externer Sicht der beste Weg zu sein, ein dediziertes Team damit zu beauftragen. Dadurch wird sichergestellt, dass bei Änderungen die Anforderungen und Bedenken der anderen beiden Teams ebenfalls berücksichtigt werden.
Sie sollten dieses Team unbedingt zusammenhalten – sie sind wahrscheinlich schon seit einiger Zeit zusammen und haben eine etablierte Geschwindigkeit. Sie auf die anderen Teams zu verteilen, wird die bestehende Velocity mit Sicherheit stören und diese Teams möglicherweise wieder in den Forming-Modus versetzen. Wenn die API-Arbeit versiegt, ziehen Sie in Betracht, zusätzlich zur API-Wartung andere Feature-Arbeiten in ihren Rückstand zu fließen, aber ich würde empfehlen, sie nach Möglichkeit zusammenzuhalten.
Darüber hinaus müssen immer mehr Produktorganisationen den Wert ihrer API wirklich verstehen. Behandeln Sie Ihre API als Produkt und stellen Sie sicher, dass alle Bemühungen, sie als solche zu vermarkten, untersucht werden.
Wenn Sie organisatorische Änderungen in einem Softwareunternehmen in Erwägung ziehen, sollten Sie immer das Gesetz von Conway berücksichtigen: http://swreflections.blogspot.com/2012/10/should-you-care-about-conways-law.html
Seien Sie sich der potenziellen Auswirkungen auf Ihre API im Laufe der Zeit bewusst, wenn Sie diese Personen auflösen und ihren Fokus grundlegend ändern. Sie haben jetzt einen Anreiz, sicherzustellen, dass ihre Funktionen funktionieren, verlieren aber möglicherweise den Wert der Standards und der Disziplin aus den Augen, die sie im Laufe der Zeit als Team aufgebaut haben, als sie mit Eigenverantwortung und Stolz an der API gearbeitet haben.
Andreas klar