Існує безліч різних методологій, з допомогою яких можна реалізувати принципи та філософію Agile. Деякі з них включають метод канбан, програмування (XP), кристал і системи (DSDM).

Одна з найпопулярніших методологій Agile Scrum з простим інтерфейсом – інтуїтивно зрозумілий і цікавий спосіб зосередитися на проекті. Хоча управління Agile було створено спеціально для розробки ПЗ, будь, хто працює в швидко розвивається і динамічному середовищі, може отримати вигоду з гнучкою та ітеративної роботи.

Історія виникнення методології

В 2001 році 17 провідних авторів ЗА зібралися в Snowbird, штат Юта, серед них Джефф Сандерленд, який вважається ” хрещеним батьком Agile. Джефф і його друзі разом створили легендарний Manifesto для Agile Software Development, ставлячи перед собою завдання розлучитися з важкими обмеженнями традиційної розробки ПО. Хоча назва проекту Agile Scrum може здаватися страшним, користувачеві не потрібно бути розробником програмного забезпечення, щоб легко зрозуміти принципи його роботи і почати самостійно його використовувати.

Переклад слова agile означає: рухливий, жвавий, швидкий, верткий, моторний, і програма повністю відповідає цим значенням. Традиційні методології управління проектами, такі як Waterfall, PMI PMBOK і PRINCE2, є жорсткими і контрольованими. Вони описують різні етапи планування проекту від початку до кінця і припускають, що у користувачів заздалегідь є всі вимоги та необхідна інформація. Agile Scrum відкидає всі традиційні методології управління проектами як громіздкі, обмежувальні та невідповідні для нових вимог, вважаючи, що бізнес-команди повинні бути швидкими і гнучкими.

Гнучке управління проектами приймає невизначеність як задану, а значення відповідають за зміну плану. Agile-планування спонукає працювати над чимось невеликим, швидко виконувати його, отримувати зворотний зв’язок, оцінювати, що працює, а що ні, і адаптувати свій план за результатами. Цей процес малих, швидких і повторюваних циклів відомий як «ітеративний».

Принципи управління базової схеми

Вивчення основ методології – найпростіша частина реалізації проекту. Освоєння техніки – це більш складне завдання. У цьому сенсі Agile схожий на покер, в якому правила освоюються за 10 хвилин, але далі, щоб почати гідно грати, потрібно багато часу. Нижче наведені деякі основні кроки для початку роботи:

Завантажити та роздрукувати PDF-версію офіційного керівництва Scrum Guide.

Виділити фрази і ролі, які є новими для користувача, і почати роботу над запам’ятовуванням того, що кожен з них в Agile Scrum означає.

Вибрати ролі.

Вибрати Scrum Master, він допоможе команді рухатися за принципами Scrum, який працює на моделі «керівник – підлеглі».

Створити свій продукт Backlog – це те місце, де вказується все що потрібно проектом, отсортированное за важливістю.

По мірі формування проекту, при появі нових потреб, вони додаються до нього. Власник продукту несе основну відповідальність за це.

Почати планування, вибрати завдання з відставання, які будуть завершені в першому проекті. Спринт обмежений часом.

Визначити тривалість часу проекту, але не більше одного місяця.

Визначити завдання, які слід включити в Agile Scrum, і хто буде відповідати за них.

Почати спринт. Члени команди працюють над своїми проектами, і кожен перевіряє їх прогрес на щоденному засіданні Scrum. Ця зустріч триває близько 20 хвилин, на ньому команди відповідають на 3 питання: що зроблено учора? що будете зроблено сьогодні? що блокує роботу сьогодні і яка допомога потрібна?

Виконати аналіз спринту.

Нове планування з урахуванням поліпшення своєї роботи, забезпечивши ефективність проекту.

Коли перший Sprint завершено, починають новий, виділивши більше завдань з відставання, і повторюють процес.

Тренер команди

Scrum – гнучкий спосіб управління проектом – зазвичай полягає в розробці програмного забезпечення. Гнучка розробка програмного забезпечення часто сприймається як методологія, але вона фактично представляє структуру управління процесом. Agile Scrum:що це? Agile Scrum в рамках гнучкого розвитку команди добре демонструється на функції ролей. Вони підтримуються двома конкретними завданнями.

Перша роль – Scrum Master, яку можна розглядати як тренера для команди. Він допомагає членам команди використовувати процес виконання проекту на найвищому рівні. Власник продукту (ПО) – це друга роль, вона направляє команду на створення правильного продукту. Модель Scrum передбачає, що проекти просуваються через серію спринтів. Відповідно до гнучкої методології спринти мають часові рамки не більше місяця, а частіше всього два тижні.

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

Процес Scrum: основні артефакти

