Agile (agile software development, від англ. Agile – моторний) – це сімейство «гнучких» підходів до розробки програмного забезпечення. Такі підходи також іноді називають фреймворками або agile-методологіями.

Agile виник в IT-середовищі, але потім поширився і в інші сфери – від промислової інженерії до штучного інтелекту.

Сенс Agile сформульований в Agile-маніфесті розробки ПО: «Люди і взаємодія важливіше процесів та інструментів. Працюючий продукт важливіше вичерпної документації. Співпраця з замовником важливіше узгодження умов контракту. Готовність до змін важливіше проходження попереднім планом ».

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

До окремих agile-підходам відносяться scrum і kanban.

Scrum – це «підхід структури». Над кожним проектом працює універсальна команда фахівців, до якої приєднується ще двоє людей: власник продукту і scrum-майстер. Перший з’єднує команду з замовником і стежить за розвитком проекту; це не формальний керівник команди, а скоріше куратор. Другий допомагає першому організувати бізнес-процес: проводить загальні збори, вирішує побутові проблеми, мотивує команду і стежить за дотриманням scrum-підходу.

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

Kanban – це «підхід балансу». Його завдання – збалансувати різних фахівців всередині команди і уникнути ситуації, коли дизайнери працюють цілодобово, а розробники скаржаться на відсутність нових завдань.

Вся команда єдина – в kanban немає ролей власника продукту і scrum-майстра. Бізнес-процес поділяється не на універсальні спринти, а на стадії виконання конкретних завдань: «Планується», «Розробляється», «Тестується», «Завершено» і ін.

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

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

Що таке Agile?

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

Agile – це філософія або орієнтація (Griffin). Agile широко служить орієнтиром для наближення до проектної роботі. Гнучка методологія підкреслює ітерацію розробки, а також тестування в життєвому циклі розробки програмного забезпечення (SDLC). Agile розбиває цілий продукт або проект на невеликі збірки. У методології Agile розробка або тестування відбувається одночасно. Agile підтримує спільну роботу, а також прямий зв’язок.

Що таке Scrum?

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

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

Подібність між Agile і Scrum:

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

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

Природа Agile і Scrum:

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

Scrum надає інкрементні модулі клієнту щотижня або два тижні.

приклади вживання

Один із принципів Agile стоїть на особисту відповідальність людини, а не на налагодження внутрішніх процесів.

(З статті на VC.ru)

Коли в роботі з професійними командами ми використовуємо Scrum, найчастіше ми вибираємо цикл довжиною в 2-3 тижні з ретроспективними зборами, які дозволяють тримати все під контролем.

(З інтерв’ю «Ведомостей» з Френком Сосьером, коучем компанії Freestanding Agility)

Головна ідея Kanban – візуалізація робочого процесу. Вона полягає в створенні фізичної панелі, на якій можна наочно відзначати прогрес.

(З перекладу колонки Forbes на Rusbase)

Якщо говорити про те, що таке agile, я б обмежився такою фразою – це набір цінностей, в рамках яких ми будуємо свою роботу з продуктами, з процесами всередині організації.

(Керуючий партнер ScrumTrek Олексій Піменов в статті на Rusbase)

Як і навіщо з’явилася scrum-методологія

До появи Scrum в світі розробки програмного забезпечення було прийнято використовувати «водоспадний підхід». Робота над продуктом велася за таким планом.

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

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

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

Висновки, які були зроблені, допомогли створити «Маніфест гнучкої розробки програмного забезпечення». До нього увійшли всього чотири пункти, але вони повністю змінили процес.

Маніфест гнучкої розробки ПО

1 Люди важливіше інструментів.
2 Якість продукту важливіше документації.
3 Взаємодія з замовником важливіше контракту.
4 Готовність до змін важливіше встановленого плану.

Ці чотири пункти стали основою для появи Agile, гнучкого процесу розробки програмного забезпечення. Пізніше були создани12 принципів, які і зараз використовуються в будь-який agile-методології.

12 принципів Agile

1 Головне – гарне ПО і задоволений замовник.
2 Готовність до змін в будь-який момент.
3 Повністю робочий ПО – якомога частіше.
4 Зустріч команди – найкраще для обміну інформацією.
5 Замовник і команда розробки повинні працювати разом.
6 Довіряти людям робити свою роботу.
7 Є робоче ПО – є прогрес.
8 Гнучкі процеси – безперервний розвиток.
9 Увага до якості сприяє гнучкості.
10 Простота процесу дозволяє не робити зайвої роботи.
11 Самоорганізаційна команда краще працює.
12 Постійне прагнення до більшої ефективності.

Agile і водоспад, ваги

Одна з методологій гнучкого процесу розробки програмного забезпечення, яка базується на agile-принципах, – Scrum.

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

Основні принципи Scrum

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

Робота короткими циклами (спринт)

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

Гнучкість. «Перевіряти і адаптуватися»

Гнучкість процесу і тестування продукту після кожного спринту. Якщо щось йде не так, команда завжди готова змінити стратегію розробки або переглянути беклог БеклогУпорядоченний список завдань, над якими scrum-команда працює при створенні продукта.продукта.

Участь замовника і користувачів у створенні продукту.

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

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

взаємодія команди

Scrum-команда – це кілька людей, які працюють на один результат і як єдине ціле. Кожен прагне до однієї спільної мети.

Про важливість scrum-команди

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

Склад команди

