Майстер-клас Бориса Вольфсона. Основи Agile

image

Цей пост написаний за мотивами майстер-класу Бориса Вольфсона (директора з розвитку HeadHunter), присвяченого (сюрприз!) основ Agile. Матеріал буде корисний всім, хто зовсім не знайомий з методологією розробки складного, або має про неї туманне уявлення.

Водоспадна модель
Доктор Ройс створив так звану водопадную модель розробки програмних продуктів. Вона швидко завоювала популярність на Заході, і деякий час тому за цієї моделі працювала переважна більшість компаній-розробників. Що вона собою являє? Розробка продукту проходить через ряд етапів:

  • збір вимог;
  • їх аналіз;
  • створення архітектури;
  • створення дизайну системи;
  • кодування;
  • тестування;
  • викладка;
  • експлуатація.
В ідеальному світі ми пройшли б за цим рівням зверху вниз, як тече водоспад, і в кінці у нас вийшла б гарна система. У чому полягало рішення доктора Ройса? Він запропонував писати багато документації, обробляти ризики, повторювати по кілька разів якісь етапи. В результаті вийшла ваговита водоспадна модель. Вся індустрія комерційного софта сформувалася в 1990-х років. І якщо в Європі і США існували важкі методології, то у нас не було ніяких. Збиралася група людей, які просто намагалися зробити хороший софт. Обидві проблеми — відсутність методології у нас і великовагові схеми на Заході — добре вирішує Agile.

Для чого потрібна методологія гнучкої розробки?
Отже, для чого ж застосовується методологія Agile?

  • Прискорення виведення продукту на ринок. Якщо ви хочете щось зробити швидше, потрібно робити це згідно з Agile. Дуже простий приклад. Є дві компанії, у них приблизно однаковий бізнес. Одна пише ТЗ, потім проектує систему і малює дизайн — це водоспадна модель, на розробку якої може піти кілька місяців. У другій компанії, яка працює за Agile, до цього часу може бути запущений сайт, випущено, вона почне заробляти гроші і захоплювати ринок, що найголовніше.
  • Управління змінами в пріоритетах. Це, мабуть, дуже болюча проблема практично для всіх компаній. Якщо ви робите проект, який триває хоча б декілька місяців, то у вас обов'язково зміняться вимоги. Звичайно, якщо це не софт, наприклад, для супутника або марсохода. Хоча навіть супутникам і марсоходам зазвичай заливають свіжу версію софта, коли вони прилітають в точку призначення. Якщо говорити про комерційну розробку, то проблема в тому, що ми, програмісти, аналітики і дизайнери, ніколи не знаємо, що потрібно не тільки замовнику, який нам платить, але й користувачам. Зазвичай всі підходять до питання так: поки користувач не спробує функціонал сайту або програми, ви не знаєте, потрібен він чи ні.
  • Поліпшення взаємодії між IT і бізнесом. Це головний біль, особливо для великих компаній, адже у бізнесу періодично змінюються вимоги, кожен говорить своєю мовою. В результаті сторони один одного не розуміють.
Відповіддю на всі ці виклики з'явився Маніфест гнучкої розробки ПЗ.

