1996-1997-1998-1999-2000-2001-2002-2003-2004
Re: Prüf-Grundsatz (635)
Beckmann, M.
Donnerstag, 30. Januar 2003 05:42
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: Dr.Markus.Beckmann@t-online.de
vm-d-l schrieb:
> Von: "Rainer Midderhoff"
>
>
>
> Hallo,
>
> ... im Zusammenhang mit Prüfungen, Auftraggeber, QS und
> "Bananenprodukten" :-) folgende Frage:
>
> Situation:
>
> AN bearbeitet Projekt nach V-Modell und liefert (o Graus
> !) nach ca. 6 Monaten intensiver Spezifikationarbeit gem.
> SE 3 ca 2 Kartons "Technische Anforderungen". Die Doku-
> mente sind alle prima formatiert, haben tolle Deckblätter
> und Inhaltsverzeichnisse (es wurden die Produktmuster
> verwendet) und sind gem. Zustandskennzeichnung beim AN
> durch die Zustände "in Bearbeitung" - "vorgelegt" -
> "akzeptiert" (natürlich nur von der QS des AN) gewandert.
>
> Der AG soll - bitteschön - diese gesammelten Werke
> innerhalb von ca. 2 Wochen abnehmen - damit diese Phase
> (hört hört !) abgeschlossen werden kann.
>
> Problem:
>
> AG versteht von den Inhalten der Dokumente *kein* Wort -
> weil: ist ja alles auf Ebene SE 3 sehr technisch. Zeit
> zum Lesen von mehreren tausend Seiten (keine Übertreibung,
> kommt immer wieder vor) innerhalb weniger Arbeitstage
> ist schlicht unmöglich - und: was bedeutet die Abnahme
> durch den AG: hat er damit Verantwortung in bezug auf
> die Tragfähigkeit der vorgeschlagenen technischen Lösung
> übernommen ? Wenn nicht: wozu soll er abnehmen ...
> Fragen über Fragen.
>
> Was meinen die Praktiker ?
Ob "Praktiker" oder "Theortiker" lasse ich jetz mal offen.
Auf jeden Fall bin ich der Meinung, dass bei Eintreten
dieser Situation schon vorher nahezu alles schief gelaufen
ist, was schieflaufen kann:
(1) Wenn erst mit Vorliegen der "Technischen Anforderungen"
klar wird, dass man tausende Seiten zur Beschreibung
benötigt, dann wurde die Komplexität nicht frühzeitig
erkannt. D. h. es hat offenbar im Vorfeld keine aus-
reichende Analyse der Aufgabe stattgefunden.
Alternativ: Die technischen Anforderungen spezifizieren
das zu erstellende System bis in die letzte "Schraube".
Dann ist die Frage, ob die Darstellung der Aufgabe an-
gemessen ist.
In beiden Fällen hat es versäumt, sich frühzeitig Ge-
danken über den Umfang der Dokumentation zu machen.
(2) "nach ca. 6 Monaten intensiver Spezifikationarbeit": das
klingt so, als ob AG und AN in der Zeit nicht miteinan-
der geredet haben. D.h. der AG hat das AN-Management
vernachlässigt, der AN hat seine projektbezogene "Kun-
denpflege" vernachlässigt.
Entweder wurden hier keine angemessenen Kommunikations-
regeln festgelegt oder es hält sich keiner daran...
(3) "AG versteht von den Inhalten der Dokumente *kein* Wort"
- dann wurde entweder im Vorfeld vergessen festzulegen,
wer was wann wie prüft oder der AG hat versäumt, quali-
fizierte Prüfer "bereitzustellen". Ursache dafür könnte
in beiden Fällen sein, dass sich AG (und AN?) nicht klar
darüber war(en), was da auf sie zukommt.
(4) "innerhalb von ca. 2 Wochen abnehmen": Hier ist zu fra-
gen, wer die Angemessenheit des Zeitraums festgelegt
hat. Besser wäre es, im Vorfeld zu klären, wer dafür
zuständig ist, angemessene Fristen einzuplanen. Derje-
nige sollte diese Planung dann auch überwachen und früh-
zeitig Alarm schlagen, wenn sich Verzögerungen abzeich-
nen.
(5) "damit diese Phase abgeschlossen werden kann": Hat man
sich vorher Gedanken darüber gemacht, ob ein "event-"
oder ein "termin-gesteuerter" Phasenabschluss erreicht
werden soll? "event-gesteuert" macht z.B. dann Sinn,
wenn man mit den Anforderungen in eine Ausschreibung
für die Realisierung geht oder die Planung der Reali-
sierung erst jetzt stattfindet. Termingesteuerte Phasen-
abschlüsse ermöglichen zwar eine bessere Planung. Die
nutzt aber nix, wenn sie durch solche Vorkommnisse "den
Bach runter geht".
Eine Mixtur wie: "Wir müssen erstmal die Planung sinn-
voll abschließen, überziehen den Zeitraum dafür um n
Wochen, wollen aber trotzdem den Endtermin halten."
führt früher oder später in die Katastrophe.
(6) Wer hat ggf. den Zeitdruck zu verantworten? Der AG, in-
dem er sagt: "Wir müssen aber unbedingt des Schlusster-
min halten!" Dann muss er ggf. auch "Murks" freigeben
und die Konsequenzen tragen.
Oder der AN, der den AG "tot-papiert", mit dem Ziel, den
AG zu überfahren und im Zeitdruck eigene Ideen durchzu-
drücken, Probleme zu verschleiern o.ä.?
(7) "hat er damit Verantwortung in bezug auf die Tragfähig-
keit der vorgeschlagenen technischen Lösung übernommen"
- auch hier wieder: Was war denn vereinbart: Übernimmt
der AG diese Verantwortung - oder nimmt er nur die Do-
kumentation "zur Kenntnis"? Wenn das mit der Verantwor-
tung des AG so vereinbart war, muss er auch die Konse-
quenzen tragen.
(8) "Wenn nicht: wozu soll er abnehmen?" Genau das sollte
vorher geklärt sein. Es wäre m.E. durchaus tragfähig
zu sagen, der AG nimmt nur die Funktionalität ab, die
Technik verantwortet allein der AN. Dann muss man sich
frühzeitig ein paar Gedanken über die Konsequenzen ma-
chen (etwa: Mache ich mich von diesem AN abhängig? Hat
das technische Grundkonzept Zukunft? Gibt es Alternati-
ven?)
Nur gut, dass die o.g. Situation nicht wirklich zu Problemen
führen kann, denn der AG (und der AN) hat ja zu Projekt-
beginn ein Risikomanagement aufgesetzt. D.h. er schaut ein-
fach nach, welche Maßnahme er für das Risiko "keine ausrei-
chenden oder qualifizierten Ressourcen für die Abnahmen der
T.A. verfügbar" geplant hatte, und setzt diese um. Das Ri-
siko wird reduziert, das Projekt läuft weiter, alle sind er-
folgreich!
Der AG hat kein Risikomanagement aufgesetzt...?
Hmm - dumm gelaufen!-)
Der langen Rede kurzer Inhalt: Das o.g. Problem hat weniger
mit dem Prüfvorgang selbst zu tun als vielmehr mit Planung,
Kommunikation, Kooperation usw.
Just my 2 EUR-Cent!-)
Markus Beckmann
> Grüße
> Rainer Midderhoff
Technische Anforderungen / Technical Requirements