Налаштування процесу у великій команді, або як ми прийшли до Scrum. Частина 3

У другій частині ми спробували покращити основні складові процесу розробки. Тепер нам потрібно об’єднати всі ці кроки

в один процес і забезпечити його неперервність.

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

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

Давайте розглянемо дві стратегії подальшого розвитку процесу.

Стратегія 1

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

Тобто таск А пройшов шлях To Do -> Dev -> Test -> Done.

Ми б хотіли забезпечити найшвидше проходження завдання від To Do до Done. Для забезпечення якості ми би хотіли
виконувати оптимальне число завдань одночасно.

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

Нехай у нас в команді є 4 розробники та 2 тестувальника. Теоретично, ми можемо взяти одночасно в роботу 4 завдання
в розробку і при цьому 2 завдання в тестування. Однак на практиці ми повинні не забувати, що всі завдання мають різну
складність і потребують різної кількості часу для виконання. А тому завантажуючи всіх розробників різними завданнями
ми ризикуємо опинитись в ситуації, коли деякі задачі будуть виконуватись не оптимально довго.

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

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

Думаю багато хто вже побачив, що ми отримали процес, схожий на Kanban.

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

Це прекрасний підхід, який перевірений багатьма командами. Однак не всім він підходить.

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

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

Стратегія 2

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

Як змінити Kanban таким чином, щоб по ньому з легкістю могли працювати Juniors і при цьому ми би не втрачали у
швидкості? Нам потрібно робити вибірку по пріоритету і складності. Або розбивати великі складні задачі на підзадачі.
Таким чином над однією задачею будуть працювати декілька розробників.

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

Тут напрошується наступні кроки:

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

Такий процес вже дуже схожий на всім відомий Scrum.

Scrum - це не методологія, а так званий Framework - тобто набір функціоналу та певний workflow, які можна
використовувати from the box, або модифікувати до своїх задач.

У термінах Scrum:

• замовник - це Product owner(PO), він відповідає і є власником Backlog. Він і лише він виставляє пріоритети і апдейтить завдання. Для кожного завдання у беклозі, PO обумовлює так званий Definition of Done.
• Ітерація - це Sprint, яка кожного разу має фіксовану тривалість - найбільш популярні - це 2 або 3 тижні, однак зустрічаються спрінти довжиною в 1 тиждень та місяць.
• Беклог ітерації - це Sprint Backlog, який заповнюється на плануванні, на якому бере участь вся команда та PO. Команда сама розбиває великі задачі на підзадачі, обговорює бізнес логіку, задає питання PO, оцінює складність виконання завдань. Sprint Backlog є фіксованим впродовж ітерації.
• Щоденні статус мітінги для синхронізації  - це Daily Scrum і проводиться постійно на щоденній основі для синхронізації роботи всієї команди.
• В кінці кожної ітерації виконані задачі демонструються PO - це так зване Sprint Demo.

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

Висновки

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

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