Іззат Шукуров, керівник проекту Workly. розповідає, кому і навіщо потрібен Scrum, з якими проблемами при впровадженні методики можна зіткнутися і яких результатів - домогтися.
Scrum - методологія управління проектами, яка застосовується, коли необхідно гнучка розробка. Послідовники Scrum приділяють увагу якісному контролю процесу розробки.
Сьогодні я розповім вам, як ми впровадили Scrum в роботу над нашим проектом Workly - сервісом, який допомагає оптимізувати роботу колективу.
На початку у нас було багато проблем. Основна - на процес міг вплинути хто завгодно. Керівник ставив задачу додати нову функцію, слідом приходив менеджер, обурювався, що розробники виконують не те, що потрібно, перебивав завдання ... У підсумку група професіоналів перетворювалася в виконавців. Ніхто не розумів причину слабких результатів компанії, а команда не хотіла брати на себе відповідальність за виконану роботу.
Відсутність синхронізації у менеджменту вбивало у розробників відповідальність за результат, позбавляло їх «маленьких перемог». Все це демотивована колектив в цілому - і в підсумку стало найбільшою проблемою в роботі. Команда не бачила загальних цінностей і не відчувала згуртованості.
Для вирішення цієї проблеми ми вирішили спробувати перебудувати роботу по гнучкими методологіями, а саме - по Scrum.
У проекті пов'язано багато людей: розробники, менеджери, бухгалтери, директора. Все залежить один від одного. Помилка будь-якої ланки може відбитися на клієнтах. Scrum вчить: щоб цього уникнути цього, весь штат повинен синхронізувати свої дії один з одним.
Чому було обрано Scrum? Він допомагає швидко реагувати на зміни ринку. І так як наш проект - стартап, йому була потрібна гнучкість, передбачуваність і продуктивність.
Крім того, Scrum дозволяє швидко і на постійній основі видавати результат, який буде задовольняти замовника.
Початок. Як переходити на Scrum?
Ми не могли відразу впровадити Scrum - команда була до цього просто не готова. Грунт довелося готувати поступово - кожне нововведення з'являлося поетапно, як вирішення проблеми, а не як правило.
З чого потрібно починати?
1. Прибрати побоювання
При впровадженні Scrum може виникнути проблема - команда з побоюванням сприймає нововведення, люди не розуміють, навіщо це потрібно. Якщо ви ставитеся до команди не як до купки виконавців, а як до групи фахівців, потрібно пояснювати їм, для чого створюються нові умови і який у цьому сенс.
2. Підвищити значимість окремої людини
Дуже важливо, щоб люди відчували себе командою, а не виконавцями. Чи не ділили колектив на «ми» - команда, і «вони» - керівники.
Ми працювали над викоріненням позиції: «я - програміст, і я нічого не хочу вирішувати». Хотіли мотивувати людей використовувати свій творчий потенціал.
3. Визначити головну мету і цінності компанії
Ми визначили мету - створити якісний сервіс, який працює стабільно і допомагає людям. Цінності команди дозволили всім ставитися до завдань відповідально. У розробників з'явилося розуміння, що вони не просто пишуть код, а надають нове рішення.
4. Позбутися від позапланових завдань
Як ми позбулися завдань, що надходять хаотично? Вимога була одна - залишити одного посередника між керівництвом і командою. На виконання цього пункту пішло три місяці, але в підсумку завдання стали надходити від однієї людини, вони були затверджені і ставилися в порядку пріоритету.
5. Вміти говорити начальнику "ні"
Частина часу пішла на те, щоб навчитися говорити «ні» керівництву. Це було важко. Не всі вміли і були готові говорити «ні» начальнику або старшому колезі. Але навчитися відмовлятися було важливо, щоб люди не брали на себе відповідальність за завідомо нездійсненне завдання, яку треба зробити в стислі терміни і з певними вимогами до якості.
невеликі складності
Процес підготовки до переходу на Scrum зайняв дев'ять місяців. Звичайно, не обійшлося і без складнощів. За великим рахунком, їх було тільки дві: деякий опір відкритості методології з боку співробітників і небажання вести постійний звіт в обраному нами Trello.
Опір виникало на перших порах, через відсутність довіри до скрам-майстру. У команди виникало помилкове відчуття, що, розкриваючи реальний відсоток виконаної роботи, вони будуть перевантажені завданнями. Ця складність вирішувалася через коуч кожного співробітника, пояснення суті методології і цілей роботи.
Поступово співробітники стали розуміти, що така відкритість дозволяє не відволікати їх від роботи, що не перепитувати про результати щогодини і встановлені завдання спринту незмінні - якщо співробітник закінчив свою частину роботи, він при бажанні може допомогти колезі, але йому не додасться додаткових завдань, щоб він «не сидів склавши руки».
Складніше було з постійною звітністю в Trello - співробітники просто забували відзначати готовність процесів в чек-листі і перетягувати картки по проектам. Але в результаті постійного нагадування і ретельних пояснень, чому це необхідно, команда звикала до цих рутинним процесам і стала виконувати їх без зайвих розмов.
перші результати
Команда була готова до роботи з методологією тільки після того, як ми забезпечили умови для роботи:
- Один посередник між керівництвом та розробниками,
- Умовний термін на виконання завдань,
- Зацікавленість в результаті кожного,
- Фокусування на своїх цілях і цінностях.
У команди з'явилися цінності. Ось які цінності ми визначили:
Ми вирішуємо завдання, а не пишемо код.
Якщо правило заважає нам бути ефективними - ми від нього відмовляємося.
Ідеальна завдання виглядає як потреба, а не як вимога. Ми самі вирішимо, що і як робити, щоб вирішити задачу.
Ми чесні один перед одним - і тому довіряємо.
Кожен робить все, що від нього залежить, настільки добре, наскільки може, і з тим, що має в ситуації, що склалася.
Ми не шукаємо винних, ми шукаємо найкращі шляхи вирішення проблеми.
Ми намагаємося не повторювати помилки, ми не соромимося їх. Помилки - це наш шлях до поліпшення себе і нашого продукту.
Нам як професіоналам довіряють завдання, а ми вибираємо шляхи вирішення - і тому несемо відповідальність за результат, беручись до роботи.
Ми не говоримо «здається / по ідеї / теоретично, це працює так», ми говоримо - «це працює так».
Якщо потрібно вирішити проблему, ми встаємо і вирішуємо, ми йдемо і запитуємо, ми говоримо про проблеми відкрито - тому що не хочемо згодом шукати винних.
У підсумку ми правильно розставили пріоритети і вказали мети, яких команда реально зможе досягти. Співробітники стали розуміти, коли продукт буде володіти тими чи іншими характеристиками. З'явилася двотижнева фокусування на єдиній меті, яку не можна змінити.
Зараз команда, використовуючи будь-які підручні інструменти Scrum, надає готовий продукт в строго певні проміжки часу. Завдяки обмеженій кількості осіб, розробники максимально сфокусовані на цілі. Розуміючи обмеження за часом, команда не витрачає його даремно, грамотно формує спринт і кожен раз отримує свою маленьку, командну перемогу.
Як змінився формат роботи?
- Дві години на планування спринту. Надходить завдання і визначається тривалість спринту.
- За 15 хвилин в день на Scrum-стендап. Кожен член команди розповідає про виконання завдань, що виникають проблеми і варіантах їх вирішення.
- Півтори години презентації в кінці спринту. Ще один важливий інструмент в методології, тонізуючий команду і дозволяє пишатися своїми результатами.
- Ретроспектива після презентації. Командна робота над помилками, в процесі якої з'ясовуються причини, чому спринт пройшов не так гладко, як очікувалося, і що заважало ідеальну роботу. Важливо, щоб під час спринту всі члени команди були максимально відвертими і чесними один з одним.
- У методології Scrum взагалі важлива взаємозамінність членів команди. Особливістю нашого робочого процесу стала ротація розробників між відділами - завершивши роботу в одному проекті, співробітник (при бажанні) може перейти в інший проект і поділитися наявним досвідом. У підсумку всі члени команди готові були вирішувати надходять проблеми, стали організованими і взаємозамінними.