Як зрозуміти, що Agile працює

image

Як зрозуміти, що Agile працює
Асхат Уразбаєв (ScrumTrek)
Перш ніж почнемо говорити, як це все виглядає зсередини, з якими проблемами ми стикаємося, коли тренуємо команду, питання: ті, хто працює з Agile, що для вас означає, що Agile команда є Agile командою? Як ви це визначаєте?




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



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



Наприклад, є всякі формальні речі, типу sprint, velocity. Не знаю, чи є у вас в компанії такі люди, які дуже люблять такі терміни, люблять ними кидатися і кажуть: «Ми проводимо щоденні стендапи. Ми працюємо по Agile чи ні?».

І, взагалі, що таке Agile? Передбачувані результати, пристосовність до мінливих вимог, швидка реакція на зміни, короткі ітерації. Це ідеї. Які там є практики? У мене, наприклад, на слайді sprint, velocity, story points; ще якісь речі, які використовують для того, щоб усе це забезпечити.

Приходиш іноді в організацію або компанію, де кілька команд — деякі працюють по Agile, деякі ні. Як судити, яка команда крутіше, виходячи з того, як вони працюють, які б практики вони не використовували — sprint, velocity або будь-які інші? Дуже важко сказати, яка команда більше ефективна, виходячи з того, що ти просто дивишся на те, як це працює.

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



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

У нас був такий випадок. В одній з компаній, з якими ми співпрацювали, вони вирішили, що буде кльово, якщо хлопці будуть використовувати геймификацию, видавати бейджики. Використовуєш velocity? На тобі бейджик. До чого це призводить? У всіх бейджиків до фіга, все в бейджиках, але толку від цього ніякого немає. Виходить чистий культ карго.

Ще одне часте визначення, що таке Agile — Agile маніфесту:



Це швидкі реакції на зміни. Можна його використовувати як визначення Agile?

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

Я спробував зрозуміти, якщо все це викинути, всі ці нюанси, що ж таке, насправді, Agile? Я постараюся про це розповісти.



Виходить, Agile-практики заради Agile-практик — це абсолютно безглузда річ. Так, вони для чогось потрібні, але треба розуміти для чого, яке завдання вони виконують. Agile маніфесту як визначення теж не працює, або працює не у всіх випадках. Яке ж визначення ефективності?

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

Я спробував сформулювати своє, бо всі ці речі — вони ситуативны, десь є, десь ні. Я намагався придумати визначення, яке більш-менш підходить до будь-якої ситуації. Що ж таке крута команда?



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

Ще крутість команди визначає масштаб проблем, які вона здатна вирішувати. І здатність швидко реагувати на постійно мінливі умови. Щось зміниться, команда адаптується, рухається далі. Це, з моєї точки зору, і є ефективність.

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

Приклад. Дуже типова проблема.



Ми все доробили! А що ще залишилося? Пофіксити баги, задеплоить… Не знаю, чи буває у вас так, але це дуже поширена проблема.

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



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

Вже наявність таких домовленостей вам сильно допомагає, тому що у вас є можливість, прийти до людини, яка чогось не робить, і сказати: «Юра, чому ти цього не зробив? Ми ж домовлялися». Юра каже: «Ну, спробую, так-так». Загалом, є можливість тиснути на совість, скажімо так.

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



Є ще одна цікава річ, яку теж спостерігаєш, коли такі речі занурюються і проходять. Через якийсь час ці речі починають відмирати. З точки зору людини, який впроваджує Agile, виглядає так: «Хлопці, я вам кльову штуку придумав, Definition of Done. Ви говорили, що вона класна, чому ви перестали робити Definition of Done?». Всі такі: «Так чого-то не треба вже». Це правда, ця штука починає поступово відмирати.

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

Повертаючись до того, яка команда є ефективною. Було зрозуміло, у кого з чим проблеми, що фокус уваги спрямований. Хтось каже: «Ми ніяк не можемо випустити код — ми випускаємо, але замовник нічим не задоволений». Цей фокус уваги для вас є ключовим. І це у вас зараз відбувається в стані усвідомленої некомпетентності — здається, що ми не вміємо.

Що виходить після того, як ви навчитеся? Наприклад, ви навчитеся деливерить. Ви вмієте поставляти якісний результат у продакшн вчасно і прогнозовано, незважаючи на постійно мінливі вимоги. Виходить часто, що ви використовували шалену кількість речей, для того, щоб навчитися це робити — ви там story point'ах оцінювали, ви використовували якийсь story mapping, у вас якісь різні підходи і т. д. Це як ліси в споруджуваному будинку. Ви їх поставили, поставили, поставили, ви над цим думали, ви цим хворіли (Agile'ом менеджери хворіють в середньому три роки). Коли навчилися, вже увагу на інші речі перемикається. Як тільки ви навчитеся, це все треба прибирати. Не треба тримати це баластом. Просто примушувати людей, вдаватися: «А чого це ви не робите? А ну-ка робіть!». Якщо вони деливерят, і замовник ними задоволений, прибираємо це все. Прибираємо всі ці ліси.



