Entwicklungsprojekte managen

Transkript

1 Entwicklungsprojekte managen Iterativ die beste Lösung finden Hardwareentwicklung mit SCRUM Autor / Redakteur: Gregor Groß * / Franz Graser Die Entwicklungsmethode SCRUM ist in erster Linie aus der Softwareentwicklung bekannt. Der Berliner Leiterplatten-Dienstleister alpha-board hat SCRUM für die Hardwareentwicklung adaptiert und berichtet von seinen Erfahrungen. Alles an einer Wand: Das Kanban-Board mit Time Box Clock ist ein wichtiges Hilfsmittel für die Projektplanung. Vor dieser Tafel findet das tägliche SCRUM-Meeting statt. Damit kennt jedes Team-Mitglied den augenblicklichen Stand der Projekte.(Bild: alpha-board) Neue Hardware zu entwickeln, ist an sich schon eine Herausforderung. Diese Entwicklungsprojekte zu managen, ist aber besonders schwer. Ein Grund dafür ist die spezielle Art dieser Projekte. In allen Projekten ist das Problem bekannt: Es geht darum, eine Lösung zu implementieren. Was die Sache bei Hardware-Entwicklung so knifflig macht, ist der Umstand, dass die optimale Lösung erst noch gesucht werden muss. Problem bekannt, Lösung unbekannt allgemein gültige Projektmanagement-Ansätze wie Wasserfall-, Balkenplan- oder Netzplan-Projektmanagement fallen somit aus, denn sie sind nur für die reine Implementierung geeignet. Werden sie trotzdem verwendet, führt das dazu, dass die falschen Ziele erreicht werden, kein Platz fürs Experimentieren bleibt, die Mitarbeiter und Kunden unzufrieden sind. Als Dienstleister für Elektronik-Design und Fertigungsservice haben wir bei alphaboard diese Erfahrungen sehr oft gemacht. Uns wurde klar: Die Hardware-Entwicklung gehört zu einer anderen Art von Projekt, bei der zwar das Problem bekannt ist, die Lösung aber unbekannt ist. Es geht also nicht nur ums reine Implementieren, sondern darum, iterativ die beste Lösung zu finden und diese dann zu implementieren. Traditionelle Projektmanagement-Ansätze sind dafür nicht geeignet. SCRUM - abgeschaut bei der Softwareentwicklung Wenn Software entwickelt wird, ist das ähnlich. Auch dort geht es darum, iterativ die optimale Lösung zu finden und diese auch gleich zu implementieren. Und so wurde in

2 der Software-Industrie das Projektmanagement-Framework SCRUM entwickelt. Dabei sind in der Software-Entwicklung folgende Vorteile zu beobachten, wenn SCRUM eingesetzt wird: Gesteigerte Produktivität des gesamten Teams, Mehr Verantwortung und Motivation für alle SCRUMmer, Schnelle Reaktion auf neue Anforderungen, Mehr Transparenz im Team, Schnellere Entwicklungszyklen mit weniger Fehlern. SCRUM erhöht auch die Zusammenarbeit mit Anwendern und Kunden. So erhält das Team schneller Feedback und kann mithilfe dieses Feedbacks schneller in Richtung optimale Lösung iterieren. Und da auch die Tester ins Team integriert sind und alle Aufgabenpakete bereits von Anfang an auf Testen ausgelegt sind und vor Lieferung an Kunden getestet werden, sinkt die Zahl der ausgelieferten Bugs. Also haben wir uns SCRUM angeschaut und getestet. Einiges muss angepasst werden, weil sich eben das Entwickeln von Soft- und Hardware doch unterscheidet. Ein Unterschied: Hardware entwickeln ist wie Software entwickeln, nur dass man eben nur zwei- bis dreimal kompilieren darf (dann nämlich, wenn wir Prototypen fertigen lassen). Projektmanagement Planning-Poker hilft, den Aufwand für Entwicklungsschritte abzuschätzen Den Aufwand für Hardware-Entwicklungsprojekte zu schätzen, ist schwer. Sicher, die Bestandteile der zu entwickelnden Hardware sind in etwa klar. Für fast alle Projekte gilt aber: Problem bekannt, Lösung unbekannt. Und hier wird es schwierig. lesen Was ist SCRUM? Ein Blick auf die Methode Das Projektmanagement-Framework SCRUM besteht aus drei Rollen für die Projekt-Beteiligten, drei verschiedenen Meetings und drei Artefakten, mit denen das Team arbeitet. Der Product Owner: Der Visionär, der

