11. Juli 2016 / von Gregor Groß

Unser Kanban-Board für viele gleichzeitige Hardware-Projekte

In unserer Ingenieur-Abteilung arbeiten derzeit 9 Ingenieure an agiler Hardware-Entwicklung und Leiterplatten-Entflechtung. Dabei waren unsere Projekte in 2015 so aufgeteilt: 34 agile Hardware-Entwicklungen (manchmal im Team) und 97 PCB Designs1 (bislang meistens alleine).

Im Arbeitsalltag sah es aufgrund äußerer Abhängigkeiten2 so aus, dass jeder Ingenieur bei uns fast immer mehrere Projekte gleichzeitig verfolgte. Genau das aber stellen wir gerade im Rahmen unserer Einführung von SCRUM für Hardware um. Wie diese Einführung bei uns übrigens läuft, könnt ihr auch in den Blogposts unseres SCRUM-Coaches Marcus Stadelmeier nachlesen:


So oder so, wir brauchten ein Kanban-Board, das uns den Status aller Projekte auf einmal zeigt. Das Kanban-Board ist zugleich der Treffpunkt für unser morgendliches Team-Treffen. Beides ist neu, wir haben das früher nicht gehabt (eine Übersicht über alle Projekte) und nicht getan (tägliches Team-Treffen).

Wir haben uns für ein Kanban-Board mit Schwimmbahnen entschieden, das in seiner gefühlt mindestens zehnten Version mittlerweile so aussieht:


Aufbau unseres Multi-Projekt-Kanban-Boards: allgemeine Infos

Fangen wir bei den Farben an (von oben nach unten):

  • rot sind unsere PCB Designs
  • grün sind unsere agilen Hardware-Entwicklungen
  • orange sind aktuelle Anfragen von Kunden, für die der Vertrieb eine Schätzung braucht

Und so sind unsere Spalten aufgeteilt:

  • Referenz ist die Projektbezeichnung, zusammengebaut aus Kundenkürzel und laufender Projektnummer
  • MA steht für die beteiligten Mitarbeiter (falls von einzelnen Leuten bearbeitet, steht links der Designer, rechts der Tester)
  • Tool bezeichnet das verwendete EDA-Tool, bei uns bevorzugt Altium Designer
  • V steht für den Vertriebler, der das Projekt betreut und manchmal zwischen Ingenieur und Kunden übersetzen hilft
  • Start ist der Anfangstermin, an dem wir mit dem Projekt beginnen (wenn der Auftrag eingegangen ist und alle benötigten Daten eingetroffen sind und wir Zeit haben)
  • Ende ergibt sich rein rechnerisch aus dem geschätzten Aufwand in Stunden geteilt durch 63
  • bei Stunden gestern tragen die Ingenieure die Stunden ein, die sie am vorigen Arbeitstag am Projekt gearbeitet haben
  • diese Stunden werden dann in angefallene Stunden aufaddiert

Beim Ende ist beispielsweise zu beachten, dass dieser Termin noch nicht die Verzögerungen beinhaltet, die entstehen, wenn die Projekte zwischenzeitlich für Freigaben beim Kunden sind. Bei PCB Designs beispielsweise lassen wir uns die Platzierung der Bauteile und das Routing freigeben und lassen die Arbeit in der Regel in der Zwischenzeit ruhen.


Schwimmbahnen

Wir haben festgestellt, dass sich bei PCB Designs bestimmte Arbeiten immer wiederholen. Diese Arbeitsschritte unterteilen jetzt die Schwimmbahn:

  • VORbereitung, wie Ordner einrichten, Abmessungen eingeben etc.
  • SCHematics anlegen
  • LIBrary-Arbeiten
  • PLAtzierung der Bauteile
  • FREIgabe, wo der Termin eingetragen wird, an dem die Freigabe für die Platzierung beim Kunden angefordert wurde
  • ROUting ist die eigentlich Schwimmbahn für den Schwimmer (Magneten), der den Fortschritt anzeigt
  • FREIgabe, hier wird der Termin für die Routing-Freigabe eingetragen
  • AUSgabe der Daten für den Kunden

