Agile методологія: швидка та брудна чи планувати спочатку?

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

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

Я вважаю, що це питання дещо інше, ніж Agile та прототипування, оскільки я не запитую про прототипування та скидання коду; Мене цікавить спритний код виробництва.

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

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

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

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

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

Мені не подобається, що для більшості людей це або "швидкий і брудний", або "великий дизайн вперед". Вони навіть не вважають, що є інші варіанти.

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

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

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

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

Ні.

Це "Почніть просто і вдосконалюйтеся, поки рухаєтесь далі".

Швидкий і брудний крихкий, але швидкий (якщо проект достатньо малий і короткочасний).

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

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

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

Тож ваш підхід просто чудовий. Однак небезпека полягає в тому, щоб сказати "Приємно, це працює, я закінчую. Що далі?". Ви ще не закінчились, є багато вирізаних куточків, щоб випрямитись, і вам слід отримати / взяти час, щоб зробити це належним чином, як тільки буде зрозуміло, що ваш підхід дає працюючу та працездатну систему. Це може бути написання тестів, документування, StyleCop, оптимізація, навчання колег про те, що ви робили і як ви це робили, переглядали і т.д.

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

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

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