Скрамуниздили

-Я хочу влаштувати паніку, зрозуміло?
-Ти там бійню влаштуєш, а не паніку.

«Великий куш»

Протягом вже досить тривалого часу мені попадаються на очі пости, статті і навіть цілі книги, завдання яких — донести до читача поради про те, як правильно робити Скрам. Всі вони, загалом-то, однотипні і побудовані на припущенні, що більшість людей неправильно розуміють пропоновані практики, їх призначення і важливість. У цих джерелах активно доводиться, що Скрам все-таки працює, йдеться про прийняття цінностей, про перестроювання мислення на рівні компанії, про тонкощі організації мітингів та інших нюансах, яких за підсумками кожного разу набирається вагон і маленький візок. Судячи з усього, проблема дійсно існує, адже навіть Кен Швабер та Джефф Сазерленд описують Скрам як "легкий, простий в розумінні і складний в оволодінні" [1]. Але справа тільки в практиках? Може бути, люди не розуміють саму суть Скрама? Коли щось починає приносити серйозні гроші, то не секрет, що саме прибуток стає провідною зіркою цього корабля. Може бути всі ці тренінги, сертифікації і спішно переучивающиеся в скрам-майстрів менеджери проектів затьмарили собою початковий посил? Цілком ймовірно. Але чи це так? Даний опус — це спроба поглянути на проблему під дещо іншим кутом, з точки зору технічної, ніж який-небудь ще.

Стів Макконнелл у своїй книзі «Досконалий код» пише: "складністю Управління — найважливіший технічний аспект розробки ПО. По-моєму, управління складністю настільки важливо, що воно повинно бути Головним Технічним Імперативом Розробки" [2]. Ідея сама по собі не нова — прагнення до простоти пронизує всю історію програмного забезпечення і культивується досі. "Простота — ключ до надійності", казав Дейкстра. "Управління складністю — квінтесенція програмування", вторить йому Керниган. І тут раптово стосовно Скраму ми зустрічаємо визначення «складний в оволодінні». Це ще що таке? У наявності явне протиріччя. Ми тут взагалі-то з усіх сил зі складністю боремося, так навіщо нам явно складна методологія розробки? Нонсенс? Але можливо, відповідь полягає в тому, що Скрам — це не методологія. І не розробки.

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

image

Що ж, давайте розбиратися, спочатку з першим, потім з другим. Звернемося до першоджерела:

Скрам – це фреймворк, в рамках якого можливо вирішувати складні адаптивні проблеми і в той же час продуктивно і творчо розробляти продукти найвищої якості."

Перше, що ми помічаємо, — це слово «фреймворк», і варто відзначити, що саме на такому визначенні наполягає Кен Швабер. Але що таке фреймворк з нашої, технічної точки зору? Це зовнішній каркас, що визначає структуру системи. Однією з характерних рис такого роду каркасів є реалізація принципу інверсії управління. Inversion of Control — поняття, досить широко сьогодні використовується в першу чергу стосовно механізму впровадження залежностей. Однак, як показує практика, люди не тільки плутають поняття IoC і DI, але інколи їх ототожнюють. Давайте ж розберемося з цим раз і назавжди. Розглянемо просту програму:

static class Program {
static void Main() {
A();
B();
C();
}
}

Наш головний метод Main викликає спочатку функцію A та B і, нарешті, C. Це можуть бути бібліотечні функції або якісь внутрішні методи додатки. Таким чином, саме програма визначає набір і послідовність здійснюваних дій, вона сама собою керує. Такий потік управління називають прямим. Якщо напрямок потоку звернути в протилежну сторону, ми отримаємо те, що ще називають голлівудським принципом — не телефонуйте нам, ми самі вам зателефонуємо (або більше технічною мовою: не викликайте нас, ми вас викличемо). Фреймворки реалізують саме такий підхід, надаючи точки розширення. Ми, як розробники підключаємо до цих точках свій код, який викликається рівно тоді, коли зовнішній каркас вважатиме за потрібне це зробити, при цьому код самого каркаса залишається незмінним. Саме цим фреймворки відрізняються від звичайних бібліотек, а подібний потік управління називають інвертованим.

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

Керує Скрам потоком виконання? Так, звичайно. Він надає нам ітеративне-инкрементную концепцію методики, визначає список дій в рамках кожного спринту і навіть визначає розпорядок дня. Тут жодних питань.

Є Скрам незмінним? І знову так. Про це автори говорять нам буквально прямим текстом: “Кожен елемент фреймворку служить визначеної мети і є ключовим для успіху і використання Скрама." Ще одне пряме попадання.