3 Iterative Vorgehensweise: Aus dem Product Backlog werden die Funktionen sortiert, die im Arbeitsabschnitt (dem sogenannten Sprint) bearbeitet werden. Durch die sich wiederholenden Sprints nähert sich das Team schrittweise dem Endprodukt an. Eine tagesaktuelle Übersicht über das Projekt bietet der Daily Scrum. (Bild: alpha-board) die Produktvision vor Augen hat Das Team: Die Entwickler und Tester, die die optimale Lösung suchen und das Produkt testen und liefern Der SCRUM-Master: Er hilft dem Team, seine Ziele zu erreichen Weil der Product Owner das Produkt vertritt, sollte er engen Kontakt zum Kunden halten (der in unserem Fall als Dienstleister für Elektronik-Design ja die Produktentwicklung bezahlt). Deswegen haben wir uns entschieden, dass der Product Owner aus dem Vertrieb kommt. Ein Kunde selber sollte kein Product Owner sein, denn der Product Owner hat ja auch die Interessen der Firma im Auge zu behalten - und nicht nur das Team hart zu reiten, um die maximale Ausbeute zu sichern. Der SCRUM-Master sorgt dafür, dass das Team arbeiten kann. Dazu gehört es, gegebenenfalls auch Hindernisse aus dem Weg zu räumen. So ein Hindernis kann auch das Management sein, das ständig neue Aufgaben quer verteilt und die Team- Mitglieder vom Arbeiten am Sprint abhält (ein sogenannter Sprint ist ein Arbeitsabschnitt bei SCRUM). Dann hat der SCRUM-Master einzuschreiten und dem Management zu zeigen, warum das Team in seiner Arbeit behindert wird. Neben den drei speziellen Projektrollen gibt es auch drei unterschiedliche Arten von Projekt-Meetings: Sprint Planning: Anforderungen ans Produkt werden in Job Stories zerlegt, die das Team diskutiert und schätzt. Dann wählt das Team aus, welche Anforderungen es im aktuellen Sprint bearbeitet. Daily SCRUM: Tägliches Meeting, um den Fortschritt zu messen, neue Aufgaben zu verteilen und Probleme anzusprechen. Sprint Review & Retrospektive: Im Review am Ende des Sprints werden die im Sprint umgesetzten Funktionalitäten gezeigt und bewertet. In der Sprint Retrospektive versucht das Team, systematisch aus Fehlern lernen, produktiver zu werden, Hindernisse zu beseitigen. SCRUM schafft darüber Transparenz, woran das Team arbeitet, vor allem mit dem Daily SCRUM. Beim Daily SCRUM dürfen alle teilnehmen (auch der Vertrieb und das Management und alle anderen Nicht-Team-Mitglieder). Sprechen dürfen aber nur das Team und der SCRUM-Master, der den Daily SCRUM leitet. Weil SCRUM soviel Transparenz schafft, ist dem Projekt-Team auch die Verantwortung überlassen, wie es sich die Arbeit einteilt. Gleichzeitig wird von Anfang an alles sofort getestet. Falls nötig, wird auch gleich ein dedizierter Tester mit ins Team aufgenommen. Das deswegen, damit von Anfang auch die Erfordernisse des Testens berücksichtigt werden und nicht erst am Ende eines Projekts, wenn es

