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

Головні дійові особи — ScrumMaster, той хто опікується процесами, веде їх і працює як керівник проекту, Власник Продукту, людина, що представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін, та Команду, яка включає розробників.

Протягом кожного спринту, 15-30 денного періоду (тривалість визначається командою), працівники створюють функціональний ріст програмного забезпечення.

Перед початком кожного Sprint проводиться Sprint Planning, на якому проводиться оцінка вмісту Product Backlog і формування Sprint Backlog, який містить завдання (Story, Bugs, Tasks), які повинні бути виконані в поточному спринті. Кожен спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.

По закінченню Sprint'а виробляються Sprint Review і Sprint Retrospective, завдання яких оцінити ефективність (продуктивність) команди в минулому Sprint'е, спрогнозувати очікувану ефективність (продуктивність) в наступному спринті, виявленні наявних проблем, оцінки ймовірності завершення всіх необхідних робіт по продукту і інше.

За методикою Scrum у виробничому процесі є визначені ролі: 

• Власник Продукту (Product Owner)
• Керівник (ScrumMaster)
• Команда розробників (Scrum Team)
• Користувачі (Users)
• Клієнти, Продавці (Stakeholders)
• Експерти-консультанти (Consulting Experts)

Канбан

Система канбан розпочала свій шлях у 1950-х роках на виробничих лініях корпорації Toyota, після чого перекочувала в офіси і стала важливим інструментом для проектних менеджерів.

Принципи канбана

Менеджери Toyota сформулювали 6 системоутворюючих правил:

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

Застосування канбан в IT

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

Тільки картки, на яких вказані інформація про терміни виконання, опис або номер процесу і ім'я виконавця, тепер прикріплюються ні до тарі з запчастинами, а до дошки з розкресленими колонками:

• Беклог - завдання, які треба виконати
• Завдання, які в даний момент розробляються
• Завдання, які виконані, але ще не передані тестувальникам
• Завдання, готові до передачі відділу тестування
• Завдання, які проходять перевірку проект-менеджером (ПМ)
• виконані завдання

Переваги та недоліки канбан

Kanban має такі переваги:

• Гнучкість планування. Команда концентрується тільки на поточну роботу, пріоритет завдання виставляється менеджером.
• Висока залучення команди в процес розробки. Завдяки постійним зборам, прозорості процесів і можливостям самоорганізації працівники гуртуються і проявляють щирий інтерес.
• Менша тривалість циклу. Якщо кілька людей має схожі навичками, тривалість скорочується, якщо ж тільки один - з'являється вузьке місце. Тому співробітники повинні ділитися знаннями і тим самим оптимізувати тривалість циклу. Тоді вся команда зможе взятися за роботу, яку забуксувала, і відновити плавний потік.
• Менше вузьких місць. Ліміти РВП дозволяють швидко знаходити вузькі і проблемні місця, які з'явилися через дефіцит уваги, людей або навичок.
• Наочність. Коли всі виконавці мають доступ до даних, то вузькі місця легше помітити. Kanban-команди, крім самих карток, зазвичай використовують два загальних звіту: графіки управління і сукупного потоку.

Канбан має і недоліки:

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

Agile

Під терміном "agile" розуміють набір підходів по "гнучкій розробці" програмного забезпечення. 

12 принципів, які складають Agile Methodology, можна поділити на 4 основні ідеї:

• Пріоритет людей і спілкування над інструментами і процесами;
• Пріоритет працюючого продукту над повною документацією;
• Пріоритет співробітництва з замовниками над затвердженням контракту;
• Пріоритет готовності змінюватися над дотриманням початкового плану.

Agile-підходи та методи:

• Фокусують команду на потребах і цілях клієнтів.
• Спрощують оргструктуру і процеси.
• Пропонують роботу короткими циклами.
• Активно використовують зворотний зв'язок.
• Припускають підвищення повноважень співробітників.
• Мають у своїй основі гуманістичний підхід.
• Не є кінцевим станом, а, скоріше, спосіб мислення і життя

Відео про Agile-підхід

Six Sigma

Вill Smith створив концепцію Six Sigma у 1986 році. Це більш структурована версія, в яку додано більше планування для економії ресурсів, підвищення якості, а також, зниження кількості браку і проблем. Кінцева мета проекту - задоволення замовника якістю продукту, якого можна досягти за допомогою безперервного процесу поліпшення всіх аспектів проекту, заснованому на ретельному аналізі показників. У концепції приділяється окрема увага усуненню проблем.

