Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Anforderungen strukturieren

Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?

Die Anforderung lebt!

Erstellt am 31 Juli 2015
von 1 Komment

Ist das Requirement Engineering tot?

desertDen Begriff „Requirements Engineering“ verbinden viele mit schwergewichtigen, dokumentenorientierten Vorgehensweisen, mit denen man Riesenprojekte besonders in der Luft- und Raumfahrt durchführt. Es beschreibt eine Herangehensweise aus den alten Zeiten der trägen „Wasserfall“-Projekte. Das Wort „Engineering“ klingt dabei wie ein komplexes Konstrukt, eine aufwändige Maschinerie für Anforderungen, ein starres Gebilde, das viel Ressourcen verschlingt und sich, wenn überhaupt, nur träge und langsam bewegt.

Frühstück bei Tiffalmy

Erstellt am 8 Oktober 2014
von Schreibe einen Kommentar

On the Set of "Breakfast at Tiffany's" Audrey HepburnLetzte Woche war die Premiere für unser ALM Breakfast in München. In einer tollen Umgebung trafen sich viele Interessierte zu Thema „Application Lifecycle Management (ALM) für Software Engineering Professionals – Fundierte Methoden und bewährt Praktiken aus der IT Industrie“. Erstaunlich war,

 

(Quelle:http://www.spiegel.de/fotostrecke/fruehstueck-bei-tiffany-fotostrecke-107206-5.html)

#3: Der Defect

Erstellt am 5 August 2014
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Änderungsmanagement im ALM

Nachdem im ersten Blogbeitrag dieser Serie ein allgemeiner Überblick gegeben wurde und im zweiten Teil die erste Vertiefung mit dem „Bug“ erfolgte, wollen wir uns im dritten Teil mit dem Defect beschäftigen.

Ein Defect beschreibt einen Fehler, der

Eine Erfolgsgeschichte: Produktentwicklung mit dem Scaled Agile Framework (SAFe)™

Erstellt am 24 März 2014
von Schreibe einen Kommentar

Die Ausgangssituation
Unser Kunde ist ein IT-Dienstleister und Hersteller einer Standardsoftware, die im Rahmen eines klassischen Vorgehensmodells entwickelt wurde.
Nach einer Analyse der bisherigen Vorgehensweise, wurden die folgenden Schwachstellen identifiziert: 

HOOD konzentriert seine agilen Aktivitäten in der neuen Marke „Agile-by-HOOD“

Erstellt am 23 Oktober 2013
von Schreibe einen Kommentar

Agile-by-HOOD LogoMünchen, 22. Okt 2013: Die HOOD GmbH geht heute mit ihrem Angebot Agile-by-HOOD an den Markt.

Erster Auftritt von Agile-by-HOOD ist auf der vielbeachteten Konferenz „Manage Agile“ in Berlin.

Seit mehr als 25 Jahren berät und unterstützt HOOD erfolgreich seine Kunden bei der Entwicklung komplexer Software und Systeme durch Requirements Engineering-Prinzipien.

Mit der Marke Agile-by-HOOD bündelt HOOD das Angebot im agilen Umfeld und macht somit einen weiteren konsequenten Schritt zur zielgerichteten Unterstützung von Organisationen, die entweder bereits agil arbeiten oder sich vorgenommen haben, in Zukunft ihre Entwicklung auf Scrum, Kanban oder ähnliche Vorgehensweisen umzustellen.

HOOD kann dabei auf langjährige Erfahrungen im Agile Coaching und fundierte Expertise im Requirements Engineering zurückgreifen, um große Unternehmen beim Umstieg von klassischer auf agile Vorgehensweise zu begleiten. Das Thema agil-skaliert ist uns ein besonderes Anliegen – wir verstehen auch die Entwicklung komplexer Produkte und Systeme mit vielen Teams und großen Organisationen.

Weitere Infos unter: http://www.Agile-by-HOOD.com

„Ein Plan ist nichts, Planung ist alles.“

Erstellt am 30 Juli 2013
von Schreibe einen Kommentar

So sagte Dwight D. Eisenhower. Gerade hatte ich meinen Projektplan aktualisiert, schon ruft mich – völlig unerwartet – mein Kollege an. Er müsse unbedingt noch diese Woche für sein parallel laufendes Projekt arbeiten und steht mir erst übernächste Woche wieder zur Verfügung. Kurz darauf erreicht mich mein Kunde und eröffnet mir, dass wir unsere Testphase zwei Wochen früher starten müssten. Der gerade aktualisierte Projektplan pulverisierte sich gerade vor meinem geistigen Auge.

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.

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?

Wer plant mit welchen Backlogs? – Sichtenwechsel notwendig!

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

Kennen Sie auch die Situation, dass Ihre Projekte nicht die optimalen Voraussetzungen für Scrum haben? Sie haben also:

  • Entwickler, die zeitgleich in mehreren Projekten arbeiten.
  • Entwicklungsteam, die auf unterschiedliche Standorte und Zeitzonen verteilt sind.
  • Nur ein auslieferbares Release, wenn die Zulieferung vieler Teams erfolgt ist.