4 möglicherweise schon zu spät ist. Der Nebeneffekt ist, dass die Talente Ihrer Mitarbeiter sich völlig frei entfalten können und ihre Mitarbeiter Spaß an Ihrer Arbeit haben werden. Verantwortung haben und Spaß haben sind die beiden größten intrinsischen Motivationsfaktoren, die es gibt. Projektbegleitend werden drei Dokumente geführt. Diese SCRUM-Artefakte erleichtern den Überblick über das Projekt: Product Backlog: Enthält alle Funktionalitäten des Produkts, priorisiert vom Product Owner nach Wichtigkeit Sprint Backlog: Die Liste der Aufgaben, die im Sprint Planning entsteht (die das Team abarbeiten muss, um die Funktionalitäten dieses Sprints zu liefern) Burndown Chart: Visualisiert die Arbeit, die im Sprint noch vor dem Team liegt und die Arbeit, die bereits erledigt wurde und ermöglicht so ein Urteil, ob die Arbeit im Sprint geschafft werden kann. Der Ablauf eines SCRUM-Projekts 1. Der Product Owner bespricht (mit dem Kunden) die Vision des Produkts (die darstellt, was mit dem Produkt erreicht werden soll). 2. Der Product Owner erstellt (gemeinsam mit dem Kunden) sogenannte User Stories für das Produkt und bewertet sie nach Wichtigkeit. Eine User Story sieht wie folgt aus: Als [Rolle] möchte ich [Tätigkeit], um [Wert/Nutzen zu schaffen]. Dazu gehören noch Akzeptanz-Kriterien, die bestimmen, unter welchen Bedingungen der Product Owner (und Kunde) die Story als geliefert ansieht. 3. Im Sprint Planning stellt der Product Owner Vision und User Stories dem Team vor (außerdem sind dabei: Team und SCRUM-Master). 4. Das Team schätzt (ohne Product Owner) die Komplexität der User Stories relativ zueinander (zum Beispiel mit dem Planning Poker). 5. Nun werden die User Stories sortiert nach Wichtigkeit und schneller Umsetzbarkeit (schnell und wichtig zuerst, langwierig und unwichtig zuletzt). 6. Aus diesen sortierten User Stories übernimmt das Team diejenigen, die es im ersten Sprint schaffen will, und verpflichtet sich dazu, sie in der vorgegebenen Zeit abzuarbeiten. 7. An dieser Stelle muss das Team auch die eigene Arbeitszeit über die Sprint-Dauer einschätzen (die niemals acht Stunden pro Person pro Tag erreicht, da immer Zeit für andere Dinge wie beispielsweise das Schätzen neuer Anfragen draufgeht).

5 8. Als letzter Schritt des Sprint Plannings werden die Stories in Aufgaben für das Team zerlegt. 9. Dann folgt der Sprint und täglich im Sprint das Daily SCRUM. 10. Am Ende des Sprints erfolgt der Sprint Review im Beisein des Kunden (deswegen vorher einmal Generalprobe im Beisein des Product Owners). 11. Und nach dem Sprint Review folgt dann die teaminterne Sprint Retrospektive, an der auch der SCRUM-Master teilnimmt. 12. Und dann sortiert der Product Owner die User Stories eventuell neu (und neu hinzugekommene dazwischen). 13. Das Team macht wieder ein Sprint Planning für den nächsten Sprint. 14. Und so weiter und so fort, bis alle User Stories abgearbeitet sind. Die während eines Sprints auftretenden Impediments (Behinderungen für das Team) werden im Daily SCRUM angesprochen. Der SCRUM-Master ist dafür verantwortlich, diese Impediments gemeinsam mit dem Management aus dem Weg zu schaffen denn nur ungestört von außen kann das Team sein selbstgestecktes Sprint-Goal erreichen. Wie SCRUM in der Hardwareentwicklung aussieht Es gibt einige Besonderheiten bei uns, weil wir eben Hardware machen und nur wenig Software. So wird beispielsweise für Software gefordert, dass das Sprintergebnis lieferbare (oder ausrollbare) Software sein soll. Daran halten wir uns auch in der Hardwareentwicklung, wandeln das aber ab zu testbar. Es geht hauptsächlich darum, dass wir nicht zwangsläufig am Ende eines Sprints neue Hardware fertigen lassen, die wir liefern. Sondern eben entweder Quick-&- Wichtige Dokumente: Die Burn-Down-Kurve (Vordergrund) und der Sprint Backlog. (Bild: alpha-board) Dirty-Prototypen, die wir selber basteln, oder auch Stromlaufpläne, Layouts oder ähnliches, die auch vom Kunden testbar sind. Oder wir liefern für bereits

