Priorisieren nach Zielen

Für eine belastbare Projektplanung ist es wichtig, alle Anforderungen eindeutig zu priorisieren. Und was tut man, wenn 80% aller Anforderungen Prio 1 haben?

Nur wenige Anforderungen an ein Projekt sind kontextfrei. Die meisten Anforderungen entstehen, um mit dem Projekt bestimmte Ziele zu erreichen. Daher erhalten so viele Anforderungen auch Prio 1 – sie sind wichtig für das jeweilige Ziel. Weiter lesen…

Gut gedacht – zu viel gemacht: wenn User Stories Spielraum lassen

Auch in gut laufenden agilen Projekten ist am Ende eines Sprints nicht immer das entstanden, was am Wichtigsten gewesen wäre. Dafür lassen User Stories zu viel Spielraum.

In einem Projekt sind alle User-Stories gut durchdacht, die Prioritäten klar verteilt und die Entwickler arbeiten die Stories streng nach Priorität ab. Trotzdem ist der Kunde am Ende der Sprints nicht zufrieden: Wichtiges wurde nicht geschafft, Unwichtiges hingegen getan. Wie kann das passieren? Weiter lesen…

Wie lange kann man sprinten?

In Softwareprojekten hat sich der Begriff „Sprint“ als Synonym für ein- bis zweiwöchige Iterationen eingebürgert. Trotzdem ist ein Sprint keine passende Analogie in mittel- bis langfristig laufenden Projekten!

Im normalen Sprachgebrauch wird der Ausdruck Sprint vor allem im Sport verwendet. Dort bezeichnet ein Sprint die schnellstmögliche Fortbewegung, zu der ein Mensch in der Lage ist. Jedoch nur auf kurzen Strecken!

Weiter lesen…

Testgetriebene Entwicklung: Test-first oder Test-last?

Testgetriebene Entwicklung (Test-driven development, TDD) sieht vor, die Tests vor dem eigentlichen Produktivcode zu schreiben (Test-first). Wer sich dabei nicht wohl fühlt, kann aber auch mit Test-last Systeme gut strukturieren und durch Tests absichern.

Mein Kollege Lutz hat in seinem Artikel zu Code-Retreats vor kurzem beschrieben, wie man – auch durch testgetriebene Entwicklung – zu einem besseren Entwickler werden kann. Seine Erfahrungen finde ich sehr beeindruckend. Sie haben mir Lust gemacht, ebenfalls an einem Code-Retreat teilzunehmen! Nur von einem der Grundsätze testgetriebener Entwicklung bin ich nicht vollständig überzeugt. Weiter lesen…

Kurze Wege nutzen – Software-Entwickler als Anforderungsmanager

Viele Software-Entwickler werden regelmäßig bei Ihrer Arbeit gestört. Nicht selten von Kollegen, die mit ihnen fachliche Anforderungen besprechen möchten. Anstatt jedoch den direkten Kontakt zu unterbinden, könnte man diesen auch gezielt fördern.

Das Thema Anforderungsmanagement wird in Projekten sehr unterschiedlich gehandhabt. Oft werden die fachlichen Anforderungen über den Projektleiter kanalisiert, damit er alle Themen im Blick hat und die Entwickler ungestört arbeiten können.

Es gibt jedoch gute Argumente dafür, sich anders zu organisieren. Weiter lesen…

Code a little, Test a little, Deploy a little – Continuous Delivery im Großen

Software-Entwicklung ohne Branches und jede Code-Änderung sofort produktiv setzen. Das klingt abwegig? Die Großen machen es uns vor!

Boris Bokowski von Google hielt einen der beeindruckendsten Vorträge auf der diesjährigen OOP. Er berichtete darüber, wie bei Google Software entwickelt wird: Weiter lesen…

Digitaler Notfall – Wie wappnet man sich gegen das Unvermeidliche?

Im Betrieb eines IT-Systems geschehen viele kleine und große Katastrophen. Üblicherweise treten genau diejenigen Katastrophen ein, gegen die man keine Vorkehrungen getroffen hat. Wie kann man sich trotzdem gegen große Ausfälle wappnen?

Weiter lesen…

Technisch oder fachlich: Wie verteilt man die Entwicklungsaufgaben in einem Team?

In kleineren Entwicklungsprojekten ist es selten offensichtlich, wie die Programmieraufgaben am besten verteilt werden. Sollen sich die Entwickler eher technisch oder fachlich aufteilen?

Nach meiner Erfahrung spezialisieren sich auch in kleineren Projekten (für mich sind das Teams mit maximal 10 Entwicklern) die Entwickler häufig nach technischen Kriterien: Es gibt den Datenbankdesigner, den Backend-Programmierer und die Web-Entwicklerin. Weiter lesen…