ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

Getting Ideas Done

16.05.09 - Entwicklung, Diskussionen, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Der Weg von einfachen Ideen zu tatsächlich Umsetzbarem ist nicht einfach. So müssen Ideen erst geboren werden. Anschließend müssen sie verfeinert und schlussendlich zur Umsetzung gebracht werden. Ein langer Weg, nutzt man nicht diverse Hilfsmittel.

In Erinnerung kommt hier Getting Things Done (GTD). Hierzu die Grundregel:

GTD basiert auf dem Prinzip, dass eine Person ihre anstehenden Tätigkeiten notiert und somit den Kopf frei hat für Wichtigeres.

Eigentlich einfach: Eine Aufgabe tut sich auf und wird sofort notiert. Daraus ergibt sich eine Liste von Aufgaben (Prioritäten etc. spielen natürlich auch eine Rolle), die man dadurch immer im Überblick hat und abarbeiten kann. Alle notierten Aufgaben muss man fortan nicht mehr in Gedanken halten, sie wurden niedergeschrieben, man kann nachsehen und muss nicht erst lange darüber nachdenken, was denn noch alles zu erledigen ist. Vorausgesetzt, man hat immer ein entsprechendes Werkzeug zur Hand, um Aufgaben niederschreiben und wieder nachlesen zu können.

Ähnlich verhält es sich mit Ideen. Jeder Mensch hat gute Ideen. Viele dieser Ideen werden jedoch nicht weiterverfolgt. Weiterverfolgt können sie jedoch nur werden, wenn man sich der Ideen bewusst ist, die man hat und sich darum kümmert. Das Ziel ist nicht, sich an eine Idee zu erinnern, wenn man Fremdprodukte sieht und denkt: „An so etwas Ähnliches habe ich auch schon einmal gedacht.“. Ziel sollte es sein, aktiv mit den eigenen Ideen zu arbeiten, um sie auch verwirklichen zu können.

„Ich habe keine guten Ideen“ mag nun der eine oder andere denken. Das mag vielleicht sogar korrekt sein und resultiert sehr wahrscheinlich daraus, dass nie auf geborene Ideen reagiert wurde. Das Gehirn hört auf, weitere Ideen zu produzieren, da diese ohnehin nicht weiterverfolgt werden. Wie also kann man aus diesem Dilemma ausbrechen?

Die GTD-Ansätze können auch für unsere Ideen genutzt werden. Einfälle und Ideen sollten niedergeschrieben werden. Hierbei ist es nicht wichtig, in welches Medium sie eingetragen werden, vielmehr sollte dieses immer verfügbar sein. Durch regelmäßige Durchsicht der gemachten Aufzeichnungen, gehen diese ins Unterbewusstsein ein und das Gehirn kann an den Einfällen weiterfeilen, bis schlussendlich ein Ansatz geliefert wird, der tatsächlich Erfolg versprechen kann. Zu beachten ist, dass DER Einfall zu jeder Zeit kommen kann, auch wenn man aktuell mit gänzlich anderweitigen Dingen beschäftigt ist. Das Gehirn arbeitet in zwei unterschiedlichen Modi, einem linearen Modus (Sprechen etc.) und einem asynchronen Modus. Letzterer verwaltet Langzeitinformationen und ist für Intuition und Problemlösung verantwortlich, quasi eine Such- und Abfragemaschine mit bewusstseinserweiternden Fähigkeiten. Der Vorgang der Ideenfindung wird also asynchron ausgeführt. Wann dieser beendet ist, ist nicht vorhersagbar. Es kann sich um Minuten, Stunden, Tage, aber auch Wochen handeln.

Quintessenz ist daher: Nicht nur Aufgaben notieren, um den Kopf für „Wichtigeres“ frei zu bekommen. Auch Ideen, Ansätze und Einfälle sollten gleich behandelt werden. Eine regelmäßige Durchsicht zeigt dem Gehirn, dass Interesse daran besteht und weitergearbeitet werden soll. Ist dies erst einmal automatisiert, werden sich die ersten Erkenntnisse einstellen.

Ganz interessant dazu ist natürlich die Frage, wo sollen diese Aufzeichnungen vorgenommen werden. Hier bieten sich unterschiedlichste Hilfsmittel an. Vom Notizbuch bis hin zum Handy ist alles möglich. Wichtig ist nur, dass das Hilfsmittel immer zur Hand ist und sofort, ohne Aufwand verwendet werden kann.

