Organisationsstruktur im Startup

Mir wurde die Rolle übertragen, 5 verschiedene Teams zu leiten (iOS, Android, Backend, Firmware und Hardware (Elektronik)). Alle diese Teams bestehen aus nicht mehr als 4-5 Entwicklern. Es gibt auch ein QA-Team (2 Ingenieure) und sie testen alle Komponenten, entweder Feature oder neue Firmware.

Früher haben alle Teams separat mit ihren eigenen Boards, Backlogs und Sprints gearbeitet. Letzten Monat haben wir mit der Arbeit an Funktionen begonnen, die es in Stories aufteilen, und iOS, Android und Backend auf ein Entwicklungsboard verschoben. Derzeit haben wir 1-2 dynamische Feature-Teams, da einige Features eine unterschiedliche Lebensdauer haben können und unterschiedliche Entwicklerpaare (z. B. iOS+Android+Backend oder FW+Backend usw.) und Einzelpersonen erfordern, die an kleinen Aufgaben/Technologien arbeiten Schulden oder andere Gegenstände.

Ich muss verstehen: - Was wäre die beste Organisationsstruktur der oben genannten Teams? Momentan habe ich keine andere Idee, als weiterhin als kleine Feature-Teams zu arbeiten. - Wie man die Produktivität jedes Teammitglieds innerhalb eines Boards schätzt, in dem wir entweder Funktionen oder einzelne Aufgaben verfolgen. Ich verstehe, dass es besser wäre, die Geschwindigkeit des TEAMs zu verfolgen, aber die Teams ändern sich irgendwie von Funktion zu Funktion und sind nicht stabil genug, um der Geschwindigkeit zu vertrauen.

Vielen Dank im Voraus!

Es scheint mir, als würden Sie zwei unterschiedliche Fragen stellen - eine zur Organisationsstruktur und eine zum Umschalten der Schätzung von Zeit zu Punkten. Vielleicht möchten Sie eine für diese Frage auswählen.
@Sarov, danke, dass du das hervorgehoben hast. Ich habe meine Frage überprüft und eine zur Schätzung entfernt, da ich aus erster Hand eine Teamstruktur organisieren muss.
Es fehlt ein bisschen Hintergrund – irgendwelche Ziele oder Schmerzpunkte, die Sie teilen können? So wie du es beschreibst, scheint die aktuelle, neu geordnete Mannschaftsaufstellung zu funktionieren – warum dann „das Siegerpferd wechseln“?

Antworten (1)

Basierend auf dem, was ich sehe, gebe ich Ihnen zwei Antworten. Wenn ich persönlich vor Ort wäre und einige Beobachtungen aus erster Hand machen könnte, könnte ich wahrscheinlich einen ausgefeilteren Vorschlag machen.

1- Best Case: Am besten nehmen Sie sich jetzt die Zeit, um Ihre Teammitglieder zu einer besseren Cross-Funktionalität zu bewegen. Anstatt einen iOS-Entwickler, einen Android-Entwickler und einen QA-Mitarbeiter zu haben, möchten Sie drei Agile-Entwickler, von denen einer zufällig stärker in iOS, einer in Android und einer in Tests ist.

Die Herausforderung besteht darin, dass dies normalerweise nicht über Nacht geschehen kann, obwohl Sie überrascht wären, wie schnell Sie von funktionalen Silos zu Full-Stack-Entwicklern wechseln können, wenn alle mit der Idee an Bord sind.

2- Schnelle Lösung: Wechseln Sie zu einem Kanban-Workflow, mit starkem Fokus auf Work-in-Progress-Limits. Haben Sie „Icons“ für Teammitglieder (Magnete, Aufkleber usw.), die sie an Storys in der Ready-Warteschlange anhängen können. Wenn alle Personen, die für eine Ready-Story benötigt werden, in der Story vorhanden sind und WIP-Verfügbarkeit in Doing vorhanden ist, verschieben Sie die Story.

Also beendet ein iOS-Entwickler eine Geschichte. Sie sieht, dass die dritte Etage nach unten iOS- und Backend-Arbeit erfordern wird, nur ist noch keine Backend-Person verfügbar. Der iOS-Entwickler sieht sich dann die obigen Geschichten an und sieht, dass eine Android-Person mit einem Firmware-Ingenieur zusammenarbeitet. Sie nimmt an ihrer Kopplungssitzung teil, damit sie mehr über Android erfahren kann, während sie darauf wartet, dass die Backend-Person frei ist. Auf diese Weise können Sie sich im Laufe der Zeit der Best-Case-Lösung nähern.

Ich habe einen „Was mache ich als nächstes“-Workflow, den ich oft mit Teams teile, die ich coache. Hier ist meine Kanban-Version:

  1. Wir vertrauen Ihnen, tun Sie das Richtige.
  2. Gibt es eine Möglichkeit, jemandem bei einer aktuellen Aufgabe zu helfen?.
  3. Kann ich einen Engpass im Workflow beheben (an einer Stelle, an der WIP oder Zykluszeit hoch ist)?
  4. Kann ich an einer noch nicht begonnenen Aufgabe an einer laufenden User Story arbeiten?
  5. Kann ich ausstehende technische Schulden beheben oder das System verbessern?
  6. Kann ich eine neue Story beginnen, die im aktuellen Ready-Rückstand hoch ist?
  7. Kann ich etwas Neues lernen oder meine Fähigkeiten verbessern?
  8. Im Zweifelsfall siehe Nr. 1.
Organisationsstruktur im Startup
AntwortenHierDatenschutz-Bestimmungen1y, 0v