Сильні сторони Six Sigma:

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

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

Слабкі сторони Six Sigma:

Основний мотив Six Sigma: «Все завжди можна зробити ще краще». Це може демотивувати співробітників, що не відчувають задоволення від виконаної роботи. Крім того, якщо проект одиничний і компанія не планує в майбутньому реалізовувати подібні проекти, всі витрати на аналіз і витяг уроків можуть виявитися марними.

Open Source

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

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

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

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

Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.

Екстремальне програмування (Extreme Programming) — методологія розробки програмного забезпечення, найпопулярніша серед так званих гнучких методологій. Має на меті поліпшення якості програмного забезпечення та чутливість до змін у вимогах замовників. Як вид гнучких методологій, XP радить часті "випуски" програми у коротких циклах розробки, що має на меті поліпшити продуктивність праці та покращити можливості виконання вимог замовника, що змінюються. Авторами даної методології є Кент Бек, Ворд Каннінгем, Мартін Фаулер та інші.

Інші елементи екстремального програмування включають в себе:

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

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

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

Задачі
Extreme Programming Explained описує екстремальне програмування як дисципліну розробки програмного забезпечення яка змушує людей створювати високоякісне ПЗ якомога швидше.

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

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

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

Написання коду
Прихильники ХР заявляють що єдиним дійсно важливим результатом розробки ПЗ є код: без готового коду нема продукту.

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

Основні прийоми XP
Дванадцять основних прийомів екстремального програмування (за першим виданням книги Extreme programming explained) можуть бути об'єднані в чотири групи:

Короткий цикл зворотного зв'язку (Fine scale feedback)

• Розробка через тестування (Test driven development)
• Гра в планування (Planning game)
• Замовник завжди поруч (Whole team, Onsite customer)
• Парне програмування (Pair programming)

Безперервний, а не пакетний процес

• Безперервна інтеграція (Continuous Integration)
• Рефакторинг (Design Improvement, Refactor)
• Часті невеликі релізи (Small Releases)

Розуміння, що поділяється всіма учасниками

• Простота (Simple design)
• Метафора системи (System metaphor)
• Колективне володіння кодом (Collective code ownership) або обраними шаблонами проектування (Collective patterns ownership)
• Стандарт кодування (Coding standard or Coding conventions)

Соціальна захищеність програміста (Programmer welfare) :

• 40-годинний робочий тиждень (Sustainable pace, Forty hour week)

Методологія Agile 

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

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

У процесі Agile керівництво відіграє життєво важливу роль.

Порівняно з Scrum - це більш жорсткий метод. Тому місця для частих змін не так багато.

Agile передбачає співпрацю та взаємостосунки між членами різних міжфункціональних команд.

Agile може зажадати багатьох передових процесів розвитку та організаційних змін.

Agile метод потребує частої доставки продукту клієнтові для зворотного зв'язку.

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

Керівник проекту контролює всі завдання у методології Agile.

Метод Agile заохочує зворотний зв'язок від замовника під час процесу. Таким чином кінцевий продукт стане якіснішим.

Поставляйте та оновлюйте програмне забезпечення регулярно.

Проектування та виконання повинні бути простими.

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

Робоче програмне забезпечення - найелементарніший показник прогресу.

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

Принципи методології Agile:

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

-Бізнесмени та розробники співпрацюватимуть щодня впродовж проекту.

-Увага до технічної досконалості та правильного дизайну підвищує швидкість виконання замолвення.

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

Існування гнучкої методології розробки програмного забезпечення (ПЗ) для управління проектами – це серія підходів, яка реалізує розробку ПЗ. Ці підходи спрямовані на використання ітеративних розробок, динамічного формування вимог та забезпечення їхньої реалізації за результатами постійної взаємодії в середині самоорганізованих робочих груп, до складу яких входять спеціалісти різного профілю. До класу гнучкої методології розробки (з англійської Agile software development, agile-методи) відносять декілька розробок: екстремальне програмування, DSDM, Scrum та Kanban. Ця методологія використовується як ефективна практика організації роботи груп невеликого розміру, які виконуються однорідну роботу, та поєднується з управлінням або комбінованим методом. Ціль гнучкої методології є розділення великого процесу виконання проекту на дрібні етапи/ітерації (тривалість кожного 2-3 тижні), що мінімізує ризики реалізації.