Zu guter Letzt noch ein kleiner Hinweis: Interessant zu diesem Thema ist pocketmod.com. Angeboten wird eine Flash-Applikation, mit deren Hilfe man sich ein „Pocket-Notizbuch“ zusammenstellen kann. Zur Auswahl stehen die unterschiedlichsten Seiten-Vorlagen, angefangen vom Kalender, bis hin zu Kontakt- und Aufgabenlisten. Diese können ausgedruckt und anschließend zusammen gefaltet werden (eine Anleitung ist ebenfalls auf der Homepage zu finden). Eingesteckt und immer dabei, ohne großen Aufwand betreiben zu müssen.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Perfektion als Maßstab?

05.12.08 - Entwicklung, Diskussionen, Software Testing, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Schön langsam wird es schwierig, alle Themen unter einen Hut zu bekommen. Ich versuche daher hiermit auf einige Punkte aus den unterschiedlichen Themenbereichen einzugehen, um hoffentlich alles ein wenig zu kanalisieren.

Alex hat ja bereits meine Aussagen zum Thema Der perfekte Softwareentwickler kommentiert. Nun hat sich auch noch Sven zu Wort gemeldet und das Thema Perfekte Software ins Spiel gebracht. Plausible und legitime Fragestellungen bzw. Aussagen können daraus erlesen werden.

Wenn ich mir darüber nun so meine Gedanken mache, dann stellt sich für mich die Frage, ob Perfektion überhaupt der Maßstab sein kann?

Qualität als Hürde

Software wird bekanntlich von sehr vielen nicht als qualitativ hochwertig angesehen, unabhängig der Bereiche, in denen seit jeher getestet wird, was das Zeug hält. In Business-Anwendungen und im Individual-Bereich zählen oft andere Anforderungen: schnelle Umsetzungszeit, möglichst hohe Funktionsdichte, möglichst hoher Gewinn. Legitime und nachvollziehbare Punkte, die sich offensichtlich mit erhöhtem Zeitaufwand durch Qualitätssicherung, Einführung neuer Methoden und Praktiken oft nicht vereinbaren lassen. Oder doch?

Aus Sicht der Nicht-Entwickler, fallen zum Zeitpunkt der Einführung derartiger Prozesse höhere Aufwände (zeitlich, monitär, etc.) an. Diese wollen oder können nicht getragen werden.

Der springende Punkte daran (und hier können sich weder Kunde, noch der Vorgesetzte, noch die Entwickler ausnehmen) ist, dass jeder seinen Teil dazu beitragen muss. Eine Gruppe alleine kann den großen Umschwung nicht bringen. Prozesse müssen optimiert, Methoden eingesetzt und beides gelebt werden. Nur dann kann es funktionieren.

Im Zuge dessen fällt immer wieder der Return on Investment (ROI). Ich gehe nicht so weit zu sagen, dass ihn niemand erkennt. Vielmehr wird oft nur der vermeintlich steinige Weg gesehen, den es zu gehen gilt. Dass dieser Weg gar nicht so steinig ist und mit kleinen, eingestreuten, Änderungen sehr schnell gegangen werden kann, wird oft nicht korrekt vermittelt (vom Entwickler, von Magazinen, von Online-Artikeln, etc.) oder vom Vorgesetzten dem Kunden gegenüber. Letztlich ist es dem Kunden egal, er will ein funktionierendes Produkt haben. Wie dies erreicht wird, Sache des Herstellers.

(Bewusst aussen vor lasse ich hierbei die Themen wie mit Features etc. umgegangen wird.)

Verantwortung übernehmen

Wohl einer der wichtigsten Punkte: Wer Verantwortung übernimmt, kann Veränderung bringen. Ein qualitätsbewußter Entwickler wird Verantwortung übernehmen, indem er einfach mal eben eine Build-Umgebung einrichtet, oder unabhängig der Unterstützung von oben seine Tests schreibt. Er wird eine geeignete Möglichkeit finden, seine Aufgaben zu analysieren, zu planen, umzusetzen und zu testen. Mit ein wenig Glück kann er diesen Gedanken auf Kollegen und Vorgesetzte transportieren.

Der Vorgesetzte muss Verantwortung üernehmen, indem dieser Entwickler gefördert wird. Natürlich muss nicht nur der qualitative Output passend sein, auch der quantitive. Ganz klar. Er muss einsehen, dass eine qualitative Verbesserung natürlich eine Auswirkung auf den gesamten Output des Unternehmens und somit auch auf das Branding des Unternehmens hat. Der Kunde wird es danken und eventuell weitere Kunden heranschaffen.

