Управљање пројектима водопада - Данас већина ИТ тимова гледа на усвајање система Агиле Пројецт Манагемент. Али оно што на крају раде је усвајање система Агиле Пројецт Манагемент у њихове пројекте. То значи комбинацију традиционалних система управљања пројектима (који се називају водопадни системи за управљање пројектима), комбиноване са принципима агилног управљања, као што је детаљно описано у оригиналном Агилном манифесту.
Како све више пројеката широм света укључује праксе Агиле Пројецт Манагемент, да ли то значи крај управљања воденим пројектима? Да ли ће сви ИТ пројекти завршити као Агиле Пројецт Манагемент?
Да бисте разумели различите моделе, укључујући Агиле, и искористили онај који најбоље одговара вашој ситуацији, важно је да прво схватите о чему се ради у традиционалном систему управљања пројектима, названом Модел управљања воденим пројектима.
Модел управљања водопадом, тако назван због природе процеса рада, карактерише следеће:
- Крајњи се производ прво визуелно визуелно приказује.
- Затим се фазе процеса рада имплементирају редоследом:
- Захтеви и анализа
- Дизајн
- Имплементација
- Тестирање
- Инсталација
- Одржавање
- Пројектни план требао би бити беспријекоран, јер након што је фаза у низу завршена, програмери не могу поново да је прегледају без поновног покретања планирања.
- Мало је простора за промене или грешке и пројектни план мора се пажљиво следити.
Порекло модела управљања пројектима водопада:
У раним фазама ИТ индустрије није постојао конкретан модел за развој софтвера.
Дакле, индустрија је усвојила редован модел рада који се користи у производној и грађевинској индустрији. Ове су индустрије имале добро дефинисане фазе рада и развили су модел који је удовољио њиховим потребама за строгом контролом трошкова. Дакле, модел хардверске индустрије примењен је у индустрији софтвера.
Винстон В Роице је први модел представио 1970. године, али није користио термин "Управљање пројектима водопада". У ствари, модел је представио као грешку. Сликовни приказ модела изгледао је попут каскадног водопада. Тхомас Е. Белл и ТА Тхаиер касније су користили термин „водопад“ у свом раду из 1976. године, „Софтверски захтеви: Да ли су они заиста проблем?“ И термин је остао.
Постоји неколико варијанти овог модела. Уопште коришћене шест различитих фаза у моделу управљања водопадом пројектима објашњене су у наставку. Међутим, у зависности од пројекта, две фазе се могу спојити заједно.
Размотримо пример изградње школе као пример за боље разумевање модела управљања пројектима водопада.
-
Захтеви и фаза анализе:
Прво морамо тачно знати шта дизајнирамо. Због тога бисмо можда желели да:
- Водите детаљне дискусије са купцем
- Покушајте јасно представити производ са најситнијим детаљима
- Анализирајте које су хардверске и софтверске компоненте потребне
- Наведите детаље који укључују: проблем који производ треба да реши, ограничења корисника, ниво перформанси и компатибилност са већ постојећим системима.
- Извршите студије случаја сличног производа.
- Размотрите захтеве сваког заинтересованих страна
- Наведите спецификације у документу са захтевима производа, који формира улаз за следећи корак.
У нашем примјеру изградње школе, у овом кораку набрајамо број учионица, материјал који ће се користити за изградњу, људе који су потребни, већ постојећу инфраструктуру. Такође бисмо забележили шта захтева руководство школе (канцеларијска соба, просторија за особље) и шта ученици захтевају (бољи тоалети, игралишта)
-
Дизајн:
У фази дизајна, све што је визуелно приказано у првој фази, претворено је у нацрт.
У ИТ пројектима, ово се састоји од дефинисања:
- Хардвер који ће се користити
- Софтверска платформа која се користи, укључујући локалну или облачну употребу
- Софтверска архитектура, укључујући различите компоненте и модуле који ће се креирати
- Инпути потребни за успешно функционисање пројекта
- Резултати који се могу очекивати (у идеалном случају ово ће се синхронизовати са Захтевима који су детаљно описани у ранијој фази)
Постоје две врсте дизајна које се играју у софтверу:
- Логички дизајн
- Физички дизајн
Логички дизајн:
Ово укључује основне податке и процесе који ће бити укључени у пројекат. У њему су детаљно дизајнирани обрасци и извештаји, дизајн сучеља и дизајн базе података. На примјер, за веб страницу карата за влак, овај дизајн ће одредити како ће цијели процес функционирати: екран на којем путник уноси своје детаље и како ће се ти подаци преточити у базу података, као и која ће врста података похрањивати те детаље.
Физички дизајн:
То се тиче дизајна физичке базе података, програма и процеса и дистрибуираних система. То се ради након логичког дизајна и укључиваће „како“ пројект ће бити изведен: хардвер, платформа на којој ће се развијати, различите базе података, екрани и обрасци који ће се користити итд.
-
Имплементација:
- Овде се одвија стварни развој софтвера / система.
- Улаз за ову фазу су дизајнерске спецификације дате у претходној фази.
- Излаз је једна или више компоненти производа уграђене у спецификације, исправљене су грешке, тестиране и интегрисане да би задовољиле системску архитектуру.
- О овој фази обично води рачунарски тим који чине програмери, дизајнери интерфејса и други стручњаци, а алат који се користи су компајлери, исправљачи погрешака, тумачи и уредници медија.
- Ова фаза обично траје максимално време и важно је пажљиво пратити процесе и дизајн. Измене дизајна у овој фази су тешке у управљању пројектима водопада.
- За велики пројекат који укључује неколико тимова, препоручује се контрола верзије ради праћења промена у стаблу кода и враћања на претходне снимке ради руковања грешкама.
- У нашем примеру: Стварна конструкција зграде употребом рада и материјала врши се у овој фази.
-
Тестирање:
Тестирање се може извршити за производ у целини или за појединачне компоненте. „Тест случајеви“ се могу проверити да ли се производ може испоручити онако како је обећано. Може бити тестирање модула, системско тестирање интегрисаног производа и тестирање прихватања. Испитивање прихватања укључује тестирање производа на рупе од стране крајњег корисника или купца. Забиљежени су недостаци да их тим за имплементацију исправи. Једном када се изврше корекције, припрема се формална документација производа.
На пример, инфраструктуру школе тестира, вероватно ревизорски тим. У неким случајевима, наставници су позвани да уђу и користе просторије за пружање повратних информација.
-
Инсталација:
Након што је тестирање производа завршено у свим аспектима, производ се може пустити на тржиште или инсталирати у просторијама купца. У овој фази се такође предаје комплетна документација производа.
У случају наше школе, она је формално отворена (по могућности великим хицем!) И школа почиње са радом!
-
Одржавање:
У овој фази ИТ тим решава све проблеме који се могу појавити након што купац заиста почне да користи производ или када постоји унапређење производа. Добра документација је окосница одржавања. Проблеми се исправљају модифицирањем кодова који се називају „закрпе“.
Ако су потребне велике промене, пројекат се може вратити развојном тиму као нови пројекат.
У нашем примеру, школи је потребно редовно одржавање, углавном инфраструктурно, на пример, неисправно електрично ожичење или пропуштање купатила. Ови проблеми се морају повремено рјешавати.
Као што видите до сада, фазе у управљању пројектима за развој водопада су различите, и док је обично стална интеракција са клијентом, првенствено је разговарати о напретку пројекта, а не о дизајну или захтевима. Међутим, модел управљања водопадним пројектима адекватно је служио ИТ индустрији током дугих година, а за већину пројеката, фазе су и даље добре, иако не тако круте.
Постоји, међутим, неколико пројеката за које је модел управљања водопадом веома погодан.
Какав је пројекат погодан за управљање водопадом?
Дефиниција производа:
Прво, крајњи резултат (производ) мора бити способан да буде добро дефинисан на самом почетку. Пројекти у којима власник производа није баш сигуран у тачне спецификације жељеног производа могу добро следити праксе Агиле Манагемент.
Документација:
Пројекат би требао бити документ који се може документовати. Документација је важан захтјев модела управљања водопадом. Захтеви производа, дизајн и изворни код морају бити јасно документовани у свим фазама. Ако оригинални чланови тима одустану, то представља водич за континуитет пројеката.
Време и ресурси:
Не смије бити тренутна хитност да се производ пусти. Временски рокови су постављени на почетку пројекта и тим се мора моћи придржавати. Такође, мора бити на располагању довољно ресурса у погледу радне снаге и технологије.
Ризик и несигурност:
Алати за управљање пројектима водопада не раде добро у окружењу ризика и несигурности. На пример, апликација за мобилне уређаје је врста производа који се суочава са сталном несигурношћу у погледу прихватања купаца и конкуренције сличних апликација.
Јасно дефинисане фазе:
Фазе система треба да буду добро дефинисане јер се морају довршити редоследом и не може се преклапати.
Када се креира нова верзија постојећег софтвера.
Изван ИТ домене, модел управљања водопадом успешно се користи у огромним пројектима као што су
- Зграда авиона
- Инфраструктурни пројекти као што су мостови
- Израда одбрамбене опреме
- Здравствени системи у болницама
У ИТ пројектима, Ватерфалл Пројецт Манагемент је посебно прикладан за оне пројекте у којима је потребан вањски хардвер. Спецификације овога не могу се променити на средини јер би то резултирало губитком милиона долара.
Када су неисправности у управљању пројектима водопада постале очигледне у софтверској индустрији, било је доста размишљања о томе како ИТ тимови могу да пруже максималну вредност клијентима, истовремено обезбеђујући флексибилност у процесу рада.
Тако је рођен Агиле Систем Манагемент Систем који сада усваја већина софтверских компанија.
Управљање пројектом водопада вс Агиле Системс:
Систем Агиле Пројецт Манагемент је флексибилан модел који је постао популаран деведесетих година. То укључује разбијање пројекта на „мини пројекте“ зване спринт и независно рад на сваком од њих. Ова врста модела омогућава програмерима да брже уграде потребне промене и веома је ефикасна тамо где је окружење корисника променљиво.
Позитивни кораци управљања воденим пројектима су:
- Пошто је крајњи производ познат у целости, планирање и дизајн су недвосмислени.
- Потенцијална питања која би се могла појавити у пројекту могу се глачати током саме фазе дизајнирања; пре него што је било који код написан.
- Мерити напредак рада је лако, јер су фазе добро дефинисане.
- Стабилност тима је ту јер тим остаје до краја пројекта. У случају Агиле-а, тим се стално мења и то захтева одређено прилагођавање.
- Документација је обимна, што екипама олакшава управљање уколико члан оде.
- Програмери сматрају да је овај модел лакши за рад с њим, јер је лако разумети,
- Након фазе Захтеви, активно учешће крајњег купца потребно је само у фази тестирања. То је зато што су сви захтеви размотрени наконац, не остављајући никакве двосмислености.
- Производ се може развити у целини, уместо да га развијате у деловима.
- Питања управљања уговорима и клијентима боље се решавају у моделу управљања водопадом.
Позитивни поступци Агиле Пројецт Манагемент-а су:
- Купац може комуницирати с пројектним тимом током читавог циклуса и може повремено мијењати производ како би одговарао промјењивом окружењу.
- Ако се производ мора ускоро објавити због тржишних околности, тим Агиле Пројецт Манагемент може издати основну верзију која може имати напредне верзије касније.
- Систем је прилично транспарентан са становишта купца и он има коректну представу у којој се фази налази његов производ.
- Будући да клијент даје предност функција, тим зна да се мора фокусирати на функције које нуде највише пословне вредности.
- Процес има свој замах.
- Тимови су флуидни и флексибилни, што омогућава идеју сваком члану
- Документација је минимална и тако се време ослобађа од тих задатака.
Након много година постојања оба модела, види се да:
Модел управљања водопадом пројектима је ефикасан за управљање пројектима, кад једном се пројекат заврши, постоје минималне промене.
Агилно управљање пројектима више одговара менаџменту производа где је важно бити флексибилан према променама.
Без обзира на то, систем управљања водопадима и даље остаје важан саставни део већине ИТ пројеката. Не можемо са сигурношћу рећи да одређени пројекат стриктно следи Агиле Працтицес Манагемент. Обично су Агиле принципи „уграђени“ у ИТ пројекте.
Неки Агиле Пројецт Манагемент имају руководиоце пројеката док строго Агиле модел имају само Сцрум Мастерс. Ово су хибридне комбинације модела Агиле и Водопад за управљање пројектима које неки називају „Агифалл“ или „Агенци Агиле“ пројекти.
Популарност система за управљање пројектима водопада настаје и из чињенице да се проблеми управљања уговорима и клијентима боље решавају методама Ватерфалл Пројецт Манагемент.
Иако све више и више пројеката долази под окретни део Агиле Пројецт Манагемент-а и све више компанија види предности флексибилног модела управљања, популарност модела за управљање пројектима водопада без сумње опада.
Међутим, тешко је замислити будућност ИТ пројеката који ће у потпуности бити окретни, у блиској будућности. И Ватерфалл Пројецт Манагемент, који је помогао софтверској индустрији у раном добу, живеће у неколико компоненти управљања пројектима бар још неколико година које долазе.
Први извор слике: пицјумбо.цом
повезани чланци
- 6 Корисне фазе тијека рада у управљању пројектима водопада
- Савјети за групну дискусију (стручни савјети)
- Разбијених 10 митова о управљању пројектима
- 6 ефективних разлога свима је потребан пројекат страсти на послу
- Топ 5 врста алата за извештавање о управљању пројектима
- Менаџмент производа вс менаџмент бренда - корисне разлике