Худий Scrum краще доброго Agile

Залп скосив 50 офіцерів і 760 рядових. Французи подалися, запанікували і — звернулися до втеча. «Тут наші справи пішли не зовсім добре», — описує цей момент битви офіційна французька депеша.
Келлі Дж. Порох. Від алхімії до артилерії.

Формування Scrum команди завжди сполучено з багатьма труднощами. Майже всі справляються з тим, щоб змінити порядок робочого процесу і почати проводити деякі з необхідних по Scrum подій. Але отримати від цих формальних змін видиму користь і почати дійсно змінювати робочий процес вдається меншості. В результаті у команди формується наступне думка про Scrum: “Ми марно витрачаємо час на мітинги. Scrum не працює. Потрібно щось міняти".

Намагаючись якось врятувати становище, активісти Scrum згадують, що Scrum — це ж ще і framework. Оголошується нова стратегія: “Ми не тільки Scrum, ми ще й Agile! Ми використовуємо best practices, беремо з Scrum тільки найкраще, те, що підходить конкретно для нашої ситуації, а все інше зайве і необов'язково". А раз так — "Ми — молодці і все робимо правильно".




На жаль, таке «спасіння Scrum» — це глухий кут. Пішовши по легкому шляху, позбувшись від складних елементів Scrum, не намагаючись самостійно шукати і вирішувати проблеми, копіюючи прийоми з випадково подвернувшихся під руку статей, можна побудувати якийсь процес. Але не Scrum. Scrum Guide, End Note: "Scrum's roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum".

Scrum — це дійсно Framework, але не в тому розумінні, як це слово зазвичай розуміють в розробці. Scrum — це каркас, фундамент, основа робочого процесу. Всі елементи Scrum задумані взаємно доповнювати і підтримувати один одного. При цьому вони не дублюються. В Scrum немає запасу міцності. З цього все, що описано в Scrum Guide обов'язково до реалізації, Scrum не можна нічого викидати. Але можна і потрібно розширювати.

Scrum Guide визначає робочий процес в загальних термінах, оскільки у кожної команди є своя специфіка, і універсального імперативного рішення для всіх немає і бути не може. Кожна команда повинна знайти найкращий спосіб організації конкретно своєї роботи по Scrum. Децентралізовані команди можуть проводити Daily по Skype, а, працюючи в одному місці, можна збиратися в робочій кімнаті чи йти в переговорну або на вулицю, якщо там завжди світить сонце і не буває дощів.

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

У книзі "Scrum: The Art of Doing Twice the Work in Half the Time" автор Scrum Jeff Sutherland обіцяє подвоєння віддачі від роботи команди. Насправді якщо він і перебільшує, то не дуже. Мабуть, не варто чекати грандіозних поліпшень миттєво. Ми розумні люди і рідко доводимо роботу до такого жалюгідного стану, що навіть мінімальна систематизація відразу дасть грандіозний результат. Однак прогрес трапиться, і масштаб поліпшень буде помітний неозброєним оком. І почнеться все з того, що раніше мовчали розробники почнуть говорити про перешкоди в роботі, і з того, що до їхньої думки почнуть прислухатися.

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

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

Помилок і оман про Scrum безліч, але деякі зустрічаються настільки часто, що починають прийматися усіма без будь-якої критики і перетворюються в Карго-культ. Щоб не потрапити в халепу самому, варто розібратися в деяких з них.

Scrum: Робота над помилками

Про команди

Часто можна почути наступне:

Scrum-команда повинна складатися тільки з розробників, кожен з яких повинен вміти робити всю необхідну роботу. Де нам таких взяти? У нас є тільки дизайнери, девелопери, верстальники і тестувальники. Раз так, Scrum-команда у нас все одно не вийде, будемо працювати по-старому".

Але в дійсності в Scrum Guide говориться наступне: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment". Так, команда повинна бути універсальною, але вона повинна бути універсальною в цілому. Якщо для доведення розробки до релізу потрібен JavaScript розробник, QA і дизайнер, в команді повинні бути вони всі. Інакше «віз не поїде».