Ziel soll es sein, dass sich alle Bereiche (Entwickler, Vorgesetzer, Kunde) gegenseitig unterstützen und sich gegenseitig motivieren sich zu verbessern. Das muss nicht in Einklang mit Verzögerung, weniger Gewinn etc. gehen. Wohl aber geht es in die positive Richtung - mit dieser Einstellung.

Suchen, Sehen, Lernen, Verstehen, Vermitteln

Was Sven festgestellt hat, kann ich nur unterstreichen. Niemand weiß alles. Perfektion kann es also in diesem Sinne nicht geben. Was es aber geben kann und sollte, ist eine permanente Annäherung. Die Entwicklung von Software geht heute kaum schneller voran, als dies vor einigen Jahrzehnten der Fall war. Lediglich die Mittel, Werkzeuge haben sich geändert. Aus einem einfachen Programmierer ist ein Entwickler geworfen. Mit höheren Anforderungen, höhrerer Eigenständigkeit und mehr Verantwortung.

In diesem Zusammenhang fällt mir spontan der Begriff des Paradigmenwechsels ein. Ein Paradigmenwechsel wird notwendig, wenn Anomalien zunehmen und erkannt wird, dass ein anderer Weg doch der bessere wäre. Bis das Spiel wieder von vorne beginnt. In unserer schnelllebigen Branche verändert sich zwar vieles, Paradigmenwechsel halten sich - aus meiner Sicht - jedoch in Grenzen. Es gibt zwar hier Neues, dort Neues, aber wirklich wichtige Praktiken werden nur sehr sehr langsam angenommen.

Woran scheitert das?

Nicht weil wir so schlecht sind, es ist die Fülle an Information, an Werkzeugen, an Methoden. Haben sich darüber früher eine Handvoll Personen Gedanken gemacht, ist in der heutigen Zeit an allen Ecken und Enden ein neuer Aspekt zu lesen. Schwierig, alles unter einen Hut zu bekommen.

Wie war das? Sprich mit fünf Leuten und du erhältst 6 Meinungen. Der einzig wahre Weg ist nicht zu finden. Aber führen nicht alle Wege nach Rom? Die impliziert, das Rom das Ziel aller Ziele wäre. Dies bedeutet, dass auch alle Wege an Ziel führen. Ist das so?

Wie viele (Software)Projekte werden nicht abgeschlossen? Wieviele werden nicht mit vollständiger Funktionalität rechtzeitig ausgeliefert? Die Antwort kann sich jeder selbst geben.

Der Punkt ist, dass eben nicht alle Wege ans Ziel führen. Unterschiedliche Zeiten erfordern unterschiedliche Aktionen.

Gibt es eine Lösung?

Wohl nicht. Man kann wohl niemanden bekehren den richtigen Weg zu gehen, weil es ihn einfach nicht gibt. Aber man kann durchaus einen richtigeren Weg vorschlagen und versuchen zu unterstützen. Eigeninitiative und Verantwortung sind sie Schlagwörter von Wichtigkeit.

Es ist schön perfekt zu sein. Niemand wird jemals perfekt sein. Weder der Mensch, noch seine erschaffenen Produkte. In ist, wer nicht perfekt sein will, sich und seine Umgebung jedoch beständig zu verbessern versucht.

In diesem Sinne:
Keine Perfektion, aber kontinuierliche Verbesserung!

Kommentar hinzufügen | 1 Trackbacks | Permalink | Trackback-URL

"Alles Neu" ist besser!

30.10.08 - Entwicklung, Diskussionen, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Nicht nur kleine Unternehmen oder einzelne Softwareentwickler erwischt es. Nein, auch große Konzerne wie Microsoft. So geistert die Meldung durch das Internet, dass Microsoft die Workflow Foundation von Grund auf neu entwickeln wird. Oder zumindest einen Großteil, so genau kann das wohl niemand mit absoluter Sicherheit sagen. Aber ist das grundsätzlich schlecht?

Die wichtige Frage dabei ist wohl, aus welchem Grund eine Neuentwicklung passiert. Gründe hierfür lassen sich einige finden:

Technologie-Wechsel
Performance-Probleme
Mangelnde Erweiterbarkt
Design-Fehler
Sich veränderte Anforderungen

Dies ist nur als kleiner Auszug aus möglichen Gründen für eine komplette Neuentwicklung einer Software oder eines Frameworks zu sehen. Aber kommen wir zur Frage, wann denn eine neue Implementierung tatsächlich gerechtfertigt ist.

