Wie wir unser Produktmanagement transformiert haben
Bei sewts automatisieren wir Prozesse, die noch nie zuvor automatisiert wurden. Daher ist es eine besondere Herausforderung, unsere Softwareentwicklung mit unserer Arbeit im Bereich Hardware und Prozessdesign zu kombinieren.
Im vergangenen Jahr haben wir unseren Entwicklungsprozess geändert, um ihn stärker produktorientiert zu gestalten und einige Herausforderungen zu bewältigen, mit denen wir konfrontiert waren. In diesem Insight-Artikel möchten wir unsere Erfahrungen mit beiden Arbeitsmodi teilen.
Unsere Herausforderungen
In unserem Entwicklungsprozess gibt es zahlreiche Herausforderungen:
- Konfigurationsmanagement: Mehrere Systemkomponenten (z. B. Roboter, SPS, das Bildverarbeitungssystem) müssen über Softwarekonfigurationen verfügen, die untereinander und mit den verschiedenen Hardwarekomponenten (z. B. Greifer, Sensoren, Kameras usw.) kompatibel sind.
- Integrierte Funktionen: Es gibt Funktionen, die Bearbeitung von Soft- und Hardware erfordern und daher zwischen unserem Software-Team und unserem Hardware-Team verwaltet werden müssen.
- Abhängigkeiten von Systemkomponenten: Die Implementierung einer Funktion in einer Systemkomponente (z. B. dem ersten Roboter) kann Auswirkungen auf eine andere Systemkomponente (z. B. den zweiten Roboter) haben oder sogar im Widerspruch zu einer Funktion stehen, die gleichzeitig implementiert wird.
- Abweichende Entwicklungszyklen: Software-Entwicklungszyklen sind meist schneller als Hardware-Entwicklungszyklen.
Wenn man das liest, kann man sich wahrscheinlich vorstellen, wie kompliziert es ist, den Arbeitablauf zu strukturieren. Schauen wir uns also an, wie wir es vor unserer Umstellung gehandhabt haben.
Unser vorheriges Vorgehen in der Entwicklung
Lange Zeit arbeiteten unsere beiden Entwicklungsteams sehr unterschiedlich. Während das Software-Team nach der Scrum-Methodik arbeitete und seine Arbeit in Sprints organisierte, hielt sich das Hardware-Team an einen iterativen Prozess auf der Grundlage von Kanban.
Beide Teams organisierten ihre Arbeit getrennt voneinander mit unterschiedlichen Entwicklungszyklen. Die Kommunikation zwischen den Teams erfolgte hauptsächlich über die Teamleiter beider Seiten sowie über informelle Treffen zwischen den Entwicklern.
Es versteht sich von selbst, dass wir sehr von einer produktiven und ausreichenden Kommunikation zwischen den einzelnen Personen abhängig waren, ohne einen Prozess zu haben, der dies steuerte. Die Folge waren viele Fälle, in denen Informationen über die oben genannten Probleme nicht in der erforderlichen Weise weitergegeben wurden, ein Problem auftrat und das System nicht betriebsbereit war oder eine unzureichende Performance erbrachte.
Es musste sich etwas verändern.
Unser neues und verbessertes Vorgehen
Zunächst haben wir ein großes funktionsübergreifendes „Produktteam“ geschaffen, das sowohl Soft- als auch Hardware entwickelt und der Scrum-Methodik folgt.
In jedem laufenden Sprint werden funktionsübergreifende und temporäre Sub-Teams zusammengestellt, um integrierte Funktionen zu implementieren. Diese Sub-Teams organisieren sich selbst und berichten täglich über ihre Fortschritte, wobei das gesamte Team teilnehmen kann, aber nicht muss. Es ist jederzeit klar, an welchen Funktionen parallel gearbeitet wird, was Missverständnissen vorbeugt.
Für diese erstellen wir High-Level-User-Stories, die viel Freiheit, aber auch Verantwortung für die Entwickler und Entwicklerinnen mit sich bringen. Das ist doch das, was man sich von einem Job wünscht, oder?
Zwei Quality-Gates stellen sicher, dass jede Funktion die Geschäfts- und Qualitätsanforderungen erfüllt. Es gibt regelmäßige und aufeinander abgestimmte Releases mit neuen Soft- und Hardwareversionen, die zueinander kompatibel sind und Konfigurationsprobleme auf ein Minimum reduzieren.
So, welche Meinungen gibt es zu unserem neuen Prozess? Bei Fragen oder Anregungen freut sich unser CPO Till auf Nachrichten unter till.rickert@sewts.de. Wir sind gespannt!
