1996-1997-1998-1999-2000-2001-2002-2003-2004
Re: Agile Methoden im neuen V-Modell (730)
von Hagen, U.
Mittwoch, 17. März 2004 15:27
Mail 0629 PM 1.4 - Wer akzeptiert das Projekthandbuch?

Mail 0630 Re: PM 1.4 - Wer akzeptiert das Projekthandbuch?

Mail 0631 Re: PM 1.4 - Wer akzeptiert das Projekthandbuch?

Mail 0632 Produktstatus Projekthandbuch

Mail 0633 Prüf-Grundsatz (Was: PM 1.4 - Wer akzeptiert das Projekthandbuch)

Mail 0634 Re: Prüf-Grundsatz

Mail 0635 Re: Prüf-Grundsatz

Mail 0636 Re: Prüf-Grundsatz

Mail 0637 Re: Prüf-Grundsatz

Mail 0638 Re: Prüf-Grundsatz

Mail 0639 Re: Prüf-Grundsatz

Mail 0640 YAGNI (Re: Prüf-Grundsatz)

Mail 0641 Software für Händi;-) (Was: Re: Prüf-Grundsatz)

Mail 0642 anders = besser?!? (Was: Re: Prüf-Grundsatz)

Mail 0643 Re: Prüf-Grundsatz , XP etc.

Mail 0644 Re: Prüf-Grundsatz , XP etc.

Mail 0645 Re: Software für Händi;-)

Mail 0646 Re: Prüf-Grundsatz , XP etc.

Mail 0647 Re: Prüf-Grundsatz , XP etc.

Mail 0648 Re: Prüf-Grundsatz , XP etc.

Mail 0649 Re: Prüf-Grundsatz , XP etc.

Mail 0650 Re: Prüf-Grundsatz , XP etc.

Mail 0652 Agile Methoden versus V-Modell. (War: Re: Prüf-Grundsatz, XP etc:)

Mail 0657 Agile Methoden im neuen V-Modell

Mail 0658 Re: Agile Methoden im neuen V-Modell

Mail 0659 Re: Agile Methoden im neuen V-Modell

Mail 0660 Extreme Programming und das V-Modell

Mail 0661 Re: Extreme Programming und das V-Modell

Mail 0662 GI-Vortrag "Agile Prozesse" in München

Mail 0663 Re: Extreme Programming und das V-Modell

Mail 0664 V-Modell am Studienplan?

Mail 0665 Re: Extreme Programming und das V-Modell

Mail 0666 Re: Extreme Programming und das V-Modell

Mail 0667 Re: Extreme Programming und das V-Modell

Mail 0668 Re: Extreme Programming und das V-Modell

Mail 0669 Re: Extreme Programming und das V-Modell

Mail 0671 Re: Extreme Programming und das V-Modell

Mail 0728 Re: Agile Methoden im neuen V-Modell

Mail 0729 Re: Agile Methoden im neuen V-Modell

Mail 0730 Re: Agile Methoden im neuen V-Modell

Mail 0731 Re: Agile Methoden im neuen V-Modell

Mail 0732 Re: Agile Methoden im neuen V-Modell

Mail 0733 Re: Agile Methoden im neuen V-Modell

Mail 0734 Re: Agile Methoden im neuen V-Modell

Mail 0735 Re: Agile Methoden im neuen V-Modell
Von: "von Hagen, Ulrich (LDS)"
Hallo Herr Linssen,
Ihre Vorgehensweise kann ich mir im Hinblick auf Ausbaustufen gut vorstellen.
Aber was mache ich, um zunächst einmal zu einem Kernsystem zu kommen, das
geeignet ist, ein vorhandenes System "auf einen Schlag" abzulösen?
[Aufgrund bestimmter technischer Rahmenbedingungen und spezifischer
Schnittstellenanforderungen kommt in unserem Fall eine sukzessive
Ablösung des Altsystems (d.h. ein Ersetzen von Teilen des Altsystems
durch Ergebnisse einzelner Arbeitspakete) nicht in Betracht.]
MfG
U. von Hagen - LDS NRW
-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet: Mittwoch, 17. März 2004 14:54
An: Multiple recipients of V-Modell-Mailingliste
Betreff: Re: Agile Methoden im neuen V-Modell (729)
Hallo Herr von Hagen,
nach meiner Meinung ist das Problem genereller Natur. Bei agilen Projekten
mit sehr kurzen Planungszyklen wird es aber besonders deutlich. Man kann das
aber auch als Chance sehen.
Wir verwenden folgendes Verfahren:
A.) Arbeitspakete gruppieren Anforderungen
B.) Offene Fragen
C.) Anforderungen haben einen Status
D.) Timeboxing
Zu A: Anforderungen werden paketweise abgearbeitet bzw realisiert.
Zu B: Wir verwenden einen Dokumententyp "Offene Frage". Offene Fragen haben
eine definierte Strukur (auf die ich hier nicht eingehe). Beispielsweise
stellt ein Modellierer einem Anforderungssteller eine offene Frage, wenn ihm
der Inhalt einer Anforderung unklar ist.
Zu C: Anforderungen erhalten einen Status. Hier sind unterschiedliche
Zustände denkbar und sinnvoll. Ein vereinfachtes (hier unvollständiges)
Zustandsmodell hätte beispielsweise die Zustände:
[roh] - private Entwurfsfassung des Anforderungsstellers.
[vorgeschlagen] - der Anforderungssteller ist mit seiner Formulierung
fertig. Es gibt aber noch offene Fragen des Entwicklers, die der
Anforderungssteller beantworten muss bzw. wo er die Formulierung der
Anforderung modifizieren muss.
[akzeptiert] - alle offenen Fragen sind beantwortet. Anforderungssteller und
Entwickler sind sich über den Inhalt und die Formulierung einig. Der
Entwickler ist bereit, die Verantwortung für die Umsetzung zu übernehmen.
[...] - weitere
zu D: Zur Realisierung (Modellierung, Implementierung etc.) werden immer nur
die Arbeitspakete eingeplant (und terminiert), bei denen bis zu einem
bestimmten Zeitraum alle offenen Fragen beantwortet sind. Ist das nicht der
Fall, wandern Sie in die nächste Planungsperiode (Release, Iteration etc.).
Hier sollte ich erwähnen, dass wir immer mit revolvierender Planung
arbeiten. Aber alles andere vermittelt Scheinpräzision.
Das löst nicht das Problem, dass Anforderungssteller über einen langen
Zeitraum ihrer Informationspflicht nicht nachkommen. Es macht aber - auch
von der Managementseite her - deutlich, wer im Obligo ist. Will damit sagen:
das löst nicht generell das Problem, aber es verschafft Linderung.
Auch wenn das jetzt etwass skizzenhaft war, hoffe ich, dass die Idee klar
wird.
Gruß,
Oliver Linssen
______________________________________________________
Geschäftsführer Liantis GmbH & Co. KG
Mobil: +49 (0) 163/2469006
http://www.liantis.com
Free your work. Liantis.
not defined