Kausale Ketten: Gründe für das Scheitern von Softwareprojekten

Auf dieser Github Page habe ich begonnen die Problemen in Softwareprojekten, die uns täglich begegnen, genauer zu analysieren, um diese vermeiden bzw. beheben zu können.

In Gesprächen mit Teilnehmern meiner Workshops werden mir regelmäßig Symptome geschildert, von denen ich der Meinung bin, dass die Ursache wie so oft tiefer liegt.

Tituliert habe ich das als kausale Ketten und orientiere mich dabei an folgendem Schema:

• Was ist das wahrgenommene Problem, also das Symptom
• Wie kam es dazu, also die Verlaufsbetrachtung
• Warum kam es dazu, was ist die Ursache

Zudem suche ich nach nachvollziehbaren Beispielen, um die Theorie zu untermauern.

Ich verstehe die Seite als Anreiz zum Nachdenken. Alle „Thesen“ sollen als Einstieg in eine lebendige Diskussion dienen.

Gebt mir gerne Feedback in Form von Pull Requests.

Werbung

Programmieraufgaben für Bewerber

Ich habe in diesem Post beispielhaft eine unserer Programmieraufgaben herausgezogen, die kürzlich unser neuer Mitarbeiter Hr. Jörg Weißbecker gelöst hat. In der Regel ist das Ziel ein möglichst hochwertiges Ergebnis zu programmieren, das z.B. die Prinzipien OCP und SoC solide umsetzt.

Zeitdruck ist an der Stelle völlig sekundär, sodass die Bewerber die Aufgaben immer von zuhause in aller Ruhe entwickeln können. Sie erhalten dann von mir nach jeder Iteration die nächste Anforderung übermittelt.

Am Ende besprechen wir das Ergebnis, sprich sie stellen ihren Gedankengang vor, reflektieren Probleme und stellen sich meinen Fragen.

 

Allgemeines vorab:

• Es ist keine Oberfläche notwendig, es genügt eine Konsolenanwendung
• Welche Bibliotheken genutzt werden, ist freigestellt
• Das Schreiben von Tests ist optional
• Aber: Setzte das objektorientierte Paradigma so gkonsequent als möglich um (!)

 

Iteration 1: Entwickeln Sie ein Programm, welches prüft, ob 2 Dateien identisch sind. Beispiel für den Aufruf:

Dublettenfinder.exe file1.txt file2.txt

 

Iteration 2: Statt 2 Dateien sollen jetzt 2 Ordnerpfade übergeben werden, für welche das Programm prüft, ob das Ordnerpaar Dubletten enthält. Wenn ja, soll es pro Dublette die Dateipfade gruppiert ausgeben. Beispiel:

Hash: xyxzasdfadsf

• Datei1: c:\abc.pdf
• Datei2: d:\efg.pdf

 

Iteration 3: Es soll möglich sein eine Liste von Verzeichnissen zu übergeben, sodass beliebig viele Verzeichnisse verglichen werden können. Außerdem sollen, sofern vorhanden, auch die Unterverzeichnisse geprüft werden.

 

Iteration 4: Fügen Sie bitte eine optionale Konfigurationsmöglichkeit hinzu, um nur bestimmte Dateitypen vergleichen zu können, sodass entweder alle Dateitypen, genau einen Dateityp oder n-Dateitypen verglichen werden können.

 

Iteration 5: Machen Sie den Algorithmus austauschbar, sodass der Identitätscheck z.B. anhand von Sha256 Hashwerten oder Bildanalyse durchgeführt werden kann.

 

Iteration 6: Nutzen Sie einen IoC Container, um dynamisch beim Start der Anwendung alle vorhandenen Algorithmen zu laden und dann vom User in der Konsole auswählen zu lassen. Jeder Algorithmus soll in einer eigenen Assembly liegen. Machen Sie dann eine Assembly für MD5 und Sha256.

 

Die  Lösung zu diesem Zeitpunkt müsste sich Fragen bzgl. der Erweiterung der folgenden 2 Änderungen stellen:

• Lösche Dubletten anhand eines bestimmten Patterns, z.B. alle in Verzeichnis ‚xy‘ oder mit Dateinamen, die ‚yz‘ enthalten.
• Ermögliche die Erkennung von doppelten Bildern anhand der Bilderkennung und nehme immer die beste Auflösung.

 

