.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • 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.
Download .NET Essentials Installer
Trickkiste

Coding Standards als wichtiges Instrument

07.01.09 - Entwicklung, Diskussionen, Qualitätsmgmt., .NET, Grundlagen
Beitrag von Norbert Eder
 Wichtigstes Ziel in der Softwareentwicklung ist es, Projekte zeitgerecht und qualitativ hochwertig abzuschließen. Damit dies auch funktionieren kann, bedarf es Coding Standards, die von allen Team-Mitgliedern eingehalten werden müssen.

Da es wieder Zeit wurde, die eigenen Coding Standards anzupassen, machte ich mich auf die Suche, um meinen Horizont diesbezüglich wieder etwas zu erweitern. Dabei stieß ich auf die Coding Standards Reference Documents von Clint Edmonson. Clint hat dabei grundlegende Coding Standards für VB.NET und C# aufbereitet und als Download zur Verfügung gestellt.

Folgende Themen werden behandelt:
  • Golden Rules
  • Formatting
  • Commenting
  • Capitatlization & Naming
  • Programming

Diese Dokumente stellen eine gute Grundlage für jeden Softwareentwickler, als auch für gesamte Teams dar. Im Idealfall werden Ergänzungen gemacht und als Standardlektüre für jeden Entwickler im Team verpflichtend vorgesehen.

Weiters empfiehlt es sich, die Coding Standards auch entsprechend zu kontrollieren, damit sie tatsächlich Anwendung finden. Dies kann in Reviews passieren.

Der eine oder andere mag an dieser Stelle vielleicht die Meinung vertreten, dass zuviel Einschränkung schlecht ist. Dem kann ich allerdings nicht zustimmen. Ein Team an Entwicklern bedarf eine Führung und auch Rahmenbedingungen innerhalb derer sie sich zu bewegen haben. Nur dann kann ein (hoffentlich) optimales Ergebnis verfolgt und erzielt werden.


  3 Kommentare - 1479 mal angesehen   |  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


Gedanken zum perfekten Softwareentwickler

04.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder
 Nach meiner Antwort zu Peter, hat sich nun auch Alex zu Wort gemeldet. Dem kann ich mich inhaltlich auch voll und ganz anschließen (ein Hoch auf mein Notizbuch).

Was ich jedoch aussagen wollte, war etwas anderes. Wir sprechen hier von Themenbereichen, die für manche täglich Brot sind und worüber oft nicht mehr nachgedacht werden muss. Bei vielen Entwicklern verhält sich das anders.

So erlebe ich fast täglich, das Begriffe wie Test-Driven-Development (TDD) oder Domain-Driven-Design (DDD) nicht allgemein hin bekannt sind. Teilweise noch nicht einmal im Ansatz.

Verweigerung: Nein! Doch!


In der Praxis wird Software oft nicht entsprechend dieser Methoden entwickelt. Dies hat unterschiedlichste Gründe:
  • Unzureichende Motivation, sich weiter zu bilden
  • Probleme mit dem Programmier-Werkzeug
  • Ausrede: Zeitdruck
  • Verweigerung dem Testing gegenüber
  • Lieber diskutieren anstatt es zu tun
  • Faulheit
  • Nicht wissen, wo beginnen

Diese Liste könnte wohl noch um zahlreiche Punkte verlängert werden.

Es gibt Entwickler, die als Leitkuh fungieren und versuchen, andere mit auf diesen Zug zu bringen. Das ist teilweise nicht so einfach. Wie bewegt man jemanden dazu, sich diesen Methoden anzuschließen, wenn jegliche Motivation, dies zu tun, fehlt?

Vorschriften. Schön und gut. Aber kann ein Softwareentwickler zu Qualität gezwungen werden? Wohl nicht. Daher ist es angesagt, Best Practices aufzuzeigen und der Einfachheit halber den Weg langsam zu beschreiten. Nicht jeder kann und will seinen über Jahre antrainierten Wasserfall-Stil von Heute auf Morgen aufgeben und sich um 180° wenden.

