Versions‑, Varianten- oder Produktlinienmanagement? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Ver­si­on, Vari­an­te und Pro­dukt­li­nie wer­den im → Pro­dukt­ma­nage­ment — ins­be­son­de­re im Soft­ware­pro­dukt­ma­nage­ment — ver­wen­det; häu­fig wird das Manage­ment der ein­zel­nen Begrif­fe betrach­tet: Es wird zwi­schen Versions‑, Vari­an­­ten- und Pro­dukt­li­ni­en­ma­nage­ment unter­schie­den.In die­sem Bei­trag wird eine kur­ze Beschrei­bung und Abgren­zung die­ser drei Begrif­fe gelie­fert. Die Begrif­fe Versions‑, Vari­an­­ten- und Pro­dukt­li­ni­en­ma­nage­ment wer­den im Geschäftskontext … 

Wei­ter­le­sen …

Die MoSCoW-Priorisierung Einzelne Anforderungen einfach priorisieren

Die MoSCoW-→ Prio­ri­sie­rung (engl. MoSCoW prio­ri­tiza­ti­on; auch MuS­­CoW-Prio­­­sie­rung) ist eine Prio­ri­sie­rungs­tech­nik für ein­zel­ne Anfor­de­run­gen (im → Requi­re­ments Engi­nee­ring), die eine Ver­pflich­tung zur Umset­zung vor­gibt. Das Akro­nym MoSCoW steht für fol­gen­de vier unter­schied­li­che Stu­fen: Abbil­dung 1 stellt die vier Eigen­schaf­ten zusam­men­fas­send dar. Abbil­dung 1: Die vier Stu­fen der MoSCoW-Prio­ri­sie­rung Im prak­ti­schen Ein­satz wer­den die Anfor­de­run­gen (ein­zeln) nach … 

Wei­ter­le­sen …

Die SMART-Kriterien Ziele gut und passend formulieren

Die SMART-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob → Zie­le oder Anfor­de­run­gen gut genug for­mu­liert sind, sodass sie umge­setzt und abge­nom­men wer­den kön­nen.  1. Beschrei­bung Im Pro­jekt­kon­text wer­den die SMART-Kri­­te­ri­en ein­ge­setzt, um zu über­prü­fen, ob → Zie­le in Pro­jek­ten “gut genug” for­mu­liert sind. Das Akro­nym SMART steht für fol­gen­de fünf Eigen­schaf­ten: Abbil­dung 1 stellt die fünf … 

Wei­ter­le­sen …

Die INVEST-Kriterien User Stories gut und passend erfassen

Die INVEST-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob ein­zel­ne → User Sto­ries “gut genug” sind. Ursprüng­lich von Bill Wake im 2003 /INVEST-03/ vor­ge­stellt, kom­men die INVEST-Kri­­te­ri­en in fast allen Ent­wick­lungs­pro­jek­ten zum Ein­satz, in denen User Sto­ries ver­wen­det wer­den. Das Akro­nym INVEST steht für fol­gen­de sechs Eigen­schaf­ten: Abbil­dung 1 stellt die sechs Eigen­schaf­ten zusam­men­fas­send dar. Abbil­dung 1: Die … 

Wei­ter­le­sen …

Die Produktvision Beschreibung der Produktlösung in kurzen Worten

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Pro­dukt­vi­si­on (engl. Pro­duct → Visi­on oder Pro­duct Visi­on State­ment) beschreibt ein zukünf­ti­ges Pro­dukt in kur­zer Form. Erst durch eine Pro­dukt­vi­si­on kön­nen Pro­dukt­zie­le abge­lei­tet wer­den, aus denen dann in Anfor­de­run­gen abge­lei­tet wer­den kön­nen.In die­sem Bei­trag wird die Pro­dukt­vi­si­on beschrie­ben. In Abbil­dung 1 ist die Pro­dukt­vi­si­on im Unter­­neh­­mens- oder Orga­ni­sa­ti­ons­kon­text dar­ge­stellt. Sie lei­tet sich … 

