Водопад Управление на проекти - Днес повечето ИТ екипи гледат да приемат Agile системи за управление на проекти. Но това, което в крайна сметка правят, е да приемат Agile Project Management системи за своите проекти. Това означава комбинация от традиционни системи за управление на проекти (наречени системи за управление на проекти за водопад), комбинирани с принципите на Agile Management, както е описано в оригиналния манифест на Agile.
Тъй като повече проекти по целия свят включват практики на Agile Project Management, означава ли това край на управлението на проекти за водопад? Ще завършат ли всички ИТ проекти като Agile Project Management?
За да разберете различните модели, включително Agile, и да използвате най-подходящия за вашата ситуация, важно е първо да разберете какво представлява традиционната система за управление на проекти, наречена Waterfall Project Management Model.
Моделът за управление на проекти за водопад, наречен така поради естеството на процеса на работния процес, се характеризира със следното:
- Крайният продукт първо се визуализира с големи детайли.
- Тогава етапите на работния процес се реализират последователно:
- Изисквания и анализ
- Дизайн
- изпълнение
- Тестване
- Инсталация
- Поддръжка
- Планът на проекта трябва да е надежден, тъй като след като завърши етап в последователността, разработчиците не могат да го прегледат отново, без да започнат планирането отново.
- Има малко възможности за промени или грешки и планът на проекта трябва да бъде внимателно спазван.
Произход на модела за управление на проекти за водопад:
В ранните етапи на ИТ индустрията нямаше конкретен модел за разработка на софтуер.
И така, индустрията прие последователния модел на работния процес, използван в производствената и строителната индустрия. Тези индустрии имаха добре дефинирани етапи на работа и те разработиха модел, който задоволяваше нуждата им от строг контрол на разходите. Така моделът на хардуерната индустрия беше приложен към софтуерната индустрия.
Winston W Royce за първи път представи този модел през 1970 г., но той не използва термина „Управление на проекти за водопад“. Всъщност той представи модела като недостатък. Изобразителното изображение на модела изглеждаше като каскаден водопад. По-късно Томас Е. Бел и Т. А. Тейър използват термина „водопад“ в документа си от 1976 г. „Изисквания към софтуера: наистина ли са проблем?“ И терминът остава.
Има редица варианти на този модел. Често използваните шест различни фази в Модела за управление на проекти за водопад са обяснени по-долу. Въпреки това, в зависимост от проекта, два етапа могат да бъдат комбинирани заедно.
Нека разгледаме примера за изграждането на училище като пример за по-добро разбиране на модела за управление на проекти за водопад.
-
Изисквания и фаза на анализ:
Първо, трябва да знаем какво точно проектираме. За това може да искаме:
- Провеждайте подробни дискусии с клиента
- Опитайте се ясно да визуализирате продукта с най-малките му подробности
- Анализирайте кои хардуерни и софтуерни компоненти са необходими
- Избройте подробностите, които включват: проблемът, който продуктът трябва да реши, ограниченията на клиента, нивото на производителност и съвместимостта с вече съществуващи системи.
- Провеждане на казуси на подобен продукт.
- Обмислете изискванията на всеки от заинтересованите страни
- Избройте спецификациите в Документа за изискванията към продукта, който формира входа за следващата стъпка.
В нашия пример за изграждане на училище, в тази стъпка изброяваме броя класни стаи, материалът, който ще се използва за изграждане, необходимите хора, вече съществуващата инфраструктура. Също така бихме отбелязали какво изисква ръководството на училището (офис стая, стая за служители) и какво изискват учениците (по-добри тоалетни, детски площадки)
-
Дизайн:
В етапа на проектиране всичко, което е визуализирано на първия етап, е направено в план.
При ИТ проектите това се състои в дефиниране на:
- Хардуерът, който ще се използва
- Софтуерната платформа, която ще се използва, включително локално или облачно разполагане
- Софтуерната архитектура, включително различните компоненти и модули, които трябва да бъдат създадени
- Входни данни, необходими за успешното функциониране на проекта
- Резултати, които могат да се очакват (в идеалния случай това ще се синхронизира с изискванията, подробно описани на по-ранния етап)
Има два вида дизайн, които влизат в игра в софтуерен проект:
- Логически дизайн
- Физически дизайн
Логически дизайн:
Това включва основните данни и процеси, които ще бъдат включени в проекта. Той подробно описва дизайна на формуляри и отчети, дизайна на интерфейса и дизайна на базата данни. Например, за уебсайт за билети за влак, този дизайн ще определи как ще работи целият процес: екрана, на който пътникът въвежда своите данни и как тези данни ще влязат в базата данни, както и какъв тип база данни ще съхранява тези данни.
Физически дизайн:
Това е свързано с дизайна на физическата база данни, програмите и процесите и разпределените системи. Това се прави след логическия дизайн и ще включва „как“ ще бъде направен проектът: хардуерът, платформата, на която ще бъде разработен, различните бази данни, екрани и форми, които ще бъдат използвани и т.н.
-
Изпълнение:
- Тук се извършва действителното развитие на софтуера / системата.
- Входът за този етап са проектните спецификации, предоставени от предишния етап.
- Изходът е един или повече от компонентите на продукта, изградени по спецификации, отстранени с грешки, тествани и интегрирани, за да задоволят системната архитектура.
- Този етап обикновено се грижи от екипа за разработка, който се състои от програмисти, дизайнери на интерфейси и други специалисти, а използваните инструменти са компилатори, отладчици, интерпретатори и медийни редактори.
- Този етап обикновено отнема максимално време и е важно старателно да следите процесите и дизайна. Промените в дизайна на този етап са трудни в управлението на проекти за водопад.
- За голям проект, включващ няколко екипа, се препоръчва контрол на версиите за проследяване на промените в кодовото дърво и връщане към предишни снимки за обработка на грешки.
- В нашия пример: Реалното изграждане на сградата с използване на труд и материали се извършва на този етап.
-
Тестване:
Тестване може да се направи за продукта като цяло или за отделни компоненти. „Тестови случаи“ може да се провери, за да се види дали продуктът може да бъде доставен както е обещано. Може да има тестване на модули, системно тестване на интегрирания продукт и тестове за приемане. Тестът за приемане включва тестване на продукта за вратички от крайния потребител или клиент. Дефектите се отбелязват, за да се отстрани екипът по внедряването. След като са направени корекциите, се подготвя официална документация за продукта.
В примера инфраструктурата на училището се тества, вероятно от одитен екип. В някои случаи учителите са поканени да влязат и да използват помещенията, за да предоставят обратна връзка.
-
Инсталация:
След като тестването на продукта приключи във всички аспекти, продуктът може да бъде пуснат на пазара или инсталиран в помещенията на клиента. На този етап се предава и пълната документация за продукта.
В случая с нашето училище то е официално открито (за предпочитане от голям изстрел!) И училището започва операции!
-
Поддръжка:
На този етап ИТ екипът коригира всички проблеми, които могат да възникнат, след като клиентът действително започне да използва продукта или когато има подобрение на продукта. Добрата документация е основата на поддръжката. Проблемите се отстраняват чрез промяна на кодове, наречени „кръпки“.
Ако са необходими големи промени, проектът може да се върне към екипа за разработка като нов проект.
В нашия пример училището се нуждае от редовна поддръжка, предимно инфраструктурна, например неизправна електрическа инсталация или течащи бани. Тези проблеми трябва да се решават от време на време.
Както можете да видите досега, етапите в управлението на проекти за водопади са различни, и макар че обикновено има постоянно взаимодействие с клиента, преди всичко е да се обсъди напредъкът на проекта, а не дизайнът или изискванията. Въпреки това моделът за управление на проекти за водопад е служил адекватно на ИТ индустрията в продължение на много много години, а за повечето проекти етапите все още са добри, макар и не толкова строги.
Има обаче няколко проекта, за които Моделът за управление на проекти за водопад е изключително подходящ.
Какъв проект е подходящ за управление на проекти за водопад?
Дефиниция на продукта:
Първо, крайният резултат (продукт) трябва да може да бъде добре определен в самото начало. Проектите, в които собственикът на продукта не е много сигурен в точните спецификации на желания продукт, може да са полезни, за да следват практиките на Agile Management.
документация:
Проектът трябва да бъде такъв, който може да бъде документиран. Документацията е важно изискване на Модела за управление на проекти за водопад. Изискванията към продукта, дизайнът и изходният код трябва да бъдат ясно документирани на всички етапи. Ако първоначалните членове на екипа се откажат, това представлява ръководството за непрекъснатост на проекта.
Време и ресурси:
Не трябва да има незабавна спешност за освобождаване на продукта. Сроковете са определени в началото на проекта и екипът трябва да може да се придържа към тях. Също така, трябва да има достатъчно налични ресурси по отношение на работната сила и технологиите.
Риск и несигурност:
Инструментите за управление на проекти за водопад не работят добре в среда на риск и несигурност. Например Мобилното приложение е вид продукт, който е изправен пред постоянна несигурност по отношение на приемането на клиенти и конкуренцията на подобни приложения.
Ясно дефинирани етапи:
Етапите на системата трябва да бъдат добре дефинирани, тъй като те трябва да бъдат завършени последователно и не може да има припокриване.
Когато се създава нова версия на съществуващия софтуер.
Извън ИТ домейна, Моделът за управление на проекти за водопад успешно се използва в огромни проекти като
- Самолетна сграда
- Инфраструктурни проекти като мостове
- Производство на отбранителна техника
- Системи за здравеопазване в болници
В ИТ проектите Waterfall Project Management е особено подходящ за онези проекти, в които се изисква външен хардуер. Спецификациите на това не могат да бъдат променени по средата, тъй като това би довело до загуба на милиони долари.
Когато недостатъците в управлението на проекти за водопад станаха очевидни в софтуерната индустрия, имаше много мисли за това как ИТ екипите могат да предоставят максимална стойност на клиентите, като същевременно осигуряват гъвкавост в процеса на работния процес.
И така се роди Agile Project Management System, която сега се възприема от повечето софтуерни компании.
Водопад Управление на проекти срещу Agile Systems:
Системата Agile Project Management е гъвкав модел, който стана популярен през 90-те години. Тя включва разбиване на проекта в „мини проекти“, наречени спринти и работа независимо от всеки от тях. Този вид модел дава възможност на разработчиците да включат необходимите промени по-бързо и е много ефективен там, където клиентската среда е променлива.
Положителните стъпки на стъпките за управление на проекта за водопад са:
- Тъй като крайният продукт е известен в своята цялост, планирането и дизайна са недвусмислени.
- Потенциалните проблеми, които могат да възникнат в проекта, могат да бъдат изгладени по време на самата фаза на проектиране; преди да бъде написан някакъв код.
- Измерването на напредъка на работата е лесно, тъй като етапите са добре дефинирани.
- Стабилността на екипа е налице, тъй като екипът остава до края на проекта. В случая с Agile, екипът се променя постоянно и това изисква известна доза корекция.
- Документацията е обширна, което улеснява управлението на екипите, ако членът напусне.
- Разработчиците намират този модел за по-лесен за работа, тъй като е лесен за разбиране,
- След фазата на изискванията активното участие на крайния клиент е необходимо само във фазата на тестване. Това е така, защото всички изисквания са обсъдени с нишки, не оставяйки неяснота.
- Продуктът може да бъде разработен като цяло, вместо да го развива на части.
- Въпросите за управление на договорите и клиентите се решават по-добре в Модела за управление на проекти за водопад.
Положителните резултати на Agile Project Management са:
- Клиентът може да взаимодейства с екипа на проекта през целия цикъл и може да прави промени в продукта от време на време, за да отговаря на променящата се среда.
- Ако продуктът трябва да бъде пуснат много скоро поради пазарни обстоятелства, екипът на Agile Project Management може да пусне основна версия, която може да има разширени версии по-късно.
- Системата е доста прозрачна от гледна точка на клиента и той има справедлива представа за етапа, в който е неговият продукт.
- Тъй като клиентът предоставя приоритет на функциите, екипът знае, че трябва да се съсредоточи върху функциите, предлагащи най-голяма бизнес стойност.
- Процесът има своя инерция.
- Екипите са плавни и гъвкави, позволяващи идеи от всеки член
- Документацията е минимална и затова времето се освобождава от тези задачи.
След много години и на двата модела, съществуващи един до друг, е очевидно, че:
Моделът за управление на проекти за водопад е ефективен за управление на проекти, където след като проектът бъде изпълнен, има минимални промени.
Agile Project Management е по-подходящ за управление на продукти, където е важно да бъдете гъвкави към промените.
Независимо от това, системата за управление на проекти за водопад остава важен компонент на повечето ИТ проекти. Не може да се каже със сигурност, че определен проект стриктно следва практиките на Agile Management. Обикновено принципите на Agile са „включени“ в ИТ проектите.
Някои Agile Project Management имат ръководители на проекти, докато строго Agile модел имат само Scrum Masters. Това е хибридни комбинации от модели за управление на проекти Agile и Waterfall, които някои наричат проекти „Agifall“ или „Agency Agile“.
Популярността на системата за управление на проекти за водопад също се дължи на факта, че въпросите за управление на договорите и клиентите се решават по-добре чрез методите за управление на проекти на Waterfall.
Докато все повече и повече проекти попадат под гъвкавостта на Agile Project Management и все повече компании виждат предимствата на гъвкавия модел на управление, популярността на Модела за управление на проекти за водопад без съмнение намалява.
Трудно е обаче да се предвиди бъдеще за ИТ проекти, които са напълно гъвкави в близко бъдеще. И Waterfall Project Management, който помогна на софтуерната индустрия през ранна детска възраст, ще продължи в няколко компонента на управление на проекти поне за още няколко години.
Първи източник на изображения: picjumbo.com
Свързани статии
- 6 полезни етапа на работния процес в управлението на проекти за водопад
- Ефективни съвети за групова дискусия (експертни съвети)
- Топ 10 мита за управление на проекти
- 6 ефективни причини всеки има нужда от страстен проект
- Топ 5 вида инструмент за отчитане на управлението на проекти
- Управление на продукти срещу управление на марката -Полезни разлики