При цьому за результат своєї роботи команда відповідає цілком. Scrum Guide: "Individual Development Team members may have specialized skills and areas of focus but accountability belongs to the Development Team as a whole". Це не порожні слова. Якщо дизайнер Інокентій намалював відмінний дизайн, але команда не змогла його реалізувати і зарелизить — це провал команди в цілому і кожного учасника команди зокрема. Інокентій, замість того щоб нарікати на JavaScript і QA, що ті повільно працюють, має замислитися: може бути, він може змінити щось у своїй роботі, щоб наступного разу команда добилася результату.

При цьому всі учасники Scrum команди мають одну посаду: Розробник. Scrum Guide: "Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule".

По-перше, це ключ до збільшення продуктивності команди. Наприклад, незважаючи на те, що Інокентій має спеціалізацію в дизайні, і найбільш ефективний саме в цьому виді роботи, тим не менше він цілком в змозі допомогти команді з тестуванням, якщо саме цей етап розробки є вузьким місцем на поточний момент. Детальніше про це — у книзі Еліяху Голдратта "Мета" (The Goal в оригіналі).

По-друге, це дозволяє всім учасникам команди обговорювати всі питання на рівних. Ідеї, оцінки, проблеми, кожен має право висловити свою думку. Наприклад Інокентій не має права ігнорувати зауваження Тетяни про те, що червоний колір шрифту на рудому тлі — це погане візуальне рішення. Не дивлячись на те, що Тетяна має спеціалізацію в тестуванні, побачивши проблему, вона має право висловитися, і її думка не можуть відмовитися вислухати бо вона, бачте, QA. У Development Team всі рівні, і це дійсно важливо. Такий підхід неуникален для Scrum, докладніше про важливість цього принципу можна прочитати в книзі Jeffrey Rothfeder "Driving Honda".

Саме взаємодопомога і взаємна повага становлять основу успішної Scrum команди.

Про рев'ю

На Demo потрібно запрошувати користувачів, а ми робимо веб-додаток і наші користувачі десь далеко. Може бути там, у сонячній Каліфорнії, Scrum-команди і можуть запрошувати користувачів на демо, але не в нашій країні морозів, ведмедів і матрьошок".

В Scrum немає Demo. Тим не менш, це не заважає багатьом проводити саме Demo. Наприклад, зібрати 200 осіб розробки в одному залі з проектором і 5 годин мучити один одного демонстраціями. Энтерпрайзно. Епічно. Марно.

В Scrum є Рев'ю. І рев'ю передбачає обговорення виконаної роботи, досягнутих результатів та подальших планів з зацікавленими особами [stakeholders]. Комунікація і зворотний зв'язок — це ключові елементи рев'ю, у всіх запрошених на рев'ю повинна бути можливість висловитися і обговорити свою точку зору з командою та іншими стейкхолдерами. Тому кількість запрошених на рев'ю повинно бути обмежено, інакше нормальне обговорення буде неможливо. Запросити на рев'ю найбільш цінних людей — відповідальність Product Owner'а. Scrum Guide: "Attendees include the Scrum Team and key stakeholders invited by the Product Owner".

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

Детальніше про рев'ю можна прочитати в книзі Кеннета Рубіна "Основи Scrum".

Про ретроспективу

Ми пробували пару раз провести ретроспективу, але говорити було особливо не про що. Взагалі в нашій команді проблем немає, тому що це зайвий мітинг — марна трата часу. Давайте краще попрацюємо зайві пару годин".

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

В команді має бути сильний Scrum Master, який навчить команду проводити ретроспективу зсередини, або хтось з досвідчених менеджерів, який зможе допомогти команді з боку.

Працюючи з боку, потрібно бути дуже акуратним і лише підштовхувати команду в правильному напрямку, а не годувати її готовими рішеннями. Інакше команда ніколи не стане самостійною і після зняття «опіки» швидко повернеться до того, з чого почала. Крім того, команди завжди краще сприймають рішення, до яких вони прийшли самі, і впроваджують їх швидше і ефективніше, ніж будь-які рішення зі сторони, навіть якщо ці рішення самі по собі гарні.