Der Ursprung dieses Gedankens liegt meist darin, dass gewünschte Anforderungen nicht mehr den Wünschen entsprechend umgesetzt werden können, oder aber laufend Probleme auftreten, die nicht in den Griff zu bekommen sind. An dieser Stelle muss nun gegenübergestellt werden, wie es um den Aufwand aussieht, der notwendig ist, diese Probleme in den Griff zu bekommen. In manchen Fällen rechnet es sich durchaus, einen Schritt zurück auf das "Startfeld" zu machen und die Implementierung der gesamten Software, oder der relevanten Teile neu zu beginnen.

Bei einem anstehenden Technologie-Wechsel werden sich einige Fragen nicht stellen. Hier steht der Wunsch (oder der Zwang) im Vordergrund, auf eine neue Technologie zu wechseln. Die Gründe können unterschiedlicher Art sein:

Fehlende Möglichkeiten
Effizienz-Einbußen
usw.

Treten tatsächlich Probleme auf (Performance, mangelnde Erweiterbarkeit), dann ist grundsätzlich Handlungsbedarf immer als dringend anzusehen. Können die Ursachen lokalisiert und dauerhaft gelöst werden (und das mit vertretbarem Aufwand) sollte darin investiert werden. Ist dies nicht der Fall, oder treten zusätzlich eigenartige Verhaltensweisen auf, dann kann durchaus an eine Neuentwicklung gedacht werden.

Auch eine Neuentwicklung bringt so ihre Probleme mit sich. Vor allem, wenn bereits Releases in Umlauf sind. Idealerweise sollten sich Schnittstellen nicht ändern. Bei einem Redesign bzw. einer Neuimplementierung ist dies allerdings nicht immer möglich. Um den neuen Anforderungen gerecht zu werden muss auch die API Neuerungen erfahren. Dies bringt sehr oft eine Inkompatibilität zu vorhergehenden Versionen mit sich. So in einigen Bereichen auch bei der geplanten Workflow Foundation. Damit gewisse Anforderungen erfüllt werden können, muss ein Bruch zur "alten" Version stattfinden. Er ist unvermeidbar. Schlecht für all diejenigen, welche die aktuelle Version einsetzen. Gut für diejenigen, die es schaffen, erfolgreich auf die künftige Version zu migrieren bzw. überhaupt erst mit der neuen Version einsteigen.

Was ich ingesamt damit sagen möchte: Ist von einer Neuentwicklung der eigenen Anwendung die Rede, verfallen die meisten sofort in Panik. Bisheriges kann doch nicht so schlecht sein. Bis jetzt wurden alle Anforderungen erfüllt. Reine Abwehrhaltung. Die Anforderungen ändern sich. Auch die zugrunde liegende Technologie. Irgendwann kommt jedes Produkt an seine Grenze. Idealerweise wird bereits frühzeitig erkannt, wann dies der Fall sein wird. Erhöht sich der Erweiterungsaufwand, wird die Anwendung oder das Framework instabil sollte man auch in diese Richtung denken. Nicht jede Neueentwicklung bedeutet, dass das bisher Geleistete schlecht ist. Man muss agieren um auch zukünftig konkurrenzfähig zu sein/bleiben. Eine Kosten/Nutzen-Rechnung sollte jedoch nicht ausser Augen gelassen werden.

1 Kommentar - 801 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Durchdachte Prozesse als Heilmittel in der Softwareentwicklung?

27.10.08 - Entwicklung, Diskussionen, Projektmgmt.
Beitrag von Norbert Eder

Die meisten Softwareschmieden haben das gleiche Problem: Die Softwareentwicklung durchläuft keinen klar definierten Prozess. Egal ob Feature, Bug oder Idee. Alles fließt in eine einige Datenhalde, die dann abgearbeitet wird. Prioritäten werden in den wenigsten Fällen vergeben. Ebenfalls finden sich oft kaum Beschreibungen, genaue Fehlerhinweise oder gar Konkretisierungen der gewünschten Anforderungen.
Immer wieder gerate ich in Unterhaltungen, in denen dieses Thema aufgegriffen wird. Meist ist man sich einig, dass am jeweiligen Software-Prozess Änderungen vorgenommen werden müssen. So einfach es theoretisch ist, treten doch in der Praxis zahlreiche Probleme auf. Wie kann man dem also entgegen wirken?

Eine der wichtigsten Aufgaben ist wohl, zu identifizieren was schief läuft und wo Handlungsbedarf besteht. Auch das klingt einfach und ist es schlussendlich nicht. Wo finden sich Ansatzpunkte?