6 vorhandene (in früheren Sprints gelieferte) Prototypen-Hardware neue Funktionalität per Firmware. Wir haben alle Projekte des Unternehmens auf unser Kanban-Board gebracht und machen vor diesem Board auch unseren Daily SCRUM. Das hat den Vorteil, dass alle wissen, wo was zwickt, und eventuell untereinander Hilfe-Stellung leisten. Projekte, die unter 20 Stunden dauern, haben nur eine Projektkarte, die wir mit einem Blitz versehen. Nur größere Projekte werden in User Stories und Aufgaben zerlegt. Diese haben aber auch eine Projektkarte. Unser Kanban-Board hat die folgenden Spalten: Projekt (Name, Dauer, Team-Mitglieder) User Stories To Do (dort kommen die Aufgaben rein) WiP (Work in Progress: idealerweise steht hier nur 1 Aufgabe pro Mitarbeiter) Waiting (für Aufgaben, die auf äußere Einflüsse warten, z.b. Nachfragen, Lieferungen oder Freigaben) Done (Fertig) Testing (unterteilt in To Test und Test in Progress ) Ready for Review (zuerst mit dem Product Owner, dann mit dem Kunden) Als Dienstleister müssen wir alle Anfragen erst einmal schätzen, um anzubieten, bevor überhaupt irgendwelche Projekte starten. Wir schätzen mit Planning Poker, weil aus unserer Erfahrung ein Team besser schätzt als einzelne Personen und Planning Poker die Diskussion vereinfacht. Doch selbst dann war unsere Erfahrung, dass die geschätzten Aufwände nicht ganz zur Realität passen und wir oft falsch lagen. Also haben wir noch einen weiteren Schritt eingeführt, das sogenannte Grooming. Das heißt, ein Ingenieur schaut sich die User Story an, stellt Fragen (falls nötig) und beschreibt die geplante Umsetzung der Story. Bevor wir den Aufwand für eine Anfrage schätzen, müssen die einzelnen User Stories erstmal gegroomt werden. Falls Fragen kommen, muss der Product Owner diese mit dem Kunden klären, bevor es mit dem Groomen weiter geht. Der Aufbau unseres Grooming Boards sieht folgendermaßen aus: Ready to Groom (vorher werden die Stories dem Team vorgelesen) Grooming in Process Fragen Ready for Planning Nicht gegroomte Stories werden nicht geschätzt, so lautet eine Vereinbarung mit dem Team. Damit das Team groomen kann, muss es Zeit haben, die von der täglichen Zeit

7 abgeht, die für den Sprint zur Verfügung steht. Das berücksichtigt das Team beim Sprint Planning und es ist auch dem Management bekannt. Fazit: Mit SCRUM wird alles gut Wir arbeiten seit fast einem halben Jahr nach SCRUM, erst in einem Projekt-Team und nun mit allen Projekten unserer Firma. Bis heute lernen wir viel darüber, wie wir noch besser SCRUMmen können. Wir sind auch ganz sicher, dass die Art und Weise, wie wir das derzeit machen, noch nicht perfekt ist. Aber wir wissen, dass wir nicht mehr in die alte, SCRUM-freie Welt zurück wollen. Mit SCRUM haben wir mehr Transparenz, weniger Ärger und mehr Spaß an unserer Arbeit. Literaturhinweise: [1]Boris Gloger: SCRUM - Produkte zuverlässig und schnell entwickeln Hier steht Blindtext für ein[2]mike Cohn: Agile Software-Entwicklung - Mit SCRUM zum Erfolg! *Gregor Groß ist Geschäftsführer des Berliner Elektronik-Designhauses alpha-board. Copyright Vogel Business Media Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter Dieses PDF wurde Ihnen bereitgestellt von

8 Iterative Vorgehensweise: Aus dem Product Backlog werden die Funktionen sortiert, die im Arbeitsabschnitt (dem sogenannten Sprint) bearbeitet werden. Durch die sich wiederholenden Sprints nähert sich das Team schrittweise dem Endprodukt an. Eine tagesaktuelle Übersicht über das Projekt bietet der Daily Scrum. (Bild: alpha-board)

9 Wichtige Dokumente: Die Burn-Down-Kurve (Vordergrund) und der Sprint Backlog. (Bild: alpha-board)