Маніфест гнучкої розробки
Він складається з декількох частин. Перша частина називається «Цінності» (Values). Це чотири «зважування»:

  • Якщо ви хочете побудувати гнучкий процес, вам потрібно взаємодіяти і спілкуватися між собою. У чому це виражається розглянемо нижче на прикладі Scrum. При цьому ви можете (і обов'язково будете використовувати якісь інструменти і процеси, наприклад, трекери — JIRA, Redmine і т. д. Але ваша робота повинна спиратися на різні мітинги, зустрічі і взаємодія, а не на налаштування трекерів або TFS (якщо говорити про Microsoft стек).
  • Працюючий продукт, який ми робимо, набагато важливіше, ніж документація по ньому. Вище було наведено приклад з двома компаніями: у однієї є готовий продукт, який можна дати користувачам, замовнику, захопивши ринок; а друга пише ТЗ, створює макети і т. д. Вся ця документація, яку користувач не може застосувати через не готовність продукту, не приносить цінності цього користувачеві. Якщо ми навчимося працювати, мінімізуючи ці кроки, або роблячи їх невеликими шматочками, то у нас вийде більш гнучкий процес.
  • Співпраця та взаємодія з замовником важливіше жорстких контрактних обмежень. Зазвичай підписується договір, в якому зазначено, що до конкретної дати за певну суму розробник зобов'язується виконати обумовлений обсяг робіт. Природно, до договору додається ТЗ. Тобто фіксується час, обсяг робіт та терміни. Це називається Fixed Price. Такий підхід не дуже хороший, якщо ви хочете працювати на довгострокову перспективу і бути гнучкими. У цьому випадку правильніше вибудовувати партнерські відносини з замовником. Якщо говорити про контрактні оформлення, то зазвичай це виливається в контракти за схемою «матеріали», коли розробнику просто оплачується витрачений час. Найголовніше, що тут починається пошук партнерства і ситуації Win-Win, коли перемагає і замовник, і його підрядник.
  • Готовність до змін у зважуванні з дотриманням початкового плану.
В Agile є план, оцінки і прогнози. Але якщо у вас є якийсь початковий план для річного проекту, а ви через три місяці вже надали якусь версію продукту, користувачі помацав його, ви зняли метрики, подивилися, що і як вони використовують, дізналися щось нове, то після цього первісний план можна майже повністю поміняти.

Наведу свіжий приклад. Ми викотили невелику фічу на HeadHunter, коли ваші навички може підтверджувати будь — поставив вам плюсик, і з'явиться напис, що стільки-то чоловік підтвердило ваш навик. У мене Scrum підтвердило 18 осіб. Ми спеціально запустили це в дуже простому вигляді, щоб подивитися, як до цього поставляться користувачі. Ми виходили з логіки, що взаємодія буде а-ля LinkedIn або Хабр, де користувачі один одного плюсують. Зняли статистику, і виявилося, що у нас ці плюсики ставлять, ймовірно, після співбесід HR. Тобто далі ми можемо розвивати цю фічу в бік HR, або як її модифікувати, щоб вона була більш корисна претендентам. Таким чином, в Agile існує чотири цінності:

  • люди і взаємодія між ними;
  • робочий продукт;
  • співпрацю і вибудовування партнерських відносин із замовником;
  • готовність до змін.
12 принципів Agile
Цінності тягнуть за собою 12 принципів Agile:

  1. Найвища цінність — це задоволення потреб замовника завдяки регулярній і максимально ранньої постачання цінного для нього. Якщо замовник хоче отримати від нас великого слона, але ми можемо дати йому частину цього слона не через рік, а через три місяці, потім ще через три місяці ще одну частину, а затії щомісяця видавати шматочки, то чим частіше ми це будемо робити і чим раніше, тим краще.
  2. Ми завжди готові змінювати вимоги, навіть на пізніх стадіях проекту, якщо дізнаємося щось нове. Таким чином, ми створюємо бізнесу або зовнішньому замовнику конкурентну перевагу. Припустимо, працюють дві компанії: одна написала ТЗ і за рік зробила продукт, а ми зробили концепцію продукту (неважливо, в якому вигляді) і поступово його викочуємо і розкочуємо. Тоді наш продукт буде більше відповідати вимогам замовників, користувачів та ринку в цілому.
  3. При використанні Agile працюючий продукт випускають максимально часто. У маніфесті прописані терміни — від кількох тижнів до кількох місяців. Насправді це тиждень/місяць, якщо ви використовуєте Scrum. У Росії найчастіше кожні два тижні випускається щось нове. А якщо роблять якийсь веб-проект, то зазвичай використовують одну з варіацій Kanban, значить, релізи можна робити кожен день. У HeadHunter зазвичай щодня виходить кілька релізів, що створює великі проблеми для наших конкурентів. Це можуть бути виправлення багів, але ми вміємо додавати щось цінне для наших користувачів.
  4. Бізнес обов'язково повинен працювати разом з програмістами, допомагати їм зрозуміти специфіку даного ринку. Наприклад, програмісти у HeadHunter повинні розуміти, як працює HR, та як здобувачі шукають роботу. Якщо ви працюєте в банку, то вам потрібно розуміння принципу роботи банку в цілому та дуже докладні відомості про тій сфері, за яку ви відповідаєте. Найбільш частою проблемою, з мого досвіду, є недоступність бізнесу — коли розробник не може отримати у співробітника потрібну інформацію. При використанні Agile важливо уникати виникнення подібних ситуацій.
  5. Команда — один з наріжних каменів Agile. Найкращих результатів досягає команда замотивированных професіоналів. Є геніальне зауваження про те, що ефективність Scrum залежить від керівника. В Agile керівник повинен створювати умови для команди і забезпечувати всебічну підтримку, проводити коучинг, стежити за атмосферою в колективі.
  6. Є багато досліджень, які показують, що найкраще спілкування — лицем до лиця. Причому бажано, щоб було якесь засіб візуалізації, на якому можна писати: аркуш паперу, дошка зі стікерами і т. д. Самий простий і ефективний спосіб дізнатися вимоги клієнта, замовника або користувача — поговорити з ними.
  7. Працюючий продукт. Про нього повторюватися не буду. Ступінь готовності проекту повинна вимірюватися не словами, про те, що ТЗ вже написано і 50% макетів намальовано, а кількістю функціоналу, випущеного в production.
  8. Agile важливий ритм, постійні поліпшення. Бізнес і програмісти завжди повинні мати можливість робити процес стійким, постійно його покращувати.
  9. Про цей пункт менеджери зазвичай не люблять говорити розробникам, але Agile взагалі не буде працювати, якщо ви написали бидло-код. У вас повинна бути хороша гнучка архітектура, в яку можна додавати різні елементи і при необхідності легко змінювати. І якщо команда не буде приділяти максимум уваги технічній якості (писати хороший код, використовувати інженерні практики, автоматизувати процеси), то ніякого Agile у вас не буде.
  10. Простота. Вона проявляється в технічної складової, в дизайні. Це один з принципів екстремального програмування. Простота дуже важлива також з точки зору випуску продукту: коли ви хочете «нарізати» того «слона», краще почати з простою частини.
  11. Менеджер (керівник, Scrum-коуч, Agile-коуч) в команді змінює свою роль: він не стільки займається організацією процесу, скільки навчає команду, тому команда повинна бути самоорганізованої. Є спеціальні стратегії, як з групи людей зробити самоорганізовану команду.
  12. Команда повинна постійно аналізувати свою роботу, процеси: що вийшло, як вони цього добилися, і постійно поліпшувати організацію робіт.
В якості підсумку можна сказати, що Agile — це серія підходів до розробки програмних продуктів шляхом безперервного і швидкого постачання цінного робочого функціоналу самоорганізованої командою професіоналів у співпраці з замовником. Це не канонічне визначення, а моє власне розуміння Agile.

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

Практики
Одна з цінностей Agile говорить: ми повинні вибудовувати робочий процес, налагоджуючи взаємодію і комунікації між людьми. Це виливається в практичні кроки. Наприклад, у ранкові стендапи, коли команда усно синхронізує свою діяльність на майбутній день. Можна замість стендапів кожному писати звіт про виконану вчора, але це вже буде не Agile, тому що виникає потік малозначуща документації. Які ж практики найчастіше використовуються в компаніях, практикуючих гнучку розробку?

  1. На першому місці стендапи. В Росії, навіть якщо компанія повністю зафейлила впровадження, використання і адаптацію Agile, зазвичай все одно залишаються стендапи. Якщо у вас не виходить їх використовувати, значить, у вас зовсім не організована команда. Практика проста: кожен день в певний час команда збирається і синхронізує свою діяльність.
  2. На другому місці планування ітерацій, коли команда планує обсяг робіт на найближчу ітерацію. Це до питання про те, що в Agile ні планування. Якщо у нас ітерація йде два тижні, то ми намагаємося зробити план, декомпозицію, може бути, розбити бізнес-завдання на технічні завдання.
  3. Unit-тестування — одна з найбільш простих інженерних практик, яку можна досить швидко почати використовувати. При наявності проблем з якістю близько 60-70% багів можна відловити unit-тестуванням.
  4. Планування релізів. Тут ми вже плануємо великими шматками — що і коли випустимо. Якщо мова йде про Scrum, то вимірюємо великими мазками, в спринтах.
Давайте подивимося, як можна графічно представити ітеративності виконання робіт.



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

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

Ще важливий момент: коли менеджери (і навіть розробники) не дуже глибоко занурені в технічну частину, їм здається, що можна ітеративне зробити програму, зібрати по шматочках, як пазл. Це оману. Розробник повинен уявляти цілком і в деталях кожен елемент картини, і почати його робити за п'ять кроків. При цьому треба мати на увазі, що умови можуть змінитися. Це називається инкрементальным підходом («інкремент» — додавання чого-то).

Щоб працювати ітеративне і инкрементально, потрібно діяти трохи інакше. У розробника в голові повинна бути якась концепція, яку він поступово опрацьовує.

Якщо ви працюєте з «водоспаду», то, зазвичай, у вас фіксовано зміст проекту. Вам кажуть: «Хочу, щоб ви зробили це. Я точно знаю, чого хочу я і мої користувачі. Оцініть, скільки чоловік для цього потрібно і скільки часу на це піде». В Agile ми діємо по-іншому: у нас є команда і фіксовані відрізки часу (я говорю про Scrum), наприклад, двотижневі ітерації. Виходячи з цього, ми плануємо обсяг робіт, який ми можемо виконати за цей час.

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

Scrum
У Хенріка Книберга є така метафора — Agile-парасольку. Це ті методології, які є гнучкими. Найбільша — Scrum, екстремальне програмування (XP), DSDM, Crystal, FDD, Kanban. Більше половини компаній, що застосовують Agile, використовують Scrum. На другому місці комбінація Scrum і XP, коли беруться управлінські практики з Scrum і додаються інженерні. Окремо зазначу, що комбінація Scrum і Kanban використовується приблизно у 8% компаній. Зараз це один із трендів, мода. Назва Scrum прийшло з регбі і перекладається як «сутичка». Простіше кажучи, при виникненні спірної ситуації команди шикуються, вкидається м'ячик, і потрібно один одного перештовхати. До розробки продукції цей термін вперше застосували в 1980-х роках два японця — Хіротака Такеуті і Икудзиро Нонака. Це хороші дослідники в області менеджменту. Зокрема, вони написали документ «The New New Product Development Game». Тут вживання слова «new» 2 рази не є помилкою. Просто назва перекладається як «Нова гра для розробки нових продуктів». Що зробили ці два японця? Вони проаналізували, як різні компанії створюють свої продукти. Причому навіть не ЗА, а всіляку техніку і електроніку. Автори розділили виявлені підходи на три типи.



  • Перший тип (A): у нас є фаза розробки, все жорстко, послідовно і добре.
  • Другий тип (B): зв'язку перетинаються, є можливість отримати зворотний зв'язок. Я запрограмував щось, програмують ще, віддаю тестировщику, він дає свої коментарі, я встигаю їх обробити до завершення своєї роботи.
  • Третій тип: кожна фаза перетинається більш ніж з однією іншою фазою. Я програмують ще щось, а мої перші завдання тестуються, викладаються у production, з них знімаються метрики, я можу внести зміни.


Тип C двоє японців порівняли з ситуацією в регбі. Чому? Сенс гри в тому, щоб взяти м'яч і донести його до лінії поля противника, долаючи опір. Але в регбі не можна кидати м'яч вперед. Коли ти біжиш і розумієш, що зараз тебе покладуть на землю, то м'яч можна віддати тому члену своєї команди. Він його ловить і біжить далі. Якщо не може подолати опір, то біжить назад.

Сучасний Scrum створений двома айтішниками — Кеном Швабером і Джефом Сазерленд. На офіційному сайті www.scrumguides.org ви можете ознайомитися з офіційним описом Scrum. Так виглядає загальна схема Scrum:



Отже, ми хочемо робити якийсь продукт. Він розрізав на окремі шматочки, які називаються бэклогом (backlog) продукту. Це вимога. Тобто у нас немає технічного завдання або якогось великого документа, який все заздалегідь описує. Зазвичай чим важливіше якісь вимоги, тим якісніше вони розбиті і описані. Цим займається власник продукту (product owner).

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

Компоненти Scrum


Ролі
Scrum-команда складається з команди розробки, власника продукту і Scrum-майстра.

  • Чому ми говоримо, що Scrum — це гнучкий Agile-фреймворк? Тому що він безпосередньо реалізує цінності і принципи, описані на початку публікації. Команда в Scrum повинна бути самоорганізується, а Scrum-майстер допомагає їй такою стати, вчить, як можна швидше і якісніше елементів бэклога створити інкремент продукту — нову версію софта. Scrum-майстер відповідає за те, щоб всі процеси працювали, щоб учасники розуміли, навіщо і як це робиться.
  • Власник продукту, product manager — людина, відповідальна за максимізацію цінності продукту, він відповідає за продукт (наприклад, Стів Джобс).
  • Команда розробки повинна складатися з мотивованих професіоналів, які можуть протягом кожного спринту робити постачання, тобто на підставі вимог створювати готовий продукт.


Процеси
  • Щоденний скрам — це планерка, на якій члени команди розповідають, що зроблено, з якими проблемами зіткнулися, що планується зробити найближчим часом, щоб кожен розумів, хто і що робить.
  • Спринт — ітерація з фіксованим строком, тобто в Scrum повинен бути ритм.
  • Планування спринту. Перед початком спринту всі збираються і визначають, що потрібно зробити протягом спринту і в якому вигляді.
  • Огляд спринту або демонстрація: всі збираються і демонструють, що нового в инкременте продукту, дивляться, фіксують зауваження, може бути, змінюють найближчі плани.
  • Ретроспектива: всі збираються і думають, що можна поліпшити в наступному спринті. Наприклад, було багато помилок, користувачі задоволені. Давайте спробуємо в наступному спринті використовувати модульне тестування. Пробуємо, наступного ретроспективі дивимося, допомогло чи ні, придумуємо щось ще.


Бэклог спринту — верхня частина бэклога. Кількість елементів зазвичай визначається швидкістю команди на заході, який називається «планування спринту», і проводиться перед початком самого етапу спринту. Спринт триває 1-4 тижні (найчастіше 2 тижні). Чим швидше і дешевше можна релізувати, тим менше тривалість даного етапу.

Щодня команда проводить 15-хвилинний стендап, Scrum-мітинг, на якому всі члени команди синхронізують свої дії. Найчастіше ці зустрічі називають просто «скрамами».

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

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

  • Бэклог продукту — це всі тікети, картки або інші вимоги у вигляді елементів бэклога, які є у вашому продукті.
  • Бэклог спринту — найбільш цінні та пріоритетні вимоги.
Приклади Scrum-практик: оцінки
Тут не буде канонічного/кошерного/ванільного Scrum'а, який описаний Швабером і Сазерлендом, і про який можна почитати тут: www.scrumguides.org. Розповім про реальних практиках, які використовуються командами. Є великовагові, нібито точні методи все «правильно» порахувати і зробити. Але практично всі великі проекти вибиваються з термінів. І це стосується не тільки IT. Наприклад, був випадок, коли аеропорт не могли запустити в експлуатацію з-за того, що не був готовий софт, який відповідає за автоматичне розподіл багажу. Якщо ви використовуєте гнучкі методології, а також те, про що я зараз розповім, то можете спокійно запускати проекти, без геройства. Один з наших великих проектів, який закінчився у вересні, фактично був готовий на production за два тижні до офіційного запуску. Я багато спостерігав, як команда, тимлиды і менеджери намагаються передбачити, коли у них буде готовий проект. Це приблизно те ж саме, що підійти до команди і попросити назвати випадкове число.



Agile і Scrum пропонують використовувати таку практику: робити відносні оцінки, тобто «вимірювати в папуг». Це означає, що я оцінюю час, який у мене піде на вирішення завдання, і скільки вона займе папуг. Їх зазвичай називають story point. Ці story point краще не прив'язувати ні до яких тимчасовим проміжкам. Яким чином робити таку оцінку, чому вона називається відносною? Зазвичай беруть якусь задачу, невелику, стандартну і зрозумілу всім, і оголошують її мірою, еталоном — вона займає 1 папуга, 1 story point. Береться наступна задача, порівнюється з першої — вона виявляється в 2 рази більше. Скільки вона займає? 2 story point. І таким чином ми розкладаємо всі завдання. В результаті ми не оцінюємо кожну задачу по часу, а порівнюємо їх між собою. Якщо десь помиляємося, то це нормально. Головне, щоб у всіх завданнях помилялися однаково. Оцінка робиться командою і в рамках команди.

Що ми можемо зробити після цього? Наприклад, запустити двотижневий спринт і взяти верхні завдання без якихось оцінок. Коли спринт закінчиться, на виході отримаємо інкремент продукту, в який буде включено якусь кількість завдань. Порахуємо, скільки story point ми зробили, і на наступний спринт просто можемо планувати таку ж кількість story point. Така оцінка виходить відносної та емпіричної. Ми не припускаємо, як люблять робити управлінці, що програміст Вася працює 8 годин і з однаковою ефективністю, а реально вимірюємо, скільки команда може проживати story point за спринт. Шкала оцінок зазвичай підбирається так, щоб розрізняти завдання різних класів.



Якщо придивитися, то схоже на числа Фібоначчі, або на ступені двійки. При цьому оцінюються зазвичай дійсно великі завдання, які далі розбиваються на більш дрібні. Для формування оцінок зазвичай використовується покер-планування. Це модифікація методу Delphi. Кожному члену команди дається колода карток з числами від 0 до 100. Є ще картка з написом «Я не розумію, що це за завдання» і картка з кавою («Давайте зробимо перерву, я вже замучився займатися цією оцінкою»). Після цього беремо завдання номер такий-то, читаємо і обговорюємо, що вона собою представляє: «Користувач вводить логін-пароль для того, щоб авторизуватися на сайті». Обговорюємо, як ця авторизація відбувається, де ми зберігаємо користувачів. Потім кожен член команди сорочкою вгору кладе картку з оцінкою, яку вважає потрібною. При цьому різні члени команди один на одного ніяк не впливають, тому що зазвичай в команді є тимлид, провідний, старший розробник, на якого дорівнює більшість. Після цього відбувається відкриття карт і обговорення.



Згідно з методом Delphi, обговорення відбувається між тими, хто поставив найбільшу і найменшу оцінки. Поставив найбільшу зазвичай бачить якісь ризики, які не помітили інші члени команди. Він скаже: «Ви знаєте, в цю базу, де у нас зберігаються логіни і паролі, ми давно не заходили. Там треба щось отрефакторить, додати колонку, застосувати інший хеш» і т. д. А людина, що поставила найменшу оцінку, або не розуміє завдання, або бачить спосіб зробити швидше, або вже робив щось подібне. Після цього відбувається другий етап обговорення: знову кладуть картки сорочками вгору, потім розкривають їх. Оцінки зазвичай більш-менш згладжуються. Знову проходить етап обговорення, приходять до консенсусу. В результаті записується в трекер, в тікет-систему, або прямо на картку, що у нас ця задача на 3 story point.

Чому це дуже хороший Agile-підхід? Ми розмовляли, обговорювали зміст завдання, засновували наші дії на взаємодії людей, а не на якихось формальних процесах. Якщо комусь цікаві процесні речі — зверніться до методу оцінки Кокома. Чим ще хороший цей метод? Тут виходить якась командна відповідальність за розмір задачі. Все беруть на себе відповідальність за те, що завдання дійсно такого «розміру». Якщо ж ви будете вимірювати трудомісткість завдань, скажімо, днями, то будуть ситуації, коли хтось в команді оцінить її в 8 днів і вона потрапить до нього, то він її і буде робити 8 днів.

Що робити в тому випадку, якщо замовник хоче зрозуміти, скільки часу займе реалізація проекту і просить відразу дати йому оцінку? Ідеальний варіант — працювати з замовником по системі «час — матеріали». Якщо замовник новий, то можна один проект зробити з Fixed Price, переконатися, що замовник адекватний, і далі дотримуватися системи «матеріали». Якщо замовник не погоджується відразу на дану систему, то її можна скорегувати: наприклад, якщо ви закінчити проект до певної дати, то отримуєте якийсь бонус. На цю тему в мережі теж є презентації.

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



Якщо якесь завдання не поміщається за розміром, то її можна розбити на більш дрібні, або позначити, що вона не увійде, або відмовитися від її рішення. Треба розуміти, що швидкість не буде рівномірною. Люди працюють зі змінною інтенсивністю, хтось хворіє, хтось працює повільніше із-за проблем будинку, комусь треба терміново поспілкуватися в соцмережі, хто взяв відпустку. Завжди потрібно прямо і однозначно говорити власнику продукту: «У нас є завдання A, B, C, ми їх точно встигнемо зробити, вони потрапляють в нашу найнижчу швидкість. Є також задача D, яку ми, швидше за все, встигнемо зробити. Але є і завдання F, яка може випасти». Здається, що це неточність, і власник скаже: «Ви що? Треба все встигнути». Насправді, коли ви йому говорите точно, що найважливіші завдання будуть зроблені, то це збільшує довіру між вами та власником продукту або замовником, і він для кожного спринту зможе вибирати найважливіші завдання і гарантовано їх отримувати.

Приклади Scrum-практик: шляховий контроль
Як під час спринту контролювати, що у нас все йде добре? Ми спланували спринт і почали його реалізацію. Для контролю використовується діаграма згоряння Burn Down Charts.



По горизонталі відзначаємо дні — це двотижневий спринт, 10 робочих днів. По вертикалі з одного боку відкладені story point, з іншого — історії користувачів або елементи бэклога. Якщо б ми з вами були роботами, а завдання маленькими і розбитими на шматочки, то ми йшли б по пунктирною лінії — це лінія ідеального Burn Down Charts. Що означають ці лінії? Верхня — скільки ми зробили історій користувачів, нижня — кількість story point. Такі графіки автоматично будуються в багатьох системах для трекінгу завдань.

Як їх читати? Якщо ваш графік перебуває над лінією ідеального Burn Down, то ви відстаєте, повільно працюєте. Тоді до кінця спринту буде не нуль завдань або story point, а десь 20-25. Можна в Excel побудувати тренд або регресію і подивитися, скільки у вас вийде завдань з такою швидкістю — дуже просто і наочно. Якщо команда бачить, що вона йде поверх ідеального Burn Down, то треба вживати заходів. На практиці зазвичай виходить ось так.



Йдуть невеликі відставання, але це у хорошої команди. Інший варіант зустрічається рідше, коли Burn Down нижче діагональної лінії. Це означає, що ви йдете з випередженням, тобто, швидше за все, ви просто взяли мало завдань.



Очевидно, що треба збільшити обсяг робіт. В крайньому випадку, тут можна ще зняти задачки, але це привід обговорити на ретроспективі, чому у вас так вийшло. Цей графік — артефакт, який можна в кінці двотижневої ітерації проаналізувати і зробити висновки.

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

Приклади Scrum-практик: огляд спринту
На цій зустрічі по мірі можливості беруть участь усі зацікавлені сторони: розробники, користувачі, служба підтримки, системні адміністратори і т. д. Огляд спринту потрібен для того, щоб запустити цикл зворотного зв'язку. Ви показуєте власнику продукту розроблений інкремент. Він дивиться, робить зауваження, вносить пропозиції, віддає їх назад в бэклог. Ви берете на роботу, створюєте новий інкремент, через одну-чотири тижні показуєте і знову отримуєте додаткові зміни у вимогах. Тобто запускаєте цикл, який в підсумку приведе вас до продукту, який хоче отримати його власник.

Приклади Scrum-практик: ретроспектива
Ретроспектива потрібна для постійних поліпшень. Гуру менеджменту Едвард Демінг колись сказав, що вдосконалюватися необов'язково, виживання — справа добровільна. Ретроспектива — як раз той етап, на якому ви можете зайнятися вдосконаленням. Як це відбувається? Вся команда збирається і обговорює всі ступені до самої ретроспективи. Зазвичай це триває від години до чотирьох, може тривати навіть день. Якщо ви подивіться олдскульные книжки, там є ретроспектива навіть на кілька днів.

Починається ретроспектива з відкриття. Зазвичай вона займає 5% часу. Завдання — розбудити всіх присутніх на ретроспективі, тому що дуже часто в командах, особливо айтишных, присутні не дуже товариські люди, але деколи мають блискучі думки. Завдання ведучого полягає в тому, щоб розговорити цих людей. Другий етап — збір даних, він займає половину часу. Команда шукає якісь факти. Їх можна згадати, дістати з трекера, роздрукувати. Також можна зібрати статистику по багам, хто репортил, який їх статус — варіантів безліч. Після збору фактів починається мозковий штурм: треба зрозуміти, в чому проблема, проникнути в суть, згенерувати ідеї, які допоможуть її вирішити. На це йде до третини часу. Наприклад, якщо у нас багато дрібних помилок, що виникають не на рівні інтеграції системи, а в коді розробників, то можна запропонувати використовувати модульне тестування. Якщо у нас дуже погана якість, як його поліпшити? Можна спробувати парне програмування, якісь інструменти, які роблять автоматизовану перевірку коду, ще щось. Зазвичай набирається 5-10 ідей. Далі потрібно втілити ці ідеї в життя. Ми не можемо відразу впровадити code review, розробити якісь інструменти. Тому вибирається максимум одна-дві ідеї, реалізацію яких треба запланувати на наступний спринт. Після цього дякуємо всіх і закриваємо ретроспективу. А ще через два тижні можна оцінити, вийшло у нас це чи ні, вивчити інші проблеми.

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



Є таке поняття, як «Цикл Демінга». Він складається з чотирьох етапів: Plan — Do — Check (Study) — Act.

  • Планування (Plan).
  • Реалізація (Do).
  • Перевірка (вивчення) (Check (Study).
  • Зміна (Act).
В ході ретроспективи можна створити план, що ви будете змінювати. Скажімо, впроваджуємо unit-тестування — як впроваджуємо, який інструмент використовуємо, яке покриття коду тестами хочемо отримати. Потім настає етап реалізації (зазвичай це спринт, якщо ми говоримо про Scrum), коли ми втілюємо рішення в життя. На наступній ретроспективі можемо перевірити, чи дійсно нам вдалося досягти потрібної ступеня покриття. Можемо подивитися, поменшало у нас кількість багів в тих місцях, які ми покрили тестами.

Після цього можемо вносити зміни: наприклад, хотіли зробити покриття 50% — зробили, кількість багів зменшилася, але вони ще залишилися — давайте піднімемо до 70%. Або зробили 70%, цикл прокрутили другий раз, перевіряємо — покращився. Давайте зробимо 90%. Ще раз прокрутили: кількість багів не зменшилася, а витрат на написання та підтримку тестів виходить багато. Давайте зробимо більш слабку кордон. Завдяки цьому циклу команда поступово покращує якусь частину процесів. Найпростіший варіант ретроспективи — Real-Time Service Board.



Команда вішає стікери, що їй сподобалося, що ні, а що треба покращити. Тут можуть бути як думки вголос: «Все зробили. Це дуже круто», «Самостійна команда», «Команда маленька — не подобається», так і технічні речі. На основі цього можна висунути ідеї і деякі з них відібрати на реалізацію.

Наостанок про Scrum
Треба сказати, що Scrum, як і всі гнучкі методології, краще працює в командах, які сидять в одній кімнаті. Тим не менш, в мережі можна знайти сотні презентацій про те, як застосовувати гнучкі методології в розподілених командах, коли люди працюють на удаленке. Тут ідея така: замість реального спілкування максимально використовувати програмні і апаратні інструменти. Що зазвичай використовують? По-перше, загальний трекер, щось типу JIRA. Це дійсно допомагає. Популярні программистские чати, наприклад, HipChat. Для спілкування Skype, Hangout. Головне, щоб була відеозв'язок, і щоб можна було демонструвати екрани своїх комп'ютерів.

Kanban
Це друга за популярністю методика. Ряд компаній працюють одночасно по Scrum і Kanban, виходить Scrumban. Напевно, це один з майбутніх трендів. Історична довідка: Kanban з'явився в Японії. Цим словом називалася папірець з пул-запитом на якісь дії. Наприклад, мені потрібна якась деталь, на неї робиться окремий канбан. Але в IT це все-таки застосовується трошки в іншому вигляді.

Цінності і принципи
У айтишном вигляді Kanban з'явився в 2010 р., тобто це досить свіжа, добре описана методологія. Її автор — Девід Андерсон. У наступному році, швидше за все, вийде оновлена версія методології. Якщо Scrum передбачає жорстко визначені процеси, які повинні зламати те, що було в установі до цього, тобто «Так, всі ми тепер працюємо по спринтам, з ранку приходимо, стендапимся, в кінці спринту показуємо демонстрацію», то Kanban передбачає більш еволюційні зміни.

  • Починаємо з того, що є зараз, і далі шляхом еволюції і поступових змін робимо з цього незрозумілого хаосу чітко налагоджену Kanban-систему. При цьому намагаємося лише еволюційно змінювати ролі, зони відповідальності та обов'язку. Заохочуємо ініціативні дії на всіх рівнях організації. Головна практика — візуалізація, зазвичай у вигляді дошки. Робота кожного члена команди повинна бути візуалізована, видно всім.
  • Кількість роботи в кожному процесі обмежується. Тобто в роботі одночасно може бути не більше якоїсь кількості завдань. Це потрібно для виключення мультитаскинга, який вбиває ефективність. До того ж це дає певні інструменти управління потоком задач.
  • Всі правила повинні бути явними. Необхідно дати визначення завершеності. Наприклад, завдання виконано, якщо написаний код, є unit-тести з покриттям 70%, і т. д.
  • Необхідно робити поліпшення з допомогою постійних експериментів, використовуючи моделі і науковий підхід, у тому числі цикл Демінга.
Візуалізація



Зазвичай використовується та ж сама дошка, що і в Scrum. Найпростіший варіант — прото-Kanban. Потік завдань розбивається на окремі етапи. Що перебуває у плані, що в аналітиці, що в розробці, що в тестуванні, що ми вже зробили. При цьому реалізується принцип обмеження кількості одночасно перебувають у роботі завдань — WIP (Work in Progress). Є формула Літтла, яка пов'язує швидкість проходження завдання в такій системі і кількість одночасних завдань. Чим менше WIP, тим швидше задачі проходять ланцюжок. Припустимо, у нас завал у тестуванні, а розробник зробив наступну задачу. Він бачить, що у тестувальників проблема. Тоді розробник допомагає їм щось зробити, або вони йдуть до керівника і кажуть: «Нам потрібен ще тестувальник».

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



Тут є ті ж самі WIP, внизу — критерії готовності (Definition of Done). Стовпець ділять на дві частини: «в роботі» і «виконане». Іноді дошку поділяють на доріжки і розміщують WIP по горизонталі. Це вже більш просунута, повноцінна Kanban-система. Кожна доріжка відповідає певному класу обслуговування. Наприклад, є гарячі завдання, коли вам вдається начальник і каже: «Треба зробити це якнайшвидше». Це окремий клас обслуговування, під нього варто забронювати WIP.

image

Як і в Scrum, тут теж можна створювати діаграми. Зазвичай їх називають «Діаграми кумулятивного потоку». По горизонталі зазначено час, по вертикалі — кількість завдань. Різними кольорами зображені різні етапи. Я згадував, що поліпшення потрібно здійснювати на основі цифр, використовуючи науковий підхід. Ці цифри можна отримати з діаграми. Найважливіші з них — WIP, тобто кількість завдань за винятком запланованих і виконаних. Ми його повинні скорочувати.

Другі важливі критерії — Cycle Time і Lead Time. Визначення бувають різними, потрібно дуже уважно дивитися. Ці два числа показують, наскільки швидко задачі проходять через вашу Kanban-систему.

В даному випадку Lead Time включає в себе очікування, тобто як сприймають вашу Kanban-систему замовники. Cycle Time — наскільки швидко завдання проходить через Kanban-систему без очікування, у загальному бэклоге. Обидва параметра потрібно зменшувати, тоді ваша система буде працювати швидше.

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

Рекомендована література

  • «Scrum і XP: нотатки з передової». Автор — Хенрік Книберг, Agile-коуч з компанії Spotify. Книга повністю безкоштовна і російською мовою. Її мінус — вона дуже стара. Її великий плюс — на ній розібрано багато інструментів, наведено конкретні ситуації у вигляді діалогів. Книгу дуже люблять практики, і для багатьох, в тому числі для мене, це була перша книжка на тему Scrum і Agile. Також в ній описані елементи екстремального програмування.
  • «Scrum і Kanban: вичавлюємо максимум». Теж російською і безкоштовно. Можна сказати, що це книга про Scrumban.
  • На мій погляд, найкращою книжкою по Scrum є «Scrum: гнучка розробка ПО» Майка Кона. У ній дуже докладно розписано, як впровадити Scrum, ким мають стати менеджери, архітектори. Найбільш детальна книга на цю тему.
  • І така канонічна книга по Kanban Девіда Андерсона — «Kanban: Successful Evolutionary Change for Your Technology Business». В наступному році вийде оновлена версія.
  • Моя книга «Гнучке управління проектами та продуктами». Вона є в електронному вигляді від видавництва «Пітер».
  • Наостанок рекомендую роботу Ахмеда Знижки «Keystone Habits of Organizational Agility». Дуже докладно розібрана ця методологія, просто унікальний матеріал для розуміння Agile.


Видеовыступления

  • Виступи на конференціях AgileDays і Lean Kanban.
  • Доповіді, експірієнс-репорти від великих компаній — «Альфа-Банк», «Яндекс», «Райффайзен», HeadHunter і т. д., а також від невеликих стартапів, в яких розповідається, як вони у себе застосовували, що працювало, що не працювало.


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

0 коментарів

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