Agile в роботі з аутсорсом

Мене звати Ілля Кітанін, я керівник групи розробки Cofoundit — сервісу для пошуку співробітників в стартапи. Сьогодні я розповім, як за допомогою статистики і принципів agile-методології максимально ефективно працювати зі сторонніми розробниками, не переплачувати і не вибиватися з графіка.

image

Бекграунд і підготовка

З березня 2016 року Cofoundit працював в ручному режимі: ми самі підбирали співробітників і співзасновників в стартапи і вивчали потреби користувачів. Зібрали вимоги і в червні приступили до розробки сервісу. Два місяці пішло на створення прототипу і ще місяць на доопрацювання фінальної версії. Ми почали працювати над продуктом в середині червня, у серпні випустили закриту бету, в кінці вересня — офіційно запустилися і продовжуємо роботу.

З самого початку в якості методології я розглядав тільки agile. Перший тиждень ми присвятили планування: розбили завдання на невеликі таски, спланували спринти, кожен довжиною в тиждень. Більшість завдань вкладалося в один спринт, але спочатку деякі займали і два, і три.

Перші спринти були відверто невдалими — ми затримали реліз на тиждень і почали відставати від графіка. Але цей досвід допоміг нам правильно оцінити терміни та відмовитися від надлишкового функціоналу. Спочатку ми хотіли зробити сервіс з симетричним пошуком: щоб і фахівець, і проект могли переглядати анкети один одного і починати спілкування. У результаті В роботі залишилась тільки перша частина: кандидат може переглядати і вибирати анкети стартапів, а проект бачить тільки тих спеціалістів, які вже виявили до нього інтерес. Тобто по суті ми запустили мінімальний життєздатний продукт.

Управління ефективністю
З допомогою «Джиры» і плагіна Time in status я постійно стежив за тим, як працює команда, і скільки часу займає життєвий цикл завдання. Я вважав час п'яти основних етапів: розробки (з моменту створення тягаючи до відправки на рев'ю), рев'ю коду (відбувається на боці команди аутсорса), деплой, тестування й твердження (з боку сервісу, тобто мною).

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

image

За результатами роботи у липні я звернув увагу, що завдання найдовше перебувають у трьох статусах: в роботі, на тестуванні і на рев'ю. Простіше всього було вирішити проблему тривалого тестування. Тестувальник в нашій команді працював part-time і просто не встигав оперативно тестувати всі завдання. Ми поговорили з підрядником і перевели його в проект на full-time. Це скоротило час тестування в два рази.

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

В другу чергу я почав розбиратися з затримками на етапі розробки. При тижневих ітераціях я не міг дозволити задачі висіти в роботі п'ять днів (весь спринт). До фінального релізу хотілося як мінімум кілька разів подивитися функціонал в роботі. Я вирішив проблему, розділивши завдання на більш дрібні.

За результатами серпня ми відставали за показником «Час на рев'ю» з боку команди аутсорса. Спочатку я постійно нагадував виконавцю, що він повинен подивитися код і дати коментарі. В листопаді я передав цю обов'язок тестировщику. З цього моменту, як тільки він закінчував роботу над завданням, він сам сповіщав відповідального за рев'ю. Повністю ми реалізували такий підхід лише в листопаді, коли деплой на тестовий сервер став займати менше часу.

У вересні слабкими показниками були «Затвердження» з боку команди сервісу і «Очікування деплоя на тестовий сервер». «Приймання» вдалося прискорити просто більш пильною увагою і швидким реагуванням на завдання. До того ж до цього часу процес розробки вже увійшов в ритм, і вже не так багато мого часу йшло на підтримку.

Час деплоя на тестовий сервер у вересні займало більше 15% — це було надзвичайно дивно. З'ясувалося, що після проведення рев'ю завдання її викладав на тест останній виконавець. Потрібно було мержить гілки, іноді виникали конфлікти, виконавець відволікався від поточних завдань. У жовтні ми прикрутили до дерева механізм автоматичного викладання завдань, що сильно скоротило час деплоя. Потім ми налагодили процес і в результаті за два місяці скоротили час на деплой у 8 (вісім!) раз.

Отже, за п'ять місяців ми скоротили час вирішення завдання майже в чотири рази. Раніше шлях від постановки завдання до затвердження результату займав у середньому 20 календарних днів. Тепер, коли термін скоротився до п'яти календарних днів, стало простіше контролювати етапи розробки, оцінювати підсумкові терміни вирішення завдань і планувати завантаження команди.

Прогнозування термінів
Інша важлива задача — точна оцінка термінів. За умовами договору з підрядником мені загалом було невигідно потрапляти в оцінку. Якщо завдання робилася швидше, ми платили тільки за витрачений на неї час, а якщо команда не вкладалася в строки, то ми платили менше.

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

Я порахував відсоток точності, з якою кожен програміст потрапляє в оцінку. В результаті я отримав коефіцієнти, які допомогли точніше планувати терміни. Наприклад, якщо програміст оцінив завдання 10 годин, але його коефіцієнт помилки близько 40%, то я можу сміливо вважати, що на завдання піде 14 годин. Профіт.

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

Тому я вважав не тільки середнє відхилення в оцінці термінів для кожного розробника, але і відсоток відхилення від середнього. Якщо він був менше 20%, я вважав це хорошим результатом — така похибка в термінах не заважала мені планувати. Але були відхилення і 30%, і 50%, і вони сильно заважали роботі над релізом.

Наприклад, розробник оцінював терміни виконання в 10 днів, його стандартне відхилення від строків 40%, оскільки реальний термін виконання завдання стає 14 днів. Але якщо відхилення від середнього складе 50%, то це ще 7 днів роботи над завданням. Отже, термін роботи становитиме 21 день замість обіцяних 10 і очікуваних 14. З такими запізненнями неможливо працювати, тому я намагався знайти їх причину і виправити.

image

У «Джире» я проаналізував запізнення та їх причини — зробив висновки, що більше відхилення від планового часу припадає на завдання, які не проходять апрув у мене, і які тестировщик по кілька разів повертає після тестування.

Спочатку я виправив ситуацію з завданнями «приймання». Основна причина повернення полягала в тому, що тестувальник недостатньо аналізував завдання. Під час тестування він діяв «за обставинами», а іноді і зовсім не розумів, як повинна працювати функція. Вирішили, що тестувальник буде готувати Definition of done (DoD) до кожної задачі: не докладні тест-кейси, а приблизний опис того, що і в якому напрямку він буде дивитися.

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

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

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

Для складних завдань ми прийняли рішення проводити дзвінок з розробником, тимлидом і тестувальником. Я коментував документацію і докладно розповідав, що саме і як я хочу, щоб було реалізовано. Якщо команда розробки бачила якісь недоліки на цьому етапі, ми відразу вносили зміни в документацію. У таких випадках оцінкою термінів займалося мінімум дві людини — розробник і тимлид.

За чотири місяці середня помилка при плануванні зменшилася в 1,4 рази. Кількість відхилень більше 50% від середньої помилки скоротилася з 9% до 1%.

Збір і аналіз статистики допоміг мені вчасно побачити слабкі місця і виправити помилки управління командою. Якісь з них могли статися і у «домашніх» розробників, якісь- особливість роботи з аутсорсом. Сподіваюся, принципи роботи з внутрішньою статистикою стануть в нагоді і вам.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.