1. Частина 2. Маніфест і принципи гнучкої розробки Даний матеріал є продовженням циклу статей, присвячених...
2. Маніфест гнучкої розробки програмного забезпечення

Частина 2. Маніфест і принципи гнучкої розробки

Даний матеріал є продовженням циклу статей, присвячених темі гнучких методів розробки програмного забезпечення. У першій частині циклу (див. "КВ" № 33 ) Ми з'ясували, що гнучкі методи з'явилися як спроба виправити недоліки традиційних інженерних методологій розробки, заснованих на детальному попередньому плануванні і водоспадних життєвому циклі. Ближче до кінця 90-х років на противагу великоваговим і надмірно формалізованим інженерним методологій з'явилося ціле сімейство нових "легких" методологій, таких, як Scrum, XP, DSDM, Crystal і т.д. У лютому 2001 року на зустрічі групи творців і лідерів легковажних методологій було вирішено в якості об'єднуючого назви використовувати слово agile (гнучкий, швидкий, моторний). Тоді ж були створені два основних документи, що визначають наповнення слова agile: Маніфест і Принципи гнучкої розробки програмного забезпечення. Мета сьогоднішньої статті - зрозуміти основні ідеї гнучкої розробки, познайомившись з вмістом цих двох документів.

Agile - нове сімейство методологій розробки

Отже, в лютому 2001 року, по суті, офіційно оформився новий напрям розвитку методологій розробки програмного забезпечення. На зміну хаосу ранніх підходів до розробки (code-and-fix) і суворої формалізації інженерних методологій прийшло сімейство гнучких методологій, заснованих на Маніфесті і Принципах розробки програмного забезпечення.

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

Маніфест гнучкої розробки

Маніфест гнучкої розробки [1] містить чотири пункти, кожен з яких представляє собою альтернативу. У лівій частині цих альтернатив містяться поняття і аспекти, які мають більшу цінність, ніж поняття і аспекти в правій частині. З точки зору авторів Маніфесту, така порівняльна форма (а не просто перерахування цінностей) допомагає краще зрозуміти, з яким вибором доводиться стикатися при реалізації проектів і що саме слід вибирати тим, хто хоче керуватися гнучкими цінностями розробки.

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

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

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

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

Принципи гнучкою розробки

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

Перший і другий принципи тісно пов'язані з останньою з альтернатив Маніфесту. Найвищим пріоритетом в гнучких методологіях вважається не точне проходження початкового плану проекту, а задоволення замовника та досягнення тих бізнес-цілей, заради яких починався проект. Таким чином, трактування поняття успіху проекту в agile відрізняється від традиційних підходів, в яких проект вважався успішним, якщо були задоволені всі 3 основних проектних обмеження (бюджет, терміни, обсяг вимог). Гнучкі методології небезпідставно наполягають на тому, що саме по собі виконання плану ще не приносить ніякої користі, більше того, саме зміни в початковому плані можуть в результаті надати найбільшу цінність проекту (перш за все, тому, що вони засновані на зворотному зв'язку і найбільш свіжої інформації про внутрішні і зовнішні чинники, наприклад, таких, як становище на ринку, стан аналогічних продуктів у конкурентів і т.п.).

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

Четвертий принцип наголошує на необхідності тісної співпраці команди проекту і замовника протягом всього життєвого циклу проекту. Як афористично пишуть М. Фоулер і Дж. Хайсмит [3], багато замовників думають, що замовне програмне забезпечення можна купити так само, як ми купуємо автомобіль: домовитися про ціну, заплатити і спокійно очікувати отримання своєї покупки. Однак у випадку з софтом отриманий в результаті продукт буде, швидше за все, як небо і земля розниться з очікуваннями замовника. Щоб отримати на виході щось путнє, необхідно працювати в тісному контакті з командою проекту, забезпечуючи зворотний зв'язок.

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

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

Сьомий принцип ще раз підкреслює, що якщо метою проектів є створення програмного забезпечення (а не планів, документації тощо.), То і прогрес проекту можна об'єктивно виміряти, лише оцінюючи працездатний додаток (або його частина). Одна з проблем водоспадного життєвого циклу як раз і полягає в труднощі об'єктивної оцінки прогресу. Інтегрований працездатний продукт з'являється в Водоспадної моделі лише в кінці життєвого циклу, і до цього моменту команда може нічого не підозрювати про можливі проблеми.

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

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

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

висновок

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

Костянтин РАЗУМОВСЬКИЙ, [email protected]

посилання:

1. agilemanifesto.org - Маніфест гнучкої розробки програмного забезпечення
2. agilemanifesto.org/principles.html - принципи гнучкої розробки програмного забезпечення.
3. www.ddj.com/architect/184414755 - Стаття співавторів Маніфесту М. Фоулера і Дж. Хайсміта, що містить аналіз Маніфесту і Принципів гнучкої розробки.

Маніфест гнучкої розробки програмного забезпечення

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

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

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

Принципи гнучкої розробки програмного забезпечення

1. Нашим головним пріоритетом є задоволення замовника за допомогою ранньої і безперервного постачання працездатного програмного забезпечення.
2. Вітайте мінливі вимоги навіть на пізніх стадіях розробки. Гнучкі процеси використовують зміни як засіб отримати конкурентні переваги для замовника.
3. Поставляйте працездатне програмне забезпечення часто: від разу на кілька тижнів, до разу на кілька місяців, віддаючи перевагу коротким інтервалом.
4. Представники бізнесу і розробники повинні працювати разом протягом всього проекту.
5. Будуйте проекти навколо мотивованих особистостей. Необхідно надати їм середовище і підтримку, якої вони потребують, і довірте їм самим зробити роботу.
6. Найбільш ефективний спосіб передати інформацію в команду проекту (а також передавати її всередині команди) - це безпосереднє живе спілкування.
7. Основним заходом прогресу проекту є працездатне програмне забезпечення.
8. Гнучкі процеси сприяють розробці з постійною швидкістю. Спонсори проекту, розробники і користувачі повинні бути здатні підтримувати постійну швидкість на необмеженої дистанції.
9. Безперервне увагу технічній досконалості і хорошого дизайну збільшує ступінь гнучкості.
10. Простота - мистецтво максимізації роботи, яку не треба робити, - є суттєвим фактором.
11. Найкращі архітектури, вимоги та дизайн створюються самоорганізації командами.
12. Через регулярні проміжки часу команда повинна проводити аналіз того, як стати більш ефективною і покращувати свій процес роботи.