Є така штука, називається #NoEstimate підхід. Це як раз про це. Можна перестати оцінювати, відмовитися від оцінки, якщо замовник вами задоволений. Є підходи, принципи, які дозволяють від цього відмовитися. Якщо ви при цьому не вмієте деливерить, звичайно, цього не треба робити, мова йде тільки про тих, хто вміє, навчився деливерить, можна перейти до цієї фази.

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

Тобто ці ліси прибираємо, тоді інші штуки можна притягнути в ваш фокус уваги, та вони й самі спливуть. Це як ваш гурток зараз, ви про це думаєте: «Як би нам заделиверить?», через якийсь час ваш гурток поступово збільшується і з'ясовується, що проблем набагато більше. Але виглядає, якщо поговорити з такими людьми, один в продакшн ніяк не вийде, інші думають про стратегію просування на ринок… Я про команди кажу. Це, знаєте, у кого-то суп рідкий, а у когось перли дрібний — такого роду розмови йдуть. Тобто так, у нас багато проблем, виглядає так, ніби їх більше, але рівень крутості цих проблем набагато вище. І така команда набагато більш ефективна.

Але з точки зору стороннього спостерігача, такого як я, такого менеджера, який впроваджує Agile і стежить за тим, щоб усередині команди могли деливерить, крута команда і некрута команда виглядають однаково. Незалежно від наявності будь-практик, використовують ті ж самі velocity, вони виглядають однаково. Але одна деливерит, інша — ні.

Що тут важливо? Важливо уникати такої штуки як культ карго.



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

Так от, коли приходять люди з боку менеджерів і кажуть: «Хлопці, ви не деливерите, нате вам таку практику», то іноді це перетворюється на культ карго. Часом це дійсно працює, але у команди немає заработанности результату. Наприклад, ви запустили Definition of Done в перший день, як тільки почали працювати з командою, а вона ще не натрапила на проблему, яка була у вигляді коміксу, просто ще не зустріла цю проблему, розумієте? Але ви запустили Definition of Done — зразок, ця штука працює… Відмовитися від цих лісів буває досить важко — ніби як, вони приносять користь, давайте все це робити. Від усього можна відмовитися, це і є гнучкість.



Яку проблему вирішує команда А? Sprint, Velocity, Story Points. Ми бачимо, вона не деливерит, не постачає, тому т. к. це здорово, і вона фокусується на цьому. Чим займається команда B поки не зрозуміло.

Які існують зони росту? Куди можна нам розвиватися?



В принципі:

  • поставка,
  • якість з точки зору technical exams, не просто якість з точки зору тестування, а технічного якості, як результату,
  • і продукт — чи робимо ми те, що потрібно користувачеві?


У кожному з цих напрямків можна розвиватися.



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



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

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

Отже, ми повертаємося до теми — що означає Agile на практиці?



Є цикл Демінга, він ліворуч, не переплутайте. Plan, do, check, act. А справа — це те саме «як вийде», просто побігли. І в принципі, межа між ними, з моєї точки зору, відрізняє Agile-команду від не Agile-команди. Якщо ми просто фигачим в запарці, і все погано — це не дуже Agile, а такий спосіб більш структурований, такий спосіб швидше призводить до більш ефективного результату. Plan, do, check, act.

Plan — спланували. І batching (я не зміг підібрати потрібного слова) — ми робимо маленький план. Якщо ми говоримо про Scrum, це два тижні вперед. Якщо ми говоримо про якісь технічні поліпшення, теж дуже короткі терміни. Якщо ми говоримо про lean startup, там теж дуже короткі терміни — дні, може бути.

Do — ми це робимо. Тут важлива дисципліна, ми добиваємося результату. Ми не просто фигачим, щоб якщо потім не вийшло, то переносимо наступний sprint. Давайте визначимо, що готові зробити, нехай це буде менше, але до кінця. Маленький скоп, дороблений до кінця.

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



Експеримент — треба пробувати нові речі, просто робити їх у вигляді експерименту. І цей короткий цикл поліпшень постійно крутити. Постійно пробуємо якісь поліпшення.



Так виглядає типовий Scrum: Backlog, Sprint, робота в класичному Scrum'е 30 днів. Виходить приблизно такий же цикл.



Sprint, якщо говорити про sprint планування, дошка завдань, стендапи, Definition of Done забезпечує дисципліну, ми проводимо демо для зворотного зв'язку в Scrum, у нас є velocity/cycle time для того, щоб виміряти, наскільки ми ефективні.

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

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



Про технічну частину — Red, Green, Refactor, якщо говорити про Test Driven Development.

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



Поставка. Що у нас виходить? Навички, які ми хочемо виховати.

