Ви обговорили з Замовником і домовилися випустити в найближчому релізі важливі для продукту фічі, які так давно і з нетерпінням чекають Користувачі. Ви на крилах несетеся на PlanningPoker, починається оцінка і бац...
- Давайте не лізь у цей модуль. Код недокументовано, все почне глючити і сипатися, особливо білінг.
- До нас працювала команда дурнів, вони вчилися програмувати на цьому проекті. Якщо сюди лізти, в команді впаде мотивація...
- Як це працює... Це треба в код дивитися. Люди, які писали, вже пішли, документації немає. Місяць мінімум.
- Ми залили дані, і все стало гальмувати. Треба спринт присвятити дослідженню причин. (і так кілька спринтів поспіль)
Ви розумієте, що відбувається щось дивне, що проект «захворів», що можна було напевно цього уникнути, якщо знати заздалегідь...
Постараємося зрозуміти, кому «бити морду» зараз і кого відмутузити профілактично коли до нас прийде наступний проект - щоб уникнути подібного колапсу.
Старий проект
Ситуація передбачувана. Коли проект дістався нам у спадок, нерідко трапляється, що код - незрозумілий, а документації немає або вона безнадійно застаріла. Розробники при згадуванні назви проекту починають плюватися.
PlanningPoker виявляє проблему - колеги намагаються зрозуміти, як влаштований той чи інший модуль, щоб оцінити, СКІЛЬКИ ЧАСУ ДОДАВАТИ ФІЧУ в цей модуль, але - все настільки заплутано, що з жахом розуміємо: щоб дати адекватну оцінку потрібно витратити кілька тижнів на розбір цього р... окоду. А щоб переписати/жорстко відрефакторити - будуть потрібні місяці, якщо не більше.
А ще потрібно вміти рефакторити не тільки код, застосовуючи з розумінням їх суті шаблони проектування, але й успішно витягнути з нутрощами г... логіку з недокументованої бази даних.
Потрібен системний підхід. Кому доручити, з ким домовитися?
Новий проект
А ось це може стати для початківців ProductOwner справжнім сюрпризом! Новий проект - який починає розкладатися.
Поки проект тільки починається, немає приводу для побоювань. Оцінки на PlanningPoker поступово стають точнішими, швидкість команди збільшується, регулярні демонстрації підвищують настрій і віру в досягнення мети релізу. Чіткий бадьорий ритм.
Симптом 1: Технічний бекліг почав зростати
Поступово, однак, все більше завдань починає з'являтися в технічному беклозі - туди розробники ставлять фічі для рефакторингу. Так, ми знаємо, щоб код проекту не «протух», потрібно «вирішувати» розробникам виявляти криві/складні моменти в коді, говорити про них на ретроспективах, і реєструвати даний клас завдань, щоб у тлі ними займатися.
Іноді це ознака... початку кінця. Команда, усвідомивши, що пішла не туди, ускладнила код, який почав на очах розсипатися, намагається почати знову і знову його переписувати - намагаючись виділити для цей час на черговому розподілі завдань:
- Ми ось обговорили... Ми написали модуль, використовували бібліотеку ORM - але вона нам не підходить, занадто складна, ми хочемо писати запити в базу безпосередньо (витрачено 2 місяці)
- Ми тут ускладнили об'єктну ієрархію спадкування, чорт не розбереться. Треба переписувати (новий проект!, дайте калаш).
Сімптом 2: «Нестабільні» спринти
Ще одна ознака можливого кінця - написаний у попередніх спринтах функціонал чомусь... не стабілізується:-). Він сипле багами і на їх виправлення йде все більше і більше часу. Так, в якийсь момент начебто потік багів зупиняється - але при мінімальній зміні функціоналу - відкривається з новою силою. Ми ж повинні, по ідеї, приймати зміни вимог з розпростертими обіймами, а тут - кашлянути страшно.
Симптом 3: «Гальма»
Все йшло як по маслу. Але ось завантажили в систему тестові дані і... вона лягла. Виявляється, не всі програмісти розуміють, що код повинен працювати практично «незалежно» від обсягу даних, не можна вибирати з таблиці всі записи і обробляти їх в коді, ворочаючи в пам'яті сотнями мегабайт і т. п.
Нерідко, щоб навчити систему працювати з очікуваним обсягом даних, потрібно серйозне переписування, яке може розтягнуться на місяці (!). А потім ще тестувати, тестувати...
Симптом 4: Матриця «незалежності»
Є ще страшна штука, про яку знають тільки досвідчені бійці, що пройшли великі проекти. Поки проект поміщається у команди в голові - немає причин для занепокоєння. Додати фічу нескладно - збираємося і розуміємо, що буде і де в системі позначиться, якщо ось тут і тут поміняти логіку.
Але коли система/веб-сайт стає великим, то... люди починають губитися. Простий приклад з життя:
PO: Колеги, потрібно додати підтримку додаткового алгоритму застосування знижки.... Оцінюємо.
Розробники: Для цього потрібно виправити бібліотеку тут, поправити шаблон виводу там. Напевно (!) все.
Так от. Виявляється після впровадження фічі... вилетіли кілька платіжних систем. Причому про це відразу дізналися Клієнти і «позитивно» відреагували.
А ми знаємо, що існують інструменти відстеження залежностей, і в «дорослих» процесах розробки вони застосовуються, тому що без них слово «напевно» в команді буде повторюватися все частіше і частіше.
Автоматизовані тести... так, вони протестують код, та й то, якщо їх писати відразу і ГРАМОТНО. А як вони складні бізнес-вимоги протестують, залежності між алгоритмами? Потрібні інші інструменти, вже для аналітиків.
Ускладнення - підступний ворог
Створюється відчуття, що чим більше проект, тим більш некерованим і запущеним він стає - як для розробників, так і для ProductOwner, так і для Замовника.
Каші стає все більше.
Найстрашніше, що є (по секрету), так би мовити «точка неповернення», після якої повернути проект в керований стан дуже і дуже складно і його дешевше закрити до біса, тому що всі заплуталися і все безмірно глючить і зловісно розтікається.
Кому бити морду?
Коли запускаєш десятки проектів, то починаєш природним чином аналізувати причини невдач і, дотримуючись духу ретроспективи, робиш висновки. Минають роки і виробляється чуття на баланс виробничого процесу, який напевно можна порівняти з музичним слухом.
ІМХО в компанії, що використовує Agile, повинен бути сильний технічний директор, спинним мозком відчуває БАЛАНС використовуваних методологій та інструментів. Читання книжок за процесами розробки допоможе почасти - потрібно саме чуття.
Причому чим проекти складніші, тим потрібно більше знань, досвіду і волі, щоб вони не пройшли «точку неповернення». Техдир трохи проспить і пара-трійка проектів пройдуть точку неповернення - можна звичайно півроку-рік створювати видимість роботи, посміхатися і всім виглядом показувати що все добре і під контролем, а потім раптово звільнитися з відволіканої причини.
Ключові завдання техдира
Отже ми побачили, що в agile-розробці техдир ніби повинен постійно вигравати в Тетріс - скільки зверху не спускається проектів, ВИРОБНИЦТВО має бути збалансованим і складність не зашкалювати. Завжди O (1) і гарний настрій; -):
- Архітектура залишається простою, за рахунок грамотного використання, коли це необхідно, шаблонів проектування (Simple Design в XP). Якщо розробники, навчені техдиром, бачать спинним мозком ускладнення, починається рефакторинг. Або техдир ставить сильних досвідчених архітекторів на складні проекти.
- Код проектів не «протухає» - розробники, навчені техдиром, розвинули нюх і ставлять завдання з вичищення поганого коду в технічних беклог.
- Код готовий до великих обсягів даних - розробники кваліфіковані, розуміють що пишуть. Тим не менш, техдир прописав у чеклист готовності проекту обов'язкове проведення навантажувального тестування.
- Або відразу використовуються юніт та інші види автотестів, або вони використовуються для складних частин проекту. Тут же можна, іноді, прикрутити різновид Continuous Intergration.
- Проект обов'язково грамотно розбитий на модулі і вони максимально незалежні один від одного - тому зміна в одному модулі швидше за все не торкнеться інших частин системи.
- Технічна документація ведеться або з використанням автоматизованих інструментів (типу phpdoc), або налаштований бізнес-процес і зміни йдуть у відділ документації.
- Аналітична документація, діаграми, схеми БД і все, що роблять аналітики - розбита на модулі і акуратно підтримується ними в актуальному стані. Аналітики не дивляться в код, але повинні ясно розуміти всі бізнес-процеси в системі/модулі, щоб бути здатними щось спроектувати далі.
- Талановиті люди залишаються в команді, тому що їм дають займатися цікавими і складними завданнями. У командах поважна професійна атмосфера, за якою стежить Техдир, не підпускаючи до людей непрофессинальних кар'єристів.
Якщо таку людину не вдається знайти - залишається одне, вибудувати складний мегаформалізований процес з взаємозамінними співробітниками. Це напевно буде дорожче і довше.
Підсумок
Щоб ProductOwner був щасливий, щоб фічі робилися в оцінений термін і зберігався впевнений рух за планом релізів, щоб жива істота під назвою «Програмний продукт» не вивергалася фонтанами нечистот в найнесподіваніші моменти, особливо перед клієнтми - потрібно знайти грамотного і досвідченого технічного директора, який працює за різновидом вищепереліченого чекліста, відчуваючого спинним мозком баланс інструментів.
Інакше - буйного коня Agile вам не осідлати.
