Лекція 6. Екстремальне програмування

Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming - XP). Этот метод предназначен для компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты. Экстремальное программирование – методология быстрой разработки программного обеспечения. Состоит из набора методик и принципов, позволяющих как по отдельности, так и в комплексе, оптимизировать процесс разработки. Этот подход также регламентирует права разработчиков и заказчиков.

Базові принципи

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

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

Прийнятна простота — необхідно вирішувати кожну проблему так, як якби її можна було вирішити самим сміхотворним простим способом.

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

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

Якісна робота — ніхто не любить погано працювати. Кожному подобається робити свою роботу «відмінно». З чотирьох раніше розглянутих змінних (об'єм робіт, витрати, час і  якість) якість насправді немає вільно змінній змінній. Єдино можливими для неї значеннями є «чудово» і  «неймовірно чудово» — вибір між цими двома значеннями залежить від того, чи поставлені на карту людські життя. Інакше ваша робота вам не подобається, ви працюєте погано і  ваш проект необоротно витікає в  стічну канаву.

Далі приводиться перелік менш важливих принципів:

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

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

• игра для того, чтобы победить – в одном случае команда играет для того, чтобы выиграть, а в другом случае — для того, чтобы не проиграть. Если разработка программного продукта осуществляется для того, чтобы победить, каждый член команды делает все, чтобы помочь команде выиграть и не делает чего-либо такого, что может помешать этому;

  • надійне експериментування – кожного разу, коли ви ухвалюєте рішення і  не тестуєте його, існує вірогідність, що ухвалене вами рішення неправильне. Чим більше таких рішень ви ухвалюєте, тим вище стає ця вірогідність. Саме так збільшується ризик. Щоб понизити ризик, результатом сеансу проектування повинні стати не завершений дизайн, а  серія експериментів, що відповідають на питання, які виникли у  вас в процесі проектування.

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

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

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

  • локальна адаптація – ви повинні самостійно визначити, як ви повинні розробляти програмний продукт. Ви не повинні думати так: «Тепер я  знаю, як слід розробляти програми». Замість цього ви повинні сказати собі: «Я повинен обдумати все це, а потім вже приступати до  програмування».

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

  • відверті оцінки – наше бажання контролювати процес розробки програмного забезпечення веде нас до  необхідності оцінки. Ця оцінка повинна бути достатньо точною.

У екстремальному програмуванні існують дві ключові ролі: замовник і розробник.