Agil oder-ingenieurmaessig

449
-1

Published on

Eine häufig gestellte Frage ist, warum man
agile Vorgehensweisen in anderen produzierenden Branchen nicht antrifft. Gibt es tatsächlich triftige Gründe dafür oder haben
wir in der IT unsere Disziplin nur nicht im Griff und versuchen uns dann mit Dingen wie Agilität zu retten, anstatt uns wie die anderen Branchen auf erprobte Ingenieurstugenden zu besinnen? Oder gibt es Agilität sehr wohl in anderen Branchen, und suchen wir nur an den falschen Stellen?

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
449
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agil oder-ingenieurmaessig

  1. 1. www.bt-magazin.de 2.2010 Deutschland: € 14,90 Österreich: € 16,80 Schweiz: sFr 29,80 Luxemburg: € 16,90 Expertenwissen für IT-Architekten, Projektleiter und Berater Stark: sorgt „Der Kritiker t“ für die Qualitä Was uns die Geschichte lehrt Vorteile von Storytelling in Projekt en Nur Wandel hat Bestand Einführung agiler Methoden Agil oder ingenieurmäßig Agile Entwicklung im Vergleich mit anderen Branchen Enterprise SOA SecuritySonderdruck für Teil 2: Lösungsmusterwww.codecentric.de Der Product Owner im Team So meistern Sie Herausforderungen
  2. 2. Agile Entwicklung Agile Entwicklung im Vergleich mit anderen Branchen Agil oder ingenieurmäßig? AUTOR: UWE FRIEDRICHSEN Auch im Rahmen des Speaker Panels zum Abschluss des Eine häufig gestellte Frage ist, warum man Agile Days auf der JAX 2010 [1] wurde von einem Teil- agile Vorgehensweisen in anderen produ- nehmer aus dem Auditorium die zuvor beschriebene Fra- ge an die versammelten Speaker des Tages gestellt. Das zierenden Branchen nicht antrifft. Gibt es scheinbare Fehlen der Agilität in anderen Branchen wie tatsächlich triftige Gründe dafür oder haben etwa dem Gebäude- oder dem Autobau verursacht bei vielen Beobachtern und Interessenten von agilen Vorge- wir in der IT unsere Disziplin nur nicht im Griff hensmodellen (z. B. Scrum [2] oder XP [3]) häufig gewisse und versuchen uns dann mit Dingen wie Agi- Vorbehalte gegenüber diesen Vorgehensweisen. Sie fra- gen sich, ob nicht einfach das Fehlen einer vernünftigen lität zu retten, anstatt uns wie die anderen ingenieursmäßigen Behandlung der SoftwareentwicklungBranchen auf erprobte Ingenieurstugenden zu – was schon seit vielen Jahren immer wieder bemängelt wird – die IT gezwungen hat, sich mit Themen wie Agilität besinnen? Oder gibt es Agilität sehr wohl in auseinanderzusetzen. Sie fragen sich, ob es nicht sinnvolleranderen Branchen, und suchen wir nur an den wäre, die Softwareentwicklung vernünftig ingenieurmäßig aufzubereiten, um deterministisch eine Produktionsquali- falschen Stellen? tät, wie z. B. im Fahrzeug- oder im Hausbau, zu erzielen, anstatt sich auf Behelfslösungen wie agile Vorgehensmo- delle zu verlassen. Es gibt eine Menge mehr oder minder guter Antworten auf diese Fragen. Auch die Speaker auf der JAX hatten einige (gute) Antworten parat. Verfolgtwww.bt-magazin.de bt | 2.2010 7
  3. 3. man das Thema aber weiter, sind aus Sicht des Autors die Jetzt zur deutlich schwierigeren Frage: Wann ist infolgenden zwei Kernaussagen von essenzieller Bedeutung: der Softwareentwicklung die Entwurfsphase zu Ende und wann beginnt die Bauphase? Und mit „Phase“ ist Softwareentwicklung ist in der Tat anders als andere hier keine Phase im Sinne einer zeitlichen Abfolge wie Ingenieurwissenschaften, da sie einen relativ einma- beim Wasserfallmodell gemeint, sondern eine logisch in ligen Bauprozess hat. sich abgeschlossene Tätigkeit. Unter Berücksichtigung Ein ausschließlich ingenieurmäßiges Vorgehen funkti- der zuvor beschriebenen Definition of Done hat Neal oniert nicht in komplexen Umgebungen, mit denen wir Ford [4] die folgende für viele überraschende Antwort bei der Softwareentwicklung häufig konfrontiert sind. geliefert: Entgegen der weit verbreiteten Ansicht ist die Entwurfsphase nicht am Ende der Designphase zu Ende,Was das im Detail bedeutet, wird im Folgenden genauer sondern erst am Ende der Implementierungsphase. Erstbetrachtet. mit dem Schreiben der letzten Zeile Code ist der Entwurf abgeschlossen. Erst dann sind alle Festlegungen für dasSOFTWAREENTWICKLUNG IST ANDERS zu erstellende System getroffen.Warum kann man z. B. ein Haus oder ein Brücke nicht Und wo bleibt dann die Bauphase? Nun, die ist in deragil bauen? Pavlo Baron, einer der Speaker des zuvor be- Softwareentwicklung aufgrund des virtuellen Werkstoffsschriebenen Panels auf der JAX 2010, hat dazu ein schö- Software so billig, dass man sie häufig übersieht: Die Bau-nes Beispiel gebracht: „Stellen Sie sich vor, man würde phase ist – wie der Name schon andeutet – der Build sowieeine Brücke agil bauen. Es werden zehn Meter gebaut, das Deployment, das Übersetzen des Sourcecodes sowie dasdann lässt man die Autos losfahren und dann ...“ (Pau- Zusammensetzen und Verteilen der fertigen Anwendung.se, gefolgt von Gelächter aus dem Publikum) „... oder Interessanterweise sind wir an dieser Stelle ingenieursmäßigaber wir bauen die Brücke zwar auf der ganze Länge, heute schon so weit, dass wir das vielfach schon auf Knopf-aber nur zehn Zentimeter breit.“ Beides führt nicht zum druck können. Moderne Build- und Deploymentsystemegewünschten Mehrwert für die Anwender. Agiler Brü- können das vollautomatisch. Wir verfügen an der Stelleckenbau macht offensichtlich wenig Sinn. Warum geht über eine Effizienz und Effektivität, von der viele anderees dann in der Softwareentwicklung? Ingenieurdisziplinen nur träumen können. Das Hauptproblem liegt in einer falschen Wahrneh- Woher kommt der häufig gemachte falsche Schnittmung des Bauprozesses in der Softwareentwicklung. zwischen Entwurfs- und Bauphase? Dafür gibt es ausZum besseren Verständnis betrachten wir noch ein- Sicht des Autors zwei Hauptgründe:mal den Brückenbau. Der Brückenbau lässt sich in eineEntwurfs- und eine Bauphase unterteilen. In der Ent- Die Bauphase ist so billig, dass man sie einfach über-wurfsphase werden die Anforderungen an die Brücke sieht. Dadurch, dass das Produkt Software so ungemeingesammelt, diese werden konsolidiert und abgestimmt, günstig zu produzieren (nicht zu entwerfen) ist, gehenes wird eine Lösungsidee entworfen und immer weiter sowohl die Zeit als auch die Kosten für den reinen Bauverfeinert, bis am Ende die detaillierten Baupläne fer- der Software nahezu gegen Null. Das ist ein grundle-tig sind. Die Baupläne sind das finale Design des Brü- gender Unterschied zu den meisten anderen Branchen,ckenbaus. Danach geht es in die Bauphase. Wenn man in denen der Bauprozess sehr aufwändig und teuer ist,nichts falsch gemacht hat und keine ungeplanten Über- wesentlich aufwändiger und teurer als der Entwurfs-raschungen auftauchen, kann man auf Basis der Pläne prozess. Ganz anders in der Softwareentwicklung: Hierdie Brücke komplett bauen, ohne dass noch irgendeine können wir so häufig bauen wie wir wollen. Es kostetweitere Klärung oder Verfeinerung notwendig wäre. uns nur einen Mausklick. Die meisten Leute suchenDas ist die „Definition of Done“ der Entwurfsphase: aber nach einer aufwändigeren Phase und assoziierenDie Entwurfsphase ist abgeschlossen, wenn alle notwen- so die Implementierungsphase fälschlicherweise mitdigen Festlegungen getroffen sind, um das Produkt – in der Bauphase anderer Ingenieurdisziplinen.dem Fall die Brücke – vollständig bauen zu können. Der Begriff „Designphase“ lässt vermuten, dass am Ende Wie sieht das jetzt in der Softwareentwicklung aus? Be- des Designs die Bauphase beginnt. Das ist grundsätzlichginnen wir mit einer einfachen Frage: Was ist das Produkt auch nicht falsch; nur wurden die bis heute üblichen Be-in der Softwareentwicklung? Das ist das ausführbare Pro- griffe in der Softwareentwicklung zu einer Zeit geprägt,gramm, nicht der Sourcecode. Sourcecode interessiert die als Programmierung in der Tat noch Teil der Bauphasemeisten Anwender nicht die Bohne und hat insbesondere war. Zu der Zeit wurden Programme häufig währendauch keinen Mehrwert für sie, ein ausführbares Programm der Analyse und des Designs bis auf Statement-Ebenehingegen schon. So weit, so einfach. spezifiziert und die so genannten Anwendungsprogram-8 bt | 2.2010 www.bt-magazin.de
  4. 4. Abb. 1: Phasenzuordnung Abb. 2: Unterschiedliche Systeme mierer hatten dann die Aufgabe, die fertige Programm- SOFTWAREENTWICKLUNG IST KOMPLEX beschreibung relativ mechanisch in COBOL, PL/1, Kommen wir zur zweiten Aussage: Ein ausschließlich in- Assembler o. ä. zu übersetzen. Diese Art der Aufgaben- genieurmäßiges Vorgehen funktioniert nur in einfachen trennung zwischen Design und Programmierung gibt es und komplizierten Umgebungen, aber nicht in komple- aber schon lange nicht mehr. Entwickler sind Designer xen, mit denen wir bei der Softwareentwicklung häufig und Programmierer in einer Person. Aufgrund des Zeit- konfrontiert sind. Was soll das bedeuten? In der System- und Kostendrucks erfolgen Designs nur noch auf einer theorie und darauf aufsetzenden Konzepten findet man wesentlich gröberen Ebene und werden im Rahmen der die Unterscheidung zwischen den folgenden Typen von Implementierung dann weiter verfeinert. Das eigentliche Umgebungen bzw. Systemen (z. B. [5], [6], Abb. 2). Programmieren ist dabei nur noch Nebensache. Die alte Vorgehensweise kann sich heute niemand mehr leisten, Einfache Systeme zeichnen sich durch einfach nach- weder zeitlich noch monetär. Was geblieben ist, sind die vollziehbare Ursache-Wirkung-Zusammenhänge aus. alten Bezeichnungen. Abbildung 1 verdeutlicht die bei- Es gibt nur wenige Einflussgrößen, die nur schwach den Sichtweisen noch einmal. miteinander verknüpft sind und sich über die Zeit nicht verändern (keine oder nur sehr geringe Dynamik). Pro-Zusammenfassend bedeutet das, dass sowohl die ex- bleme in einfachen Systemen sind leicht zu verstehentrem niedrigen Kosten in der Bauphase als auch eine und zu lösen. Der Lösungsweg lässt sich in klar struk-nicht mehr zeitgemäße Begriffsverwendung zu den turierten Prozessen und so genannten Best Practicesbeschriebenen Verwirrungen beim Vergleich der Soft- für jedermann wiederholbar festhalten. Ein einfacheswareentwicklung mit anderen Branchen geführt haben. Problem ist z. B. das Reinigen eines Fahrzeugs oder dasZusätzlich eröffnen die extrem niedrigen Baukosten in Austauschen der Tonerkartusche bei einem Drucker.der Softwareentwicklung gegenüber anderen Branchen Komplizierte Systeme unterscheiden sich von einfachenganz neue Möglichkeiten. Softwareentwicklung ist also Systemen dadurch, dass es viele Einflussgrößen gibt,tatsächlich anders. die stark miteinander verknüpft sind. Die Verknüp- Oder können Sie sich folgendes Szenario im Brücken- fungen sind aber ebenfalls über die Zeit konstant (ge-bau vorstellen: Erste Woche: „Ich will eine Brücke über ringe Dynamik). Im Gegensatz zu einfachen Systemendiesen Fluss. Bauen Sie mal eine ganz normale Brücke bis ist die Ursachen-Wirkung nicht mehr für jedermannnächste Woche.“ Zweite Woche: „Ach, ich glaube, dass offensichtlich. Deshalb benötigt man häufig Experten,wir die doch besser vierspurig bauen sollten.“ Dritte Wo- um Probleme in komplizierten Systemen zu analysie-che: „... oder vielleicht doch besser als Hängebrücke?“ ren und zu lösen. Das System bleibt aber in sich deter-Vierte Woche: „Ich habe gerade die Verkehrsprognose ministisch und es gibt zumindest eine richtige Lösungerhalten. Wir sollten sie doch auf sechs Spuren erweitern für ein Problem. Ein kompliziertes Problem ist z. B.und als Tunnel bauen.“ ... und so weiter. Das klingt ab- das Reparieren eines defekten Fahrzeugs oder die Soft-solut absurd, oder? In der Softwareentwicklung ist das wareverteilung in einem großen Unternehmen.aber normal und funktioniert meistens sogar, weil die Komplexe Systeme haben wie komplizierte SystemeBauphase praktisch nichts kostet. viele Einflussgrößen, die stark miteinander verknüpftwww.bt-magazin.de bt | 2.2010 9
  5. 5. sind. Allerdings sind diese Verknüpfungen einer ho- Heutige Softwareentwicklung ist eine komplexe Auf- hen Dynamik unterworfen, d. h. sie verändern sich gabenstellung. Genauer gesagt besteht sie aus einfachen, stark über die Zeit. Damit beginnt das System über- komplizierten und komplexen Anteilen. Die Komplexität raschende Eigenschaften zu entwickeln, die durch ergibt sich alleine schon daraus, dass in der Regel viele isolierte Betrachtung seiner Bestandteile nicht mehr Menschen in den Entwicklungsprozess involviert sind, erklärbar sind (Stichwort: Emergenz). Die Komplexi- vom Manager über Fachbereiche, Anwender, Projektlei- tät liegt nicht primär in den Bestandteilen des Systems, ter, Entwickler, Tester, Betrieb, Datenschutzbeauftragte, sondern in der dynamischen Interaktion zwischen den Betriebsrat usw., und sich dadurch ein komplexes System Teilen. Dennoch bilden sich im Gegensatz zu chao- mit hoher, nicht vorhersagbarer Dynamik über die Zeit tischen Systemen (die hier nicht betrachtet werden sol- ergibt. Zusätzlich sind die genauen Anforderungen zu len) Muster, die man erkennen muss, um Probleme in Beginn eines Projekts häufig noch unklar. Sie klären sich einer solchen Umgebung zu lösen. Man nähert sich der erst im Laufe des Projekts, und erste Lösungen haben Lösung in (kurzen) Zyklen des Probierens, Bewertens dann wieder Rückwirkungen auf die Anforderungen. und Korrigierens sukzessive an. Komplexe Systeme So ändern sich Anforderungen, weil man lernt, dass entstehen fast immer, wenn Menschen ins Spiel kom- sie sich in der geplanten Form nicht umsetzen lassen, men. Ein Unternehmen ist z. B. ein komplexes System. die ursprüngliche Anforderung nicht zum gewünschten Das Entwerfen eines neuen Autos (nicht nur die reine Ergebnis führt, Konflikte zwischen verschiedenen An- Konstruktion, sondern der gesamte Prozess) oder ei- forderungen aufgedeckt werden oder durch veränderte ner neuen Software sind ebenfalls (fast immer) kom- Rahmenparameter neue Anforderungen entstehen usw. plexe Probleme. Die Wechselwirkungen und Einflüsse sind hochdyna- misch, kurzum: Softwareentwicklung ist heute in derOft werden komplizierte und komplexe Probleme mitei- Regel komplex.nander gleichgesetzt. Das kommt zum einen daher, dassdie Begriffe im täglichen Sprachgebrauch häufig syno- KOMPLEXITÄT KANN MAN NICHT IGNORIERENnym verwendet werden. Zum anderen liegt es aber auch Man kann versuchen, diese Komplexität zu verleugnendaran, dass komplizierte Probleme auf den Laien – und und so tun, als wären alle Probleme in der Softwareent-wir sind nun einmal Laien in allen Themen, die nicht wicklung höchstens kompliziert, getreu dem Motto „Eszufällig unsere Fachgebiete sind – ähnlich wirken wie gibt kein Problem, das man per ‚Teile und Herrsche’ nichtkomplexe Probleme. Er erkennt die zugrunde liegenden in den Griff bekommt“. Die Fehlschlagstatistiken von IT-Ursache-Wirkung-Prinzipien nicht und der Effekt ist, Projekten sprechen da aber eine andere Sprache. Massivedass ihm das komplizierte Problem komplex erscheint. Termin- und Budgetüberschreitungen, schlechte Quali- Was haben einfache, komplizierte und komplexe tät und unzufriedene Kunden sind das häufige Ergebnis,Systeme denn mit der zuvor beschriebenen Aussage zu wenn man die Komplexität ignoriert und nur auf defi-tun? Nun, ingenieursmäßiges Vorgehen basiert auf festen nierte Prozesse und ingenieursmäßiges Vorgehen setzt.Ursache-Wirkung-Prinzipien und stabilen Teil-Ganzes- Besser ist es, auf Vorgehensweisen zu setzen, die explizitBeziehungen. Große Probleme werden nach dem Teile- mit der Komplexität umgehen. Die derzeit bekanntestenund-Herrsche-Prinzip in kleine Probleme zerlegt, die in Vertreter dieser Kategorie sind die agilen Vorgehenswei-der Summe das große Problem ergeben. Komplizierte sen. Sie bündeln genau die Elemente, die man benötigt,Lösungen werden nach klaren Regeln aus einfachen Lö- um komplexe Probleme zu lösen: Kurze Zyklen, schnellessungen zusammengesetzt. Damit ist ein ingenieursmäßiges Feedback, häufige Reflektionen, kontinuierliche Annähe-Vorgehen dazu geeignet, einfache und auch komplizierte rung an die Lösung, gepaart mit weiteren ErfolgsfaktorenProbleme zu lösen. Es ist beeindruckend, welch hochkom- für komplexe Umfelder wie viel Kommunikation, inter-plizierte Probleme die Ingenieurskunst gelöst hat, aber sie disziplinäre, sich selbst organisierende Teams, indirektebenötigt stabile Ursache-Wirkung-Zusammenhänge. Führung, kontinuierliches Lernen usw. Komplexe Probleme hingegen mit ausgeprägter Dy- Andere Branchen wie die Automobil- oder die Phar-namik, bei denen die Wechselwirkungen über die Zeit maindustrie haben das übrigens schon lange verstanden:das Systemverhalten dominieren und nicht mehr die Komplexe Probleme wie das Entwickeln neuer FahrzeugeEigenschaften der Einzelteile, kann man nicht ingeni- oder neuer Medikamente werden dort schon lange mit agi-eurmäßig lösen. Komplexe Probleme kann man nur mit len Methoden gelöst. Auch wenn es nicht immer explizitempirischen Vorgehensmodellen lösen, die auf kurzen agil genannt wird, findet man an diese Stelle die ganzenZyklen, schnellem Feedback, häufigen Reflektionen und zuvor beschriebenen Elemente der Agilität: kurze Zyklen,kontinuierlicher Annäherung an die Lösung basieren. schnelles Feedback usw.10 bt | 2.2010 www.bt-magazin.de
  6. 6. Tatsächlich stammen viele der Grundideen der heu-tigen Agilität nicht aus der Softwareentwicklung, sondernaus anderen Branchen wie Automobil-, Kopierer- oderKamerabau, die Lösungen für die Komplexitätsproblemein der Produktentwicklung gesucht haben [7]. Die agi-len Grundideen lassen sich sogar bis in den militärischenFlugzeugbau der 50er Jahre zurückverfolgen [8], wo siesehr erfolgreich angewendet worden sind. Vielleicht wür-de uns der in anderen Ingenieursbranchen schon langeselbstverständliche Umgang mit Agilität leichter fallen,wenn wir endlich akzeptieren, dass das Entwickeln undSchreiben des Sourcecodes nicht (mehr) zum Bauen, son-dern zum Entwerfen der Lösung gehört. Und das ist wiein den anderen Branchen in der Regel eine komplexe Abb. 3: Aufgabe und MethodeAufgabenstellung, für die man die angemessene Vorge-hensweise – wie etwa Agilität – benötigt. mäßig optimieren. Agilität gibt es also sehr wohl in an- Ist damit ingenieursmäßiges Vorgehen in der Software- deren Branchen, man muss nur an den richtigen Stellenentwicklung komplett passé? Nein, natürlich nicht. Wie suchen.bereits zuvor geschrieben, besteht Softwareentwicklung Damit stellt sich in der Softwareentwicklung nichtaus einfachen, komplizierten und komplexen Anteilen. die Frage nach ingenieursmäßigem Vorgehen oder Agi-Die einfachen und komplizierten Anteile sollten wir na- lität, sondern es ist klar, dass wir beides benötigen: Dietürlich weiterhin mit ingenieursmäßigem Vorgehen lösen einfachen und komplizierten Aufgabenstellungen sollten(bzw. ad hoc in ganz einfachen Fällen), denn da hilft uns wir weiter ingenieurmäßig optimieren, während wir dieAgilität nicht weiter. Das tun wir auch schon mit großem komplexen Probleme mithilfe von Agilität lösen sollten.Erfolg, was aber nicht heißt, dass wir da nicht noch bes- Grundsätzlich sind wir da aber schon auf einem gutenser werden sollten. Abbildung 3 verdeutlicht den Zusam- Weg (wenn auch nicht immer aus den richtigen Grün-menhang zwischen Aufgabenstellung und angemessener den). Jetzt müssen wir nur noch mit den GlaubenskriegenMethodik noch einmal. aufhören und uns auf das Lösen unserer reichlich vor- handenen Herausforderungen und „Probleme“ mit denZUSAMMENFASSUNG jeweils passenden Mitteln konzentrieren. Aber auch dasZusammenfassend lässt sich festhalten, dass das Im- werden wir noch schaffen...plementieren von Software, d. h. das Entwickeln vonSourcecode, nicht Teil der Bauphase, sondern Teil der Uwe Friedrichsen hat langjährige Erfahrungen als Architekt,Entwurfsphase ist. Erst mit der letzten Zeile Sourcecode Projektleiter und Berater. Aktuell verfolgt er als Leiter Com- petence Center Architektur bei der codecentric AG Soft-ist der Entwurf abgeschlossen. Die extrem niedrigen ware- und Unternehmensarchitekturen im Kontext agilerKosten des eigentlichen Bauens von Software im Ver- Konzepte.gleich zu anderen Branchen führen häufig dazu, dass di-ese Phase komplett übersehen wird. Als Folge wird das Links & LiteraturImplementieren von Software mit der Bau- oder Produk- [1] Agile Day auf der JAX 2010: http://it-republik.de/konferenzen/tionsphase in anderen Branchen verglichen, also sozu- jax2010/session/?tid=1505sagen Äpfel mit Birnen. Dadurch hinken praktisch alle [2] Scrum: http://de.wikipedia.org/wiki/Scrum [3] Extreme Programming: http://de.wikipedia.org/wiki/Vergleiche der Softwareentwicklung mit anderen Bran- Extreme_Programmingchen sowohl in Bezug auf ingenieursmäßiges Vorgehen [4] Ford, Neal: „Emergent Design & Evolutionary Architecture“,als auch in Bezug auf Agilität. Vortrag bei der rheinjug: http://www.rheinjug.de/videos/ Weiterhin ist die heutige Softwareentwicklung eine gse.lectures.app/Talk.html#EmergingDesignRheinjug [5] Snowden, D.J.; Boone, M.E.: „A Leaders’s Framework for Deci-komplexe Aufgabenstellung, die man mit klassischen sion making“, in Havard Business Review, November 2007ingenieurmäßigen Mitteln nicht in den Griff bekommen [6] Honegger, J.: „Vernetztes Denken und Handeln in der Praxis“,kann. Dafür benötigt man andere Mechanismen, wie sie Versus Verlag Ag, Zürich 2008z. B. die Agilität anbietet. Andere Branchen praktizieren [7] Takeuchi, H.; Nonaka, I.: „The new new Product Development Game“, in Havard Business Review, Januar-Februar 1986das schon lange erfolgreich, indem sie z. B. die komplexe [8] Bradshaw, Pete: „R&D Archaeology: The Lockheed SkunkProduktentwicklung nach agilen Prinzipien organisieren, Works“: http://valueshepherd.com/commentary/während sie den komplizierten Produktbau ingenieur- archaeology_skunk_works/archaeology_skunk_works.htmwww.bt-magazin.de bt | 2.2010 11
  7. 7. codecentric AGMerscheider Straße 142699 SolingenTelefon: +49 (0) 212 - 233628 10Telefax: +49 (0) 212 - 233628 79E-Mail: info(at)codecentric.de

×