Projektverantwortliche (unabhängig ob der Geschäftsführer, der Program Manager, der Project Manager usw.) finden sich immer wieder in der Situation, dass sie den aktuellen Entwicklungsstand nicht beurteilen können. So wird an der Businesslogik geschraubt, mit kaum sichtbaren Ergebnissen oder Erweiterungen finden ihren Weg in die Software, die auch erst im letzten Schritt eine Auswirkung auf das User Interface haben. Meist sehr unbefriedigend für denjenigen, der das Produkt seinen Kunden schmackhaft machen soll.

Die Entwickler auf der anderen Seite sehen sich damit konfrontiert, dass die Software im halbfertigen Zustand begutachtet wird, wobei doch gemachte Erweiterungen noch gar nicht sichtbar sein können. Aufgaben mit höchster Priorität werden verteilt, die aktuell nicht zum Entwicklungsstand passen und daher auch nicht wahrgenommen werden können. Zustätzlich werden in ein etwaiges vorhandenes System alle Punkte eingepflegt, sodass sie für jeden Entwickler sichtbar sind (eventuell sogar noch mit Benachrichtigung). Dies bringt definitiv Unruhe in das Entwickler-Team, da man sich automatisch Gedanken über Dinge macht, die zum aktuellen Zeitpunkt nicht relevant sind.

Resultat sind langwierige Diskussionen. Entwickler in ihrer technischen Welt auf der einen Seite und der wirtschaftliche Bereich auf der anderen. Wie gesagt: Stundenlanges Gerede. Jeder "spricht in seinen Worten". Die Annäherung geht gegen null. Schlussendlich glaubt jeder, die andere Seite verstanden zu haben, um bei nächster Gelegenheit zu merken, dass dem nicht der Fall ist.

Nun die entscheidende Frage: Wie kann Ordnung in dieses Chaos gebracht werden?

Es gilt den Wildwuchs von Informationen Herr (oder Frau) zu werden. Der Entwickler soll für ihn relevante Informationen zu Gesicht bekommen und nicht mehr. Dies bedeutet, dass - wie in agilen Prozessen üblich - Releasetermine definiert werden müssen. Jedes Release enthält eine klar abgegrenzte Feature-Liste. Diese wird mit Prioritäten versehen und entsprechend abgearbeitet. Zusätzliche (neue) Anforderungen werden für das aktuelle Release nicht mehr aufgenommen, sondern neuen Releases zugewiesen. Wichtig ist hier, dass die neuen Funktionalitäten klar definiert werden (genaue Spezifikationen müssen definitiv vorhanden sein, ebenfalls Use Cases usw.).

Wird ein Releaseplan zusammengestellt obligt es dem Entwickler eine Machbarkeitsanalyse durch zu führen und entsprechend Rückmeldung zu geben. Bei Machbarkeit erfolgt eine Aufwandsschätung. Darauf hin kann der "Auftraggeber" seine Prioritäten vergeben und festlegen, für welches Release dieser Punkt Relevanz hat.

Der Vorteil liegt klar auf der Hand:

Der Projektverantwortliche hält einen klaren Releaseplan in der Hand. Er weiß zu jeder Zeit, welche Features umgesetzt werden können und welche aus Zeitgründen in ein anderes Release verschoben werden müssen. Zusammen mit entsprechenden Auswertungen und Erfahrungswerten gelangt er zur Information, wieviel tatsächlich von seinem Team umgesetzt werden kann.
Der Entwickler erhält eine Liste von Punkten die umzusetzen sind. Änderungen (manche lassen sich leider nicht vermeiden, Blocker o.ä.) sind nicht vorgesehen. Er kann sich auf seine Aufgaben konzentrieren und muss sich mit neuen Aufgaben erst bei der Erstellung des nächsten Release-Planes beschäftigen. Er hat den Kopf für aktuelle Aufgaben frei.
Einer muss schließlich die Software verkaufen. Er hat aussagekräftige Informationen zur Hand, die er dem Kunden vorlegen kann. Zudem ist jedoch auch klar, dass mal eben ein Feature nicht untergeschoben werden kann. Dieses muss durch den Prozess durch und wird je nach Priorität und Aufwand einem bestimmten Release zugeordnet. Schwerwiegende Fehler sind davon natürlich ausgenommen. Natürlich kann sich durch die Wichtigkeit des Kunden bzw. des Punktes auch der nächste Release-Plan entsprechend verändern. Der aktuell vorliegende Plan sollte davon jedoch unberührt bleiben.

