Управління проектами водоспадів - сьогодні більшість ІТ-команд прагнуть прийняти Agile системи управління проектами. Але те, що вони в кінцевому підсумку роблять, - це прийняття Agile систем управління проектами до своїх проектів. Це означає поєднання традиційних систем управління проектами (звані системами управління проектами водоспадів) у поєднанні з Принципами спритного управління, як детально описано в оригінальному маніфесті Agile.
Оскільки все більше проектів у всьому світі включає практику Agile Project Management, чи означає це кінець управління проектами водоспадів? Чи всі проекти ІТ в кінцевому підсумку стануть Agile Management Project?
Щоб зрозуміти різні моделі, включаючи Agile, та використати ту, яка найкраще підходить для вашої ситуації, важливо спершу зрозуміти, про що йдеться у традиційній системі управління проектами під назвою модель управління проектами водоспаду.
Модель управління проектами водоспадів, названа так через характер процесу роботи, характеризується наступним:
- Кінцевий продукт спочатку візуалізується дуже детально.
- Потім етапи робочого процесу реалізуються послідовно:
- Вимоги та аналіз
- Дизайн
- Впровадження
- Тестування
- Установка
- Технічне обслуговування
- План проекту повинен бути надійним, оскільки після завершення етапу в послідовності розробники не можуть переглянути його, не починаючи планування заново.
- Існує мало можливостей для змін або помилок, і план проекту необхідно ретельно виконувати.
Походження моделі управління проектами водоспадів:
На ранніх етапах ІТ-галузі не існувало конкретної моделі розробки програмного забезпечення.
Так, галузь прийняла послідовну модель робочого процесу, що використовується у виробничій та будівельній галузях. Ці галузі мали чітко визначені етапи роботи, і вони розробили модель, яка задовольняла їх потребу в жорсткому контролі витрат. Так модель апаратної галузі була застосована до галузі програмного забезпечення.
Вінстон Ройс вперше представив цю модель в 1970 році, але він не використовував термін «Управління проектами водоспаду». Насправді він представив модель як недосконалу. Мальовниче зображення моделі виглядало як каскадний водоспад. Пізніше Томас Е. Белл і Т. А. Тейєр використовували термін «водоспад» у своїй статті 1976 р. «Вимоги до програмного забезпечення: чи справді це проблема?», І термін залишився.
Існує ряд варіантів цієї моделі. Нижче пояснюються загальновживані шість різних фаз у моделі управління проектами водоспаду. Однак, залежно від проекту, два етапи можуть бути об'єднані разом.
Розглянемо приклад побудови школи як приклад для кращого розуміння моделі управління проектами водоспаду.
-
Вимоги та етап аналізу:
По-перше, ми повинні точно знати, що ми проектуємо. Для цього ми можемо:
- Провести детальну дискусію із замовником
- Постарайтеся чітко візуалізувати виріб з його найменшими деталями
- Проаналізуйте, які апаратні та програмні компоненти потрібні
- Перелічіть деталі, які включають: проблему, яку вирішує виріб, обмеження замовника, рівень продуктивності та сумісність з уже існуючими системами.
- Провести тематичні дослідження подібного продукту.
- Розглянемо вимоги кожного із зацікавлених сторін
- Перерахуйте специфікації в Документі про вимоги до продукту, який формує вхід для наступного кроку.
У нашому прикладі будівництва школи на цьому кроці ми перераховуємо кількість аудиторій, матеріал, який потрібно використовувати для будівництва, необхідні люди, вже існуючу інфраструктуру. Також ми зазначимо, що вимагає керівництво школи (кабінет, кабінет для персоналу) та що потребують учні (кращі туалети, дитячі майданчики)
-
Дизайн:
На етапі проектування все, що було візуалізовано на першому етапі, перетворюється на план.
У ІТ-проектах це полягає у визначенні:
- Обладнання, яке буде використовуватися
- Програмне забезпечення, яке буде використовуватися, включаючи локальне або хмарне розгортання
- Архітектура програмного забезпечення, включаючи різні компоненти та модулі, які слід створити
- Вхідні дані, необхідні для успішної роботи проекту
- Результати, які можна очікувати (в ідеалі це синхронізується з вимогами, детально описаними на попередньому етапі)
Існує два типи дизайну, які грають у програмному проекті:
- Логічний дизайн
- Фізичний дизайн
Логічний дизайн:
Сюди входять основні дані та процеси, які будуть включені в проект. У ньому детально описано дизайн форм та звітів, дизайн інтерфейсу та дизайн бази даних. Наприклад, на веб-сайті квитків на поїзд ця конструкція визначатиме, як буде працювати весь процес: екран, на якому мандрівник вводить свої дані, і як ці дані будуть надходити в базу даних, а також який тип бази даних буде зберігати ці дані.
Фізичний дизайн:
Це стосується розробки фізичної бази даних, програм і процесів та розподілених систем. Це робиться після логічного дизайну і буде включати "як" проект буде виконано: обладнання, платформа, на якій він буде розроблятися, різні бази даних, екрани та форми, які будуть використовуватися тощо.
-
Впровадження:
- Тут відбувається власне розвиток програмного забезпечення / системи.
- Вхід для цього етапу - це технічні характеристики, передбачені попереднім етапом.
- Вихід - це один або кілька компонентів продукту, побудованих за специфікаціями, налагоджені, протестовані та інтегровані для задоволення архітектури системи.
- За цим етапом зазвичай опікується команда розробників, яка складається з програмістів, дизайнерів інтерфейсів та інших фахівців, а використовувані інструменти - компілятори, налагоджувачі, інтерпретатори та редактори засобів масової інформації.
- Цей етап зазвичай займає максимум часу, і важливо старанно слідкувати за процесами та дизайном. Зміни в дизайні на цьому етапі важкі в управлінні проектами водоспаду.
- У великому проекті, що включає декілька команд, контроль версій рекомендується відстежувати зміни в кодовому дереві та повертатися до попередніх знімків для обробки помилок.
- У нашому прикладі: фактичне будівництво будинку з використанням праці та матеріалів робиться на цьому етапі.
-
Тестування:
Тестування може проводитися для виробу в цілому або для окремих компонентів. "Тестові кейси" можна перевірити, щоб перевірити, чи продукт може доставити, як обіцяли. Тут може бути тестування модулів, тестування системи інтегрованого продукту та приймальне тестування. Тестування прийнятності включає тестування продукту на прорізи кінцевим користувачем або замовником. Дефекти зазначаються, щоб команда впровадження виправляла. Після внесення поправок готується формальна документація на товар.
У прикладі інфраструктура школи тестується, ймовірно, аудиторською командою. У деяких випадках вчителів пропонують зайти і використовувати приміщення для надання зворотного зв'язку.
-
Установка:
Після того, як тестування товару буде завершено у всіх аспектах, продукт може бути випущений на ринок або встановлений у приміщеннях замовника. На цьому етапі також передається повна документація на товар.
Що стосується нашої школи, то вона офіційно відкрита (бажано великим пострілом!) І школа розпочинає свою діяльність!
-
Технічне обслуговування:
На цьому етапі ІТ-команда виправляє будь-які проблеми, які можуть виникнути, коли клієнт насправді починає користуватися продуктом або коли відбувається вдосконалення продукту. Хороша документація є основою обслуговування. Виправлення виправляються шляхом зміни кодів, які називаються "виправленнями".
Якщо потрібні значні зміни, проект може повернутися до команди розробників як новий проект.
У нашому прикладі школа потребує регулярного технічного обслуговування, в основному інфраструктурного, наприклад, несправної електричної проводки або протікання ванних кімнат. Ці проблеми потрібно час від часу вирішувати.
Як ви бачите, етапи управління проектами розвитку водоспаду відрізняються, і, як правило, існує постійна взаємодія з клієнтом, це насамперед обговорення ходу проекту, а не проектування або вимог. Однак модель управління проектами водоспадів належним чином служила ІТ-індустрії протягом багатьох років, і для більшості проектів етапи залишаються хорошими, хоча і не такі жорсткі.
Однак є декілька проектів, для яких Модель управління проектами водоспаду дуже підходить.
Який проект підходить для управління водоспадом?
Визначення продукту:
По-перше, кінцевий результат (продукт) повинен бути здатний бути чітко визначеним на самому початку. Проекти, в яких власник продукту не дуже впевнений у точних специфікаціях потрібного продукту, можуть цілком дотримуватися практики Agile Management.
Документація:
Проект повинен бути таким, який може бути задокументований. Документація є важливою вимогою моделі управління проектом водоспаду. Вимоги до продукту, дизайн та вихідний код повинні бути чітко зафіксовані на всіх етапах. Якщо вихідні члени команди відмовляються, це формує керівництво щодо безперервності проекту.
Час та ресурси:
Не повинно бути негайної терміновості для випуску товару. Терміни встановлюються на початку проекту, і команда повинна вміти їх дотримуватися. Крім того, повинно бути достатньо ресурсів, що стосуються робочої сили та технологій.
Ризик та невизначеність:
Інструменти управління проектами водоспадів не дуже добре працюють в умовах ризику та невизначеності. Наприклад, мобільний додаток - це тип продукту, який стикається з постійною невизначеністю щодо прийняття клієнтами та конкуренції подібних додатків.
Чітко визначені етапи:
Етапи системи повинні бути чітко визначені, оскільки вони повинні виконуватися послідовно, і не може бути перекриттів.
Коли створюється нова версія існуючого програмного забезпечення.
За межами ІТ-області, модель управління проектами водоспаду успішно використовується у величезних проектах, таких як
- Будівництво літака
- Інфраструктурні проекти, такі як мости
- Виробництво оборонного обладнання
- Системи охорони здоров'я в лікарнях
В ІТ-проектах управління водоспадом особливо підходить для тих проектів, для яких необхідне зовнішнє обладнання. Технічні характеристики цього не можуть бути змінені посередині, оскільки це призведе до втрати мільйонів доларів.
Коли недоліки в управлінні проектами водоспадів стали очевидними в галузі програмного забезпечення, багато роздумували над тим, як ІТ-команди можуть забезпечити максимальну цінність для клієнтів, забезпечуючи гнучкість у процесі робочого процесу.
Таким чином, народилася система Agile Project Management, яку зараз приймає більшість програмних компаній.
Управління проектами водоспадів проти Agile Systems:
Система Agile Project Management - це гнучка модель, яка стала популярною у 90-х роках. Він передбачає розбиття проекту на "міні-проекти", що називаються спринтами, і незалежна робота над кожним із них. Така модель дозволяє розробникам вносити необхідні зміни швидше, і це дуже ефективно, коли середовище клієнта є змінним.
Позитивними етапами управління проектами водоспаду є:
- Оскільки кінцевий продукт відомий у повному обсязі, планування та дизайн неоднозначні.
- Потенційні проблеми, які можуть виникнути у проекті, можна випрасувати на самій стадії проектування; перш ніж був написаний будь-який код.
- Виміряти хід роботи легко, оскільки етапи чітко визначені.
- Стабільність команди є, оскільки команда залишається до кінця проекту. У випадку Agile команда постійно змінюється, і це вимагає певної корекції.
- Документація обширна, що спрощує управління командами, якщо член виїжджає.
- Розробники вважають, що з цією моделлю легше працювати, оскільки її легко зрозуміти,
- Після етапу Вимог, активна участь кінцевого замовника потрібна лише у фазі тестування. Це тому, що всі вимоги були обговорені ниткими, не залишаючи двозначності.
- Товар можна розробити в цілому, а не розвивати його частинами.
- Питання управління контрактами та клієнтами краще вирішувати в рамках Моделі управління проектами Waterfall.
Позитивом Agile Project Management є:
- Замовник може взаємодіяти з командою проекту протягом усього циклу і час від часу може вносити зміни в товар, щоб відповідати мінливим умовам.
- Якщо продукт повинен бути випущений дуже скоро через ринкові обставини, команда Agile Project Management може випустити основну версію, яка може мати пізніші версії пізніше.
- Система є досить прозорою з точки зору замовника, і він має чітке уявлення про те, на якій стадії знаходиться його товар.
- Оскільки клієнт надає пріоритет функцій, команда знає, що йому слід зосередитись на особливостях, що надають найбільшу цінність для бізнесу.
- Процес має свій імпульс.
- Команди є плавними та гнучкими, що дозволяє ідею від кожного члена
- Документація мінімальна, тому час від цих завдань звільняється.
Після багатьох років обидві моделі, що існують поруч, очевидно, що:
Модель управління проектами «Водоспад» ефективна для управління проектами, коли після виконання проекту відбуваються мінімальні зміни.
Agile Project Management більше підходить для управління продуктами, коли важливо бути гнучкими до змін.
Незалежно від цього система управління проектами водоспаду залишається важливою складовою більшості ІТ-проектів. Не можна точно сказати, що конкретний проект суворо дотримується методів Agile Management. Зазвичай принципи Agile "включені" в ІТ-проекти.
Деякі Agile Project Management мають менеджерів проектів, тоді як строго Agile модель має лише Scrum Masters. Це гібридні комбінації моделей управління проектами Agile та Waterfall, які деякі називають проектами «Agifall» або «Agent Agile».
Популярність системи управління проектами Водоспад також пояснюється тим, що проблеми управління контрактами та клієнтами краще вирішуються методами управління проектами Waterfall.
Хоча все більше та більше проектів підпадає під складну складність управління проектами, і все більше компаній бачать переваги гнучкої моделі управління, популярність Моделі управління проектами «Водоспад» безсумнівно зменшується.
Однак важко передбачити майбутнє для ІТ-проектів, які є цілком спритними, найближчим часом. І управління проектами Waterfall, яке допомогло індустрії програмного забезпечення в дитинстві жити в кількох компонентах управління проектами принаймні ще кілька років.
Перше джерело зображення: picjumbo.com
Пов'язані статті
- 6 корисних етапів робочого процесу в управлінні проектами водоспаду
- Ефективні поради для групової дискусії (поради експертів)
- 10 міфів щодо управління проектами
- 6 Ефективні причини, з якими кожен потребує пристрасного проекту на роботі
- Топ-5 видів інструменту звітності управління проектами
- Управління продуктами проти управління брендами - Корисні відмінності