Конкуренція в IT-сфері потребує оперативності та ефективності. Клієнти хочуть одержати оптимальні рішення за короткий термін. Як організувати команду розробників, щоб рівень продуктивності та мотивації зашкалював, а терміни дотримувалися?
Спробуйте гнучку методологію управління проектом SCRUM.
SCRUM робить комунікацію у команді ефективною, мотивує розробників і всі учасники процесу якісно взаємодіють між собою. Крім того, методологія дозволяє оперативно вирішувати проблеми, які з'являються «по ходу справи». Це підвищує якість фінального продукту.
Конкуренція в IT-сфері потребує оперативності та ефективності. Клієнти хочуть одержати оптимальні рішення за короткий термін. Як організувати команду розробників, щоб рівень продуктивності та мотивації зашкалював, а терміни дотримувалися?
Scrum для вас, якщо...
Найбільше методологія підходить для проєктів, що вимагають кастомних технічних рішень (мобільні додатки, великі веб-ресурси). А команда має бути самоорганізованою і багатофункціональною.
Продукт розробляється за SCRUM невеликими ітераціями - спринтами. І в цій системі є ролі, які допомагають бігти спринт максимально ефективно.
Хто це: PO, SM DT?
Product owner (PO) — людина, яка знається на бізнес-логіці продукту. Як правило, це представник клієнта. PO бачить кінцеву мету, як, наприклад, мобільний додаток працюватиме у користувачів. Він спілкується з ЛПР та доносить інформацію команді розробки.
Саме PO формує список завдань для команди та проекту (Product Backlog). Всі завдання виставлені за пріоритетами, яким слідує команда.
Scrum master (SM) — це лідер команди та фасилітатор. Він займається мотивацією, максимізує ефективність команди, працює над усуненням перешкод, допомагає розробникам. Перед кожним новим спринтом SM формує Sprint Backlog на основі Product Backlog. Простіше кажучи, лідер команди розбиває завдання від PO на дрібніші, які в кінцевому підсумку приведуть до результату.
Команда розробки (Development team, DT) складається з фахівців, які працюють над продуктом.
Ключові моменти для DT:
- Розробники вільні у прийнятті технологічних рішень. Команда самостійно вирішує, як саме вона виконує завдання від PO та SM.
- Вся команда відповідає за виконання завдань, а не індивідуальний розробник.
- Оптимальна кількість людей у команді — плюс-мінус 6 осіб. Більше — розрив у комунікації, менше — збільшення обсягу роботи на одну людину.
- Взаємозамінна команда, що самоорганізується.
Sprint — як це працює?
Щойно з ролями визначилися, починаються спринти. Sprint — короткий забіг, обмежений часом та списком завдань для команди. Зазвичай спринт триває від 1 тижня до місяця, багато в чому залежить від складності проекту. Поки команда дістанеться точки A до кінцевої версії продукту B, пройде кілька спринтів, а то й десятки.
Навіщо це? Хіба не можна відразу чітко сформувати фінальне бачення продукту?
У цьому є головна перевага SCRUM — щодня команда зустрічається на “Daily” зі скрам-майстром. Всі розробники обмінюються інформацією про те, як іде робота, що зробила особисто кожна людина, що вона зробить завтра.
Такі зустрічі є відмінною мотивацією, сприяють розвитку командного духу, дозволяють миттєво вирішувати проблеми.
На завершення спринту всі зустрічаються на "demo" і представляють результат роботи.
Наприкінці спринту команда зустрічається на Ретроспективі. Там обговорюються і генеруються нові рішення, аналізуються успіхи і невдачі. Головне - піти з набором рішень, а також розумінням, що можна поліпшити.
А з "понеділка" починається новий спринт, з новим пакетом завдань. Це дає змогу постійно апдейтити фінальний продукт. Плюс Scrum дає нам потенційно робочий продукт наприкінці кожного Sprint'а.
Важливий момент: Sprint Backlog не можна доповнювати новими завданнями до кінця спринту. Це дає чіткий фокус команді та усуває можливість "навішувати" завдання протягом двох тижнів. Кожен розробник чітко бачить своє завдання і працює над ним, самоорганізовуючись.
Як оцінювати ефективність?
Отже, у нас є Product Backlog - завдання, які потрібно виконати, а PO має фінальне бачення продукту. Що ще потрібно, щоб зрозуміти, що розробники зробили все правильно?
Щоб переконатися, що все зроблено добре, аналітики в команді пишуть тести за кожним завданням. У них детально описано, який результат має вийти. Простіше кажучи, в них описано на яку кнопку натиснути, і що при цьому вийде.
Окремі тести пишуться на кінець кожного спринту, дуже докладно, щоб оцінювати ефективність за два тижні.
Переваги методології
Scrum орієнтований на клієнта. У день завершення чергового спринту ви можете запросити замовників, показати результати роботи, а клієнт оновити свої вимоги. Дати можливість замовнику відчути себе частиною процесу розробки - чудова конкурентна перевага.
Цікавинки - Покер-планування
У процесі планування спринту потрібно оцінити завдання і виділити на них час. Він обчислюється в StoryPoint'ах. Фактично це оцінка складності завдання.
У великих IT-компаніях широко поширений досвід покер-планування.
У кожного члена команди є колода карт. Кожна карта має свій номінал - це по суті і є StoryPoint'и. І після обговорення будь-якого завдання, всі "гравці" викладають 1 карту, яка на його думку відображає складність виконання.
Потім гравці, які виклали максимальну і мінімальну "ставку" аргументують свій вибір. Після цього обговорення процедура повторюється доти, доки думки не зійдуться. Боїтеся серйозних витрат часу? У "грі" є суворий регламент.
Якщо детально і чітко дотримуватися ідеології Scrum, команда буде максимально вмотивована (щоденні мітинги зі звітами про процес виконання), усі члени команди бачитимуть прогрес і кінцеву точку (візію) продукту. Проблем із комунікацією не буде, а всіх дедлайнів дотримуватимуться.
Для більшого занурення в SCRUM рекомендуємо прочитати книгу "SCRUM . Революційний метод управління проєктами" Джеффа Сазерленда.