Управління проектами Agile Scrum з використанням гнучких підходів припускає наявність артефактів. Первинним з них у розробці Scrum є сам продукт. Модель очікує, що команда виведе продукт або систему в потенційно робочий стан в кінці кожного спринту. Заготівля продукту – ще один артефакт. Це повний список функцій, які потрібно додати в продукт. Власник приоритизирует відставання, тому команда завжди використовує найбільш цінні функції.

Популярний і успішний спосіб створення відставання продукту з використанням методології полягає в тому, щоб заповнити його розповідями користувачів, які представляють короткий опис функцій, описаних зі своєї точки зору. В управлінні проектами, в перший день спринту та під час наради з планування, члени команди визначають відставання у спринті. Затримку sprint можна розглядати як список справ команди для спринту, тоді як відставання продукту – це список функцій, які потрібно створити в користувацьких історій.

Спринт-відставання – це список завдань, які команда повинна виконати, щоб додати функціональність.

Додаткові артефакти, які є результатом гнучкої методології Scrum, – це графік проходження спринту і діаграма виходу. Графіки Burndown показують об’єкт роботи, що залишився або в спринті, або у випуску, та є ефективним інструментом розробки програмного забезпечення, щоб визначити, чи буде проходити новий спринт за розкладом, щоб усі заплановані роботи були завершені до необхідної дати.

Командні завдання учасників

Scrum Master є тренером команди і допомагає практикуючим Scrum досягти найвищого рівня продуктивності. В процесі Master відрізняється від традиційного менеджера проектів, у тому числі ця роль не забезпечує щоденне керівництво для команди і не призначає завдання окремим особам. Хороший Master в процесі управління проектами Agile Scrum вкриває команду від зовнішніх відволікаючих чинників, дозволяючи її членам зосередитися під час спринту з обраної мети.

У той час як Scrum Master фокусується на тому, щоб допомогти команді бути кращою, власник продукту працює, щоб направити команду до правильної мети. Власник робить це, створюючи переконливе бачення продукту, а потім передаючи його команді. Він відповідає за пріоритизацію відставання під час розробки Scrum, щоб переконатися, що він дійшов до нуля, оскільки в цьому випадку більше пізнається про будується системі, її користувачів та команді.

Третя і заключна роль в управлінні проектами – це команда Scrum. Хоча люди можуть приєднатися до неї з різними назвами посад, в проекті ці назви незначні.

Методика стверджує, що кожна людина вносить свій внесок будь-яким способом, щоб завершити роботу кожного спринту. Це не означає, що тестувальник буде перепроектувати систему. Учасники будуть витрачати більше свого часу на робіт, в якій би дисципліни вони не працювали до прийняття рішення гнучкої моделі. Але з Scrum люди будуть працювати за межами своїх обов’язків, тому що це буде робитися для блага команди.

Керівник проекту

Scrum master – це людина, яка допомагає іншим людям зрозуміти проект і служить його команді, усуваючи перешкоди. Він також допомагає спростити складність навчанням scrum Agile. Майстер повинен переконатися, що команда розробників працює на основі базових значень. Його часто вважають тренером команди, який допомагає їй робити кращу роботу. Більш того, він гарантує, що впровадження Scrum буде успішним на підприємстві. Майстер виступає в якості центру проекту.

Йому необхідно виконувати такі функції:

Контролювати, що команда відповідає своїм бізнес-цілям.

Сприяти спільній роботі членів команди.

Виконувати планування, збір заготовок команди, спринт-демонстрацію, ретроспективу спринту.

Обробляти і допомагати підтримувати цілісність значень проекту.

Сприяти вдосконаленню технічних практик, таких як TDD, автоматичне тестування і безперервна інтеграція.

Контроль за присутністю зацікавлених сторін на зборах.

Контроль за розподілом ризику між командами.

Проведення техніко-економічних обґрунтувань, складання та перевірка специфікацій.

Канбан проти Scrum

Scrum і Kanban – це повторне робочі системи, які покладаються на потоки процесів і спрямовані на скорочення відходів. Однак є кілька основних відмінностей між ними.

Канбан – це метод візуального управління, розроблений Хиротакой Такеучи і Икуджиро Нонакой в стратегії розвитку продукту в 1986 році. Сьогодні дослідження та еволюція Канбана триває і бізнес-команди постійно знаходять нові способи використання його в якості корисного інструменту, включаючи продуктивність, ефективність, час циклу та якість. Канбан добре працює при використанні Scrum або будь-якого іншого Agile-методу.

В принципі, Канбан може застосовуватися для візуалізації та поліпшення потоку роботи незалежно від методології, використовуваної для виконання роботи. Kanban може бути налаштований так, щоб відповідати процесам і робочим систем, які команда або компанія вже має. Після того,як метод роботи був прийнятий або розроблений на основі принципів Agile, команда може почати використовувати Agile-інструменти, такі як плати kanban і інструменти прогнозування проектів, які допоможуть управляти проектами і робочими процесами.

Таблиця порівнянь Agile Scrum і kanban.

