Екстремальне програмування?, Різне, Програмування, статті

Георгій Філягін

– В моєму уявленні, назва «екстремальне програмування »було вибрано за аналогією з« екстремальними видами спорту »: повітряним серфінгом, парашутування з хмарочосів і тому подібним. Іншими словами – небезпечне, що стоїть на грані, майстерне. Проблема в тому, що я представляю картину, де хлопець з ноутбуком програмує на Delphi, здійснюючи стрибок у воду з п’ятдесятиметровій скелі!


– І чим це відрізняється від звичайного програмування?


(Фрагмент обговорення екстремального програмування у конференції borland.public.delphi.non-technical)

Історія екстремального програмування (ЕП) почалася в першій половині 90-х років. Автор терміну Кент Бек (Kent Beck) обдумував нові підходи до створення програм. Працюючи спільно з іншим розробником над черговим проектом, Кент помітив кілька прийомів, завдяки яким вдавалося підвищити ефективність праці. У березні 1996 року Кент спробував використовувати накопичені спостереження в роботі над новим завданням, що виконуються на замовлення фірми «Даймлер-Крайслер». В результаті він сформулював положення, пізніше стали відомими як методика екстремального програмування (Extreme Programming).


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


Можливо, для програмістів зі стажем «відкриття» Кента можуть здатися одночасно і очевидними, і надуманими. Тому спробуємо розібратися, скориставшись матеріалами сайту www.extremeprogramming.org/.


Новий підхід

Екстремальне програмування будується на тому, що створювати просту і зрозумілу програму вигідніше, ніж складну і заплутану. Типовий проект (пам’ятаєте, що мова йде про розробки, які виконуються на замовлення західних компаній) передбачає приблизно в 20 разів більші витрати на працю програмістів, ніж на апаратне забезпечення. Що це означає? У проекті вартістю 2 млн. дол. близько 100 тис. витрачається на комп’ютери. Припустимо, вам вдалося підвищити ефективність роботи програм, що призвело до зниження вимог до апаратного забезпечення, і ви досягли економії в 20% – 20 тис. дол Тепер уявіть, що вдалося якимось чином написати програми так, що на їх підтримку і доопрацювання витрачається на 10% менше людських ресурсів. А це вже економія в 200 тис. дол!


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


Ще одна особливість, приваблива для замовника, – готовність програмістів до постійних змін в проекті. Часто замовник має можливість коригувати роботу тільки в той момент, коли не найпридатніші рішення в програмі вже втілені. За рахунок постійного зворотного зв’язку з замовником ЕП дозволяє вносити зміни саме на тій стадії, коли це дійсно ефективно.


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


Де і коли?

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


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


Неможливо використовувати ЕП на гігантських проектах – воно підходить для невеликих груп програмістів (від 2 до 10 чоловік). При постійно мінливому технічному завданні така група може бути помітно ефективніше великого колективу, який використовує традиційні методики.


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


Ще один критерій застосовності ЕП – особливості предметної області. Повинна існувати можливість створення автоматизованого тесту. Хоча для багатьох областей це так, але є й такі області, де дана вимога нездійсненно. Для перевірки необхідно провести попередні тести. Іноді потрібно переформулювати завдання або перетворити систему, щоб забезпечити автоматизоване тестування.


Проекти ЕП свідчать про більшу продуктивність праці залучених до них програмістів в порівнянні з аналогічними проектами, виконуваними по звичним методиками. Однак зростання продуктивності не був початковою метою ЕП. Головна мета – розробка програм в необхідні терміни. Якщо для вас це важливо, то, можливо, настав час спробувати ЕП.


Формулювання

Замість терміна «технічне завдання» ЕП використовує термін «формулювання користувача ». Формулювання дозволяють оцінити час, необхідне для розробки програми. Вони записуються користувачами як опис дій, які повинна виконувати система. Формулювання схожі на сценарії використання, але не обмежуються описом інтерфейсу користувача. Кожна формулювання займає три-чотири пропозиції в термінах замовника (не програміста!).


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


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


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


Планування

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


Головним підсумком є ​​план випуску версій, що охоплює весь проект. Далі цей план використовується для створення планів кожної ітерації. Ітерації детально плануються безпосередньо перед початком кожної з них. Найважливіше завдання – правильно оцінити терміни виконання робіт по кожній з користувацьких формулювань.


Часто при складанні плану замовник в першу чергу намагається скоротити терміни. Цього робити не варто, щоб не викликати проблем пізніше. Основна філософія планування будується на тому, що проект вимірюється в чотирьох параметрах: обсяг, ресурси, час і якість. Обсяг – скільки роботи має бути зроблено, ресурси – як багато розробників знаходиться у вашому розпорядженні, час – Коли проект буде закінчений, якість – наскільки добре буде реалізована і протестована програма. Можна, звичайно, встановити тільки три з чотирьох величин, але рівновага завжди буде досягнуто за рахунок залишилася.


