Agile – це комплексна методика організації процесу розробки ПЗ, яка включає в себе цілу сім’ю окремих підходів, або, як їх ще називають, фреймворків (Scrum, Kanban, Lean, DSDM, XP, FDD, Crystal). Вона використовує ітеративний підхід до управління проектами та розробки ПЗ, що дозволяє командам прискорити та організувати будь-який процес. Замість того щоб випускати весь продукт цілком, agile команда виконує роботу в рамках невеликих інкрементів. Вимоги, плани та результати постійно проходять перевірку на актуальність, завдяки чому команди можуть швидко реагувати на зміни. Основною сферою, де використовується Agile, є розробка програмного забезпечення. Але в сучасному світі Agile можна застосувати до будь-якої організації будь-якої галузі.
Філософія Agile включає в себе: Agile Manifesto, та 12 принципів.
Agile Manifesto:
1. Люди та співпраця важливіші за процеси та інструменти.
2. Працюючий продукт важливіший за вичерпну документацію.
3. Позитивна співпраця із замовником важливіша ніж обов’язки по контракту.
4. Готовність до змін важливіша ніж дотримання плану.

Принципи Agile:
1. Наш головний пріоритет — задоволення клієнта шляхом ранньої та безперервної розробки цінного програмного забезпечення. Замовник і виконавець зацікавлені в успіху однаково.
2. Позитивне ставлення до змін, навіть на пізній стадії розробки. Гнучкі процеси використовують зміни для конкурентної переваги клієнта.
3. Працюючий продукт слід випускати якомога частіше, від кількох тижнів до кількох місяців, віддаючи перевагу коротшим термінам.
4. Замовник та розробники повинні працювати разом щодня протягом усього проекту.
5. Над проектом повинні працювати мотивовані професіонали. Забезпечте їм необхідне середовище, підтримку та довірте їм виконання роботи.
6. Найефективнішим і дієвим методом передачі інформації до команди розробників і всередині неї є бесіда віч-на-віч.
7. Працююче програмне забезпечення є основним показником прогресу.
8. Гнучкі процеси сприяють сталому розвитку. Замовник і розробники повинні мати можливість підтримувати постійний темп нескінченно довго.
9. Постійна увага до технічної досконалості та якості проектування підвищує гнучкість проекту.
10. Простота – це мистецтво не робити зайвої роботи.
11. Найкращі архітектури, вимоги та проекти виходять із самоорганізованих команд.
12. Через регулярні проміжки часу команда розмірковує над тим, як стати більш ефективною, а потім відповідно налаштовує та коригує свою поведінку.

А теперь розглянемо деякі методики Agile окремо.
Scrum – це методика, яка допомагає команді професіоналів організувати свою роботу максимально ефективно. Як спортивна команда готується до вирішальної гри (до речі, scrum — англ. «битва»), так і Scrum-команда повинна отримувати уроки з набутого досвіду, опановуючи принципи самоорганізації, працюючи над вирішенням проблеми, аналізувати свої успіхи та провали, щоб постійно вдосконалюватись. Scrum сприяє цьому.
Методику Scrum найчастіше застосовують команди розробників додатків, але принципи та досвід її використання можна застосувати до командної роботи будь-якого роду. Це одна із причин такої популярності методики. Учасники команди Scrum проводять збори, використовують спеціальні інструменти та беруть на себе особливі ролі, щоб організувати роботу та керувати нею.
Поняття Scrum та Agile часто плутають, тому що Scrum будується навколо ідеї про постійне вдосконалення, яке є головним принципом Agile. І все ж таки Scrum — це методика роботи, а Agile — це спосіб мислення. Перейти на Agile не так просто; вся команда має прагнути змінити свій підхід до створення цінності клієнтам. Але можна почати використовувати методику, таку як Scrum. Це спрямує мислення у потрібне русло та допоможе практикувати принципи Agile у повсякденному спілкуванні та роботі.
Методика Scrum за своєю суттю є евристичною. В її основі лежить постійне навчання та адаптація до мінливих факторів. Згідно зі Scrum, команда не знає всього на початку проекту, але розвиватиметься, вивчаючи уроки з досвіду. У структурі Scrum закладена та свобода, з якою команди пристосовуються до змінних умов та вимог користувачів. Робочий процес передбачає зміну пріоритетів та короткі цикли релізу, що сприяє постійному навчанню та вдосконаленню команди.
Структурованість не заважає методології Scrum бути гнучкою. Її можна адаптувати до потреб організації. Існує безліч теорій про те, як слід застосовувати Scrum, щоб досягти успіху, але незалежно від того, яку методологію ви оберете, її головними принципами мають бути ясність комунікації, прозорість та прагнення до постійного вдосконалення. Решту ви вільні вибирати самі.

