Неможливо зрозуміти певний момент у принципах Agile Manifesto

24

Я читав Принципи Agile Manifesto . Все здається зрозумілим і розумним, крім одного пункту:

Простота - мистецтво максимізувати обсяг незаробленої роботи - є суттєвим.

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

agile management

— суперМ
джерело

2

+1, щоб протистояти голосуванню проти, - тут у вас напрочуд цікаве питання.

1

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

30

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

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

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

— Франческо
джерело

35

Ідея полягає у тому, щоб уникнути виконання роботи, яка не є необхідною, тобто "максимізувати обсяг не виконаної роботи".

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

YAGNI - споріднене поняття.

— Йоахім Зауер
джерело

5

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

— Макс

2

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

— superM

7

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

15

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

— Йорг W Міттаг

2

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

— пдр

5

Ми звикли це називати «золотим покриттям». Вимога молотка полягає в тому, що він може забити цвях у шматок дерева. Це не робить цю роботу краще, ніж бути молотком із позолоченим покриттям.

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

— Стюарт Вудвард
джерело

4

Ця ідея дуже схожа на концепцію виробничої системи Toyota (TPS) , яка призвела до більш загального виробництва Lean Manufacturing, а потім до застосування цих методів до Lean Development Software . TPS значно передує гнучкому руху, коріння якого виробляється в кінці 1950-х.

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

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

— Томас Оуенс
джерело