Kürzlich gab es in der dotnetpro einen Artikel von Stefan Lieser, welcher eine recht ähnliche Kata gelöst hat. Die Lösung von Herrn Weißbecker befindet sich hier.

Was wollt ihr über Coding Dojos wissen?

Ich schreibe aktuell an einem Artikel zu dem Thema. Für mich sind Coding Dojos ein effektives Mittel um aktiv die kontinuierliche Verbesserung voranzutreiben. Das ist mir sehr wichtig, denn es geht viel Potential verloren, indem Wissensmanagement nur passiv abläuft. Wer sich z.B. den eigenen Code von vor 3 Jahren anschaut, wird hoffentlich feststellen, dass er heute besser entwickelt. Dieser Prozess vollzog sich quasi nebenbei. Meine Intension ist deshalb aktiv Werkzeuge zu testen und nutzen, um Verbesserungen forcierter anzugehen.

Coding Dojos sind in dem Kontext ein erprobtes Mittel. Weitere habe ich in diesem Artikel bzw. in der unten stehenden Grafik aufgelistet:

 

 

Den geneigten Leser würde ich bitten mir auf Twitter, Facebook oder am besten hier in die Kommentare mitzuteilen, welche Erfahrungen er mit Coding Dojos gemacht hat, wo Probleme liegen, was Erfolge waren und was er gerne in einem Artikel dazu lesen würde. Zur Anregung kann diese kleine MindMap dienen:

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Welche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

• Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
• Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

• Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
• Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
• Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
• Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
• Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
• Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
• Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
• Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Was ist das nur mit dem Bloggen?

Ich habe mich nie viel mit Schreiben beschäftigt. So geht es vermutlich vielen Bloggern. Natürlich schreibt jeder etwas von uns täglich in irgendeiner Form – und seien es nur E-Mails oder Facebook Kommentare. Ich spreche aber von Inhalten, die Wissen verarbeiten und vermitteln sollen. Konkret beziehe ich mich auf Online Beiträge in Form von Blog Posts. Da gilt es klar von Printmedien zu trennen, deren Form und Stil sich unterscheiden.

Inzwischen bin ich nach 3,5 Jahren des Schreibens bei knapp 250 Blogbeiträgen angekommen. Klar ist: Das Schreiben geht jetzt leichter von der Hand. Ein gewisses Vorgehen hat sich eingependelt, ein eigener Stil sich entwickelt. Es ist zu einem Hobby geworden, dem ich regelmäßig nachgehe. Es heißt, “das Interesse steuere die Wahrnehmung”. Deshalb verhält es sich mit Hobbies so, dass man automatisch mehr dazu lernt, sich für das Thema sensibilisiert und über kurz oder lang größere Kreise schlägt. Bei mir war dies kürzlich z.B. durch einen Artikel in der dotnet pro der Fall. Sportler können der Argumentation leicht folgen. Der typisch männliche Fitnessstudio-Gänger wird sich beispielsweise anfangs die Grundübungen aneignen, danach erweitert er sein Trainingsprogramm, im Anschluss beschäftigt er sich mit Trainingsprinzipien und früher oder später mit Ernährung.

Mir ist es gar nicht so wichtig wie viele Besucher ich habe oder wie viele Backlinks ich generiere. Bloggen ist für mich ein digitales Mittel der Reflektion, das mir bei meinem Wissensmanagement hilft. Das Wiederholen erleichtert die Langzeitspeicherung. Diskussionen bringen neue Erkenntnisse. Der Blog dient mir als eigenes Nachschlagewerk, als Hilfestellung für Kollegen, als Feedback an Dritte, als Beitrag zur Community, als Möglichkeit zur eigenen Weiterentwicklung.

Um den gerecht zu werden, habe ich mich heute mit zwei Fragen beschäftigt, welche ich an den Leser weitergeben will:

• Warum bloggt ihr?
• Was tut ihr um euch als Schreiber weiterzuentwickeln?

Den letzten Punkt werde ich in meinem nächsten Beitrag angehen, denn kürzlich habe ich dazu an einer Inhouse Schulung teilgenommen.

Lebenslanges Lernen

