Eingeschneit und noch am Leben kann es diese Zeilen geben …

Erstellt am 11 Dezember 2012
von Schreibe einen Kommentar

Einige Monate ist es her, da war dem Entwickler das Herz so schwer. Das Build gebrochen, die Tests daneben und QM – haben ihm den Rest gegeben. Einige Wochen ist es her, da war dem Projektleiter das Herz so schwer. Die Planung umsonst, das Team rebelliert und HR mahnt ungeniert.

Verschlossene Türen und Scrum

Erstellt am 27 November 2012
von Schreibe einen Kommentar

Gestern traf ich eine neue Kollegin des Nachbarprojektes vor der verschlossenen Tür ihres Projektbüros. Wir begannen uns über unsere Projekte auszutauschen und es stellte sich heraus, dass wir gerade am gleichen Thema arbeiten, allerdings in verschiedenen Projekten. Der Wissensaustausch war für uns beide informativ und gewinnbringend. Auf dem Nachhauseweg musste ich über die Begegnung nachdenken…

Agile Transition – wenn aus der Zeit des Wasserfalls noch Altlasten bestehen

Erstellt am 23 Oktober 2012
von Schreibe einen Kommentar

Agile Entwicklungsmethoden gewinnen stark an Bedeutung und lösen zunehmend phasen- und dokumentengetriebene Vorgehensweisen ab. Werden agile Prinzipien und damit verbundene Entwicklungstechniken konsequent eingesetzt, wird die Qualität steigen und die Fehlerzahl tendenziell sinken. Aber es gibt auch noch die Zeit vor der Umstellung auf agile Entwicklungsmethoden. Aus diesen Zeiten werden – gerade in großen Organisationen –…

Story-Requirements – ein Gedankenspiel

Erstellt am 2 Oktober 2012
von Schreibe einen Kommentar

Spätestens seit sich die agile Softwareentwicklung als alltagstaugliche und in einigen Entwicklungsbereichen auch als alternative Vorgehensweise durchgesetzt hat, sind die User Stories fester Bestandteil der Entwicklung. Die Requirements sind aber als Entwicklungsartefakt nicht ausgestorben. So existieren in vielen Unternehmen beide Artefakte – User Story und Requirement – nebeneinander, quasi stellvertretend für die agile und die…

Die Diskrepanz zwischen Anforderung und Implementierung

Erstellt am 25 September 2012
von Schreibe einen Kommentar
This entry is part 1 of 3 in the series Anforderung und Implementierung

Man kennt den klassischen Weg, Anforderungen zu spezifizieren: ein Spezifikationsdokument mit den Kundenanforderungen wird erstellt (oft „Lastenheft“ genannt), dann ein Dokument, das die Umsetzung der Kundenanforderungen beschreibt (oft „Pflichtenheft“ genannt). Ist damit sichergestellt, dass die Implementierung korrekt sein wird?

Rollenkonflikte in agilen Umgebungen

Erstellt am 18 September 2012
von Schreibe einen Kommentar

Mit der Einführung von Scrum werden die Rollen Scrum Master, Product Owner und Entwicklungsteam neu eingeführt. Im Fokus dieses Beitrages steht der Product Owner. Der Product Owner ist verantwortlich für den Produkterfolg und für den Wert, den die Arbeit des Entwicklungsteams liefert (Scrum Guide). Der Product Owner tritt dem Entwicklungsteam als Kunde bzw. als Kundenstellvertreter…

________ Retrospektive ________

Erstellt am 28 August 2012
von Schreibe einen Kommentar

Für Scrum bereit, das Board an der Wand, Cards die jeder mag. Wertvoll die Zeit, das Heft in der Hand, Conversation jeden Tag. Die Story ist klar? Der Sprint in Gang, die Tasks bleiben aber liegen. Confirmation ist rar, dem Product Owner ist bang, das Inkrement kann so keiner kriegen. Das Desaster ist da, das…

Optimal und doch schlecht

Erstellt am 21 August 2012
von Schreibe einen Kommentar

„Vor 6 Monaten haben wir SCRUM eingeführt, uns Berater und Coaches ins Haus geholt und alle geben ihr Bestes. Und trotzdem sind wir nicht schneller in der Entwicklung geworden und die Qualität läßt immer noch zu wünschen übrig. Wie kann das sein?“ Da kann man nur eines mit Sicherheit sagen: SCRUM ist nicht schuld daran.…

Agilität ist keine Ansichtssache

Erstellt am 19 Juni 2012
von Schreibe einen Kommentar

Wir sind mittlerweile recht gut darin, Informationen zu analysieren und zu verwalten (z.B. Anforderungen), komplexe Strukturen in einfachere Substrukturen herunterzubrechen etc., also darin, statische oder strukturelle Komplexität zu meistern. Warum tendieren dann „große“ Systeme (v.a. Softwaresysteme) dazu, immer „schlechter“ zu werden mit einem stetig anwachsenden Fehlerberg?