Premierminister, werde agil!
03. Mrz
Es gibt eine britische Website, auf der man online eine Petition an den Premierminister schreiben und unterzeichnen kann. Auf dieser Site findet sich eine neue Petition, die der Regierung empfiehlt, die Art und Weise, wie öffentliche Projekte eingekauft und abgewickelt werden, zu überdenken – in Richtung von inkrementellen und agilen Vorgehensweisen. Der Petitionstext (Übersetzung von mir):
Wir, die Unterzeichner, haben keine Lust mehr, zu hören, wie viel von unserem Geld für fehlgeschlagene IT-Projekte der Regierung verpulvert wird.
Wir glauben, dass dies im Wesentlichen an der Art und Weise liegt, mit der diese Projekte ausgeschrieben und geliefert werden – nämlich, alle Anforderungen eines enormen Projektes im Vorhinein zu verlangen und sich darauf zu verpflichten. Das verurteilt Projekte dazu, fehlzuschlagen noch ehe sie begonnen haben.
Im privaten Sektor hat man sich bereits weitgehend von diesem falschen Modell zu einem inkrementellen Ansatz bewegt, der Änderungen im Verständnis und den Anforderungen erlaubt und die Wahrscheinlichkeit für einen Misserfolg enorm reduziert. Es ist an der Zeit, dass unsere Regierung das auch tut.
Wir bitten den Premierminister, den aktuellen Ansatz auf den Prüfstand zu stellen und für IT-Projekte der Regierung einen mehr inkrementellen und agilen Ansatz in Betracht zu ziehen.
Wow, das sollte hier in Deutschland auch gelten! Wo kann man hier eine ebensolche Petition abgeben? Ich wäre sofort dabei!
Projektverträge: Schlanke Regelungen ersparen Tauziehen
26. Feb
Heute erscheint die neue Ausgabe der Fachzeitschrift OBJEKTspektrum, diesmal mit dem Schwerpunktthema “Lean Development und Kanban”. Darin finden Sie auch einen Artikel von mir über agile Projektverträge. Hier die Zusammenfassung:
Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden “immer” oder “oft” benutzt, fast zwei Drittel hingegen “selten” oder “nie”. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Diese Situation stellt neue “Anforderungen an die Anforderungen”. Der Artikel zeigt, wie Anforderungen heute aussehen können, damit man mit ihnen sehr schlanke Projektverträge gestalten kann. “Money for nothing, changes for free” sind hier die zunächst unglaublich klingenden Stichworte. Auftrag geber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden.
Im Flow arbeiten! Der Kunde wird es danken!
23. Jan
Das folgende kleine Flash-Video habe ich erstellt, um Ihnen zu zeigen, wie es sich auswirkt, wenn Ihr Team traditionell im Stapel arbeitet (z.B. 5 Sachen spezifiziert, dann 5 Sachen entwickelt) oder wenn es im Flow arbeitet und nur 1 Sache spezifiziert, dann 1 Sache entwickelt, usw.
Der rund eine Minute lange Film zeigt anschaulich, wodurch der Unterschied für den Kunden zu Stande kommt. Mehr über Flow gibt es hier.
Aus welcher Mischung entsteht Software? [OOP 2010]
17. Jan
In Italien ist jeder ein Experte für Espresso – alle wissen: “Per un buon caffè, ci vogliono cinque ‘M’: miscela, macinatura, macchina, mano e mente.” (Für einen guten Espresso braucht man die fünf ‘M’: Mischung, Mahlung, Maschine, Hand und Geist).
Ist das in der Software-Entwicklung genauso? Die OOP hat sich ja in diesem Jahr auch so ein Motto auf die Fahne geschrieben: people, process, technology. Prüfen wir doch mal: people = mano e mente, process = macinatura, technology = macchina – nanu, wo bleibt miscela, die Mischung, der Rohstoff, aus dem die Software entstehen kann?
Alistair Cockburn hat diese Frage 2006 in einem Artikel beantwortet: “Software engineering … is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory.” Die Mischung besteht also aus den bisher unvalidierten Entscheidungen, die in der Mühle und der Maschine immer weiter verarbeitet werden, bis der Benutzer seine neue Software in Händen hält.
Beispiele für solche unvalidierten Entscheidungen sind:
- Jede Anforderung ist eine Entscheidung, die auf einem bestimmten Geschäftsklima basiert. Wenn sich das Klima ändert, könnte die Entscheidung falsch werden.
- Eine Architektur ist eine Entscheidung, die auf Technologie und Business basiert. Wenn sich die Technologie verändert bevor die Software genügend Wert für das Business eingespielt hat, ist die Entscheidung verschwendet.
- Jede Zeile Code ist eine Entscheidung, basierend auf Anforderungen, Technologie und Ästhetik. Sollte eines davon obsolet werden bevor die Software genügend Geld für die Firma verdient hat, dann war auch das Verschwendung.
Halten wir also am besten die Zyklen kurz und schlank und erzeugen nur so wenig unvalidierte Entscheidungen wie möglich. Über Anforderungen rasch entscheiden, Entwurf und Programmierung zeitnah durchführen, dem Benutzer lauffähige Systeme in die Hand geben, die er sofort validieren kann. So bleibt der Kaffee frisch, weil die Bohnen nicht lange liegen.
Ich lade Sie ein, mit mir auf der OOP einen Kaffee zu trinken!
Features priorisieren in der Gruppe [OOP 2010]
15. Jan
Mein aktueller Kunde hat ein Stakeholder-Gremium, das sich regelmäßig trifft, um neue Anforderungen zu priorisieren, die das Entwicklungsteam baldmöglichst umsetzen soll. Es besteht aus Vertretern der relevanten Geschäftsbereiche, die jeweils mit einem Teil der Anforderungen im selben lauffähigen System zu unterschiedlichen Zeitpunkten “live” gehen wollen. Die Stakeholder müssen sich also (trotz unterschiedlicher Interessen) auf einheitliche Priorität einigen, die der Product Owner dann dem Entwicklungsteam gegenüber vertritt.
Ausgangssituation: Priorität gemeinsam festlegen
Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:
- Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
- Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
- Was meinen die anderen Stakeholder dazu?
- Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?
Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)
Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.
Spielregeln
Die Spielregeln für “Buy a feature” sind sehr einfach und wirkungsvoll:
- Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
- Jedes Feature hat einen “Preis”, der durch den Entwicklungsaufwand bestimmt wird.
- Stakeholder “kaufen” nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
- Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.
Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.
Die Randbedingungen hatte ich wie folgt gesetzt:
- Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
- Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
- Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste “Launch” des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.
Der Ablauf des Spiels
Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.
Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.
Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.
Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: “Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.” Wer hätte das für möglich gehalten?
Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.
Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: “Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?”. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.
Feedback vor und nach dem Spiel
Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: “Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.” Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.
Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:
- “Die Visualisierung der Entscheidungen ist sehr gut.”
- “Man kommt sehr schnell zu einer Einigung.”
- “Es lockert diese Meetings auf und macht Spaß.”
Tja, da bleibt mir nur ein “Danke” an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!
Wann sollte man nicht agil arbeiten? [OOP 2010]
09. Jan
Gestern war ich in einem Gebäude mit Erdgeschoss und 8 anderen Stockwerken. Der Aufzug brachte mich in den 7. Stock, dann konnte ich mir aussuchen, auf einer Treppe oder mit einem anderen(!) Aufzug in den 8. Stock zu kommen, wo ich den Besprechungsraum, mein eigentliches Ziel, finden würde.
Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”
Allgemeines Gelächter in der Gruppe.
Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.
Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.
Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?
Prozess-Schutzmechanismen und Skipisten
09. Jan
Karl Scotland hat einen sehr interessanten Blog-Post über Sicherheitsmechanismen in Prozessen geschrieben. Seine wesentliche These: Prozesse hängen stark vom Können der Ausführenden ab – so wie es unterschiedlich schwierige Skipisten (schwarze, blaue, …) gibt, so gibt es unterschiedlich stark geschützte Prozesse. Je stärker die im Prozess eingebauen Schutzmechanismen, desto geringer sind unter Umständen Produktivität und die Reaktionsbereitschaft (Agilität). Mehr Risiko ermöglicht höhere Belohnung, bei entsprechendem Können der Skifahrer.
Lesenswert!
Führung, Motivation, Produktivität [OOP 2010]
02. Jan
Thesen zum Einstieg
These 1: Menschen leisten am meisten, wenn sie motiviert sind. Zumindest, wenn das Rennen über eine längere Strecke gehen wird. Kurze Strecken hoher Leistung sind auch rein aus Anstrengung machbar, bei längeren Strecken kommt die Energie am besten aus der Begeisterung. Softwareentwicklung gehört zu den längeren Rennen.
These 2: Softwareentwicklung ist ein Spezialfall von Arbeit mit Wissen, und zwar mit einem Wissen, das nicht von Anfang an komplett vorhanden ist, sondern eines, das wie ein stetiger Strom während der gesamten Projektlaufzeit ins Team fließt.
These 3: Wissensarbeit ist wie ein kooperatives Spiel – es gibt dabei keinen, der vernünftigerweise allein bestimmen könnte, was als Nächstes der beste Spielzug ist. Das gilt insbesondere sogar für den Projektleiter – er muss die Entscheidung über den besten nächsten Zug seinen Mitarbeitern überlassen.
Formen der Führung
Je nach der Komplexität der Arbeit, die die Teams leisten, muss der Führungsstil angepasst werden, damit die Sache ein Erfolg wird. Sehr einfache Arbeit kann man mittels Kommando und Kontrolle managen. Für etwas komplexere Aufgaben sind Zielvorgaben und Belohnung bei Zielerreichung das Richtige. Noch komplexere managt man durch charismatische Führung. Für höchst komplexe Tätigkeiten wie die Softwareentwicklung erreicht man die besten Ergebnisse, wenn man Selbstorganisation zum Prinzip macht. Niemand anderes als das Team weiß am besten, was in der aktuellen Situation zu tun ist. Als Manager nutzt man dieses Wissen und stellt dem Team lediglich eine Dienstleistung namens Führung zur Verfügung.
Robert K. Greenleaf hat vor einigen Jahrzehnten schon Essays dazu verfasst, das gemeinsame Thema hieß Servant Leadership, im Prinzip “Führung als Dienstleistung”. James A. Autry hat Greenleafs Erkenntnisse weiter konkretisiert, in seinem Buch von 2001: The Servant Leader: How to Build a Creative Team, Develop Great Morale, and Improve Bottom-Line Performance. Darin finden sich einige interessante Kernaussagen:
- Bei Führung geht es nicht um das Steuern von Leuten; es geht darum, für Leute zu sorgen und eine nützliche Ressource für die Leute zu sein.
- Führung bedeutet nicht, der Boss zu sein; es geht darum, für Leute präsent zu sein und eine Gemeinschaft am Arbeitsplatz aufzubauen.
- Bei Führung geht es nicht um die Verteidigung von Territorium; es geht darum, Ihr Ego loszulassen, Ihren Geist mit zur Arbeit zu bringen und Ihr bestes und möglichst authentisches Selbst zu sein.
- Führung befasst sich nicht so sehr damit, Anfeuerungsreden zu halten, sondern damit, wie man einen Platz schafft, an dem Leute gute Arbeit machen können, darin einen Sinn finden und ihren Geist zur Arbeit mitbringen.
- Führung ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.
- Führung erfordert Liebe.
Motivation und Produktivität
Wenn ich die obigen Kernaussagen von Autry lese, denke ich “Wow, so möchte ich als Teammitglied geführt werden!” Ein Manager ist in der Lage, eine Umgebung für Motivation und gute Arbeit zu schaffen, wenn er diese Sätze tief verinnerlicht und danach handelt. Nebenbei: Dann wird ihm sein Job auch richtig Spaß machen, weil er mit dem, was sein Team braucht, in Resonanz kommt.
Produktivität stellt sich dann durch Selbstorganisation des Teams ein, bei der der Manager lediglich Unterstützung leistet. Soziale Systeme entwickeln Verhalten, sie organisieren sich selbt aufgrund von Regeln, Feedback und Diskurs. Es beginnt mit einfachen Regeln, z.B. “Wir wollen nur Code einchecken, der den Build übersteht und fehlerfrei durch alle Unit-Tests geht.” Wenn jemand eine solche, gemeinsam anerkannte Regel verletzt, indem er schlechten Code eincheckt, bekommt er von den Teamkollegen (und vom CI-Server) Feedback. Er wird sich vermutlich wundern, mit seinen Kollegen ins Gespräch kommen. Zuletzt wird er die Ursache herausfinden und beheben, indem er vor dem Einchecken zunächst seine Arbeitsumgebung aktualisiert, alle Unit-Tests laufenlässt und Fehler lokal behebt, bevor er nochmals eincheckt. Das ist eine Verhaltensveränderung, Selbstorganisation durch Feedback und Diskurs. Die Produktivität des Teams wird ansteigen, weil wieder einer weniger “im Weg steht”.
Der Manager als Mentor
Als Manager oder Coach kann ich diesen Prozess der Selbstorganisation fördern, indem ich genug Quellen für Feedback schaffe, Menschen ermutige, Feedback zu geben und in den Diskurs zu gehen. Ich kann das Team fragen, welche anerkannten Regeln für das gemeinsame Handeln gelten müssen und die Verabschiedung dieser Regeln fördern. Ich kann Regeln auch hinterfragen (lassen), wenn mehrfach gegen sie verstoßen wird oder wenn das Team so reif wird, dass sie weniger Regeln brauchen.
Das alles ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit. 
Schlanke Zeiten [OOP 2010]
29. Dez
Ein paar Gedanken zum Zeitbegriff in agilen Verfahren.
In allen agilen Methoden versucht das Entwicklungsteam, dem Kunden ein gewünschtes Feature möglichst schnell zur Verfügung zu stellen. Das ist ein wichtiger Bestandteil des Entwicklungsprozesses: zeitnahe Lieferung löst zeitnahes Feedback aus und hilft, das Projekt auf der Spur zu halten.
Die agilen Methoden können dabei von den jahrzehntelangen Erfahrungen aus der Lean Production profitieren. Kanban tut das explizit, XP und Scrum tun das implizit. Die Frage ist nur : Was heißt eigentlich “schnell” oder “zeitnah”? Über welche Zeit reden wir da eigentlich?
Lead time
Die für den Kunden interessante Zeit ist eigentlich diese: “Wenn ich heute ein Feature in die Entwicklung gebe, wann kann ich es in der lauffähigen Software erkennen und testen?”. Diese Zeit nennt man in der Lean-Welt lead time. Ihre Einheit ist tatsächliche, abgelaufene Zeit (elapsed time). Sie enthält sowohl die Zeit für den Fertigungs-Workflow (also Analyse, Design, Unit-Test, Implementierung, Integration, etc.) als auch eventuelle Wartezeiten vor der Fertigung, weil das Team gerade noch andere Features zu entwickeln hatte.
Cycle time
Eine andere Zeit, die weniger für den Kunden und mehr für die Entwickler und deren Manager interessant ist, nennt man in der Lean-Welt cycle time. Ihre Einheit ist nicht tatsächlich abgelaufene Zeit (elapsed time), sondern der Rhythmus (engl. cadence), wie oft der Entwicklungsprozess ein Feature fertigstellt. Um den Unterschied zu verstehen, ein Beispiel: Ein GUI-Designer wird beauftragt, eine größere Anzahl bereits fertig entwickelter HTML-Seiten (z.B. 100 Stück) graphisch schön aufzubereiten. Sagen wir, er liefert jede Woche (5 Arbeitstage) 20 Stück, dann beträgt die cycle time pro HTML-Seite 2 Stunden (5 Tage mal 8 Stunden = 40 Stunden, dividiert durch 20 Stück, also 2 Stunden pro Stück).
Littles Gesetz und Work in Process
Wie stehen nun diese beiden Zeiten in Beziehung? Das fand John D.C. Little schon 1961 heraus. Damals formulierte er es so: In einem stabilen Wartesystem (Beispiel: Supermarkt) ist die durchschnittliche Anzahl von Kunden gleich dem Produkt aus Ankunftsrate und der durchschnittlichen Verweildauer im System.
Was heißt das, übertragen auf lead time und cycle time? Nun, die Ankunftsrate ist der Kehrwert der cycle time, die Verweildauer ist gleich der lead time und die durchschnittliche Kundenanzahl entspricht der Anzahl der Features, an denen das Team im Durchschnitt gleichzeitig arbeitet. In der Lean-Welt nennt man das work in process.
Also können wir Littles Gesetz so umstellen: lead time = work in process * cycle time.
Wenn der oben erwähnte GUI-Designer zu viele Aufträge hat, weil er für zu viele Kunden gleichzeitig arbeitet, ist seine work in process sehr hoch, z.B. befinden sich 100 HTML-Seiten bei ihm in Arbeit. Wenn ein Kunde nun eine neue Seite zum “Schönmachen” beauftragt, bekommt er sie erst nach einer lead time von durchschnittlich 5 Wochen zurück (100 Seiten x 2 Stunden/Seite, geteilt durch 40 Stunden pro Woche). Der Kunde wird unzufrieden sein, und der GUI-Designer sollte sich überlegen, ob er nicht mehr Aufträge ablehnen oder seinen Kollegen weitergeben sollte.
Handlungempfehlung
Was lernen wir daraus, wenn wir zu einem Software-Entwicklungsteam gehören oder ein solches managen? Um den Kunden zufrieden zu machen, sollte das Team die lead time optimieren. Das Einfachste ist, die work in process zu reduzieren, also einfach nicht an so vielen Sachen gleichzeitig zu arbeiten. Das Schwierigere ist, die cycle time zu reduzieren, also effizienter zu arbeiten. Dazu braucht es Methode. Wenn Sie Lust haben, zeige ich Ihnen , wie auch das geht. Rufen Sie mich an.
Kanban-Training im Februar 2010
21. Dez
Im Februar gebe ich ein zweitägiges Kanban-Training in deutscher Sprache. Kanban ist ein leichtgewichtiges Prozess-Framework für die Entwicklung von Software. Es überträgt die Kanban-Prinzipien, die ursprünglich im Umfeld von Lean Production entstanden sind, auf die Softwareentwicklung.
Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.
Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!
