Mastering Software Architecture

Seit einiger Zeit setze ich mich recht intensiv mit dem Thema Software Architektur auseinander. So entstand mein Bedürfnis, mir diesen Themenbereich einmal von erfahrenen Architekten näher bringen zu lassen. Da ich Gernot Starke bereits durch seine Bücher (z.B. „Effektive Softwarearchitekturen“) kenne, war es für mich naheliegend das Seminar „Mastering Software Architecture“ zu besuchen, welches er gemeinsam mit Peter Hruschka („Business Analysis und Requirements Engineering: Produkte und Prozesse nachhaltig verbessern“) anbietet.

Ein schöner Nebeneffekt dabei war, dass das Seminar unter anderem auch die Lernziele des Lehrplans für die Prüfung zum „Certified Professional for Software Architecture – Foundation Level“ (CPSA-F) der iSAQB transportierte, so dass ich mich während des Seminars mehr oder weniger spontan dazu entschlossen habe auch diese Zertifizierung zu machen.

Weiterlesen „Mastering Software Architecture“

Produktivität durch Pair Programming

Noch immer hält sich selbst in Entwickler-Kreisen das Vorurteil, Pair Programming würde die Entwicklungsgeschwindigkeit reduzieren.

Klar, wenn zwei Entwickler an einem Rechner sitzen kann immer nur einer Tippen. Doch ist Programmieren wirklich nur das Abtippen von Code? Und wenn dem so ist, warum schafft es auch der beste Programmierer nicht am Tag mehr Zeilen zu schreiben, als eine durchschnittliche Rechtsanwaltsgehilfin in einer Stunde?

Ich habe selbst schon Pair-Programming-Sessions erlebt, bei denen zwei Entwickler vor dem Rechner reine Verschwendung waren. Dabei kann man mit einem motivierten und disziplinierten Paar sowie einer Hand voll best practices, die Velocity mit Hilfe von Pair Programming durchaus verdreifachen.
Weiterlesen „Produktivität durch Pair Programming“

Bucket Estimation

Nachdem ich bereits über absolutes Schätzen in Personentagen und relatives Schätzen mit Hilfe von Story Points geschrieben habe, möchte ich im Folgenden ein sehr einfaches und schnelles Verfahren vorstellen, mit dem man sehr unkompliziert ein umfangreiches Backlog abschätzen kann. Beim Bucket Estimation schätzt man Anforderungen, indem man sie dem Aufwand nach sortiert, sie anschließend gruppiert und dann allen Product Backlog Items in einer Gruppe (Bucket)  die gleiche Anzahl an Story Points zuweist.

Zum Schätzen eines Backlogs mit 50 bis 75 Backlog Items benötigt man mit dieser Methode in der Regel 1,5 bis 2 Stunden.

Weiterlesen „Bucket Estimation“

Relatives Schätzen mit Story Points

Ein Trick, um die Probleme des absoluten Schätzens auszugleichen, ist das Schätzen mit Hilfe von Story Points.

Diese Schätzung drückt im Gegensatz zum absoluten Schätze in Personentagen aus, wie hoch der Aufwand zweier Anforderungen im Bezug zueinander sind und kann darum auch als relative Schätzung bezeichnet werden. Ist eine Anforderung doppelt so anspruchsvoll wie eine andere, so hat sie auch doppelt so viele Story Points.

Weiterlesen „Relatives Schätzen mit Story Points“

Absolute Schätzungen in Personentagen

Absolutes Schätzen in Personendaten PT ist immer die schlechteste aller Möglichkeiten. Hierbei müssen ein oder mehrere Entwickler abschätzen wie viele Tage die Entwicklung einer Software in Anspruch nimmt. Es gilt PT = (Dauer der Entwicklung in Tagen) x (Am Projekt beteiligte Personen).

Eine solche Abschätzung ist meist vor Beginn des Projektes notwendig, um auf dieser Basis eine Entscheidung treffen zu können, ob das Projekt umgesetzt werden kann oder nicht.

Weiterlesen „Absolute Schätzungen in Personentagen“

Aufwandsabschätzung in der Softwareentwicklung

Aufwandsabschätzungen gehören zu den unangenehmsten Aufgaben eines Softwareentwicklers. So unangenehm dieser Task ist, so wichtig ist er jedoch auch. Sei es um im Vorfeld die Kosten für eine neue Software zu kennen, um eine zeitliche Release-Planung machen zu können oder um Behinderungen im Entwicklungsprozess zu erkennen.

Weiterlesen „Aufwandsabschätzung in der Softwareentwicklung“

Vom Geld und von Fließkommazahlen

Vor kurzem hatte ich mal wieder eine Diskussion über Rundungsfehlern bei Fließkommazahlen (double, float etc.). Klar, ein bekanntes Problem, von dem man zumindest in der Uni schon einmal gehört haben sollte. Aber wie schrieb schon Tom DeMarco in „Warum ist Software so teuer?“

Haben Sie jemals einen dummen Fehler begangen? – Wilkommen in der realen Welt.

Haben Sie diesen Fehler hundertmal hintereinderander gemacht? – Willkommen in der Software-Entwicklung.

Weiterlesen „Vom Geld und von Fließkommazahlen“