Für agile Hardware-Projekte konnten wir keine sich in jedem Projekt wiederholenden Arbeitsschritte identifizieren, deswegen tragen die Ingenieure bei ihrem Projekt die Arbeitsschritte ein, die für das Projekt passen. Unten sieht man zwei Projekte, wo das getan wurde.


Der Rest des Kanban-Boards

Danach kommen noch die folgenden Abschnitte:

  • wartet seit wird derzeit nicht benutzt, steht aber für Kommentare zur Verfügung (ist von der letzten Version übrig)
  • Freigabe angefordert: wann wurde die finale Freigabe angefordert?
  • Freigabe erhalten: wann kam die finale Freigabe?
  • zwei unbenutzte Spalten
  • bezahlte Stunden, was einfach eine Anzeige dafür ist, ob es bei dem Projekt schon eine Meilensteinzahlung gab
  • Bemerkungen

Wie man sieht, sind wir zumindest sicher, dass auch diese Version noch überarbeitet werden wird. Daher all die unbenutzten oder noch von früher beschrifteten Spalten.


Tägliche Benutzung unseres Kanban-Boards

Wir benutzen unser Kanban-Board täglich beim Daily SCRUM, unserem Meeting fürs komplette Team. Das Meeting findet immer um 9:30 Uhr vor dem Kanban-Board statt und ist für die gesamte Firma offen, allerdings dürfen nur Entwickler und Ingenieure sprechen4.

Beim Daily SCRUM gehen wir alle Projekte von oben angefangen durch. Ein Ingenieur erzählt, was beim jeweiligen Projekt am vorangegangenen Arbeitstag erreicht wurde, woran er heute arbeitet, ob er Unterstützung braucht, Fragen hat oder unlösbare Probleme. Die abgearbeiteten Stunden werden eingetragen, der Schwimmer wird verschoben.


Strichcode

Hat sich im Projekt nichts ereignet, weil z.B. der Ingenieur an einem anderen Projekt arbeitete oder wir auf Freigaben oder Informationen vom Kunden warten, erhält das Projekt einen Strich. Das haben wir eingeführt, um zu sehen, welche Projekte gerade nicht vorwärts kommen - und vor allem, wo Projekte immer hängen bleiben.

Auf dem Bild oben sind vier Projekte, die ziemlich viele Striche haben. Bei dreien steht in den Bemerkungen, dass sie auf irgendwelche Informationen von außerhalb warten. Nur bei einem steht in den Bemerkungen nichts drin, allerdings warten wir dort auch auf Daten (was mittlerweile in den Bemerkungen nachgetragen wurde). Drin stehen könnte aber auch sowas wie „Am (5 Tage in der Zukunft) Meeting mit allen Beteiligten“ oder „Bis (Datum in der Zukunft) in Produktion“.

Beim Einschätzen von Angeboten gilt das gleiche: wenn das Angebot beim Daily SCRUM auf dem Board steht, erhält es einen Strich. So sehen wir, wie lange so eine Anfrage dort verweilt - und können als Team wahrnehmen und darauf achten, dass wir die Anfragen zeitnah einschätzen.


Fußnoten:

  1. PCB Designs: Leiterplatten-Entflechtungen, Leiterplatten-Layouts, Leiterplatten routen, die Konstruktionsdaten für die Fertigung der physischen Schaltung konstruieren. ↩︎
  2. Abhängigkeiten ist ein SCRUM-Begriff: wo und wann sind wir von Zuarbeiten von außerhalb des Unternehmens abhängig. Bei Leiterplatten-Layouts geht es häufig um Rückfragen oder Freigaben, z.B. bei Platzierung und Routing. ↩︎
  3. Wir gehen davon aus, dass wir im Durchschnitt pro Arbeitstag sechs Stunden produktiv am Projekt arbeiten werden. ↩︎
  4. Alle anderen Teilnehmer nur, wenn sie gefragt werden. ↩︎