Streben nach Perfektion


Der Entwickler ist faul - wird immer behauptet. Daraus ließe sich ableiten, dass er von Haus aus versucht den idealen Weg zu finden, seine Arbeit zu lösen. Lieber einmal kurz und knackig implementieren, als ständig Fehler beheben zu müssen. Lieber mit Testing arbeiten und sich so absichern. Lieber Tools verwenden, die sich aktuelle Paradigmen zu Nutze machen und die Arbeit erleichtern. Alles logische und nachvollziehbare Punkte. Was aber, wenn die Faulheit in die andere Richtung ausschlägt?

Verbesserungsmöglichkeiten?


Eine fehlende Grund-Motivation kann man keinem Entwickler einpflanzen. Aber dem Gewillten kann man den Weg ebnen. Vielleicht wäre es also ganz gut, sich darüber Gedanken zu machen, wie man denn unbedarfte Software-Entwickler erfolgreich, ohne allzu große Hürden auf diesen Weg bringt. Der von Alex aufgezeigte Weg ist sicherlich einer, den doch einige von uns gegangen sind. Aber ist er nicht zu steinig?

Daher meine abschließende Frage: Gibt es überhaupt einen einfachen Weg, das Verständnis und die Bereitschaft zu agilem Denken zu schaffen, oder kann dieser Weg nur vom Entwickler selbst eingeschlagen werden?

  2 Kommentare - 885 mal angesehen   |  2 Trackbacks   |  Permalink  |  Trackback-URL


Gedanken zum perfekten Software-Design

03.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder
 Peter Bucher hat in seiner Blogpost Es gibt kein perfektes Design, oder doch über die Qualität des Sourcecodes in Projekten geschrieben. Einige der Punkte möchte ich so aber nicht stehen lassen.

Entwickler und Wunschdenken


Im Gegensatz zum zugrunde liegenden Artikel bin ich nicht der Meinung, dass das Wunschdenken bei vielen Entwicklern in Richtung "Perfektes Design" geht. Vielmehr ist es den meisten Entwicklern wichtig, dass die umzusetzenden Punkte in der veranschlagten Zeit umgesetzt werden. Die Qualität wird daher oft außen vor gelassen. Dies resultiert darin, dass sich viele Entwickler kaum Zeit nehmen zu prüfen, wie ein Algorithmus etc. entwickelt werden kann, so dass er performant und zukunftssicher ist.

Das heißt, das Wunschdenken vieler Entwickler geht meist in Richtung "Hoffentlich bin ich bald fertig mit meinem Task". Natürlich gibt es auch Ausnahmen. Keine Frage. Aber sie sind nicht in der Mehrheit.

Debugging-based Development


Ein wichtiger Punkt hierbei ist - und diesen habe ich schon sehr sehr oft erlebt - das Entwickeln per Debugging. Was bedeutet das? Es werden ein paar Codezeilen geschrieben, dann wird gleich der Debugger angeworfen um zu sehen ob es funktioniert. Wenn nicht, dann gibt der Debugger ohnehin Bescheid an welcher Stelle es knackt. Dort wird eine Änderung durchgeführt und der nächste Debug-Durchlauf startet.

Vielmehr sollte sich der Entwickler zuvor Gedanken darüber machen, was denn da wirklich gefordert wird. Daraus ergeben sich Anforderungen an den zu schreibenden Code. Hier ist es oft sinnvoll, sich vielleicht doch ein paar Minuten mit dem MSDN auseinander zu setzen. Eventuell gibt es dann doch einen Hinweis, der mich das Problem wesentlich eleganter lösen lässt. Zusätzlich ist es immer von Vorteil, sich den Ablauf des Problems aufzumalen. Ob dies nun via UML-Tool passiert, per Visio (ja, kann auch UML) oder einfach am Blatt Papier hängt von der Komplexität und der Anzahl der notwendigen Klassen ab. Aber es fängt schon bei Methoden an, die drauflos entwickelt werden.