Власник продукту. Людина, яка представляє продукт і є посередником між замовником, користувачами і командою розробників. Іноді їм може бути сам замовник.
Scrum-майстер. Найчастіше – спеціально найнятий працівник, який веде команду до результату. Він не керує командою, але спостерігає за виконанням основних принципів Scrum. Його завдання – не тиснути, не робити всю роботу самому і не розподіляти обов’язки, але допомагати, направляти і вирішувати питання, які гальмують процес розробки.
Розробники. У складі scrum-команди завжди є люди з різним набором навичок. Так, команда з п’яти-дев’яти чоловік веде весь проект від початку до кінця. Одна команда – один готовий продукт.

Як виглядає scrum-команда

розподіл ролей

Скрам працює, коли є розподіл ролей. Всього їх три.

Команда. Це самоорганізована група з 3-9 чоловік. Внесок окремого співробітника не оцінюються. Важливо тільки те, якого результату домоглася команда спільними зусиллями.

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

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

Інструменти скрам

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

Інструкція: як використовувати Скрам, щоб працювати по Аджайлу

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

Скрам пропонує робити так:

Прокачати теоретичну базу: почитати книги по темі і подивитися відеолекції. Записи з конференцій Agiledays є на Ютубі на каналі. У співтоваристві послідовники Скрам діляться досвідом – можна повчитися у них.
Вибрати власника продукту. Це людина, яка в деталях представляє готовий продукт. Він же буде оцінювати ризики, вигоди і приймати стратегічні рішення.
Зібрати команду з 3-9 чоловік. У команді повинні бути люди, у яких достатньо знань і навичок, щоб працювати над проектом.
Призначити скрам-майстра або запросити на цю роль професіонала з консалтингового агентства.
Запропонувати власнику продукту прописати беклог і дати команді його оцінити. Дуже добре, якщо команда оцінить його не в годинах, а в відносних одиницях.
Запланувати спринт. У нього повинна бути фіксована тривалість і точний список завдань, який не можна доповнювати.
Зробити роботу прозорою. Кожен член команди повинен бачити, які завдання вже вирішені, а над якими ще потрібно попрацювати. Для цього потрібні інструменти: скрам-дошка або діаграма згоряння завдань.
Проводити щоденні загальнокомандні збори – щоденний Скрам. На зустрічах учасники команди звіряються з результатами один одного, дивляться, на якому етапі перебуває проект і вирішують, як далі рухатися до мети. Збори триває 15 хвилин. Якщо виходить довше, значить, команда і скрам-майстер щось роблять не так.
Завершити спринт оглядом. Огляд спринту – зустріч, на якій присутні будь-які зацікавлені особи: споживач, замовник, власник продукту, скрам-майстер. На зустрічі команда показує готовий продукт або його частину. Неважливо, що це буде, головне – щоб воно виконувало свою функцію.
Провести ретроспективне збори відразу після огляду спринту. Коли команда показала працюючий продукт, всі сідають за стіл і аналізують спринт. Що пройшло добре? Що можна поліпшити? Які перешкоди подолала команда? В кінці зборів скрам-майстер і команда повинні подумати, як зробити наступний спринт ще краще.
Негайно призначити новий спринт!

Кому підійде Аджайл

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

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

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

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

слово експертам

Залежно від завдань ми застосовуємо різні методи в рамках філософії – agile, scrum, kanban.

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

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

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

Важливий момент: agile-методологія – це загальний напрямок, а kanban і scrum – вже її різновиди.

Ми використовуємо зв’язку scrum + waterfall, а також допрацьовували протягом року саму agile-дошку. Головна причина використання: прозорість і простота. По суті, це виходить той же самий конвеєр Генрі Форда: перехід завдання від статусу до статусу зі зміною виконавця, тому основним принципом до самої agile-дошці є вже простота.

Ми використовуємо agile як безпосередню частину нашого workflow, тому всі проекти, від брендинга і розробки сайтів і аж до нашого стартапу по AI і нативной рекламі NativeOS, в бюро Chernika ведуться саме з даного workflow.

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

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

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

Для наочності і відкритості роботи відділу розробки ми повісили спеціальну дошку з позначками “to do”, “in progress”, “review”, “test”, “done”, де всі члени команди наклеюють стікери з завданнями (в колонці “to do” ), а в міру їх виконання переміщують в наступні пункти. і щасливий фінал – кінцевий пункт “done”. Це допомагає скласти загальну картину і дає можливість бачити, над чим працює кожен учасник.

Дуже важливий момент методу (і організації робочого процесу): після затвердження всіх завдань (“to do”), список блокується на внесення. Так нові надходять завдання не відволікають від процесу і не гальмують роботу.

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

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

Командна робота також підвищує відповідальність: все отримують бонус, тільки якщо команда виконала поставлені на певному етапі завдання.

Інга Корягіна
Agile – це філософія, scrum – структура, waterfall – метод, kanban – система управління. Scrum і kanban – варіанти agile, але у них є деякі явні відмінності. Методика scrum вимагає фіксованих ролей, тоді як у kanban немає необхідних ролей. Scrum заснована на ітераціях, які об’єднують планування, оптимізацію процесів і випуск. У kanban це можна робити регулярно або кожен раз, коли вам потрібно. Команда scrum вимагає оцінки своєї роботи, тоді як команді kanban це не потрібно.

Використані джерела і корисні посилання по темі: https://rb.ru/story/agile-scrum-kanban/ https://ru.esdifferent.com/difference-between-agile-and-scrum https://skillbox.ru / media / management / kak_ponyat_scrum / https://allo.tochka.com/agile-scrum

Джерело запису: lastici.ru