Але що ми вбудовуємо в цей фреймворк, в ці самі точки розширення, що знаходяться між грумингами, стэндапами та ретроспективами? Очевидно, саму розробку з усіма її компонентами: дизайном, тестуванням, проектуванням, конструюванням, рефакторінгом і т. д. Причому зауважте, Скрам жодним чином не намагається лізти в цей процес, не робить спроб ні змінити, ні диктувати свої правила і умови. Як будь-який порядний фреймворк, він нічого не знає про бізнес-логікою, з якою взаємодіє. А це означає, що замість розробки ми можемо вбудовувати та інші речі. І дійсно, на сьогоднішній день Скрам адаптований для сфери фінансів, охорони здоров'я, вищої освіти. Окремі ентузіасти використовують його для будівництва будинків, ведення домашнього господарства і навіть організації весіль. Але стривайте. Якщо ми вбудовуємо розробку під фреймворк, буквально як чорний ящик, то чи не виходить так, що цей зовнішній каркас самої розробкою і не керує? Саме!

Але що ж він тоді робить? За відповіддю далеко ходити не треба, достатньо повернутися до першоджерела: "вирішує складні адаптивні проблеми". Зокрема, "показує відносну ефективність управління продуктом і практик розробки", а результатом такого спостереження є "можливість їх поліпшити".

Щоб краще зрозуміти, про що йде мова, зробимо невеликий екскурс в історію. Роберт Мартін, відомий в широких колах також як Дядечко Боб, у своїй промові «Майбутнє програмування» [3] виділяє дві передумови появи гнучких процесів. Одна з них полягає у тому, про що ми і так з вами в загальному-то в курсі: в 90-х світ розробки ЗА почав активно змінюватися, і водоспад став давати збої. Відповідно, потрібні були нові підходи, орієнтовані на динамічні бізнеси з усіма відповідними характеристиками: необхідністю швидкої адаптації до ринку, схильністю до постійних змін і т. д. Недарма Кент Бек називав однією з головних цілей Agile "стирання межі між розробкою і бізнесом". Ще більше перейнятися цим твердженням можна, якщо взяти до уваги, що насправді Бек використовував слово «internet» — зцілення. Проте дивитися на ситуацію з точки зору одного тільки бізнесу було б неправильно. Якщо ви відкриєте список авторів знаменитого Agile-маніфесту, то виявите, що практично всі ці люди — пропалені технарі. Цілком логічно припустити, що вирішували вони не тільки проблему бізнесу, але і якусь свою власну, суто технічну. І це дійсно так. За емпіричною оцінкою того ж Боба Мартіна кількість програмістів збільшується вдвічі кожні п'ять років. Це означає, що в будь-який момент часу, взагалі кажучи, половина всіх розробників — це люди з досвідом, не перевищує п'ятирічний термін. Чи є це проблемою? Мабуть, що так. Знову ж таки, суть питання не в конкретному часовому відрізку, а у кількості досвіду як такого, адже, будемо відверті, кореляція між часом і рівнем знань існує і досить висока. Таким чином, гнучкі методології не тільки намагаються задовольнити потреби бізнесу, надаючи йому більш зрозумілу, зручну і вигідну модель розробки програмних продуктів, але і займаються питанням недостатнього рівня професіоналізму в команди програмістів.

Скрам ж, будучи фреймворком, надає організаційний інструмент, що дозволяє, подібно лакмусовим папері, максимально швидко виявляти проблеми в цих двох областях і оперативно на них реагувати. Але не більше. Якщо ви не вмієте налагодити роботу з вимог, а ваші розробники пишуть неякісний, выползающий з усіх строків та бюджетів код, то сам по собі Скрам не змінить рівним рахунком нічого. Найбільша помилка якраз полягає в тому, що люди очікують, що одне тільки його застосування здатне оптимізувати внутрішні процеси. "Ваші очікування — це ваші проблеми", як казав один відомий футболіст. Звідси ж випливає, що завдання скрам-майстра полягає не стільки в пильному і ревному спостереженні за подіями, артефактами і правилами фреймворку, скільки саме у виявленні та усуненні виникаючих проблем. І так, це означає, що він повинен не тільки вміти відрізнити хорошу власну історію від поганої, але й безпосередньо впливати на технічні аспекти розробки, такі як впровадження тих чи інших інженерних практик. Чотири цінності і дванадцять принципів — це лише вершина айсберга Agile, а підтримують їх конвенція іменування, еволюційний дизайн, огляди коду, розробка через тестування, рефакторинг, безперервна інтеграція, шаблони проектування, парне програмування та інші численні технічні методики. Пам'ятайте: неможливо вирішити проблеми розробки з допомогою одних лише організаційних висновків. Від стэндапов і ретроспектив самих по собі кращий код не з'явиться у ваших репозиторіях. Але він має всі шанси там опинитися, якщо з допомогою інструментів Скрама ви навчитеся виявляти проблеми команди в технічних областях і будете володіти достатнім запасом компетенції, щоб застосовувати до них саме технічні рішення.

І тоді ніхто і ніколи не зможе скрамуниздить ваш «чистий код, який працює» [4].

[1] Scrum Guide
[2] Стів Макконнелл «Досконалий код»
[3] The Future of Programming
[4] Рон Джеффріз
Джерело: Хабрахабр

0 коментарів

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