Das Hauptproblem bei Machen wir einfach mal schnell ist, dass irgendwann der Punkt kommt, der eine Änderung erfordert. Es funktioniert nicht so, wie man sich das gedacht hat. Und hier fängt es an: Der Code wird mit Gewalt so zurechtgerückt, dass er schlussendlich funktioniert. Im Schönwetter-Fall.

Streben nach Perfektion


Der eine hat's, der andere nicht. Es wäre eine Verallgemeinerung zu behaupten, dass jeder Entwickler nach Perfektion strebt. Viele wollen das Produkt fertig stellen, damit Geld herein kommt. Andere reden sich auf den Zeitdruck aus. Andere wollen wieder eine vergoldete Glaskuppel bauen und können ihr Projekt nie abschließen. Es muss also ein Mittelweg gefunden werden. Dieser sollte sowohl in sauberen Code (wie sieht sauberer Code aus?), Einfachheit und Zukunftssicherheit resultieren. Ebenso wenig sollte die Testbarkeit vergessen werden.

Fazit


Es gibt zwar kein perfektes Design, es gibt auch keinen perfekten Sourcecode. Aber jeder Entwickler sollte sich zumindest Mühe geben, Coding-Standards einzuhalten, sich mit seiner Programmiersprache als Werkzeug zu beschäftigen und diese auch entsprechend einzusetzen wissen. Ebenso gehört dazu, auch einmal die eine oder andere Minute mit dem Lesen der Dokumentation zu verbringen und grundsätzlich analytischer an die Problemstellung heran zu gehen.

Sehr gut funktioniert es, sich zuvor zu überlegen, wie denn der neue Code verwendet werden soll. Ein Zeilen wie die neuen Klassen und/oder Methoden verwendet werden sollen und schon erkennt man frühzeitig Probleme und kann diese noch vor dem Start der Implementierung bereinigen. So kleine Dinge können so viel verbessern.

  4 Kommentare - 1201 mal angesehen   |  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 - 803 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Mit Unit Tests zur einfacheren und intuitiveren Verwendung

15.09.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder
 Unit Tests sind ein Thema bei dem es Entwickler wie Ärzte halten: Gehe zu vier Ärzten und erhalte fünf Meinungen. Bei Unit Tests läuft es auf dieselbe Art. Also wie jetzt wirklich?

Mit den in Visual Studio integrierten Test-Möglichkeiten sollte man meinen, dass der Entwickler nun wirklich keine Ausrede mehr parat hat, Unit Tests nicht zu schreiben. Weit gefehlt. In vielen Projekten werden derartige Tests noch immer vernachlässigt bzw. im schlimmsten Fall nicht angedacht. Einen der Hintergründe - das Thema Aufwand - hatte ich schon einmal versucht, aus dem Weg zu räumen. Oft erscheinen Tests jedoch auch zu kompliziert, oder es wird diese großartige Unterstützung schlicht einfach nicht bedacht.

Für Unit Tests spricht aber nicht nur, dass damit die Fehlerfreiheit von Teilen der Software verbessert und laufend überprüft werden kann. Der Entwickler kann damit sich selbst, dem Team und neuen, zukünftigen Mitgliedern die Arbeit ebenfalls wesentlich erleichtern. Wie denn das?

