Чому клієнти люблять Agile ?

via Shutterstock .

[ Від редакції: дану статтю до редакції прислав автор , який побажав залишитися невідомим. ]

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

Спробуємо розібратися в питанні - чому ж замовники так люблять Agile ?

Залишимо технічні подробиці , і перемкнемося на щось важливіше - на явні і приховані очікування клієнта . Саме вони найчастіше визначають вибір способу роботи , а не раціональні міркування і точні розрахунки ( на жаль) . Отже:

перше, Agile - це дешево.

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

друге , Agile - це просто . Просто для розуміння людиною, далекою від проблем розробки ПЗ. Це можна пояснити і «продати» замовнику . Зазвичай набір артефактів , присутніх у Agile - процесах ( типу того ж Scrum ) цілком зрозумілий для нетехнического людини , більше того - він симпатичний. Там немає страшних слів , на кшталт « прототипування » , «архітектура» , «план робіт » , «зони відповідальності» і тому подібного. Його можна вивчити за пару днів і сміливо їздити на конференції , слухаючи таких же «фахівців» , як і ти сам . J Тобто Agile - це sexy .

третє, Agile - це безпечно. Не потрібно приймати на себе відповідальність за рішення. Сьогодні я хочу одного , завтра - іншого , і це нормально. Передумав - не проблема. Викинути реалізоване в кошик - запросто ! Нове не налізе на те , що зроблено на даний момент , і взагалі призводить до краху системи? Це ще з чого раптом ? Навіщо ж ВИ тоді ТАК писали код ?

Загалом, з якою сторони не глянь , Agile дуже зручна система роботи . Оптимальна чи що? Це, як кажуть , залежить. Кажу відразу - я знаю , що Agile працює. Не просто впевнений - я ЗНАЮ . Так як він реально працював у деяких проектах , в яких я сам брав участь .

Але працює він тільки тоді , коли дотримуються добре всім відомі умови:

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

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

Чи часто дотримуються ці вимоги? На жаль . Нечасто. А чесно кажучи - рідко. Досить і досить .

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

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

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

Вже ніхто не знає , як програма влаштована в цілому ( що -ж ви доки не писали ? Ай -яй- яй !) .
Частина людей йде , нові приходять і довго не можуть розібратися в продукті.
Масштабованість і продуктивність продукту вичерпані , і без жорсткого рефакторінга та опрацювання архітектури ( страшне слово) - з місця не зрушити .
Додавання нових фіч вимагає все більше часу через нелінійного зростання складності продукту .
Розробники все голосніше і голосніше матюкаються на якість коду. Це все б нічого (нехай терплять , вони ж САМІ його писали ) , так от лихо - можуть і піти , зі словами « не можу так говнокодіть , замовник сам не знає чого хоче». І нових набрати - непросто і витратно.
Мотивація людей , вимушених часто працювати «на корзину» , закономірно знижується. Це факт. Хто там чого про « ви повинні бути завжди готові до змін ? ». Ага , повинні . Ми взагалі багато чого повинні - зарядку там вранці , зуби на ніч і т. д. Людська психіка - штука невблаганна , і її так просто не обдуриш і не переможеш . Доведено , що робота на кошик - один з головних демотиваторів для професіонала . Це не обговорюється.

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

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

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

І все це якось працює.

[ Від редакції: для повноти картини ми вирішили взяти кілька коментарів у практиків Agile . ]

Олексій Солнцев , Delivery Manager в Infopulse:

По-правді , у статті все перевернуто з ніг на голову. У першу чергу , замовники люблять Agile за рахунок швидкості виведення продукту або його нової версії на ринок. По-друге , ті з них хто колись зустрічався з процесами управління змінами і такими поняттями як « Change Request , Impact Analysis , Change Control Board » розуміють , наскільки дешево їм може обходитися внесення змін у вимоги , якщо вони будуть грати за правилами Agile .

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

Артем Сердюк , з-засновник стартапу 47cups , тренер компанії SCRUMGuides , ScrumMaster і Agile Coach компанії iSM Ukraine:

Якщо клієнти втручаються у вибір процесу (а ним і крім цього є, чим зайнятися ) , у справу вступають не « забобони » , а цінності : те , що для замовників важливо в ІТ -проектах. А важлива для них надійність , передбачуваність , стабільність. Будь-який стандартний процес розробки для замовника краще , ніж бардак. Неважливо , як це називається - Scrum , RUP або CYADD , до тих пір , поки команда виконує обіцянки і є відчуття контролю , клієнту глибоко плювати на процес.

Інша справа , що Scrum , який ми в цьому випадку впровадили , - ні в якому разі не Agile - процес . Agile - процес - це процес , який народжується по ходу розробки. Повторю : не продукт еволюціонує (замовник сам не знав , чого хотів) , а процес . Ті правила , які є на старті , не працюють і весь час змінюються . Ролі змінюються. Довжина ітерацій змінюється. Тільки дуже - дуже базові речі залишаються ... та й то не завжди.

У тому середовищі , про яку говорить автор ( крос - функціональна команда професіоналів , і всі в одній кімнаті включаючи замовника) , Agile - процес не потрібен! Всі стабільно , всі правила відомі - до чого тут адаптуватися ? Буде працювати абсолютно будь-який процес .

А от коли у вас розподілена команда , різниця з клієнтом в 12 годин, нова для нього і для вас предметна область - ось тоді процес буде і правда Agile . Експерименти , провали , експерименти , успіхи . І цей Agile ненавидять як замовники , так і команди розробки , тому винахід нового - це постійний стрес , це нестерпно . Але Agile - єдиний відомий нам спосіб працювати в таких складних і незрозумілих умовах. Тому так і працюємо.

Опубліковано: 12/11/13 @ 09:31
Розділ Різне

SEO Блог

Чому клієнти люблять Agile ?

Рекомендуємо: