Чи є переваги гнучких практик, крім того, щоб мати робочу конструкцію між спринтами?

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

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

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

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

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

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

По-перше, модель "водоспад" завжди була солом'яною людиною, яка описувала, як НЕ запускати проект розробки програмного забезпечення. Подивіться.

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

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

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

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

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

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

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

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

У відповідь на цитату з питання, що є принциповим неправильним уявленням проти спритних противників

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

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

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

Те саме з YouTube, Twitter та незліченною кількістю інших компаній.

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

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

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

Агільна розробка програмного забезпечення вимагає технічної майстерності від команди. Це випливає з наступних технічних практик XP (екстремальне програмування). Наприклад, ви повинні дізнатися про рефакторинг, tdd, всю команду, програмування пар, інкрементальний дизайн, ci, співпрацю тощо.

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

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

Для мене головною перевагою спритного є зниження ризику в проекті.

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

Ви можете стверджувати, що ця постійна зміна компрометує вашу систему і знижує якість, але я б сказав дві речі. 1) Ця зміна все-таки відбувається в більш традиційних проектах з доставки програмного забезпечення - вона просто не враховується і виникає пізніше в проекті, коли це, як ви вказали, важче і дорожче змінити. 2) Agile має багато що сказати про подолання цієї зміни з точки зору використання досвідчених людей з мотивацією та таких практик, як TDD, спарювання та перегляд коду. Без такої зміни в налаштуваннях на якість та постійне вдосконалення я приймаю, що часті зміни, сприятливі для яких, можуть почати створювати проблеми.

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

Якщо ваша архітектура потребує значних змін у результаті зміни вимог, у вас є погана архітектура або погані вимоги. Хороша архітектура дозволяє відкласти якомога більше рішень та роз’єднати компоненти вашої системи. Гарні вимоги (користувача) - це не такі речі, як "використання іншої бази даних".

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

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

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

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