Der Eckpfeiler daran ist, sich vor der tatsächlichen Implementierung eines Arbeitspaketes Gedanken zu machen, wie die resultierenden Klassen getestet werden können. Idealerweise werden die Tests vor der Entwicklung dieser Teile geschrieben, muss aber nicht zwingend passieren. Da sich der Entwickler nun im Vorfeld schon Gedanken über die Verwendung macht, wird daran gefeilt, bis eine leichte, intuitive Verwendung möglich ist. Schließlich möchte niemand 10 Zeilen Sourcecode schreiben, nur um eine einfache Berechnung auszuführen. Das Ergebnis ist also ein klares, einfach verständliches Design, welches sowohl die gestellte Aufgabe erfüllt und zudem nach der Implementierung voll funktionsfähig ist. Fehlen Gedanken zur Anwendung, kann letzterer Punkt nicht immer sichergestellt werden. Änderungen am Design sind daher im Nachhinein nötig und führen mitunter sehr schnell zu einer Verwässerung des ursprünglichen Designs.

Der Nachteil daran ist einfach erklärt: Neben der Notwendigkeit, sämtliche Dokumentationen zu ändern (Design Dokument etc.) hat sich durch die spätere Änderung das Design eventuell so stark verändert (meist durch Work-Arounds), dass die Code-Teile nicht mehr intuitiv zu verwenden sind. Team-Kollegen, neue Mitstreiter oder eventuelle Kunden, die programmiertechnisch damit in Berührung kommen, müssen sich lange durch die Dokumentation quälen anstatt durch einen ersten schnellen Tests die Funktionsweise zu verstehen. Eine einfache Sache kann also schnell zu einer Katastrophe ausarten.

Der weitere Ablauf liegt ebenso auf der Hand: Irgendwann wird ein anderer findiger Entwickler diesen Sourcecode zur Überarbeitung markieren. Es entsteht ein Arbeitspaket mit der Prioritätsstufe niedrig - wenn sich einmal Zeit findet. Bis dieser Tag angebrochen ist (in der Regel nie) werden an diesen Stellen vermutlich zahlreiche Funktionserweiterungen implementiert. Ein einfaches Austauschen ist somit auch nicht mehr möglich. Treten zu einem späteren Zeitpunkt gerade hier vermehrt Fehler auf, wird ein alter Spruch missbraucht: Das ist im Laufe der Zeit so gewachsen..

Als Tipp kann ich daher nur jedem Entwickler mitgeben: Bereits im Vorfeld sind Gedanken über die spätere Verwendung von Code-Teilen notwendig. Sinnvoll kann es natürlich sein, nach einem ersten Grob-Design mit einem Testfall zu beginnen. Anhand dessen kann abgeleitet werden, ob die angedachte Verwendungsweise tatsächlich gut ist, oder ob Nacharbeit notwendig ist. Nach zwei bis drei Iterationen über diese Punkte hat sich ein Verständnis für dieses Arbeitspaket entwickelt und auch die Verwendung sollte weitaus klarer und intuitiver sein, als dies vermutlich beim ersten Ansatz der Fall war.

  Kommentar hinzufügen   |  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


Nervig hoch 2: FxCop + WPF

14.05.08 - Entwicklung, Qualitätsmgmt., .NET, WPF
Beitrag von Norbert Eder
 Ein Großteil des FxCop Ruleset ist bei meinen Projekten ständig aktiviert und hilft so, den Code sauberer, sicherer und performanter zu halten.

Aber gerade in Kombination mit WPF ergeben sich daraus natürlich einige Probleme oder besser gesagt, Ärgernisse. Nehmen wir die Regel CA1823. Diese besagt, dass ein Feld nicht verwendet wird, oder ihm nie ein Wert zugewiesen wurde. Derartige Regeln werden bei mir grundsätzlich als Fehler und nicht als Warnung behandelt.

Wie kommt man nun dazu, sich über diesen Fehler zu ärgern? Ganz einfach. Man vergebe einem Element einen x:Name. Dadurch wird es im generierten File (.g.cs) angelegt, damit aus der Codebehind-Datei darauf zugegriffen werden kann. Eventuell möchte man dies jedoch nicht, sondern vergibt dem Element bloß einen Namen, um per Binding darauf zuzugreifen.