Цінності Scrum:
1. Зобов’язання. Члени команди особисто зобов’язуються досягти командних цілей.
2. Мужність. Члени команди роблять правильні речі та працюють над складними проблемами.
3. Фокус. Зосередження на роботі, визначеній для спринту, і на цілях команди.
4. Відкритість. Члени команди та зацікавлені сторони відкрито розповідають про всю роботу та виклики, з якими зіштовхується команда.
5. Повага. Всі члени команди поважають одне одного.

Принципи Scrum:
1. Прозорість. Команда має працювати в середовищі, де кожен знає, з якими проблемами зіштовхуються інші члени команди.
2. Перевірка. Часті перевірки, вбудовані в структуру процесу, щоб дати команді можливість обміркувати, як працює процес. До таких пунктів перевірки належать Daily Scrum meeting і Sprint Review Meeting.
3. Адаптація. Команда постійно досліджує актуальність продуктів і переглядає ті пункти, які не мають сенсу.

Команда Scrum:
Product Owner. Це замовник, або назначений ним відповідальний професіонал. Його завдання — розуміти вимоги бізнесу, клієнта та ринку. Його задачі:
• Написання та підтримка Product Backlog.
• Тісна співпраця з замовником та scrum-командою, повідомляючи кожному учаснику значення робочих завдань у Product Backlog.
• Надає команді зрозумілі вимоги, які можна протестувати.
• Відповідає за прийомку в кінці кожної ітераціі.
Scrum Master – стежить за застосуванням принципів Scrum у своїх командах. Він навчає команду та Замовника Scrum-процесу і намагається оптимізувати застосування цієї практики.
Успіх Scrum-майстра залежить від того, наскільки добре він розуміється на роботі, яку виконує команда, і може допомогти команді підвищити прозорість роботи та оптимізувати процес. Це головний координатор, який складає перелік необхідних ресурсів (кадрових та матеріально-технічних) для зборів із планування спринту та огляду його підсумків, стендапу та ретроспективи спринту.
Development Team – команда, що включає в себе від 3 до 9 максимально кваліфікованих професіоналів, які вміють робити усі етапи розробки ПЗ. Вона є самостійною, самоорганізованою та максимально мотивованою на результат.

Артефакти Scrum
Артефакт — це те, що ми створюємо, наприклад, інструмент для вирішення проблеми. У Scrum існує три артефакти: беклог продукту, беклог спринту та інкремент із вашими критеріями готовності. Ці три постійні присутні у кожній команді Scrum.
Product Backlog – це головний перелік завдань, їх ще називають User Story, які потрібно виконати. Його веде Замовник або Product Owner. Це постійно змінний перелік функціональних можливостей, вимог, покращень та виправлень, з якого складаються завдання для беклогу спринта. Загалом це список завдань команди. Власник продукту постійно звертається до беклогу продукту, змінює в ньому пріоритети і підтримує його актуальність, тому що може з’явитися нова інформація або можуть відбутися зміни на ринку, через що зникне сенс виконувати ці завдання або з’являться нові способи вирішення проблем.
Sprint Backlog – це список робочих завдань, історій або виправлень багів, відібраних командою розробників із User Story написаних у Product Backlog. Перед кожним спринтом проводяться збори з планування спринту (його ми обговоримо далі у статті), у якому команда обирає, які завдання з бэклога продукту необхідно виконати у межах спринту. Беклог спринту може бути фіксованим і може змінюватися по ходу спринта. Однак ніщо не повинно заважати досягненню основної мети спринту – того, чого команда хоче досягти за поточний спринт.
Increment – це готовий до використання кінцевий продукт за підсумками спринту. Iнкремент презентується на демонстрації наприкінці спринту, де команда показує, що вона зробила за спринт. Його часто визначають як критерій готовності продукту, контрольну точку, мету спринту або навіть повну версію або поставлений епік. Все залежить від того, якими критеріями готовності керується ваша команда та як вибираються цілі спринту. Наприклад, деякі команди вважають за краще випускати щось для своїх клієнтів наприкінці кожного спринту. Їх слово «готово» означає «поставлено». Однак для інших команд це може бути непрактичним. Уявіть, що ви працюєте над серверним продуктом, який можна постачати клієнтам лише раз на три місяці. Ви, як і раніше, можете розбивати роботу на двотижневі спринти, але для вас продукт буде готовий, коли ви завершите роботу над частиною більшої версії, яку плануєте поставити цілком. Однак не забуватимемо, що чим більше часу йде на випуск ПЗ, тим менше шансів у цього ПЗ здобути успіх.