Dieser Prozess ist natürlich nur einer von vielen. An allen Ecken und Enden muss gefeilt werden. Idealerweise setzen sich jedoch Projektverantwortliche und Entwickler an einen Tisch und versuchen einen gangbaren Weg zu finden. Die Bedürfnisse sind auf beiden Seiten die gleichen:

Jeder möchte wissen, was im nächsten Release implementiert ist und was nicht.
Wie sieht es mit den nächsten Schritten aus? Was ist für zukünftige Releases geplant?
Wann sind wir fertig?
usw.

Fragen über Fragen. Ein sauberer Prozess kann nicht auf alles eine Antwort geben. Aber viele Antworten können erleichtert werden und durch zusätzliche Messungen kann festgestellt werden, wieviele Manntage tatsächlich innerhalb eines Monats umgesetzt werden können, was das für die Roadmap des Produktes bedeutet und viele weitere Angaben, welche die Planung erheblich erleichtern.

Vielleicht sind Projektverantwortliche und Entwickler in ihren Wünschen doch nicht so weit voneinander entfernt ...

1 Kommentar - 852 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Einfache Verbesserungen für kleine Teams

11.09.08 - Diskussionen, Patterns, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Immer wieder, wenn ich mit kleinen Entwickler-Teams zu tun habe, sehe ich, dass dieselben Probleme vorhanden sind. Meist dreht es sich um die folgenden Punkte:

Das Projekt wurde nicht ausreichend spezifiziert. Der Auslöser für das Projekt kennt die genauen Anforderungen, brachte diese jedoch nie vollständig in ein Dokument. Sollte ein Dokument vorhanden sein, findet dieses oft nicht den Weg zum Entwickler. Daher erhält dieser oft unzureichende Informationen, um das Projekt erfolgreich durch zu führen.
Keine Arbeitspakete. Soll ein Projekt durchgeführt werden, muss eine Analysephase durchlaufen werden. Im Zuge dieser Phase sind Arbeitspakete zu definieren. Diese erleichtern zum Einen die Abgrenzung zu anderen ToDo's und ermöglichen eine Kontrolle. Zeitschätzungen dafür werden sehr oft ebenfalls nicht angegeben. Deswegen gestaltet sich eine Kontrolle schwierig.
"Drauf-los-Entwicklung". Die Vorgaben sind bekannt und es wird einfach einmal entwickelt. Zukünftige Anforderungen werden nicht in Betracht gezogen, auch wird erst bei der Integration der einzelnen Teile in Erfahrung gebracht, ob diese überhaupt miteinander harmonieren. In den meisten Fällen sind größere Änderungen notwendig.
Kontrolle. Zum Thema Kontrolle gibt es zwei Wege die hauptsächlich durchschritten werden: Entweder findet keine Kontrolle statt (oder erst ca. 2 Wochen vor Auslieferung) oder es wird versucht das ultimative Kontrollsystem einzuführen. Oft wird hierbei jedoch auf notwendige Vorarbeiten vergessen, wodurch eine Kontrolle gar nicht durchgeführt werden kann (Arbeitspakete in Kombination mit Zeitschätzungen als Beispiel).
Ressourcen-Planung. Ressourcen müssen geplant werden. Freie Kapazitäten sollten vor Annahme eines Projektes bekannt sein. Ebenso sollte bekannt sein, dass eventuell zwischenzeitlich Ressourcen für andere Projekte abgestellt werden müssen - und zu welchem Umfang. Viele Teams werden von plötzlicher Ressourcen-Knappheit überrascht, da plötzlich Entwickler zu anderen Projekten abgezogen werden müssen. Es gilt daher eine saubere Ressourcen-Planung durch zu führen und - wenn notwendig - frühzeitig für Ausgleich zu sorgen.
Der fehlende Architekt. Nicht jeder Softwareentwickler ist zum Architekten geboren. Großes Wissen und viel Erfahrung ist notwendig, um zukunftssichere Grundgerüste zu entwickeln. Gerade kleine Teams haben oft keinen "gelernten" Architekten zur Verfügung. In diesem Fall kommt es für die meisten Projekte billiger, sich zumindest für das Grundgerüst eine entsprechende Person zu zu kaufen.