Und schon taucht dieser Fehler auf und schreit nahezu danach, suppressed zu werden - was ja eigentlich vermieden werden sollte.

Wäre schön, wenn sich diesbezüglich zukünftig etwas tun würde ..

  8 Kommentare - 15669 mal angesehen   |  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 - 1357 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Aufwandsschätzungen verbessern

04.02.08 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Aufwandsschätzungen gehören quasi zur täglichen Arbeit eines Softwareentwicklers – zumindest sollte es das. Gerade für den Projektmanager ist es nicht unerheblich, über den zu planenden Aufwand Bescheid zu wissen, als auch feststellen zu können, wie der derzeitige Stand ist. Daher müssen Aufwände für erfasst werden für:
  • das gesamte Projekt
  • daraus resultierende Komponenten
  • daraus resultierende einzelne Tasks


Kontrolle der Aufwände


Einer der wichtigsten Aspekte daran ist es, dass die ursprünglich abgegebenen Schätzungen ständig neu betrachtet und gegebenenfalls aktualisiert werden. In vielen Unternehmen unterbleibt dieser Schritt, wodurch das Projektmanagement oft keine aktuellen Zahlen zur Verfügung hat und Verzögerungen nicht sofort erkannt werden.
Aber auch der Entwickler selbst kann von der Überarbeitung der Aufwandsschätzungen profitieren. Zumindest sollten die ursprünglich geschätzten Aufwände mit dem tatsächlichen Aufwand verglichen werden. Dadurch werden Verzögerungen festgehalten und stellen einen wichtigen Ansatzpunkt zur Analyse dar. Unter anderem können dadurch folgende Fragen beantwortet werden:
  • Bei welchen Aufgaben wurden die ursprünglichen Schätzungen überschritten?
  • Betrifft dies ähnliche Aufgaben bzw. die Arbeit mit speziellen Techniken/Technologien?
  • Welche Probleme sind dafür verantwortlich?

Auf Basis der Antworten zu diesen Fragen können Schritte eingeleitet werden, um die Aufwandsschätzungen beim nächsten Mal zu verfeinern bzw. um grundlegende Probleme aufzuarbeiten. Dies hilft nicht nur dem gesamten Projekt, sondern jeder einzelne Entwickler bekommt ein immer besseres Gefühl für die zu schätzenden Aufgaben und schließlich können dadurch eigene Schwachpunkte gefunden und bekämpft werden. Es resultiert also eine Verbesserungsliste der eigenen Fähigkeiten. Ganz gut, wenn man bedenkt, dass damit die Qualität der eigenen Arbeit wesentlich verbessert werden kann.

Gegenüberstellung


Welche Daten sollten nun gegenüber gestellt werden? Ich kann hier hauptsächlich aus meiner persönlichen Erfahrung sprechen und wiedergeben, welche Daten von mir ausgewertet werden:
  • Ticket (aus Ticketing-System)
  • Ursprüngliche Schätzung
  • Gesamter Aufwand
  • Abweichung in Stunden
  • Abweichung in Prozent
  • Bei Problemen eine entsprechende Angabe darüber

Diese Liste kann in entsprechenden Tools (beispielsweise Excel) gut erstellt und gewartet werden. Ebenfalls lassen sich entsprechende Diagramme anfertigen, die anhand des Verlaufs über zahlreiche Aufgaben hinweg eine Tendenz anzeigen und somit auch erkennen lassen, ob Reaktionen auf etwaige Verzögerungen tatsächlichen Einfluss ausüben.

Fazit


Aufwandsschätzungen müssen gemacht werden und in vielen Fällen passiert dies auch durch den tatsächlichen Entwickler. Damit dieser nun an seinen Fähigkeiten arbeiten kann empfiehlt es sich, die eigenen Angaben und Leistungen auch ständig zu messen und zu bewerten. Mit einfachen Mitteln können hier sehr gute Ergebnisse erzielt werden.

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



Zurück Weiter