Wei­ter­le­sen …

Agiles Requirements Engineering Die Anforderungen im agilen Kontext passend erfassen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Agi­le → Requi­re­ments Engi­nee­ring (Abkür­zung: ARE) fasst alle Akti­vi­tä­ten zusam­men, die bei der Erfas­sung und Behand­lung von Anfor­de­run­gen in agi­len Kon­tex­ten / bei agi­lem Vor­ge­hen zum Ein­satz kom­men kön­nen.In die­sem Bei­trag wird das Agi­le Requi­re­ments Engi­nee­ring beschrie­ben. Agi­les Requi­re­ments Engi­nee­ring (ARE) ergänzt die agi­len Metho­den und Ansät­ze, wie sie bei­spiels­wei­se in → … 

Wei­ter­le­sen …

Das Ermitteln von Anforderungen Eine Haupttätigkeit im Requirements Engineering

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Ermit­teln (engl. Eli­ci­ting) von Anfor­de­run­gen ist eine der Haupt­tä­tig­kei­ten im → Requi­re­ments Engi­nee­ring.In die­sem Bei­trag wird das Ermit­teln mit sei­nen Pro­zes­sen, Werk­zeu­gen und Metho­den beschrie­ben. In die­sem Bei­trag wird das Requi­re­ments Engi­nee­ring in die Berei­che Anfor­de­rungs­ent­wick­lung (Requi­re­ments Deve­lo­p­ment) und → Anfor­de­rungs­ver­wal­tung (→ Requi­re­ments Manage­ment) unter­teilt, wobei die­se wie­der­um in die vier Haupttätigkeiten … 

Wei­ter­le­sen …

Aufwand für das Requirements Engineering Ermittlung und Bewertung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Um → Requi­re­ments Engi­nee­ring zu betrei­ben, muss der → Auf­wand dafür berück­sich­tigt wer­den. Die­ser Bei­trag beschäf­tigt sich mit “typi­schen” Auf­wän­den für das Requi­re­ments Engi­nee­ring. Der Auf­wand zum Betrei­ben von Requi­re­ments Engi­nee­ring (RE) soll­te vor dem Start eines Requi­­re­­ments-Engi­­nee­ring-Vor­­ha­­bens bestimmt wer­den. Hier­über kann ver­deut­licht wer­den, wie viel Arbeits­zeit für das gesam­te → Vor­ha­ben aufgewandt … 

Wei­ter­le­sen …

Der Requirements Engineer Aufgaben und Rollenbeschreibung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Der Requi­re­ments Engi­neer (mög­li­che Abkür­zung: REeng) ist für die Ent­wick­lung und Ver­wal­tung von Anfor­de­run­gen in Orga­ni­sa­tio­nen zustän­dig. Was dies kon­kret bedeu­ten kann, soll­te für den jewei­li­gen Kon­text genau defi­niert wer­den, wobei → Rol­len­be­schrei­bun­gen dabei hel­fen.In die­sem Bei­trag wer­den die Auf­ga­ben (und Rol­len) des Requi­re­ments Engi­neers kurz beschrie­ben. Die Dar­stel­lung in die­sem Bei­trag ist … 

Wei­ter­le­sen …

Der Product Owner Aufgaben, Verantwortlichkeiten und Rollenbeschreibung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Der Pro­duct Owner ist eine zen­tra­le Per­son / Rol­le bei der Erfas­sung und Umset­zung von Anfor­de­run­gen in agi­len Pro­jek­ten und im → Agi­len Requi­re­ments Engi­nee­ring (ARE).In die­sem Bei­trag wird die Rol­le des Pro­duct Owners mit den Auf­ga­ben kurz beschrie­ben. Der Pro­duct Owner erfasst und ver­wal­tet die Anfor­de­run­gen bei agi­ler Vor­ge­hens­wei­se. Da bei der … 

Wei­ter­le­sen …