(LaTino mit n, da bin ich empfindlich)
Der Vorwurf war nicht, dass du starke Meinungen vertrittst - das tue ich selbst gern und schätze es auch bei anderen - sondern, dass einige Folientexte mit Argumenten verwechselst und es nicht für nötig hältst, deine Aussagen zu untermauern. Das ist schade, weil, wie ich schon schrieb, deine Meinung durchaus kein Einzelfall ist, sondern in meiner täglichen Arbeit bei Projektverantwortlichen und im Management sogar relativ oft anzutreffen ist.
Ein für meine Begriffe sehr gutes Argument wäre ein Verweis darauf gewesen, dass man mit dem Einsatz agiler Methoden u.U. Gefahr läuft das zu tun, was im Link oben "hype driven development" genannt wird. Und die Risiken von "HDD" sind dort (Link) ja recht anschaulich dargestellt.
| Zitat von Blaster |
Wie gehst Du mit den nachfolgenden Problemen um:
1) Wie Du die Anaomlien, Inkosistenzen und Probleme während der Zunahme des HDD erkennst?
|
Zugegeben habe ich hier etwas Schwierigkeiten, zu erkennen, was du wissen möchtest. "Zunahme des HDD"? Inwiefern? Was der Autor spöttisch "HDD" nennt, also das Hinterherlaufen hinter Trends, wie soll das "zunehmen"? Entweder man verfällt dem Trend, oder nicht, das ist ein binärer Zustand. (Immer gesehen für ein Projekt.) Wenn man dem Trend verfällt, besteht das Risiko, dass man hinterher das Gegenteil von dem erreicht, was man wollte (dass es teurer wird, länger dauert, unzuverlässiger funktioniert). Wenn man dem Trend nicht verfällt, sondern auf bewährte Methoden zurückgreift, besteht das Risiko, dass man von den Vorteilen des Trends ggf. nicht profitiert, d.h. man vergibt sich die Chance, dass es funktioniert.
Wichtig auch: unter bewährte Methoden wird eine Softwarebutze, die seit Jahren SCRUM macht, eben auch SCRUM verstehen. Bewährt heisst: ich weiß, dass es für mich funktioniert, ich kenne die Vor- und Nachteile, und ich kann beides in meine Kalkulation einbeziehen und stelle im Projektnachlauf fest, dass diese Kalkulation nah an der Realität war. Insofern unterstützt der Link keinesfalls deine These, dass agile Methoden per sé ein "Run in das Mittelmaß" (was soll _das_ eigentlich bedeuten?) sind.
| Zitat |
Wie überzeugst Du
a) eure Kunden
|
Easy. Meine Kunden gehören - wenigstens die Entscheider - zu Unternehmen, wo die IT noch "EDV" und "DFÜ" genannt wird. Die wissen, dass COBOL das Maß der Dinge ist, weil sie Software im Einsatz haben, die damit Anfang der 70er geschrieben wurde
und immer noch funktioniert. Überspitzt gesagt: wenn ich die überzeugen will, dass ihr Produkt mit einer gewissen Technologie/Methodik entwickelt werden soll, dann muss ich ihnen ein Beispielprojekt zeigen, dass mindestens schon 30 Jahre läuft. Alles andere wird für kurzfristige Trends gehalten. Ich kenne Entscheider, die halten OOP für einen dieser kurzfristigen Trends.
Der schwierigste Part. Gute Entwickler sind faul. Wenn sie das Risiko sehen, dass sie mit einer Methode mehr Aufwand haben als mit der anderen, wählen sie im Normalfall das, was sie kennen. Wenn allerdings, um ein fiktives Beispiel zu nennen, 5 Kollegen von einer Konferenz kommen und jetzt alle künftigen Projekte in Rust machen wollen (nix gegen Rust, ich liebe die Sprache), dann lässt man sie Rust evaluieren. Zum einen dauert das lange genug, um die nachkonferenzliche Euphorie verfliegen zu lassen, zum anderen kommt dabei auch noch was Sinnvolles raus. Weiß man dann, welche Probleme man mit Rust lösen kann, kommen ein paar interne Projekte auf der grünen Wiese. Wenn die funktionieren, wird geschult und wenn dann ein Teilbereich eines Projekts aus den bestehenden Erfahrungen heraus am besten mit Rust umgesetzt wird, hat man das Know-How, die Leute und die Erfahrung, um auch Fehlschläge managen zu können.
Wenn mein Management sieht, dass ich ich nicht abwehre nach dem Prinzip "kenn ich nicht, fress ich nicht", sondern dass ich mir auch Gedanken betriebswirtschaftlicher Natur gemacht habe - Risikoanalyse zB - dann haben sie alles, was sie für eine Entscheidung benötigen. Stell ich mich hin und sage "auf der einen Folie im Internet stand "Only way out [..of agile project (dis)management] is rigorous Release Management, but more then [sic!] ITIL V3.", deshalb sollten wir das nicht machen" dann habe ich a) den falschen Job und wenn das Management dann auch noch auf mich hört, haben b) die auch den falschen Job.
Zulieferer in dem Sinn haben wir nicht, wir stellen Software her, keine Autos. Teilweise hängen wir von Anbietern anderer Lösungen ab in dem Sinn, dass unsere Software mit deren kommunizieren muss. Ein aktuelles Projekt kommt mir dabei in den Sinn, wo unsere Software Daten verarbeiten und integrieren muss, die eine Reihe von Services eines Drittanbieters zur Verfügung stellt. Besagter Anbieter arbeitet agil, bzw glaubt das. Tatsächlich arbeitet er (aus meiner Sicht) einfach nur unorganisiert. Das führt dazu, dass wir als Konsumenten seiner Services so arbeiten: drei Wochen warten - neue Schnittstelle/neues Feature geht jetzt! - 3 Tage Arbeit - schade, die notwendige Schnittstelle xy tut noch nicht - drei Wochen warten und von vorn. Das ist frustrierend, bringt unseren Zeitplan und schlimmer noch den unseres Kunden durcheinander. Ich halte unseren Hintern aus Schwierigkeiten heraus, in dem ich immer klar kommuniziere, dass es hakt, wo es hakt, und wessen Zuständigkeit das ist. Zudem haben Kunde und ich eine Exit-Strategie ausgearbeitet, als sich langsam herauskristallisierte, wie das läuft. Ich werden den "Zulieferer" nicht überzeugen können, die Finger von Methode xy zu lassen, aber ich kann das Risiko erkennen und managen.
| Zitat |
| 3) Wie findest Du die wirklichen coolen, innovativen Entwicklungen, erstellt von den kreativsten Köpfen der Welt (den besten?!?) und erhälst Zugang? - Aka finding the underground and get in! - Denn diese sind die Letzten, die sich in der Öffenlichkeit stark produzieren, um sie zu finden. |
Das ist zwar eine sehr romantische Vorstellung - die des braven, bescheidenen Hackers, der im Hinterhof in der Garage von Mutti the next hot thing strickt und kein Interesse hat, groß per PR auf sich aufmerksam zu machen - aber keine sehr realistische.
Beobachte den Markt (Technologien UND die Konkurrenz). Ruh dich nicht aus. Probiere Dinge. Gib deinen Mitarbeitern die Chance, an etwas zu scheitern und alle davon lernen zu lassen, ohne sie dabei zu demotivieren. Widerstehe der Versuchung, etwas Funktionierendes in einer anderen Technologie von Grund auf neu zu entwickeln. Trau keiner Powerpoint-Folie. Hör auf deinen Justiziar.
Das wären so meine Tipps aus 25 Jahren Softwareentwicklung und PM.
| Zitat |
HDD ist und war immer ein Run in das Mittelmaß!
S.u.a. Agiles M & D. |
Da habe ich auch noch ein passendes Zitat.
| Zitat von Obi-wan Kenobi |
| Only a Sith deals in absolutes. |
LaTino