Dies sind einige Punkte, auf die ich immer wieder in der Praxis stoße. Die einen Teams leben dabei nach dem Motto "Es wird schon irgendwie gehen", wobei die anderen definitiv nach Verbesserung streben. Ich persönlich kann nur jedem Team bzw. jedem kleinen Softwareunternehmen raten, sich zumindest für ein paar Stunden einen Spezialisten zu zu kaufen. Sind bisherige Abläufe bekannt (grobe Abläufe lassen sich in kurzer Zeit ohne Weiteres feststellen), können selbst kleine Änderungen große positive Auswirkungen auslösen.

Will ein Unternehmen dafür kein Geld an externe Personen vergeben, dann sollten zumindest meine aufgeführten Punkte mit der eigenen Vorgehensweise reflektiert werden. Alleine daraus lassen sich einige Verbesserungsmaßnahmen ableiten.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder

Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.

6 Kommentare - 1356 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

Den Projekt-Sumpf hinter sich lassen. Jetzt!

28.11.06 - Entwicklung, Projektmgmt.
Beitrag von Norbert Eder

Unterschiedlichste Studien (beispielsweise von der Standish Group [1]) zeigen auf, dass nur ein Bruchteil sämtlicher IT-Projekte auch tatsächlich fertiggestellt werden. Populieren wir diese Studien zusätzlich mit Zufriedenheitsdaten, dann sieht die Statistik noch weit schlechter aus.

Woran diese scheitern möchte ich nun anhand meiner ganz persönlichen Erfahrung beschreiben.

Wie schon in der Post Warum "Mein Chef will .."-Projekte meist in die Hose gehen (und in der darauffolgenden Diskussion, siehe Kommentare) beschrieben, sind oft ungenaue Spezifikationen und/oder Beteiligte mit fehlender Kompetenz, Faktoren für das Scheitern von Projekten. Dem kann im Grunde recht einfach entgegengewirkt werden, allerdings entsteht hierfür anfangs ein erhöhter Aufwand, als auch möglicherweise (sogar eher wahrscheinlich) zusätzliche Kosten.

1) Fehlende interne Kompetenz durch externe Berater kompensieren. So kann vermieden werden, dass in den wichtigen Anfangsschritten grundlegende Fehler gemacht werden. Dies gilt sowohl für die gemeinsame Spezifikation mit dem Kunden, als auch der Entscheidung bezüglich zu verwendender Technologien, Entwurf der Architektur und verwandten Themen.

2) Kommen aufgrund der Unternehmensgröße Business Consultants zum Einsatz empfiehlt es sich auf technisch versierte Personen zu setzen. Hier denke ich unter anderem an Spezifikationen die so technisch nicht umsetzbar sind oder den Aufwand ins quasi Unermessliche treiben. Auch Techniker können den Umgang mit dem Kunden lernen und wirtschaftliche Zusammenhänge begreifen. Aus meiner Erfahrung erzielen Business Consultants die größten Erfolge, die in "ihrem Leben davor" die Rolle des Umsetzenden inne hatten.

3) Technische Entscheidungen, Lösungswege etc. sollten auf jedem Fall mit der Entwicklungsabteilung (den zuständigen Personen) abgestimmt werden. Der Kunde versteht im allgemeinen dass bestimmte Punkte nicht sofort fixiert werden können, da notwendige Zusagen der Umsetzenden fehlen. Dadurch erhöht sich für ihn die Chance das zu bekommen was er auch tatsächlich möchte.

Eine zusätzliche Problematik ergibt sich bei der Kommunikation. Oftmals werden bereits vorhandene Kanäle nicht benutzt oder es existiert eine Scheu vor neuen Möglichkeiten. Ablagesysteme für Dokumente aller Art fehlen oft (nun, wer findet ein bestimmtes Dokument als erstes?). Zuständigkeiten, Tasklisten werden oft nicht kommuniziert. Missverständnisse stehen also an der Tagesordnung. Vielfach kommt zusätzlich folgendes Verhalten zu Tage: Ein Thema wird lieber über mehrere Tage hinweg via Email diskutiert, anstatt für 10 Minuten zum Höhrer zu greifen, das Thema zu besprechen, danach kurz in einem Protokoll zusammen zu fassen um es dann endlich erledigen zu können.

Das Thema der Kommunikation ist jedoch nicht nur auf interne Prozesse beschränkt. Ebenfalls wird oftmals die Kommunikation zum Kunden vernachlässigt. So ist ein Projekt spezifiziert, das Projekt begonnen, aber eine laufende Absprache und Kontrolle mit dem Kunden fehlt vollkommen. Der Kunde möchte über den Fortschritt bescheid wissen, kommt im Zuge diverser Demonstrationen auf Veränderungswünsche usw.

