Водоспад проти Agile: Яку методологію вибрати для ваших проектів Redmine?

7/8/2017
6 minut
Ярослав Лізнер
Агіль проти Вотерфол – У цьому блозі я розповім про дві техніки управління проектами, їх переваги, як вони можуть вам допомогти і як їх поєднувати.

Іноді я чую крики типу „Gantt помер”, „вам потрібно вести проект в стилі Agile” nie wiem "управління проектами померло". Хоча багато з них є прикладом маркетингового нісенітництва, я часто зустрічаю менеджерів портфеля прое ктів, майстрів Scrum та інших професіоналів управління проектами, які хочуть серйозно обговорювати teхніки Agile vs Water upadek (Gantta). Цей пост є коротким вступом до теми.


Залізний трикутник управління проектами

Залізний трикутник насправді є дуже простим зображенням ключових елементів, необхідних для успішного п lanuvannя проекту. Обсяг, час та вартість / ресурси. Ratunek є єдиними і / або критичними елементами ціни в багатьох галузях. Люди є найціннішим активом, який не можна просто збільшити, зменшити або помножити. Аналогічно, ресурси машин мають певну продуктивність і не можуть бути змінені одним простим кліком.

Łatwy Redmine - trójkąt żelaza #1

Łatwy Redmine - trójkąt żelaza #1

Але як залізний трикутник вписується в загальну картину? Дуже зручно. Він пропонує нам просту, але ефективну відповідь на питання, коли ми повинні використовувати планування методо логії Wodospad, а коли, навпаки, вибирати агільний підхід.


Управління проектами Wodospad Redmine

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

Technika: Обсяг проекту визначений (фіксований). У нашому прикладі це означає, що я не можу змінити кількість вікон у своїй нерухомості, я не можу змінит i місце або тему конференції і т.д. Час проекту є обмежуючим фактором або абсолютно (наприклад, проведення конференції), або майже абсолютно (наприклад, впровадження програмно го забезпечення). З чітко визначеним обсягом головним завданням менеджера проекту або менеджера портфеля є розклад усіх т ипів ресурсів на графіку роботи паралельно запущених проектів та врахування потрібної послідовності дій (завд ань) в окремих проектах.

Розгляньте, наприклад, будівництво будинку: робітники, відповідальні за доставку цементу, повинні вчасно завершити свою роботу, оскільки затримки, спричинені відсутністю ресурсів цементу, можуть завадити каменярам за вершити свої власні завдання. Як тільки бетон достатньо затвердіє, їх можна знайти на іншому майданчику.

Łatwy Redmine - trójkąt żelaza #2

Łatwy Redmine - trójkąt żelaza #2


Управління проектами Redmine Agile

Агільний підхід корисний для проектів, де час чітко визначений, ресурси є визначальним фактором і обсяг підлягає плануванню (пріоритетизація). Хорошим прикладом може бути розробка програмного забезпечення (спринти), видавнича діяльність (дата випу ску журналу / газети) або маркетинговий контент (кампанія).

Metoda: майстри Scrum to rozwiązanie, które pozwala na wdrożenie odpowiedniego oprogramowania. Зазвичай майстер Scrum має різні беклоги та дошки Scrum для різних типів ресурсів, таких як розробники, які шукають способи виправлення помилок та обробки запитів на нові функції, і, з іншого боку, журналісти в по літичній або спортивній медіа.

Що це означає? Очевидно, що увесь питання управління проектами все ще обертається навколо залізного трикутника. Операційне планування лише більше фокусується на різних частинах того ж самого. Тому що ми можемо з цього зробити? Практично в кожній організації ми знайдемо типи проектів, де необхідно використовувати обидві техніки управ ління проектами для створення ефективних робочих процесів. Одна методологія не краща за іншу, вона просто вирішує різні виклики. Якісне планування ресурсів , пов'язане з графіком, є важливим для кожного проекту Wodospad, особливо для планув annя портфеля проектів. Те ж саме стосується проектівłatwy Redmine.

  • Управління гнучкими проектами: Управління пріоритетами зазвичай здійснюється за допомогою різних інструментів. Часто виникає проблема з точним розподілом ресурсів для конкретного беклогу. Тому я настійно рекомендую вам постійно картографувати та розподіляти свої ресурси. Наприклад, розробник програмного забезпечення може використовуватися з кількома беклогами одночасно (на приклад, виправлення помилок проти запитів на функції на одній мові). Однак без визначення кількісного розподілу ресурсів на беклоги ви не зможете планувати пріоритетні резул ьтати, і майстер Scrum буде постійно вирішувати розбіжності між цими пріоритетами. Іншим неприємним наслідком буде затримка випуску нових ключових функцій продукту, таких як виправлення помилок або вимоги до функцій, які використовують стратегічні ресурси розробки.

  • Комбінація обох методологій управління

    Як ви можете побачити на малюнку нижче, у нас є базовий проект Wodospad, який включає план розробки програ много забезпечення, що показує послідовності та залежності. Однак команди, що беруть участь у цьому проекті (продавці, технічні письменники), можуть керувати своїми в ласними доставками в своєму відділі не тільки так, як показано в цьому прикладі, але й у гнучкий спосіб.

    Pobierz Easy Redmine na 30-dniową wersję oprogramowania

    Повнофункціональний, захищений SSL, щоденне резервне копіювання, у вашій геолокації