Івенти Scrum
Sprint – це проміжок часу, протягом якого команда Scrum спільно працює над створенням готового інкременту. Як правило, спринт триває два тижні, хоча деякі команди обирають обсяг спринта в один тиждень або поставити інкремент, який має достатню цінність швидше. Дейв Вест із Scrum.org рекомендує планувати спринт тим коротшим, чим складніша робота і чим більше в ній невідомих. Але останнє слово завжди за командою. Не соромтеся змінювати тривалість спринту, якщо здасться, що вона вам не підходить. Протягом цього періоду власник продукту та команда розробників можуть переглянути обсяг спринту, якщо це необхідно. Це і є ключем до розуміння емпіричної суті Scrum.
Усі заходи від планування до ретроспективи проводяться протягом спринту. Після того, як тимчасовий проміжок для спринту визначений, він повинен залишатися незмінним, доки ведеться розробка. Так команда отримуватиме цінні уроки з минулого досвіду та застосовуватиме висновки до майбутніх спринтів.
Sprint Planning – на цих зборах, які тривають максимум 8 годин, команда розробників під керівництвом Scrum-майстра планує роботу (обсяг спринту), яку необхідно виконати упродовж поточного спринту . На ньому визначається мета спринту. Потім у Sprint Backlog додаються конкретні User Story з Product Backlog. Ці історії завжди співвідносяться з метою. При цьому команда Scrum узгоджує такі історії, які можна буде реалізувати практично під час спринту.
Наприкінці зборів із планування кожен член команди Scrum повинен чітко уявляти, які завдання можна виконати за спринт і як поставити інкремент.
Daily Scrum meeting – це дуже короткі щоденні збори, які для зручності проводяться в один і той же час (зазвичай вранці) і в тому самому місці. Багато команд намагаються вкластися в 15 хвилин, проте це лише рекомендація. Щоденна Scrum-нарада проводиться, щоб кожен учасник команди був у курсі того, що відбувається, не відхилявся від мети та отримував план роботи на найближчі 24 години. На цих зборах кожен учасник команди відповідає на питання: що він зробив вчора, що він планує робити сьогодні і які в нього виникли проблеми.
Sprint Review – наприкінці спринту команда збирається для перегляду демонстрації інкременту (чи його вивчення) у неформальній обстановці. Команда розробників представляє зацікавленим сторонам та колегам завершені робочі завдання з беклогу, щоб зібрати відгуки. Власник продукту вирішує, чи варто випускати інкремент.
Під час наради Product Owner змінює Product Backlog виходячи з результатів останнього завершеного спринту. Цей процес може перейти у планування наступного спринту. Нарада триває 3-4 години.
Sprint Retrospective – проводиться, щоб команда зафіксувала та обговорила всі успіхи та невдачі спринту, проекту, учасників, їхніх взаємин та інструментів. Мета ретроспективи — створити умови, щоб команда могла оцінити все, що вдалося і що потрібно покращити наступного разу, та не зациклювалася на невдачах. Триває 1-3 години.