Чи можна правильно назвати себе (або свою команду) "Agile", якщо ви не займаєтеся TDD (Test-Driven Development)?

Так, так, так, мільйон разів так.

Agile - це філософія, TDD - конкретна методологія.

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

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

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

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

Схоже, подібні думки мають і інші (з більшою кількістю повторень SOLID) ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Хоча Agile без TDD та OOD неможливо зробити, це важко. Без TDD швидкість ітерації ...

(Посилання у твіті - це повна відповідь на LinkedIn)

"Бути спритним" просто означає дотримуватися цінностей та принципів спритного маніфесту . Ніщо в цьому документі не згадує TDD або навіть тестування одиниць з цього приводу.

Так що так, ви можете бути спритними, не роблячи тестування TDD чи модуля.

Я б не рекомендував це, хоча ...

Так ,

Подивіться на одне із спритних значень:

Індивіди та взаємодія над процесами та інструментами

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

Я підсумую це так:

• Сьогодні TDD є дефакто-стандартом для спритності

• Існують способи бути спритними без TDD

я кажу

Ні [роду]

Якщо ви повернетесь до початкового джерела http://en.wikipedia.org/wiki/Extreme_Programming TDD є основоположним для процесу; випробування замінюють технічні вимоги та випадки використання водоспаду, служать живою документацією та прикладами функціонування тощо. Вони незамінні.

Однак зараз існує так багато різних ароматів "спритного", що цілком можливо, що один з них ухиляється від TDD

EDIT: Тлумачення питання @ Мерфом здається кращим. Чорт забираю, я навіть це схвалив, це гарна відповідь. Однак я вважаю, що маніфест "Agile" - це сукупність принципів, а не методологія розвитку. Я не бачу сенсу говорити "о так, я спритний", а не реалізувати практику, яка приносить користь. Зокрема:

Робоче програмне забезпечення є основним показником прогресу.

і

Швидкі процеси сприяють сталому розвитку. Спонсори, розробники та користувачі повинні мати можливість постійно підтримувати постійний темп.

Для мене ці два принципи передбачають, якщо не вимагають TDD - принаймні я не знаю іншого способу їх досягнення без цього!

EDIT 2: так, технічно ви можете написати тести після цього; але я все ще вважаю тест-перший / TDD як фундаментальний. Не тому, що ви не можете "бути спритними" без цього, а тому, що з ним будете більш спритні. Тест перший / тест-керований набагато ефективніший підхід, ніж тест-пізніше / тест-післядум. Описи тестів - це вимоги . Не відкладайте їх пізніше ;-)

РЕДАКЦІЯ 3: Нарешті я зрозумів, що мене так турбує у дуже добре написаній відповіді Мерфа. Це те поняття, що можна було "бути спритним", а не робити цього . І "робити це" (як показано вище) в значній мірі вимагає TDD.

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

Ви можете бути спритними, але, можливо, є можливість для вдосконалення.

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

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

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

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

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

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

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

Робоче програмне забезпечення є основним показником прогресу

Чи можете ви бути Agile, не роблячи TDD (тестова розробка)?

Коротка відповідь: Так.

Більш довга відповідь: На це питання вже існує дуже багато справді хороших відповідей і дуже хороші посилання. Я не буду намагатися обговорювати ці моменти.

На мій досвід, Agile полягає у виборі правильного рівня Lean-ness для даного проекту. Що я маю на увазі під худобою? І чому я вказую це на цю відповідь?

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

Давайте подумаємо про ланцюги поставок великого безіменного роздрібного торговця, розташованого в АК. Є споживач. Вони заходять у магазин. Магазин отримує різні товари через вантажівку. Вантажівки, імовірно, отримують ці продукти зі складу. Склад заповнюється відвантаженнями різних виробників. У свою чергу виробники мають цілі ланцюги поставок.

Що станеться, коли генеральному менеджеру за доставку у вищезазначеній ланцюзі поставок сказати, що він отримуватиме щомісячний бонус у розмірі 1 мільйона доларів США за кожен рік, що у нього є менше 10 вантажівок у флоті? Він негайно рубає флот до 9 вантажних автомобілів. У цьому "жахливому" сценарії це призведе до збільшення кількості товарів, що зберігаються на складі (збільшення витрат у цьому вузлі). І, це буде "голодувати" фасади магазину.

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

Повернутися до TDD та UT. TDD - механізм вираження вимог. Система ОБОВ'ЯЗКОВО виконувати ці обмеження. Досить справедливо. TDD може замінити поведінку вимог Use Drive Drive Development або поведінку вимог, що керуються історією користувача. Він має "прихильну" перевагу в поєднанні робочих навантажень на випробування та вимоги. Це користь, якщо загальне робоче навантаження зменшиться. Це не так, якщо загальне навантаження на робочу мережу збільшується (давайте виправляємо якість).

І ось, ви запитали: Чи можете ви бути Agile, не роблячи TDD (тестова розробка)?

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

Цитувати улюбленого автора ... JRR Толкіен

Владар кілець. Стипендія Кілець. Pg 94 "І також сказано", відповів Фродо: "Не йдіть до ельфів за порадою, бо вони будуть і ні, і так".

Отже, зрештою, ... це залежить. Ви повинні відповісти на питання. Який шлях найбільш ефективно призведе вас до бажаної мети.

TDD чи не TDD. Це залишається питанням. :-)

PS - Цю відповідь я також відтворюю на іншому сайті. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Порівнюючи інженерний замок.

Agile Castle

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

Замок TDD

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

Agile TDD Замок

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

Висновок

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

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

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

Примітки

• Те, що проводити одиничні тести не означає, що ви використовуєте TDD. TDD означає провести тест перед виробленим пристроєм і використовувати тест під час розробки для підтвердження пристрою. Тестування одиниць без TDD можна використовувати, щоб переконатися, що ви не втрачаєте функцій раніше вбудованих функцій.
• Проведення спринтів та інших зустрічей не робить вас спритним. Цілі маніфесту роблять вас спритними. Ви можете розбити цілі водоспаду на спринти з одиницями роботи, не дотримуючись прихильності віддавати перевагу людям над процесами.
• За визначенням TDD і Agile. Ваші тестові одиниці керуватимуть не доставляючими одиницями, і тому TDD рухатиметься швидше, ніж Agile. І якщо ви використовуєте обидва, ваші Agile цикли будуть містити один або більше циклів TDD (якщо кожен блок тестується).
• З того, що я розумію: Ви не зможете Agile, не спромігшись розробити доступний / значущий блок для користувача. Пристрій може бути значущим, навіть якщо він прискорює виріб. Але як Agile пояснює рефакторинг для легшого обслуговування? Я недостатньо висвітлив це, щоб відповісти на це.
• Збій TDD не вдався до тестування пристрою. Створення коду, який не створює функцію правильно.

Agile змушує вас вирішувати та зменшувати графік та ризики щодо якості на кожній ітерації. тобто TDD не потрібно вважати спритним .

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