Gerade in der IT-Branche ist es elementar sein Wissen kontinuierlich weiterzuentwickeln. Nicht umsonst findet sich in vielen Fachbüchern und Fachzeitschriften inzwischen die Aussage, dass die größte Herausforderung für den Vorgesetzten der Zukunft die Entwicklung hin zum Coach ist. Das heißt fungiert nicht länger selbst als fachlicher Entscheider, sondern er verhilft dem Mitarbeiter zu dieser Kompetenz. So wie der Fussball-Coach nicht selbst Fussball spielt, sondern den Spielern zeigt, worauf es ankommt und wie sie sich verbessern, damit sie im konkreten Spiel ihr Leistungspotential  eigenverantwortlich ausschöpfen. Hierzu mehr in einem späteren Blogbeitrag.

Der lernaffinste Mitarbeiter nützt nichts, wenn er nicht entsprechende Werkzeuge und Materialien an die Hand bekommt. Dazu benötigt es ein aufgeschlossenes Unternehmen, das den langfristigen Nutzen der dazu nötigen finanziellen Mitteln sieht und einen Vorgesetzten, der passende Angebote kennt. An dieser Stelle möchte ich einige Beispiele nennen, die in der IT der Firma heco zum Einsatz kommen:

eLearning: Ein hervorragendes eLearning Portal mit qualitativ sehr hochwertigen Video Trainings ist Pluralsight. Wir haben erst kürzlich dazu einjährige Subscriptions mit Offline Nutzung erworben, sodass die Kollegen die Inhalte offline unterwegs auf Handy, Tablet oder Laptop konsumieren können. Damit kann selbst die 20-minütige Zugfahrt produktiv genutzt werden.

eBook Reader: Inzwischen besitzt jeder IT-ler einen Kindle. Es kann oftmals sein, dass zunächst der Vorgesetzte aktiv und auf sinnvolle Bücher hinweisen muss. Bei uns stelle ich beim wöchentlichen Mittagessen typischerweise die Frage: “Liest gerade jeder an etwas?”. Die Kosten werden dabei vollständig übernommen, der Mitarbeiter liest im Gegenzug natürlich überwiegend in seiner Freizeit.

Zeitschriften Abos: Mit der Web and Mobile Developer, der Tec Channel kompakt und der dotnet Pro haben wir für alle 3 IT Bereiche jeweils ein Abo im Programm.

Unkonferenzen: Persönlich bin ich kein Freund von großen, handelsüblichen Konferenzen. Diese haben zwar z.B. für einen allgemeinen Überblick ihre Daseinsberechtigung, aber wir konzentrieren uns mehr auf sogenannte Unkonferenzen wie den Developer Open Space. Das Gespräch unter “Gleichen” die selbst die Inhalte festlegen und gleichzeitig dann auch erarbeiten ist enorm hilfreich.

Gruppen: Sei es die .NET User Group, die SQLPass, der Agile Scrumtisch oder die Social Media Night Stuttgart. Bei vielen Treffen sind wir vertreten. Die Treffen sind gänzlich kostenfrei (lediglich SMCST kostet 5€ pro Person). Unterstützt werden unsere Mitarbeiter durch Poolfahrzeuge und mit kürzerer Arbeitszeit, um ggf. auch bei längeren Strecken pünktlich kommen zu können.

Webinare: Viele Produkthersteller bieten Webinare an, welche wir oftmals im Kollektiv im Besprechungsraum auf der Leinwand konsumieren. Besonders Mindjet ist hier sehr aktiv.

Coding Dojos: Die Software-Entwickler bei uns halten regelmäßige Coding Dojos, d.h. interne Entwickler Trainings. Damit geht der Betrieb zunächst einmal in Vorleistung, denn die Zeit wird ja nicht für Produktivcode genutzt. Meiner persönlichen Erfahrung nach kann ich nur sagen, dass sich die Zeit definitiv lohnt.

Soziale Netze: Ein vielleicht ungewöhnlicher Punkt, aber soziale Netze sind für den Arbeit im Umfeld des Wissensmanagements ein unverzichtbares Werkzeug. Während in vielen Arbeitsstätten der Zugang gesperrt oder verboten ist, sind bei uns die Mitarbeiter aufgerufen aktiv mitzuwirken, um sich ein entsprechendes Netzwerk aufzubauen. Das schnelle Finden von Consultants, die kurze Info bei einem spezifischen Problem oder einfach Mal flugs die wichtigsten Eckpunkte in einem unbekannten Thema einholen; das alles geht mit Twitter & Co. 1,2,3. Das ist wesentlich effizienter und kostensparender als die Eigenrecherche, die sich schnell zu mehreren Stunden aufsummiert.