Домігшись перших успіхів у поліпшенні процесу на рев'ю, потрібно подвоїти зусилля. Якщо здається, що зараз ніяких проблем немає, — це чітка ознака того, що все дуже погано. Проблеми є завжди. Ретроспектива — це Kaizen, безперервний і нескінченний процес поліпшень.

Про Scrum-майстра

Scrum-майстер в кожній команді — це марнотратство. Та й де їх узяти? Ми відкрили вакансію і за півроку найняли тільки одного, і то майже без досвіду. Робити особливо нічого, рев'ю ми проводимо раз на квартал, щоденні стендапи команди самі організовують і взагалі справляються, проблем немає. Він, звичайно, дуже багато часу проводить в кімнаті з xBox, але проджект овнеры ним задоволені, кажуть, він допомагає старших розробників на планування збирати і звіти по командам робить в кінці місяця. В загальному одного нам вистачить, а можна закрити вакансію, що безглуздо шукати".

Дійсно, найняти Scrum-майстра, а особливо хорошого — хто ж буде поганого наймати — практично неможливо. Але це і не потрібно. Важливо знайти в команді розробника, здатного виконувати цю роль. Дати йому таку можливість, знявши з нього істотну частину навантаження, яку він зараз виконує. І головне, почати вчити.

Так, вчити Scrum-майстрів потрібно. Для виконання цієї ролі потрібен навик, який не з'являється сам собою. Можна відправити «майстрів» на тренінг, це нескладно, але результат буде скромний. Набагато важливіше навчити майстрів різних команд регулярно збиратися разом обговорювати проблеми, з якими вони стикаються і рішення, які вони знаходять. Також буде корисно, якщо «майстра» почнуть самі готувати і проводити внутрішні семінари по Scrum на цікаві їм теми.

Scrum-майстер може знайти багато корисного Scrum Guide.

Про координацію робіт

Scrum призначений тільки для маленьких, окремих, незалежних команд. А нас 30 розробників, не рахуючи тестувальників, розробляють один додаток. Ми працюємо з загальним кодом і загальною базою, яка вже тут незалежність. Ми поділилися на шість команд, які повинні взаємодіяти а Scrum цього не передбачає. Так що збільшення продуктивності чекати не варто. Ну хоча б Product Manager'ам більше не потрібно торгуватися за кожного конкретного розробника".

Так, спільні зусилля кількох Scrum-команд, що працюють над спільним продуктом, потрібні регулярно, і це нормально.

В Scrum немає Product мападег'ів, або будь-яких інших менеджерів, так само як немає Demo. Тим не менш, розробка може бути скоординована в рамках Scrum.

Продуктові зміни, що не потребують складних технічних зусиль, можуть бути просто узгоджені між Product Owner'ами команд і сплановані з високим пріоритетом.

Складні технічні роботи, забезпечення цілісності архітектури, уникнути «конструювання велосипедів» забезпечуються регулярним запрошенням на рев'ю і плануванням технічних експертів програми. Scrum Guide: "The Development Team may also invite other people to attend [on Sprint Planning] in order to provide technical or domain advice". У компанії для цього можуть бути виділені ролі архітекторів додатки поза команд або це можуть бути просто досвідчені та висококваліфіковані розробники, які працюють в конкретних командах, але активно взаємодіють з питань розробки продукту в цілому.

Про планування і DoD

Планування всією командою — це маячня. Марна трата часу. Минулого разу дизайнери цілу годину торгувалися, якого кольору робити кнопки, а нам їх слухати? Ми плануємо цілий день, а встигаємо тільки половину завдань, краще б цей час на роботу витратили. І взагалі планувати роботу на два тижні марно, тому що завтра з'явиться баг, який потрібно буде терміново пофіксити, і весь план розвалиться. А некритичні баги ми взагалі не фиксим, тому що план спринту міняти не можна. ДоД? Що це?".

У плануванні дійсно повинна брати участь вся Scrum команда. Це важливо. Таким чином гарантується, що всі будуть знати що і як команда буде робити в спринті, щоб не грати в «зіпсований телефон» в процесі роботи. Так само це дозволяє відразу врахувати всі зауваження з усіх точок зору.

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

Повний склад команди при плануванні потрібно при первинному розборі бэклога перед оцінкою, при формуванні мети спринту і складанні плану дій по його досягненню.