Кожна ітерація виглядає як мінімізований програмний проект та включає всі задачі, які необхідно виконати для отримання міні-приросту по функціональності: планування, аналіз вимог, проектування, програмування, тестування та документування. Необхідно врахувати, що після завершення кожного етапу, підприємство не матиме нову версію продукту/програми. Робоча група/команда обов’язково має виконувати перегляд та переоцінку пріоритетів після завершення кожного етапу. В основу Agile-методів покладено спілкування обличчя до обличчя (face-toface). Більшість таких команд має розташовуватись в одному офісі, інколи до цих команд входить замовник проекту або його представник (визначає вимоги до продукту, це може бути менеджер проекту, бізнес-аналітик або клієнт). Команда включає тестувальників, дизайнерів інтерфейсу, технічних спеціалістів та менеджерів.

Існують методології, які притримуються цінностей та принципів Agile Manifesto: - Agile Modelling – набір визначень, принципів та практик, які дозволяють швидко та просто виконати моделювання і документування у проектах розробки ПЗ. До складу не входить інструкція для проектування, опис щодо побудови діаграм в UML. Ціль – ефективне моделювання та документування, яке не охоплює програмування та тестування, не включає питання управління проектом, розгортанням та супроводу системи, однак включає перевірку моделі кодом.

- Agile Unified Process – описує просте та зрозуміле наближення (модель/структуру) для створення ПЗ для бізнес-додатків. - Agile Data Method – група ітеративних методів розробки ПЗ, в яких вимоги та рішення досягаються у рамках співпраці різних крос-функціональних команд.

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

Ролі в Scrum

У класичному Scrum існує 3 базових ролі:
-Product owner
-Scrum master
-Команда розробки (Development team)

Product owner (PO) є сполучною ланкою між командою розробки та замовником. Завдання PO - максимальне збільшення цінності продукту, що розробляється і роботи команди.

Одним з основних інструментів PO є Product Backlog. Product Backlog містить необхідні для виконання робочі завдання (такі як Story, Bug, Task і ін.), Відсортовані в порядку пріоритету (терміновості).

Scrum master (SM) є «лідером-службовцем » (англ. Servant-leader). Завдання Scrum Master - допомогти команді максимізувати її ефективність за допомогою усунення перешкод, допомоги, навчанні та мотивації команді, допомоги PO

Команда розробки (Development team, DT) складається з фахівців, які виробляють безпосередню роботу над виробленим продуктом. Згідно The Scrum Guide (документу, що є офіційним описом Scrum), DT повинні володіти такими якостями і характеристиками:
-Бути самоорганізованими. Ніхто (включаючи SM і PO) не може вказувати команді яким перетворити Product Backlog в працюючий продукт
-Бути багатофункціональними, володіти всіма необхідними навичками для випуску працюючого продукту
-За виконувану роботу відповідає вся команда, а не індивідуальні члени команди

Рекомендований розмір команди - 7 (плюс-мінус 2) людини. Згідно ідеологам Scrum, команди більшого розміру вимагають занадто великих ресурсів на комунікації, в той час як команди меншого розміру підвищують ризики (за рахунок можливої відсутності необхідних навичок) і зменшують розмір роботи, який команда може виконати в одиницю часу.

Процес Scrum

Основою Scrum є Sprint, в перебігу якого виконується робота над продуктом. По закінченню Sprint повинна бути отримана нова робоча версія продукту. Sprint завжди обмежений по часу (1-4 тижні) і має однакову тривалість протягом всього життя продукту.

Перед початком кожного Sprint проводиться Sprint Planning, на якому проводиться оцінка вмісту Product Backlog і формування Sprint Backlog, який містить завдання (Story, Bugs, Tasks), які повинні бути виконані в поточному спринті. Кожен спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.

Кожен день проводиться Daily Scrum, на якому кожен член команди відповідає на питання «що я зробив вчора?», «Що я планую зробити сьогодні?», «Які перешкоди на своїй роботі я зустрів?». Завдання Daily Scrum - визначення статусу і прогресу роботи над Sprint, раннє виявлення перешкод, що виникли, вироблення рішень щодо зміни стратегії, необхідних для досягнення цілей Sprint'а.

По закінченню Sprint'а виробляються Sprint Review і Sprint Retrospective, завдання яких оцінити ефективність (продуктивність) команди в минулому Sprint'е, спрогнозувати очікувану ефективність (продуктивність) в наступному спринті, виявленні наявних проблем, оцінки ймовірності завершення всіх необхідних робіт по продукту і інше .