Funktion oder Feature? Was ist der Unterschied?

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Die Begrif­fe Funk­ti­on und Fea­ture wer­den in der → Soft­ware­ent­wick­lung ver­wen­det, sind aber nicht unbe­dingt iden­tisch ein­setz­bar.
In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe geliefert.

In der Wiki­pe­dia schreibt zum Begriff Funk­ti­on / Funk­tio­nen eines Objekts /#Wiki-Funktion/:
“Als Funk­tio­nen eines Objek­tes bezeich­net man die Auf­ga­ben, die es erfül­len kann. Mit­hil­fe sei­ner Funk­tio­nen kann ein Objekt also gewis­sen Zwe­cken die­nen. Ein ein­zel­nes Objekt kann meh­re­re Funk­tio­nen haben, wel­che dem­sel­ben Zweck die­nen kön­nen oder ver­schie­de­nen. Gleich­zei­tig kann eine Funk­ti­on auch für meh­re­re Zwe­cke genutzt werden.”

Zum Fea­ture steht in der Wiki­pe­dia knapp /#Wiki-Feature/:
“Pro­gramm­fea­ture, die Funk­tio­na­li­tät einer Soft­ware (sie­he auch Fea­ture-Request)“
und zum Fea­ture-Request wird dann wei­ter aus­ge­führt /#Wiki-Feature-Request/:
“Fea­ture-Request (von engl. fea­ture = Eigen­schaft, Fähig­keit, Funk­ti­on; request = Antrag, Anfra­ge, Wunsch; auch Leis­tungs­merk­mal­an­for­de­rung) oder Ver­bes­se­rungs­vor­schlag bezeich­net die Anfra­ge, eine Soft­ware um eine neue Funk­ti­on zu erwei­tern oder die vor­han­de­ne Funk­tio­na­li­tät zu verändern.”

Das → IIBA defi­niert den Begriff Fea­ture wie folgt /BBG-17d/:
“Lösungs­merk­mal (fea­ture): Abgrenz­ba­rer Bestand­teil einer Lösung, in dem eine Rei­he von Anfor­de­run­gen umge­setzt wird und der Wert für → Stake­hol­der liefert.”

Die Cha­rak­te­ri­sie­run­gen von Funk­ti­on und Fea­ture sind in Abbil­dung 1 wiedergegeben.

Funktion

Abbil­dung 1: Funk­ti­on und Feature

Grund­sätz­lich sind bei­de Begrif­fe fast syn­onym zu ver­wen­den. Wäh­rend im klas­si­schen Vor­ge­hen eher der Begriff Funk­ti­on genutzt wird, fin­det sich bei agi­ler Vor­ge­hens­wei­se bevor­zugt der Begriff Fea­ture. Wenn von einem Fea­tur­ebün­del (Fea­ture Bund­le) gespro­chen wird, so ist die­se eine zusam­men­hän­gen­de Samm­lung von Fea­tures, die häu­fig als Gan­zes umge­setzt werden. 

