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

Мінливий світ інтернету та програмування сайтів

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

Друга проблема добре відома і відображена в давньої мудрості: щоб задати правильний питання, треба знати половину відповіді. У ситуації, коли кожен новий сайт ви розробляєте з використанням щойно з'явилися технологій (нові модулі, нова версія власного движка, нова версія бази даних), - фактично ви кожен раз багато робите заново. Це значно ускладнює процес створення сайтів Рівне, тому що ви не знаєте, як будете це розробляти і на якій платформі Joomla чи Drupal. А можливо у ТЗ буде створення інтернет-магазину на основі Magento, що тоді?

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

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

Екстремальне програмування сайтів

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

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

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

На основі такого опису команді розробників, дизайнерів, верстальників стають зрозумілі їхні найближчі кроки. Основні архітектурні рішення, загальні рамки майбутнього сайту, загальна будова. Але я підкреслюю - найближчі кроки. Досить одного-двох. Кроки повинні бути невеликі (тиждень, кілька днів). Після кожного кроку - перегляд всіх умов, облік всіх змін. В екстремальному програмуванні такі кроки називають ітераціями.

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

Спілкування з замовником

І все ж нам потрібно чимось замінити відсутність формального технічного завдання, - адже ми повинні зробити те, що потрібно замовнику. Вихід - тісне спілкування з представником замовника і користувачами на всіх етапах робіт (не тільки в точках перевірки, не тільки на початку і кінці робіт, а протягом всього часу роботи над проектом).

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

Щоденні релізи по розробці сайту

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

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

Творчість, а не копіювання

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

  • Тестування до початку розробки.
  • Парне програмування.
  • Постійний рефакторинг.
  • Простота розробки.
  • Колективне володіння кодом.
  • Швидкий випуск версій.
  • Постійна інтеграція.
  • Стандарти кодування.

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

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

Простота розробки - з двох варіантів вибирається більш простий і швидко реалізований.

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

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

Співпраця, а не конфлікт

Одне з важливих наслідків прийняття концепції хаотичності навколишнього світу - зникнення конфліктів між менеджерами та виконавцями. Ці, здавалося б, вічні "граблі" добре знайомі всім, хто має відношення до розробки веб-сайтів Рівне. У традиційній (каскадної) моделі розробки пік конфлікту доводиться на найважливіший етап - предвипуск або випуск проекту. Головна причина - розробники зробили не зовсім те, що хотів менеджер або замовник.

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

Спіральна модель життєвого циклу розробки сайтів

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

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

Автори матеріалу: Вікторя Марчук, Ігор Саленко та Ольна Днувець, підготували для IT-огляду.