Fehlende Kontrolle. Wir bereits angesprochen: In vielen Fällen fehlen Kontrollmechanismen. Nein hier soll nicht der Mitarbeiter überwacht werden, sondern vielmehr der Fortschritt des gesamten Projektes. Denn nur dadurch kann festgestellt werden ob der Fertigstellungstermin zu halten ist. Nur dadurch kann dem Kunden ständig Feedback über den aktuellen Implementierungsstand geliefert werden. Fakt ist: man weiß wo man steht.

Dokumentation. Nein, nicht nur die Software sollte dokumentiert werden. Besprechungen, Telefonate, eben sämtliche Entscheidungen. Dadurch kann festgestellt werden, wann etwas definiert wurde, wer anwesend war und dadurch kann vermieden werden, dass immer wieder über bereits beschlossene Tasks diskutiert wird (sogenannte Endlos-Tasks die wie ein Damokles-Schwert über alle Beteiligten hängen). Zusätzlich zur daraus resultierenden Historie können Entscheidungswege nachvollzogen werden, können beispielsweise auch neue Mitarbeiter einfacher ins Boot geholt werden.

Lange Rede kurzer Sinn:
Ein Projekt erfolgreich abzuschließen ist im Grunde nicht schwer. Es erforderd Konsequenz von allen Beteiligten und eine realistische Planung. Ein Kunde ist bereit einen Monat länger auf die Software zu warten, wenn es zu Beginn so definiert wurde. Aber dann muss sie ausgerollt werden. Er soll ja als Kunde erhalten bleiben ...

Natürlich habe ich jetzt viele Punkte nicht beachtet, aber ich denke, dass ich viele wichtige Punkte erfasst habe. Leider steht jedem Projektmanagement Aufwand und Kosten gegenüber, aber durch eine effiziente und genaue Planung können Kosten, Aufwand, Ungemütlichkeiten, Streit etc. eingespart werden.

[1] Homepage Standish Group Inc

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Warum "Mein Chef will ..."-Projekte meist in die Hose gehen ...

27.11.06 - Entwicklung, Projektmgmt.
Beitrag von Norbert Eder

Aufgrund meiner Tätigkeit bei tutorials.de stoße ich immer wieder auf junge Programmierer die als Praktikant oder als Einzelkämpfer in einem Unternehmen arbeiten, deren Chef ihnen ein Projekt aufträgt, welches den Horizont dieser Person eindeutig sprengt. Selten wird begriffen, dass diese Projekte einfach nur schief gehen können, zumal grundlegende Gegebenheiten einfach fehlen. Hier eine Liste, die ich mir oft bei Fragen zu Lösungen dieser Art denke:

1. Die Anforderungen werden nicht klar genug vorgegeben. "Wir brauchen ein Shop-System". Gut, die grundlegende Anforderung wäre definiert, aber der Rest? Hier liegt es am Entwickler nachzuhaken und alles notwendige in Erfahrung zu bringen. Sonst ab in die Hose mit diesem Projekt.

2. Der Chef (der kein Techniker ist) gibt das Projekt, als auch sämtliche Rahmenbedingungen wie etwaige Verschlüsselungen, Architekturen etc. vor. Auch das wird meist in die Hose gehen, da hier einfach das Know-How des Chefs auf dem Gebiet der Softwareentwicklung fehlt und etwas - nur weil man es zufällig irgendwo gehört hat - nicht unbedingt das Beste für das eigene Projekt ist.

3. Durch Zeitdruck wird dem kleinen Entwickler keine Zeit gelassen, sich mit der Materie zu beschäftigen, sich ein Design auszudenken, mit erfahrenen Programmierern darüber zu sprechen. Raus kommt ein Rucki-Zucki-Projekt, das den ursprünglichen Anforderungen eventuell entspricht, aber spätestens bei der ersten Änderung zusammenbricht.

Diese und weitere Punkte könnte ich an dieser Stelle aufzählen. Daher an dieser Stelle nur der Hinweis: Diverseste Statistiken zeigen, dass die meisten Projekte definitiv in der Hose landen und entweder nicht zur Zufriedenheit gelöst werden bzw. überhaupt gar nicht fertiggestellt werden. Daher: bitte unbedingt jedes Projekt genau spezifizieren, Rahmenbedingungen klären, ToDo's festlegen, Technologien und Techniken evaluieren und erst _dann_ mit der Implementierung beginnen. Es ist keine gute Lösung am nächsten Tag bereits einen ersten Prototypen zu sehen bzw. sehen zu wollen ...

9 Kommentare - 1791 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL