Wie synchronisiert man ein agiles Software-Team mit einem Wasserfall-Hardware-Team?

Unser Team besteht sowohl aus Software- als auch aus Hardware-Ingenieuren. Das Softwareteam verwendet Scrum-Projektmanagement, während das Hardwareteam Wasserfall verwendet.

Die Priorität unserer Softwareanforderungen ändert sich ziemlich häufig, daher ist es für uns sinnvoll, agil zu bleiben. Die Priorität unserer Hardwareanforderungen ist eher statisch und langsam, daher macht es für uns wieder Sinn, beim Wasserfall zu bleiben.

Der knifflige Teil ist die Integration von Hard- und Software. Gibt es Methoden, um diese beiden gegensätzlichen Projektmanagementstile deterministisch zu synchronisieren?

Ich habe einige Zeit bei DO-178B gearbeitet, und wir haben früher Meilensteine ​​festgelegt, an denen Software- und Hardwareteams integriert und vorläufiges Feedback erhalten (Erkennung von Anforderungsabweichungen, neuen Anforderungen usw.). Wir suchen jedoch nach Methoden, die engere Rückkopplungsschleifen beinhalten.

Wie viel Software-Emulation oder -Simulation der Hardware haben Sie? Wie gut definiert ist die Hardware/Software-Schnittstelle – reicht es aus, eine Simulation oder Emulation der Hardware zu implementieren, um die Software bis zu einer vordefinierten Integrationsphase von der Hardware zu entkoppeln? Das große Problem wäre, dass, wenn die Schnittstelle von beiden Sites nicht vollständig korrekt implementiert wird, sehr spät im Prozess Fehler gefunden werden (wenn die Hardware fertig ist).
Vielleicht können Sie die Schwierigkeiten beschreiben, mit denen das Hardware-Team derzeit konfrontiert ist und die es derzeit daran hindern, häufiger zu liefern. Einige Beispiele werden in agilealliance.org/files/session_pdfs/… diskutiert, aber verschiedene Hardware-Teams in verschiedenen Unternehmen könnten vor unterschiedlichen Herausforderungen stehen, da Hardware-Entwicklung ein weit gefasster Oberbegriff für viele verschiedene F&E-Aktivitäten ist.

Antworten (2)

TL;DR Sie sollten Scrum in beiden Teams verwenden.

bei Wasserfall zu bleiben macht für uns Sinn

Es hat keinen Vorteil, wenn ein Hardware-Team einen Wasserfall macht. Tatsächlich gilt es für jedes Team. Die Wahl zwischen ihr und agilen Methoden ist keine einfache Anforderungspriorität. Warum sollten Sie sich an einen Prozess mit langen Vorlaufzeiten, hohen Gemeinkosten und geringer Time-to-Market halten, wenn Sie ihn vermeiden können?

Früher haben wir Meilensteine ​​festgelegt, an denen Software- und Hardwareteams integriert wurden

In Scrum erstellt das Team regelmäßig funktionierende, potenziell auslieferbare Inkremente eines Produkts. Wenn zwei Teams Sprint parallel ausführen, sollte ihre kombinierte Definition of Done auch die Integration abdecken.

Das Ende jedes Sprints ist ein Meilenstein, von dem Sie sprechen. Wenn die kombinierte Ausgabe die Definition of Done erfüllt, sind Sie synchronisiert.

Wir suchen jedoch nach Methoden, die engere Rückkopplungsschleifen beinhalten.

Noch mehr Gründe, Wasserfall ganz aufzugeben :) Möchten Sie nicht, dass Ihr Hardware-Team in einem Monat statt in einem Jahr etwas Wertvolles liefert?

Außerdem ist es sinnvoll, in allen Ihren Projekten die gleiche Methodik zu verwenden - das vereinfacht zumindest das Lernen. Sie könnten jeden anderen agilen Ansatz mit dem Hardware-Team verwenden, aber diese Vielfalt wird Ihnen nicht gut tun.

Die Umstellung Ihres Hardware-Teams auf Scrum wird sicherlich helfen. Wie Steve McConnell jedoch sagte:

...wenn Sie sich zu 100 Prozent auf eine einzelne Methodik einlassen, werden Sie die ganze Welt in Bezug auf diese Methodik sehen. In einigen Fällen werden Sie Gelegenheiten verpassen, andere Methoden anzuwenden, die für Ihr aktuelles Problem besser geeignet sind.

Nehmen wir also an, Wasserfall funktioniert gut für Ihr Hardwareprojekt und Sie müssen nur die beiden synchronisieren.

Ich würde empfehlen, den Release-Plan als Abhängigkeitspunkt zu verwenden. So wie Apple eine neue iPhone-Version ankündigt, sollte Ihr Hardware-Team eine neue Hardware-Version ankündigen. In Ihrem Fall haben Sie das Glück, die Funktionsliste vorher zu kennen.

Das Softwareteam wiederum sollte Releases entsprechend planen. Es müssen 1-2 Reserve-Sprints durchlaufen werden, wenn sich die Veröffentlichung des Hardware-Teams verzögert.