Waterfall срещу Agile: Коя методология да изберете за вашите проекти в Redmine?

Понякога чувам викове като „Гант е мъртъв“, „трябва да го карате по пъргавия начин“, или дори "управлението на проекти е мъртво." Въпреки че много от тях са само пример за маркетингови боклуци, често срещам мениджъри на портфолио на проекти, скрам майстори и други професионалисти по управление на проекти, които искат сериозно да спорят за Agile срещу Waterfall (Гант) техники. Тази публикация е кратко въведение в темата.

Желязният триъгълник на управлението на проекта

Желязният триъгълник всъщност е много просто представяне на ключовите елементи, необходими за успешното планиране на проекта. Обхват, време и разходи/ресурси. Ресурси са единствените и/или критични елементи на цената в много индустрии. Хората са най-ценният актив, който не може просто да бъде увеличен, намален или умножен. По същия начин машинните ресурси имат определен производствен капацитет и не могат да бъдат променени с просто щракване.

Easy Redmine - Желязният триъгълник #1

Но как железният триъгълник се вписва в цялостната картина? Много удобно. Той ни предлага прост, но ефективен отговор кога трябва да използваме планирането на методологията на Waterwall и, напротив, кога да изберем пъргав подход.

Управление на проекта Redmine Waterfall

Методологията на водопада е най-подходяща за проект, чийто обхват е точно дефиниран и е ключов елемент от проекта, като строителство на недвижими имоти, планиране на конференции или Лесно внедряване на софтуер Redmine.

Техника: Обхватът на проекта е определен (фиксиран). В нашия пример това означава, че не мога да променя броя на прозорците в моя имот, не мога да променя мястото или предмета на конференцията и т.н. Времето на проекта е ограничителен фактор или абсолютно (напр. конферентна връзка) или почти абсолютно (напр. софтуерна реализация). При строго дефиниран обхват, основната задача на мениджъра на проекти или портфолио мениджъра е да планира всички видове ресурси на времевата линия в паралелно изпълнявани проекти и да вземе предвид необходимата последователност от действия (задачи) в отделните проекти.

Помислете, например, за изграждането на къща: работниците, отговорни за доставката на цимент, трябва да завършат работата си своевременно, защото закъсненията, причинени от липсата на циментни ресурси, могат да попречат на зидарите да изпълнят своите задачи. След като бетонът е достатъчно здрав, те вече могат да бъдат намерени на друг сайт.

Easy Redmine - Желязният триъгълник #2

Redmine Agile управление на проекти

Подходящият подход е полезен за проекти, където Времето е точно определено, Ресурсите са определящ фактор и Обхватът е обект на планиране (приоритизиране). Добър пример може да бъде разработката на софтуер (спринтове), дейност по публикуване (дата на издаване на списание/вестник) или маркетингово съдържание (кампания).

Техника: майстори на скраб или плановици в подобни роли задават задачи за следващия спринт. Обикновено майсторът на скраб има различни скриптове и дъски за скраб за различни видове ресурси, като разработчици, които искат да отстраняват бъгове и да се справят с искания за нови функции, а от друга страна, журналисти в политически или спортни медии.

Easy Redmine - Желязният триъгълник #3

Какво означава?

Очевидно целият въпрос за управлението на проекти все още се върти около железния триъгълник. Оперативното планиране се фокусира повече върху различни части от едно и също нещо. И така, какво можем да извлечем от него?

1. На практика във всяка организация бихме могли да намерим видове проекти, където е необходимо използвайте и двете техники за управление на проекти За създаване на ефективни работни процеси. Една от методологиите не е по-добра от другата, тя просто адресира различни предизвикателства.
   
   
2. Качествен график на ресурсите свързана с времевата линия е от съществено значение за всеки проект на Waterfall, особено за планиране на портфолио от проекти. Същото важи и за Лесно Redmine проекти.
   
   
3. Управление на гъвкави проекти: Управлението на приоритетите обикновено се извършва чрез различни инструменти. Често има проблем с точното разпределение на ресурсите за специфично изоставане. Така че в това отношение силно ви препоръчвам Карта и да разпределяте ресурсите си последователно. Например, разработчик на софтуер може да се използва с множество изоставания едновременно (напр. корекции на грешки спрямо заявки за функции на един и същ език). Без да дефинирате количествено разпределение на ресурсите за изоставания, обаче, няма да можете да планирате приоритетни резултати и Scrum Master ще трябва непрекъснато да разрешава несъответствията между тези приоритети. Друга неприятна последица ще бъде забавеното пускане на нови ключови функции на продукта като корекции на грешки или изисквания за функции, които експлоатират ресурси за стратегическо развитие.

Комбинация от двете методологии за управление

Както можете да видите на снимката по-долу, имаме основен проект на Waterfall, който включва план за разработка на софтуер, който показва последователности и зависимости. Въпреки това екипите, участващи в този проект (продавачи, технически писатели), могат да управляват собствените си доставки в своя отдел не само, както е показано в този пример, но и по гъвкав начин.

Пример за лесен проект Redmine Gantt - Waterfall