В принципі, з моєї точки зору, ключовий навик — вміння декомпозировать на невеликі власні історії, які инкрементально покращують ваш продукт. З цим величезна проблема в індустрії, з цим постійно доводиться стикатися. У вас фігачать ТЗ, ви робите по ТЗ. Наскільки це інкрементальний підхід? Ні фіга не інкрементальний. Ви говорите: «Блін, замовник козел, він не задоволений. Хоча ми зробили все точно по ТЗ». Підхід був не інкрементальний, в инкрементальном підході ми розділяємося на користувальницький story, робимо в першу чергу працюючий прототип, який постійно у нас поліпшується. Так програти неможливо.

Вміння закінчувати їх швидко і спільно і до кінця — це другий навик, якому ми повинні навчитися. У нас існують метрики, які показують, наскільки ефективно ми працюємо — cycle, velocity та інші, і всякі інструменти типу User Story, Story Mapping, Estimation, Definition of Done і т. д.



Lean Startup виглядає точно так само. Це ідея, продукт, ми отримуємо дані, цикл learn, build, measure.

У вас є якийсь продукт для кінцевих користувачів, наприклад, веб-сайт, у вас є welcome-сценарій з поганою конверсією, ви хочете конверсію поліпшити. Welcome-переписати сценарій. Ви знайшли кращих юзебилистов, вони вам кажуть: «Юра, це займе три місяці». Команда тобі каже: «Юра, це три місяці». Юра каже: «Ні, це дуже важливо, давайте робити. Ну, реально, там терміновий welcome-сценарій, все переписуємо». Вони його три місяці переписують, ви деплоите це продакшн, і конверсія падає. Що робити? Lean startup означає, що ми випускаємо Minimum Viable Product, маленькі поліпшення, які инкрементально дозволяють вам протестувати, чи правильно ви розумієте, що відбувається в голові у вашого кінцевого користувача. І прямо подивитися на ту ж саму конверсію просто в real time. Ви випустили фічу, подивилися на конверсію, подивилися, як вона впливає на різні типи, когорти користувачів і т. д. тобто можна такий цикл постійно крутити, якщо ви розумієте, що відбувається в голові у користувача, при цьому у вас є зворотній зв'язок, у вас в голові з'являється модель вашого користувача, емпатія з ним виникає. Програти так неможливо.

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



Вміння відчувати емпатію з користувачем, вміння отримувати зворотний зв'язок від ринку.

Знову-таки, ці цикли повинні бути дуже коротенькими. В Lean Startup це кілька днів, це навіть не Scrum'івські два тижні. Всякі метрики існують. І інструменти Customer Development, Lean Startup, Design Thinking.



Якість — це вміння поставляти без багів, якісний код, автоматизувати рутинну роботу. Це досить очевидні й зрозумілі речі. Знову-таки, пробуємо це робити маленькими шматочками. Повертаючись до того ж рефакторінгу, ви не можете зупинити бізнес-девелопмент, поки ви рефакторите цей шматок, хоча дуже хотілося б. Ключова особливість такого роду реиндженирингов, чи можемо ми працювати маленькими шматочками, це означає, що ваш продукт Open Running. Ви пишете новий шматочок компонента і поступово перемикаєте на нього функціонал до тих пір, поки все не перепишете. У вас може одночасно працювати кілька дублюючих функціоналів. Поки все у вас не буде дороблено.

Метрики, які нас цікавлять. Зазвичай, це вартість транзакцій, викладення, якщо говорити про поліпшення time to market, це звичайно, скільки часу вам потрібно, щоб фічу видати продакшн, якщо у вас є великий обсяг автоматизації або ручної автоматизації. Вартість такої транзакції не так складно прорахувати, грубо кажучи, скільки людино-днів ви витрачаєте на повне регрессионное тестування вашого продукту, і кількість дефектів у продакшне, яке у вас виникає. Збалансовані речі в тому сенсі, що ви можете просто зафігачити в продакшн «як вийде», не тестувати взагалі, у вас буде багато продакшн дефектів, і навпаки.

Test Automation, Continuous Continuous Integration і Delivery, DevOps — це окрема тема. Там ідея така, що ви можете випустити все продакшн, не тестуючи і перевіряючи на кінцевих користувачів. Якщо ваші метрики падають, з допомогою моніторингу можете дати зворотний зв'язок. Але це теж дуже коротенький цикл, можна коротенькі цикли ганяти дуже швидко.

Контакти
» askhat@scrumtrek.ru
» Facebook
» Twitter
» Zibsun
» Блог компанії Scrumtrek

Ця доповідь — розшифровка одного з кращих виступів на конференції з управління та підприємництва Whalerider.
Ми вже почали підготовку до 2017 року, до речі :)

Додаткові матеріали минулих років Ви можете отримати, підписавшись на список розсилки конференції WhaleRider.

Асхат Уразбаєв представляє компанію ScrumTrek, яка організовує найпопулярніші конференції з agile — AgileDays
Джерело: Хабрахабр

0 коментарів

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