Мета спринту і список завдань, взятих у спринт, часто плутають. Аж до формулювання «наша мета, зробити всі завдання, взяті в спринт». Це помилка.

Мета повинна визначати очікуваний якісний результат від майбутньої роботи, і така мета повинна бути одна. Мета не повинна мінятися протягом спринту. Scrum Guide: "No changes are made that would endanger the Sprint Goal". Наявність мети дає команді певну тактичну свободу у виборі того, що і як буде реалізовано, що часто буває дуже важливо. Scrum Guide: "The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint". Це не тільки можливість відмовитися від реалізації менш цінних завдань, якщо ресурсів недостатньо, але і привід зробити більше, якщо є хороша ідея або можливість.

Можливо і очікувано, що список робіт, запланованих на спринт, буде змінюватися. Scrum Guide: "Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned" і "If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint". Вносити зміни до спринт нормально і очікувано. Підозріло протилежне, коли команда працює весь спринт з початкового плану, не вносячи в нього жодних змін взагалі.

Команди часто «забувають» про Definition of «Done» (DoD) — критерії виконаної роботи. Це здається само собою зрозумілим, виконана значить виконана, що тут незрозумілого.

Без чітких і поділюваних усіма критеріїв завершеної роботи команда буде постійно промахуватися з плануванням: “Ми все зробили! А що залишилося? Протестить і зарелизить...".

Також критерії виконаної роботи важливі для аналізу результатів спринту, розуміння того, що саме не було зроблено для завершення роботи, дає чудову тему для ретроспективи і дозволяє сформулювати конкретні кроки для вирішення такої проблеми.

По цій темі Scrum досить багато запозичує з Бережливого виробництва (lean.

Фіксована тривалість спринту тут відповідає часу такту. Процес планування реалізує систему витягування, коли, замість того щоб говорити команді, що вона повинна робити за спринт, Product Owner пропонує можливі варіанти, з яких команда обирає роботу в тому обсязі, в якому вона може її зробити.

Концепція DoD забезпечує виключення втрат незавершеного виробництва, самого великого з виділяються в lean видів втрат, оскільки до закінчення спринту всі розпочаті роботи повинні бути виконані до кінця. Scrum Guide: "At the end of a Sprint, the new Increment must be Done".

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

Докладніше про види втрат у виробництві та Ощадливому виробництві можна прочитати в книзі Джефрі Лайкера "Дао Toyota", також у цій темі присвячена ціла глава в книзі Сазерленда "Scrum. Революційний метод управління проектами", згадуваної вище. Одна з технік планування, заснована на історіях, добре розкрита у Кеннета Рубіна "Основи Scrum".

Про Scrum-покер

Від Scrum-покеру ніякого толку. Розробники дві години мусолять задачки, роблять якісь оцінки. І що в результаті? Кожен раз ми беремо на спринт в два рази більше завдань, ніж реально робимо".

Ідея Scrum-покеру настільки поширено, що багато хто думають, що це невід'ємна частина Scrum і без нього взагалі нікуди. Це не так. Scrum-покер — це всього лише одна з технік, що має свої достоїнства і недоліки, так само як використання Scrum-дошки або планування робіт у вигляді Користувальницьких історій.

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

Можливо, варто почати грати на гроші. А можливо, персональні оцінки розробників будуть працювати краще ніж усереднені.

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

Про Scrum в цілому

Scrum — це суто теоретичний підхід, який може спрацювати тільки в ідеальних, парникових умовах, в реальному житті Scrum не застосуємо. І взагалі Scrum це вчорашній день, зараз все потрібно робити по Agile!".

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

Не варто плутати Scrum і Agile, ці концепції не є альтернативними, не протистоять і не замінять один одного.

За великим рахунком Agile — це набір тактик, які безумовно розумні, але недостатні для побудови повноцінного робочого процесу. Варіантів agile-процесів безліч хороших серед них не так багато.

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

Так, Scrum не дається без праці.

C'est la vie.

Дмитро Мамонов

Департамент розробки,
Підрозділ мержа у майстер,
Відділ роботи з гіт,
Старший оператор баш консолі

Джерело: Хабрахабр

0 коментарів

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