Wissen ist Macht! Zu viel Wissen schadet.

In einem klassisch aufgebauten OO-System ist jedes Objekt selbst dafür zuständig, seine Abhängigkeiten, also benötigte Objekte und Ressourcen, zu erzeugen und zu verwalten. Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde. Insbesondere muss es, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen.

Ein Implementierungsbeispiel mit dem ASP.NET MVC Framework, dem DI Framework StructureMap 2.0 in C# und etwas TDD:

http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx

Mehr: http://de.wikipedia.org/wiki/Dependency_Injection

Verwandte Artikel:

Agiles Projektcontrolling

Agilität bedeutet nicht, dass man orientierungslos vor sich her entwickelt. Durch folgende Praktiken haben die verschiedennen Interessengruppen einen guten Einblick in das Projekt.

  • Tägliche Teammeetings
  • Burndown (oder -up) Grafiken je Iteration (Sprint) und für das gesamte Release
  • Echte Fortschrittsmessung mit der Definition von DONE
  • Anzahl der entdeckten Fehler nach DONE Meldung
  • Review Meetings am Ende einer Iteration
  • Grad der Testabdeckung

Daneben natürlich die üblichen Klassiker:

  • Zeit
  • Kosten

Verwandte Artikel:

Git und Mercurial vs. SVN und CVS im Chaosradio Podcast CRE130

Guter Vergleich von SVN und CVS mit verteilten Versionierungssystemen Git und Mercurial im CCC Chaosradio Podcast CRE130. Einblick in die Historische Entwicklung, Unterschiede und Erweiterungen.

Die Verteilung des kompletten Repositories sorgt in der Open Scource Szene zu einer wirklichen verteilten Möglichkeit der Code Ownership. OpenSource++ quasi.

Auch für Closed Source Projekte bietet das stark vereinfachte Merging von Branches Vorteile in Repositories mit parallelen Zweigen.

Weblink: http://chaosradio.ccc.de/cre130.html

Verwandte Artikel:

Anleitung, Muster (Pattern) oder Rezept?

Eine Anleitung ist eine Abfolge von Anweisungen, zur Bewältigung einfacher und komplizierter Situationen.

Muster hingegen sind Vorlagen zur Bewältigung komplexer Situationen.

Ein Rezept ist etwas zwischen einer Anleitung und einem Pattern.
Obwohl ein Kochrezept die Umwelt auf eine Untermenge beschränkt (Zutaten und Kochutensilien) und eine mehr oder weniger detaillierte Anleitung gibt, schmeckt das Resultat doch immer anders. Gleichzeitig erkennt man in den Ergebnissen Gemeinsamkeiten, also Muster.

Richtiges Anwenden einer guten Anleitung erbringt in der Regel das gewünschte Ergebnis. In komplexen Situationen gibt es hingegen viele Einflussfaktoren, die nicht dem Ursache-Wirkungs-Prinzip folgen. Ein Muster beschreibt eine Situation daher niemals komplett.

Siehe auch:
http://de.wikipedia.org/wiki/Entwurfsmuster
Linda Risiungs Pattern Almanac http://www.smallmemory.com/almanac/

Verwandte Artikel:

Warum dauert die Sprintplanung so lange?

Gegebenheiten:
– Die Anforderungen im ProduktBacklog werden in idealen Personentagen abgeschätzt (GF-Beschluss).
– Die Anforderungen sind am Sprintende sehr oft nicht vollständig umgesetzt (Muss zusätzlich untersucht werden!).

Effekt:
Im ersten Sprintplanungs-Teil, in dem sich das Team die Anforderungen auswählt, zu denen es sich committed, wird der Restaufwand in idealen PT abgeschätzt. Über mehrere Iterationen hinweg werden also immer wieder die gleichen Anforderungen neu abgeschätzt. Das kostet Zeit und ist ermüdend. Dadurch wird der zweite Sprintplanungs-Teil, in dem die Anforderungen in Tasks herunter gebrochen und auf Stundenbasis geschätzt werden nur mühsam und wird nur unvollständig gelebt.
Vor allem die Entwickler, die es nicht gewohnt sind große Aufgaben in kleine aufzuteilen haben damit Schwierigkeiten.

Lösungsmöglichkeit:
Wenn die Anforderungen ohnehin schon in idealen Personentagen geschätzt werden, kann SP1 und SP2 zusammengefasst werden.
Dabei werden direkt die (restlichen) Aufgaben je Anforderung ermittelt, in Stunden abgeschätzt und notiert.
Lediglich neue Anforderungen könnnen vorab grob in PT geschätzt werden.
Das Sprint Burndown Chart kann somit ggf. auch ohne Aufteilung der Anforderungen in Aufgaben mit der Summe der Anforderungsaufwände auf der Y-Achse gestartet und bei vollständiger Erledigung abgetragen werden.

Verwandte Artikel: