Життєвий цикл розробки програмного забезпечення. Частина 2
Сьогодні на уроці:
- Методологія розробки програмного забезпечення. Scrum та Kanban
- У чому різниця між Scrum та Kanban?
- Коментар від автора
Методологія розробки програмного забезпечення. Scrum та Kanban
Вибір моделі Agile SDLC сам не є кінцем історії. Залежно від проекту та компанії ви вибираєте фреймворки у рамках методології. Наприклад, Scrum та Kanban – це два типи гнучкої методології розробки програмного забезпечення. Вони обидва дозволяють розбивати складні завдання на дрібніші частини, які потрібно ефективно виконати за допомогою постійного покращення та оптимізації роботи. Обидва надають великого значення прозорому та ясному робочому процесу.
У Kanban немає ні тимчасових інтервалів під кожну задачу чи ітерацій, ні встановлених ролей – вони розвиваються відповідно до потреб проекту та організації. Ця структура може бути надто вільною для деяких компаній, але якщо ви відчуваєте, що потрібно покращити процеси, спробуйте Kanban, що допоможе подивитися на завдання з абсолютно нової точки зору.
У чому різниця між Scrum та Kanban?
Основу Scrum становлять короткі ітерації чи спринти, зазвичай, 2-3-х тижневі. Перед початком спринту команда сама формує список фіч на ітерацію, далі запускається спринт.
Після закінчення спринту виконані фічі заливаються на продакшн, а невиконані переносяться в інший спринт. Як правило, фічі, які робляться під час спринту, не змінюються: що було на старті спринту — має бути зроблено за будь-яку ціну до закінчення спринту.
На Kanban ми подивимося там, де він і з'явився. Уявіть конвеєр, на якому роблять деталі для машин Toyota. Є верстат, він робить дзеркала для машин. Він вміє робити ліві дзеркала, праві дзеркала, задні та дзеркала для сонцезахисного козирка. Принцип простий: натисніть на кнопку, поміняй режим — отримай нову продукцію.
Основна різниця між Scrum та Канбан — у довжині ітерацій. У Scrum ітерації – 2 тижні, у Kanban завдання програмісту можна «підсовувати» хоч щодня.
Kanban дає більше гнучкості, якщо під гнучкістю розуміти частоту зміни пріоритетів. Вчора ви залили на продакшин нову фічу, а сьогодні отримали дані з передової і дізналися, що ця штука не працює так, як було задумано — люди не натискають кнопку «купити». Ви "даєте по шапці" UX, він дає вам нові вимоги. Ви піднімаєте нагору черги це завдання, програміст бере це завдання «згори», виконує його і, до вечора fix вже на продакшені, конверсія в платежі зросла на 12%. Це перемога.
У Scrum завдання прийнято оцінювати в Story points або годинах. Без оцінки не вдасться сформувати спринт: нам потрібно знати, чи встигнемо ми зробити завдання за 2 тижні. Через 2 тижні ми отримуємо цінну статистику — скільки годин чи Story points команда змогла зробити за спринт. Velocity – це продуктивність команди за один спринт. Цей параметр дозволяє Scrum менеджеру передбачити, де команда буде за 2 тижні.
У Kanban не прийнято робити оцінку. Це опціонально, команда вирішує сама. Тут немає поняття "швидкість роботи команди", а лише середній час на завдання. Час розраховується за допомогою спеціального звіту Cycle Time.
Cycle Time для задачі = час виконання завдання мінус час початку роботи над завданням. Наприклад, у вас є колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для завдання дорівнюватиме deployed-developing, тобто скільки часу пройшло від моменту, коли завдання почали виконувати до моменту поки вона потрапила в deployed.
Отже, у Scrum наша мета – закінчити спринт, у Kanban – завдання.
#devnote
Отже, зараз в роботі у командах найчастіше зустрічаються ці дві методології: Kanban та Scrum, тому рекомендую в першу чергу з ними ознайомитися ближче.
По більшій мірі, дана тема потребує особистої практики ("поклікати", спробувати що куди йде, яка послідовність і як працює).
Коли буде апдейт цього матеріалу у формат відео, я продемонструю на практиці, як це все працює. Але вже зараз рекомендую вам ознайомитися з існуючими відео в YouTube по цій темі (щоб закріпити прочитане сьогодні).
Мова про прості та зрозумілі відео на кшталт цього: лінк
Або ж взагалі про офіційну документацію (хардкор рівень): лінк
На жаль, допоки наші україномовні відео ще не готові, вам потрібно проявити свою навичку самостійності та знайти відеоурок для детальнішого розуміння окремих речей, котрі ми зачіпаємо. Але все буде, рухаємось крок за кроком!
На цьому поки з вами прощаюся, післязавтра опублікую декілька вікторин з питаннями та відповідями стосовно сьогоднішнього матеріалу. До того ж часу, якщо у вас є конструктивні запитання щодо матеріалу, ми можемо поспілкуватися з вами у чаті.
Група в телеграмі: https://t.me/ruby4you
Автор курсу: Шкоропад Даниїл