Wei­te­res:

  • Bei agi­ler Vor­ge­hens­wei­se umfasst ein Fea­ture ein oder meh­re­re → User Sto­ries. Typi­scher­wei­se soll­te ein Fea­ture inner­halb eines Releases, bes­ser noch inner­halb eines Sprints umge­setzt wer­den können
  • Als → Fea­ture Free­ze wird ein → Zeit­punkt bei der Erstel­lung von Anfor­de­run­gen / Requi­re­ments oder bei der Pro­gram­mie­rung von Soft­ware­sy­te­men bezeich­net, ab dem kei­ne wei­te­ren Fea­tures mehr hin­zu­ge­fügt wer­den dür­fen, der Funk­ti­ons­um­fang damit festliegt
  • Eine “Fea­ture List” (oder auch “Func­tion­al Scope List”) kann in einem → Vor­ha­ben sehr früh­zei­tig erstellt wer­den. Eine sol­che → Lis­te umfasst die Fea­tures des zu erstel­len­den Pro­dukts und kann wei­ter­ver­wen­det wer­den, so bei­spiels­wei­se zur Erstel­lung eines → Las­ten­hefts oder zur Releaseplanung
  • Eine “Fea­ture Group” wird bei der agi­len Soft­ware­ent­wick­lung auch als “The­me” bezeichnet
  • Im → Beschaf­fungs­we­sen gibt es den RFF / Request for Fea­ture (deutsch Auf­for­de­rung zur Ange­bots­er­wei­te­rung). Die­ser Request wird genutzt, wenn ein bestehen­des Ange­bot — bei­spiels­wei­se auf Basis eines → Las­ten­hefts — nicht mehr aus­rei­chend ist
  • Es gibt den Spruch “It’s not a bug, it’s an fea­ture” / “Es ist kein → Feh­ler, es ist ein Fea­ture”. Hier­mit ist gemeint, dass ein nicht erwar­te­tes Ver­hal­ten, wel­ches bei einem → Soft­ware­test auf­ge­fal­len ist, vom Ent­wick­ler so beab­sich­tigt war, es wur­de ledig­lich ver­ges­sen, dies zu dokumentieren
  • Beim Soft­ware­test: Nicht-doku­men­tier­te Fea­tures sind Fehler
  • Es gibt den Ansatz des Fea­ture Dri­ven Deve­lo­p­ments (FDD), bei dem sich das Umset­zungs­vor­ge­hen bei der Ent­wick­lung von Soft­ware an den­je­ni­gen zu ent­wi­ckeln­den Fea­tures ori­en­tiert, die Kun­den einen Mehr­wert bringen
  • Die Func­tion-Point-Metho­de dient dazu, die Grö­ße / → Kom­ple­xi­tät von Soft­ware­sys­te­men zu bewer­ten und zu vergleichen
  • “Buy a Fea­ture” ist eine Metho­de zur → Prio­ri­sie­rung bei der agi­len Softwareentwicklung
  • Ein “Mini­mal Mar­ke­ta­ble Fea­ture (MMF)” ist die kleinst­mög­li­che Men­ge von Fea­tures, die in Betrieb genom­men wer­den kön­nen und gleich­zei­tig ver­markt­bar sind
  • Ein “Fea­ture Toog­le” ist ein Sys­tem / eine Eigen­schaft, bei der ein Fea­ture bei Bedarf an- oder abge­schal­tet wer­den kann
  • Unter “Fea­ture-Fal­le” /Perri20/ wird die Pro­ble­ma­tik zusam­men­ge­fasst, dass Pro­dukt­ma­na­ger dazu nei­gen, bei ihren Pro­duk­ten eine mög­lichst hohe Anzahl von Fea­tures ein­zu­bau­en, ohne dar­auf zu ach­ten, ob die­se dem Kun­den Mehr­wert brin­gen. Oder anders aus­ge­drückt: Es wird mehr auf “→ Out­put” und weni­ger auf “→ Out­co­me” geach­tet
  • Das → Pflich­ten­heft kann als “Func­tion­al Spe­ci­fi­ca­ti­on” oder “Fea­ture Spe­ci­fi­ca­ti­on” bezeich­net werden

Lite­ra­tur

  • /BBG17‑d/ IIBA: BABOK v3: Leit­fa­den zur Busi­ness-Ana­ly­se BABOK Gui­de 3.0, Dr. Götz Schmidt, Wet­ten­berg 2017, ISBN 978–3‑945997–03‑1
  • /Perri18/ Melis­sa Per­ri: Esca­ping the Build Trap. How Effec­ti­ve Pro­duct Manage­ment Crea­tes Real Value, O’Reil­ly UK, Farn­ham, Gre­at Bri­tain 2018, ISBN 978–1‑4919–7379‑0
  • /Perri20/ Melis­sa Per­ri: Raus aus der Fea­ture-Fal­le. Wie effek­ti­ves Pro­dukt­ma­nage­ment ech­ten Mehr­wert schafft, O’Reil­ly, Köln 2020, ISBN 978–3‑96009–120‑2

Web­links

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website