Krátke spôsoby, rýchle rozhodnutia
Vývoj softvéru Lean sa v posledných rokoch stáva čoraz dôležitejším. Nestačí však využívať štíhly vývoj softvéru iba vo vývojovom tíme; požiadavky a koncepčný proces musia byť tiež organizované „štíhlo“. DR. V tomto dvojdielnom článku Matthias Eberspächer popisuje osvedčenú organizačnú štruktúru, ktorá umožňuje štíhly softvérový koncept. V prvej časti predstavuje dva najdôležitejšie orgány tejto organizácie.
obsah
- Čo je a odkiaľ pochádza „Lean“?
- Organizácia projektu
- Základný tím (KT)
- Držitelia mandátu (MT)
- výhľad
- literatúry
predmetov
Séria článkov
- Ústredné orgány a ich úlohy
- Ďalšie úlohy a odporúčania pre prax
Vývoj softvéru Lean sa v posledných rokoch stáva čoraz dôležitejším. Nestačí však využívať štíhly vývoj softvéru iba vo vývojovom tíme; požiadavky a koncepčný proces musia byť tiež organizované „štíhlo“. DR. V tomto dvojdielnom článku Matthias Eberspächer popisuje osvedčenú organizačnú štruktúru, ktorá umožňuje štíhly softvérový koncept. V prvej časti predstavuje dva najdôležitejšie orgány tejto organizácie.
obsah
- Čo je a odkiaľ pochádza „Lean“?
- Organizácia projektu
- Základný tím (KT)
- Držitelia mandátu (MT)
- výhľad
- literatúry
Toyota ukázala, ako to je: Automobily sa dnes vyrábajú „štíhlo“. Výroba sa nevykonáva „na sklade“, ale na objednávku; dodané sú iba diely, ktoré sú nainštalované okamžite. Môže sa však softvér naprogramovať rovnako ako pri výrobe automobilov? Áno môžeš! Cieľom vývoja štíhleho softvéru je minimalizovať dodací čas od požiadavky po uvedenie hotového softvéru do prevádzky. Nestačí však použiť vývoj softvéru Lean iba vo vývojovom tíme: Požiadavky a proces koncepcie musia byť tiež usporiadané ako „štíhle“. Pre úspech tu je rozhodujúce ustanovenie a udržiavanie rovnomerného „ťahu zákazníka“, ktorý umožňuje efektívny vývoj štíhleho softvéru.
Tento dvojdielny článok sa zameriava práve na rozhranie medzi používateľmi a vývojovým tímom. Ukazuje, ako projektoví manažéri a klienti ideálne zostavujú projektový tím pre štíhly projekt, ako je štíhlym spôsobom riadený proces požiadaviek a koncepcie a čo je potrebné zohľadniť. Aj keď prvé skúsenosti s týmto prístupom získali v softvérových projektoch u výrobcov automobilov, nič nebráni tomu, aby sa tu opísané koncepty uplatnili na iné typy vývojových projektov a priemyselných odvetví.
Prvá časť popisuje, čo stojí za štíhlou správou a ktoré aplikácie štíhlych koncepcií existujú pri vývoji softvéru. Je opísaná organizácia štruktúry projektu, ktorá umožňuje štíhly softvérový koncept, a najdôležitejší výbor - jadrový tím - a najdôležitejšia rola - držiteľov mandátov - tejto organizácie sú podrobne popísané. Druhá časť dokončuje popis jednotlivých výborov a rolí, napr. Projektového manažéra, a na praktickom príklade vysvetľuje proces projektu. Článok je zakončený odporúčaniami, ktoré vyplynuli zo skúseností s týmto prístupom v projektoch.
Mal som veľmi dobré skúsenosti s projektovým prístupom a organizáciou prezentovanou v mojich projektoch. Myšlienka tohto prístupu sa netýka iba projektov, ktoré sa uskutočňujú výlučne podľa štíhlych princípov, ale aj projektov, v ktorých následná implementácia koncepcií prebieha podľa iných agilných alebo dokonca tradičných modelov procesov (napr. Vodopád) . Motivácia pre štíhly prístup v riadení a koncepcii požiadaviek je samozrejme o to väčšia, ak je zvyšok implementácie projektu agilný a štíhly. Metodika uvedená v tomto dokumente má slúžiť ako návrh na použitie štíhlej projektovej organizácie pre seba a na jej ďalší rozvoj.
Výhody prístupu
Výhody postupu uvedeného v tomto článku prichádzajú do úvahy iba pri dostatočnom rozsahu projektu: Trvanie by malo byť viac ako šesť mesiacov a v projektovom tíme by malo byť najmenej desať zamestnancov projektu na plný úväzok. Inak úsilie spojené s prípravou a zriadením organizácie projektu, vrátane zaškolenia pracovníkov projektu, presahuje výhody postupu.
Na ilustráciu tejto výhody je porovnanie plánovaného rozsahu implementácie s rozsahom služieb skutočne spracovaných za plánovací interval (zvyčajne jeden rok) informatívne: Ukazuje sa, že vývojové práce vykonané ročne boli zhruba dvakrát vyššie ako pôvodne plánované. Inými slovami: S kapacitami, ktoré sú k dispozícii pre technickú koncepciu, je možné koncepcionalizovať asi dvakrát toľko tém, ako sa plánovalo. Plánovanie týchto projektov bolo v zásade založené na empirických hodnotách z tradičných projektov: Koľko tém môže dosiahnuť dostatočnú technickú koncepčnú zrelosť na implementáciu za jeden rok? Z tohto počtu samozrejme nemožno odvodiť, že tu uvedený postup je dvakrát lepší ako napríklad model vodopádu; je to však jasný náznak, že práca s štíhlymi konceptmi môže byť oveľa efektívnejšia ako tradičné procesné modely.
Typickým projektovým prostredím, v ktorom sa tento prístup uplatňoval, boli projekty pre (ďalší) vývoj a/alebo konsolidáciu existujúcich IT oblastí u výrobcov automobilov. Silné stránky postupu boli zreteľné najmä vtedy, keď požiadavky, ktoré sa majú implementovať, ešte neboli úplne pripravené na technický koncept, ale boli známe iba na „nadpisovej úrovni“, t. J. Iba zhruba vo forme zoznamu tém v excelovej tabuľke. S cieľom určiť rozpočet a časový rámec, s ktorým môže projektový tím pracovať, boli projektové/obchodné ciele vždy jasne formulované („SMART“) a bola k dispozícii štruktúra rozpisu práce s definovanými hlavičkami pracovných balíkov.
Výkon jednotlivých pracovných balíkov sa dal vždy rozdeliť na dostatočne malé, nezávislé veľkosti dávky. Toto je dôležitý predpoklad, pretože to je jediný spôsob, ako dosiahnuť krátke a rovnomerné načasovanie projektu. Na realizáciu projektu boli k dispozícii interní zamestnanci odborných a IT oddelení, ako aj externí konzultanti a dodávatelia od poskytovateľov IT služieb, a to vo fázach technickej koncepcie, koncepcie IT, implementácie, integrácie a akceptačných testov a uvedenia do prevádzky.
Čo je a odkiaľ pochádza „Lean“?
„Lean“ pochádza z Toyota Production System (TPS), ktorý sa zameriava na optimalizáciu organizačných procesov. Najznámejšou koncepciou TPS je výroba synchronizovaná s dopytom („just-in-time“): do ...