Масштаб – ворог успіху

Дейв Куїк

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

Чому так відбувається Розглянемо кілька прикладів

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

• Наші оцінки – аж ніяк не точна наука Хто з нас не потрапляв у ситуацію, коли реалізація якоїсь функції виявлялася набагато складніше, ніж передбачалося спочатку

Звичайно, деякі завдання спочатку увазі виконання проекту певного масштабу і складності Написати текстовий редактор без можливості введення тексту нескладно, але його навряд чи можна буде назвати

Див книгу Фредеріка Брукса «Міфічний людино-місяць, або як створюються програмні системи» (СПб: Символ-Плюс, 2000)

текстовим редактором Які ж стратегії допомагають керувати кордонами в реальних проектах

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

• «Розділяй і володарюй» Шукайте можливості розділити роботу на менші незалежні фрагменти Керувати кількома невеликими незалежними проектами простіше, ніж одним великим проектом з взаємоповязаними частинами

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

• Демонструйте результати якомога швидше Люди рідко розуміють, що їм потрібно, поки не отримають якийсь результат У відомому коміксі[7] представлена ​​еволюція проекту дитячих гойдалок: що сказав замовник і як його вимоги зрозуміли учасники проекту, що виконують ті чи інші ролі У підсумку виходить хитромудре споруда, лише віддалено нагадує гойдалки А на останньому малюнку під назвою «Чого хотів замовник» зображені найпростіші гойдалки з автомобільної покришки на мотузці Коли у замовника є щось, що він може особисто випробувати, рішення деколи виявляється простіше, ніж передбачалося При першочергової реалізації найважливіших функцій ви в якості зворотнього звязку отримуєте найважливішу інформацію на ранній стадії, коли вона потрібна найбільше

Прихильники гнучких методологій закликають нас будувати «найпростіше, що буде працювати»[8] Невдачі проектів зі складною архітектурою відбуваються набагато частіше, ніж з простої Скорочення кордонів проекту часто призводить до спрощення архітектури – і це одна з найефективніших стратегій, що дозволяють архітекторові підвищити шанси успішного завершення проекту

Біографія автора наведена на сторінці 65

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

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


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

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

Ваш отзыв

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

*

*