Управління портфелем

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

Існує дев’ять важливих факторів методології портфельного управління Agile Scrum:

Потенційні цінності. Команда управління портфелем буде визначати потенційні нові ідеї і продукти для розробки, перевіривши бізнес-середовище, з’ясувавши, що роблять конкуренти, шляхом отримання відгуків від існуючих клієнтів. Це допоможе забезпечити їх потреби в майбутньому за допомогою гнучкого моделювання та мозкового штурму.

Потенційні починання. Команда управління портфелем буде інвестувати час в розуміння потенційних починань. Вони можуть віддати перевагу бізнес-кейс для цієї мети, створюючи припущення високого рівня про ринковому потенціалі або окупності інвестицій (ROI). Команда також може розглянути альтернативні підходи до цієї роботи і вибрати фокус-групу або невеликий експеримент, щоб краще використовувати Agile Scrum методологію.

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

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

Ініціювати зусилля – це Agile Scrum вимогу. Нові продукти можуть розроблятися або командою продукту, або командою проекту. У випадку продуктів, які є принципово новими для організації, можна спочатку прийняти дослідний мінімальний старт-підхід, коли спочатку перевіряється ринковий потенціал продукту з допомогою серії навчальних експериментів.

Фінансування. ІТ-зусилля повинні фінансуватися. Це включає як фінансування нових проектів для початкових зусиль, так і постійне фінансування будівництва, переходу і роботи після їх розгортання. Крім того, після початку фінансування, буде здійснюватися регулярний контроль, щоб забезпечити його розумне витрачання.

Планування ІТ-можливостей. ІТ-відділ повинен мати ресурси, як з точки зору фінансів, так і людей, для виконання своїх обов’язків. Це повинні бути фахівці з правильними навичками, щоб виконувати роботу в координації з учасниками проекту.

Управління постачальниками. Важливим аспектом управління портфелем, особливо коли мова йде про постачальників ІТ-послуг, що надають підрядників, консультантів або служб розвитку. Управління постачальниками включає в себе закупівлю контрактів, визначення потенційних постачальників, контроль за виконанням контрактів і, в кінцевому рахунку, укладення контракту.

Управління портфелем ІТ, включаючи подальші розробки, а також операційні рішення.

Параметри гнучкого управління ресурсами

Управління ресурсами може стати позитивним підкріпленням для гнучких підходів при включенні наступних параметрів:

Частота співпраці в якості критерію прийняття рішення про склад команди.

Місце розташування – сильно зважений параметр.

Впровадження особистісного фактора самими співробітниками.

Ступінь сталості тим.

Орієнтований на продуктивність планування командного рівня.

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

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

Схожість і відмінності методів

Між методами існує багато відмінностей. Головне, чим відрізняється Agile від Scrum: Agile – це філософія, а Scrum – процес реалізації філософії. Схожість методів:

Рівнозначно пов’язані з управлінням проектами і розробкою програмного забезпечення.

Оптимальне використання ресурсів.

Ефективне управління різними завданнями.

Націлені на те, щоб максимально використовувати бізнес-користувачів.

Забезпечують доставку продукту або проекту бізнес-користувачам протягом мінімально можливого часу.

Підкреслюють постійне вдосконалення, співробітництво і відкрите спілкування.

Agile і Scrum відмінності мають такі:

Сфера дії.

Планування. Гнучка методологія передбачає регулярне надання та оновлення програмного забезпечення. Під Scrum наступний спринт запланований після того, як команда завершила поточні спринтерські дії.

Дизайн і виконання. Agile підкреслює, що дизайн і виконання прості. Під Scrum дизайн і виконання можуть бути експериментальними та інноваційними.

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

Гнучкість. Ключовою перевагою Agile-методології є гнучкість, оскільки вона швидко адаптується до змін. Тоді як Scrum має кілька жорсткий і структурований підхід і стиль.

Співробітництво. Agile підкреслює співробітництво, а також безпосередня взаємодія або спілкування між членами команди, в той час як Scrum забезпечує спільну роботу за допомогою щоденних зустрічей з чітко визначеними ролями для майстра сутички, бізнес-користувачів і різних членів команди.

Зв’язок. Гнучка методологія надає пріоритет прямого зв’язку і пов’язаним з нею методів для досягнення різних цілей. Scrum не приділяє занадто великої уваги прямим повідомленням.

Тепер користувачу зрозуміло, що Agile Scrum – це необхідні інструменти для управління проектами та розробки програмного забезпечення. Вони слідують системного підходу, щоб одержати найкращі результати. Обидва вони націлені на те, щоб забезпечити максимальну цінність для бізнес-користувачів за рахунок оптимального використання ресурсів, підкреслюють повторне процеси, сприяючи змін, постійного вдосконалення, співпраці, відкритого спілкування. Вони відмінно доповнюють один одного у багатьох відношеннях.