Про те, що таке Scrum і з чим його їдять написані мільйони статей. Однак більшість з них припускають, що до скрама існує якийсь вакуум, або навпаки жорстке середовище з веденням процесів по PMBOK та ін. Безліч авторів пишуть про «нульовий спринт» в проекті, що починається, про підбір ідеальної команди, про вибір довжини спринту, проте свого часу я не знайшов великої кількості статей про впровадження Agile методологій в існуюче середовище, в якому до цього не було методологій, але вже були сформовані традиції.
Два з половиною роки тому, коли ми з командою (точніше її тоді ще не було) починали розробляти наш продукт, ми не замислювалися про методології, процеси та інші, що здавалися нам тоді не потрібними, бюрократичні питання. Час минав, продуктів ставало більше, команда росла. Поступово, всі почали розуміти, що утворюється якийсь хаос, який все складніше контролювати, а головне, який серйозно обмежує наші можливості. Насправді, непомітно для нас ситуація наближалася до критичної.
Під катом довга реальна історія впровадження Scrum у процес розробки, який переживав не найкращі часи. Сподіваюся ця історія буде вам цікава і, можливо, допоможе вам вирішитися або вирішити якісь проблеми.
Щоб краще оцінити ситуацію:
Трохи про те, хто ми
Ми, технічна команда компанії Sputnyx, розробляємо комплекс систем для автоматизації роботи з інтернет рекламою. На даний момент ми повністю покриваємо потреби клієнтів з управління контекстною і таргетованою рекламою, а також пропонуємо ряд дрібних інструментів для автоматизації рутинних завдань.
Команда складається з п'яти осіб (1 фронт, 3 бека і я - менеджер продукту) + один DevOps інженер, що забезпечує нас першокласним налаштуванням серверів.
Також є окрема команда з розробки нашої RTB платформи, але в даній розповіді вона не фігурує.
Отже, ситуація:
Осінь 2014. Команда підтримує дві невеликих системи і активно розробляє три інших, об'єднаних в один комплекс із загальною архітектурою. По суті це навіть не команда. У процесі розробки, історично склалися люди відповідальні за кожну систему і тільки нею займаються. Підтримкою двох маленьких систем і розробкою однієї займається один програміст, ще дві системи розподілені по двом іншим членам команди і, нарешті один фронтендер займається розробкою єдиного інтерфейсу, який можуть використовувати всі системи.
Кодова база на той момент становила вже сотні тисяч рядків, тестів була мінімальна кількість, автоматизації ніякої. У Git-e використовувалося дві гілки master на продакшені і dev в розробці, природно було безліч проблем при великих зливаннях і т. д. Поступово швидкість впровадження нових фіч впала практично до нуля. Керівництво просило хоч якось оцінювати терміни, але по суті, будь-які оцінки були пальцем у небо.
Великою проблемою було ще й те, що ми не могли навіть якось балансувати між проектами і пріоритетами. При спробі виділити більше людей на систему А, призупинивши, наприклад розробку системи B, ми стикалися з тим, що програміст абсолютно не знав чужий код, слабо представляв бізнес-завдання системи і, по суті, гальмував розробку ще на довгий час.
Чому все було так погано? Все просто. Коли ми починали, головним було зробити все швидко, а як відомо в гонитві за швидкістю завжди страждає якість. У глибині душі кожен розумів, що це неправильно, але здавалося, що немає часу подумати про це. Так, ми самі винні, але що є, то є.
Було зрозуміло, що треба щось змінювати.
Початок
Ідея використання Scrum давно витала в повітрі. Основні її переваги були рівно такими, як нам потрібні: короткий релізний цикл, гнучкий беклог, швидкий зворотний зв'язок. Однак існували і проблеми. По-перше, у нас хоч і один комплекс, але різних систем, у кожної свій беклог, свої пріоритети і немає можливості забезпечити кожну систему своєю командою. По-друге, програмісти дуже інертний клас співробітників, вони звикли працювати, як раніше і, хоча й самі розуміли, що не все гладко - побоювалися кардинально щось змінювати. По-третє, Scrum - це не тільки ведення проекту, це автотести, CI, чистий код і багато чого з того, що у нас на той момент не було.
Але час настав, було зрозуміло, що зволікати більше не можна і ми почали готуватися до того, щоб глобально змінити те, як ми працюємо.
Впровадження
Для початку, потрібно було вирішити головну проблему, без якої ніякі наступні кроки не представлялися можливими.
Обмін знаннями
До цього ми готувалися довго. Доробили всі великі завдання, які на той момент були розпочаті, склали описи бізнес-функцій систем, а кожен розробник підготував розповідь про тонкі або неочевидні місця в його коді.
Коли все було готово, ми на два тижні призупинили будь-які нові розробки, тільки під фіксинг і тільки в крайніх випадках. За два тижні кожен член команди презентував свій код, а я в найдрібніших деталях розповідав про власні потреби.
Два тижні люди вивчали код, намагалися фіксувати «чужі» баги і ставили багато запитань.
Коли з цим було покінчено і кожен хоча б приблизно уявляв про що мова в кожному проекті - настав час змінювати процес.
Тут треба згадати, що на початку всього я був і Scrum майстром і Product owner. Я відмінно розумів, що це не правильно, але в той момент, просто неможливо було працювати інакше. Я єдиний з команди якісно знав принципи і правила скрама, але я ж і повинен був представляти продукт.
Процес
Якщо до цього моменту все йшло відносно добре, то тут почалися проблеми. Програмісти загалом підтримували Scrum, але коли дійшла справа до планування - почалися заперечення виду "Навіщо стільки часу витрачати на балаканину?", "Цілий день безтолку сидимо в переговорці", але звичайно самий шок був у всіх, коли я заїкнувся про Daily Scrum - "Кожен день балакати - жахливо", "Кожен сам може подивитися все в джирі/бакітбакете", якщо "",, якщо він запитає - "",, "",, "",, - ", - запитає.
Було зрозуміло, що вводити щось треба поступово, і справа тут не в тому, що процес був нав'язаний «зверху», ні, люди хотіли змін, але таке було вище їх сил.
Ми почали з введення спринтів і так, планування.
Ми об'єднали беклоги всіх підсистем в один і постаралися розставити пріоритети. Наші перші user-story представляли з себе старі таски, вони могли бути чисто технічними і тд. Оцінювали в story points, за основу взяли шкалу ступенів двійки, але звичайно спочатку оцінки різнилися в рази. Перші спринти у нас тривали тиждень, деякі не схвалювали такі короткі спринти, і таку часту «балаканину», але ті, хто мене підтримували, розуміли, навіть на тиждень ми поки не могли запланувати все точно, про великі спринти поки не могло бути й мови.
Ми почали наш перший спринт у середу ввечері і вирішили, що ретроспектива буде через тиждень у середу вранці, таким чином, вона займе півдня, потім планування і новий спринт. Ні про які демо тоді, звичайно не могло бути й мови, нам по суті нічого було показувати, крім того це ще один пункт збільшення емоційного навантаження на програмістів.
Отже, в середу вранці, прийшовши на ретроспективу ми дружно зрозуміли, що у нас в роботі ще кілька завдань зі спринту, які «залишилося трохи доробити» (насправді трохи могло означати цілий день роботи). Тут виявилася ще одна незрозумілість, на ретроспективі ми повинні були обговорювати проблеми і можливості поліпшити наш процес, але програмісти дружно заявляли, що «ніяких проблем немає». Вони не відчували, що щось не встигли, та сьогодні вони все по обговорюють, а потім закінчать. Не було відчуття циклічності процесу.
Ще кілька тижнів ми продовжували працювати в такому режимі, я намагався звернути увагу на те, що спринт це саме ітерація, а не просто відрізок на шляху. Зрештою було знайдено більш менш хороше рішення. Ми розділили ретроспективу і планування і рознесли їх на різні дні, у вівторок ретро, в середу планування, між цими зустрічами, програмісти вирішували різні RND завдання, ті, які було ще рано якось оцінювати, яке було не ясно, що робити. Але найголовніше, між ретро і плануванням було заборонено працювати над завданнями минулого спринту. Це теж спочатку не сподобалося, тому що незакінчений код залишався і забувався, проте цей захід приніс свої плоди. Команда почала розуміти, що незакінчені в спринті завдання - реально не закінчені, вони можуть бути забуті, залишені на невизначений термін і т. д.
Тим часом, треба було звернути увагу і на роботу з кодом. Раніше тести писалися тільки на ключові функції і, по суті, вони покривали вкрай малу частину коду. З цього моменту ми вирішили, що кожен шматок коду, який зачіпає вирішуване завдання, повинен бути покритий тестами. Тут теж були свої моменти, наприклад на плануванні перші спринтів п'ять, треба було часто нагадувати при оцінці «А з тестами це завдання скільки балів займе?». Але це впроваджувалося все-таки досить просто, всі занадто добре розуміли навіщо це треба.
Іншою великою бідою стало те, що незважаючи на два тижні вивчення, люди все-таки погано знали «чужі» проекти.
По-перше, на плануванні завдання по проекту А людина, яка його розробляла оцінювала в 4 бали, а решта в 16 і 32. Доводилося довгий час пояснювати, що оцінка повинна враховувати те, що завдання може опинитися у людини, яка раніше з цим проектом не працювала.
По-друге, розробники стали активно користуватися тим, що Scrum пропонує членам команди самим вибирати собі завдання. Таким чином, програміст зазвичай намагався взяти собі завдання по «своєму» проекту, щоб не заморочуватися з чужим кодом. На кілька тижнів, нам довелося вести правило, що тобі заборонено брати завдання зі «свого» проекту, якщо на дошці є інші. Було невдоволення, але, треба сказати, воно швидко зійшло нанівець, як тільки люди достатньо вивчили весь код.
Але звичайно головне і, безумовно найкраще, що сталося під час цього переходу, так це те, що кілька хороших хлопців, які раніше просто працювали за одним столом, нарешті стали ставати командою. До цього вони, хіба що разом ходили на обід, та й то рідко, а тут стала виникати реальна взаємодопомога, спільна робота і відповідальність.
Розвиток
Повільно, але вірно, ми рухалися в бік правильного і хорошого процесу, який допомагав нам працювати.
Через пару місяців ми ввели Daily Scrum (стендап), призначили його на 12:00, тому що до цього часу зазвичай всі вже були на роботі (у нас дуже гнучкий графік). Довгий час на стендапі кожен просто називав завдання над якими працював, і це було не дуже корисно, але пройшов якийсь період адаптації і команда стала реально обмінюватися корисною актуальною інформацією про проблеми і прогрес.
Спринти стали двотижневими, ми навчилися краще оцінювати завдання і змогли собі це дозволити. Оцінки на плануванні стали збігатися в більшості випадків, а коли вони не збігалися ми могли все обговорити і, найчастіше, прийти до спільної думки.
Відсоток суто технічних завдань у беклогу став поступово падати. І все частіше завдання представляло з себе саме User Story.
Слабким місцем в процесі, все ще була ретроспектива, на більшості з них команда не могла запропонувати тем для обговорення. «У нас все добре» - досить поширене твердження. Виконуючи роль Scrum майстра, я прочитав велику кількість матеріалів на цю тему і став використовувати деякі методики, однак є все-таки велика різниця між теорією і практикою, наприклад стандартний метод пошуку кореневої проблеми - дуже хороший, але на практиці, він показував, що у нас є проблема в неподільності деяких завдань, про яку ми і так знали, але жоден хитрий метод не міг нам допомогти вирішити цю проблему. Однак все-таки з часом у хлопців почала проявлятися ініціатива, яка безумовно була вкрай корисна.
Ми стали використовувати Git Flow, налаштували Jenkins щоб проганяти автотести при кожному кімміті, стали міряти покриття коду і намагатися його покращувати. Кількість хотфіксів, які на початку могли займати пів спринту, стала скорочуватися. Якість продукту, а головний настрій наших користувачів суттєво покращився. Ми проаналізували де у нас слабкі місця в процесі розробки і придумали як вчинити з довгими Code Review.
Наші дні
Минуло більше півроку з тих пір, як ми почали цю епопею. Сьогодні ми все ще розвиваємося і збираємося робити це завжди. Проте вже можна сказати про результати.
- Ми працюємо однією командою над усіма завданнями, а значить, якщо хтось захворіє - жоден проект не залишиться без підтримки.
- Швидкість розробки в кількості впроваджених фіч за період часу зросла в кілька разів, якщо порівнювати з осені минулого року.
- Кількість багів і хотфіксів, на даний момент у нас від нуля до одного за спринт, що говорить про те, що якість системи збільшилася на порядок.
- За ці півроку ми розгребли беклог від накопичених завдань, прибрали зайве і зараз це повноцінний динамічно-мінливий список фіч, які ми реально впровадимо в найближчий квартал.
- Крім цього, завдяки реалістичним оцінкам, ми, знаючи швидкість команди, можемо будувати більш довгострокові плани і розраховувати, що приблизно зробимо в наступні півроку.
Попереду у нас ще багато роботи над собою. Нещодавно ми нарешті дійшли до того, що пора ввести демо, подивимося до чого це призведе. Крім того, ми розуміємо, що ми просто далекі ще від ідеалу і можемо працювати на порядок швидше і намагаємося цього досягти. Однак головне, що я можу сказати, що ніхто з команди не шкодує про те, що ми почали це, і незважаючи на багато труднощів, багато з яких, можливо були пов'язані ще й з нашою недосвідченістю в agile процесах, ми-таки досягли порядку в процесах і реально врятувалися з ситуації, в яку нас завели гонитва за швидкістю і острах бюрократії.
Спасибі за прочитання, буду радий відповісти на будь-які питання, а також прийняти будь-яку критику.