План релізів

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


Ітерації

Ітерації надають процесу розробки динамічність. Не потрібно планувати ваші програмні завдання надовго вперед. Краще замість цього влаштовувати нараду для планування на початку кожної ітерації. Не варто й намагатися реалізувати те, що не було заплановано. У вас ще буде час, щоб реалізувати ці ідеї, коли до них дійде черга згідно з планом релізів.


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


Планування ітерацій

Планування ітерацій починається із зустрічі на початку кожної ітерації з метою вироблення плану кроків для вирішення програмних завдань. Кожна ітерація повинна тривати від однієї до трьох тижнів. Формулювання всередині ітерації сортуються в порядку їх значущості для замовника. Крім того, додаються завдання, які не змогли пройти тести приймання і вимагають доопрацювання. Формулювання і результати тестів переводяться в програмні завдання. Завдання записуються на картках, які утворюють детальний план ітерації. Для вирішення до кожної з задач потрібно від одного до трьох днів. Завдання, для яких потрібно менше одного дня, можна згрупувати разом, а великі завдання розділити на кілька дрібних. Розробники оцінюють завдання і терміни, для їх виконання. Для розробника дуже важливо точно встановити час виконання завдання. Можливо, буде потрібно переоцінити деякі формулювання і переглянути план релізу після кожних трьох або п’яти ітерацій – це цілком допустимо. Якщо ви в першу чергу реалізуєте найбільш важливі ділянки роботи, то ви завжди будете встигати зробити максимум можливого для ваших клієнтів. Стиль розробки, заснований на послідовності ітерацій, покращує процес розробки.


Щоденні ранкові наради (планерки)

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


Все геніальне – просто

Простий дизайн завжди займає менше часу, ніж складний. Тому завжди робіть самі прості речі, які тільки зможуть працювати. Завжди швидше і дешевше замінити складний код відразу, перш ніж ви витратите багато часу на роботу з ним. Зберігайте речі такими простими, як тільки можливо, не додаючи функціональність до того, як це заплановано. Майте на увазі: зберігати дизайн простим – це важка робота.


Система метафор

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


Попередні рішення

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


Взаємодія з користувачем

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


Вихідні тексти

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


Колективне володіння вихідними текстами дозволяє кожному висувати нові ідеї в будь-якій частині проекту. У випадку досить великих систем одна людина просто не в змозі утримати в голові всю архітектуру проекту. Завдяки колективному володінню вихідними текстами знижується ризик прийняття головним розробником невірного рішення і усувається небажана залежність проекту від однієї людини.


Парне програмування

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


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


Зміна позицій

Під час чергової ітерації всіх працівників слід переміщати на нові ділянки роботи. Подібні переміщення необхідні, щоб уникнути ізоляції знань і усунути «вузькі місця». Особливо плідною є заміна одного з розробників при парному програмуванні.


Інтеграція

Без послідовної та частою інтеграції результатів розробки програмісти не можуть бути впевнені, що вони правильно розробляють проект. До того ж неможливо вчасно оцінити якість виконаних фрагментів роботи та внести необхідні корективи.


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


Не додавайте функціональність занадто рано

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


Безжально переробляйте

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


Оптимізуйте в останню чергу

Чи не оптимізуйте до тих пір, поки не буде готове все. Ніколи не намагайтеся передбачити, де в продуктивності системи буде «вузьке місце». Знаходьте його за допомогою вимірювань на готовій системі. Спочатку змусьте систему працювати, потім переконайтеся, що вона працює правильно, і тільки після цього зробіть, щоб вона працювала швидко.


Не працюйте понад графіка

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


Помилки і тестування

Тестування – один із наріжних каменів ЕП. Ви повинні забезпечити автоматичне тестування як окремих модулів, так і всіх класів в системі. Не забувайте, що створення тестів повинно передувати розробці програми. Тест необхідно поміщати в бібліотеку кодів разом з кодом, який він тестує. Головна причина недостатнього тестування – наближається термін здачі проекту. Проте тест економить у багато разів більше часу і грошей, полегшуючи виявлення помилок. Чим складніше написати тест, тим він більш необхідний, оскільки тим більше подальша віддача від нього.


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


Остаточні тести грунтуються на формулюваннях користувачів. Ці тести розглядають вашу систему як «чорний ящик» і розраховані на отримання цілком певного результату роботи системи.


Тести слід автоматизувати, щоб їх можна було виконувати часто. Грунтуючись на результатах тестів, розробники включають в чергову ітерацію роботу над помилками.


З чого почати?

Спробуйте використовувати ЕП у вашому наступному проекті. Почніть зі збору формулювань і вироблення попередніх рішень. Потім зберіть нараду і розробіть план виходу версій. Щоб план був прийнятний для всіх, у нараді повинні брати участь замовники, розробники і керівництво. Приступайте до ітеративної розробці з наради по першій ітерації.


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


Коментар

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*