Як «продати» аджайл різним людям в організації

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

«Продаємо» розробникам

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

Опір

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

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

Мікроменеджмент

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

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

Перехід в об’ємних процесах

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

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

• прототипування;
• взяття вимог;
• аналіз дизайну;
• імплементація;
• стабілізація.

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

Розподілена розробка

Команди, які працюють в аджайлі, схильні приймати рішення швидше, ніж при традиційному плануванні, покладаючись на часте і нерідко неформальне спілкування.

Провал у застосуванні аджайл-процесу в компанії, де розробників розділяли тисячі кілометрів, навчив нас: організаціям варто уникати розподіленої роботи хоча б у перші два-три місяці переходу.

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

Потрібні справжні таланти

У аджайл-процесі центральну роль грає принцип Баррі Боема:

«Наймайте менше людей, але найкращих».

Із проєкту прибираються неважливі активності, тому у розробників залишається більше часу на розвиток.

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

Надто старанні команди

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

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

Тестувальники та інші не-кодери

Написання початкового коду — головна активність у процесі розробки, та в аджайл-процесі воно особливо важливе: без нього і технологія — не технологія.

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

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

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

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

«Продаємо» топ-менеджменту

Цю групу людей хвилюють зазвичай питання чотирьох типів:

• Як ми можемо обіцяти замовникам нові фічі?
• Як відстежувати просування?
• Як аджайл-процес відобразиться на інших групах людей (не розробників)?
• Коли саме закінчується проєкт?

Багатьом менеджерам, особливо вищого рівня, не подобається прощатися з рівнем контролю, який дають діаграми Ганта та інші артефакти довгострокового планування. Їх може заспокоїти обіцянка команди розробки поставити весь потрібний функціонал до конкретної дати, навіть якщо вони знають, що група на це не здатна.

Обіцянки замовникам

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

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

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

Відстеження просування

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

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

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

Вплив на інші групи

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

Як результат, розробники отримали докладну специфікацію у 2000 сторінок, яку потрібно було відпріоритезувати та розбити на місячні відрізки роботи!

Групі розробників потрібно було вгадувати пріоритети щодо списків завдань від продактів на 3-4 місяці. Втім, щойно група освоїла скрам, вона почала виконувати вимоги раніше, ніж інші групи встигали їх писати.

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

Завершення проєктів

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

Працювати тут можна так само, як і у випадку з відстеженням просування та статус-звітом, лише додати бюджетування та стратегічне планування. Наприклад, ми оцінили, що один комерційний проєкт займе від 9 до 15 місяців – досить неточна оцінка, адже ми не знали точно, які фічі мають бути у готовій системі. Однак незалежно від того, скільки красотульок знадобилося б клієнту, ми були впевнені, що відповідний початковий реліз відбудеться через дев’ять місяців. Отже, ми переконали менеджерів профінансувати ці дев’ять місяців із застереженням, що обговоримо додаткове фінансування наприкінці цього періоду.

«Продаємо» ейчарам

Здається, що перехід на аджайл ніяк не торкається ейчарів, але це тільки здається. Наприклад, на проєкті, який ми перекладали на XP, два програмісти прийшли до HR-відділу зі скаргами на парне програмування — що, звичайно, для HR-фахівців прозвучало дивно та непродуктивно. Оскільки ми не пояснили нову модель спочатку, довелося доводити ейчарам, що парне програмування корисне.

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

Складно впихнути таски з ітерації XP або спринту в скрамі в детерміністський план. Але якщо проактивно працювати з HR-відділом, можна сформулювати завдання та дедлайн, які впишуться і в ці вимоги, і в скрам-процес.

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

Перекладено та адаптовано командою BrainRain за статтею Майка Кона та Доріс Форд Introducing an Agile Process to an Organization.