Можно ли правильно назвать себя (или свою команду) «Agile», если вы не занимаетесь TDD (Test-Driven Development)?

Да, да, да, миллион раз да.

Agile - это философия, TDD - это особая методология.

Если бы я хотел быть действительно разборчивым, я мог бы просто указать, что существует довольно много вариантов xDD, которые их сторонники подробно объяснят, не являются TDD, но они по-прежнему в значительной степени связаны с тестированием в первую очередь, так что это будет обманом.

Итак, давайте скажем это - вы можете быть гибкими, не занимаясь разработкой «сначала тестируй» (посмотрите, как работает scrum - нигде нет подробностей о том, как вы пишете код). Посмотрите на доску канбан, посмотрите на все виды гибких методологий.

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

И, наконец, в равной степени верно то, что вы могли бы сделать Test First, не будучи проворным и веским аргументом для проведения теста сначала, независимо от вашей общей философии разработки.

Кажется, что другие (с более твердым представителем) имеют аналогичное мнение ...

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.

РЕДАКТИРОВАТЬ: @ Мёрф интерпретация вопроса, кажется, является предпочтительным. Черт, я даже проголосовал за это, это хороший ответ. Однако я придерживаюсь своей позиции, что Agile Manifesto - это набор принципов, а не методология разработки. Я не вижу смысла в том, чтобы говорить «о, да, я проворен», фактически не применяя практики, которые приносят пользу. В частности:

Рабочее программное обеспечение является основной мерой прогресса.

а также

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

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

РЕДАКТИРОВАТЬ 2: да, технически вы можете написать тесты впоследствии; но я все еще рассматриваю тест-первый / TDD как фундаментальный. Не потому, что вы не можете «быть проворным» без этого, а потому, что вы будете более проворны с этим. Тест первый / управляемый тест - это гораздо более эффективный подход, чем тест позже, тест позже. Описания тестов являются требованиями . Не откладывайте их на потом ;-)

РЕДАКТИРОВАТЬ 3: Я наконец понял, что беспокоит меня так хорошо очень хорошо написанного ответа Мерфа. Это то понятие, что можно быть «проворным», фактически не делая этого . И для того, чтобы «сделать это» (как показано выше), требуется TDD.

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

Вы можете быть проворным, но, вероятно, есть возможности для улучшения.

Один из принципов Agile заключается в том, что вы должны быть в состоянии реагировать на изменения. Это значит, что заранее не знаешь, что нужно строить. Если бы вы следили за процессом «водопада», вы бы знали за x месяцев заранее, что именно вам нужно создать, и вы могли бы разработать отдельные программные компоненты, чтобы каждый из них участвовал в какой-то более крупной схеме, достигая конечного продукта (по крайней мере, вы бы подумали, что это было так). Но поскольку Agile требует, чтобы вы не знали, что такое конечный продукт, вы никогда не знаете, для чего будет использоваться код, и, что более важно, когда он будет изменен.

Поэтому вам необходим полный набор тестов, чтобы убедиться, что уже созданные функции продолжают работать после изменения базы кода.

Но это само по себе не TDD. Если вы пишете тесты после написания кода, это не TDD. Но TDD помогает в другом аспекте, он предотвращает перепроизводство.

В моей собственной гибкой команде я боролся с разработчиками, пишу код, который, по их мнению, пригодится позже в проекте. Если бы это было развитие водопада, это, вероятно, было бы хорошо, потому что они добавили поддержку чего-то в плане проекта на следующие x месяцев.

Но если вы следуете гибким принципам, вам не следует писать этот код, потому что вы не знаете, понадобится ли это вообще. Функция, запланированная на следующую неделю, может быть внезапно отложена на неопределенный срок.

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

Таким образом, TDD помогает избежать перепроизводства, позволяя команде быть максимально эффективной, что также является основным гибким принципом.

Рабочее программное обеспечение является основной мерой прогресса

Можете ли вы быть гибким, не занимаясь TDD (разработкой на основе тестирования)?

Краткий ответ: да.

Более длинный ответ: на этот вопрос уже есть много действительно хороших ответов и очень хороших ссылок. Я не буду пытаться обсуждать эти вопросы.

По моему опыту, Agile - это выбор правильного уровня Lean-ness для данного проекта. Что я подразумеваю под Lean-ness? И почему я привожу это в этот ответ?

Бережливое отношение не означает отказ от всего возможного из вашего метода. Как заметил один из наших коллег, вам не нужно включать TDD или модульный тест в ваше поведение. Тем не менее, в контексте проекта вы обнаружите, что это может или не может быть полезным.

Давайте подумаем о цепочке поставок для крупного неназванного ритейлера, расположенного в АК. Есть потребитель. Они идут в магазин. Магазин получает различные товары на грузовике. Грузовики, по-видимому, получают эти продукты со склада. Склад заполнен отгрузками от разных производителей. У производителей, в свою очередь, есть целые цепочки поставок.

Что произойдет, когда генеральному менеджеру по отгрузке в вышеупомянутой цепочке поставок скажут, что он будет получать ежегодный бонус в размере 1 млн. Долл. США за каждый год, когда у него в парке менее 10 грузовиков? Он немедленно разделит флот до 9 грузовиков. В этом «ужасном» сценарии это приведет к увеличению количества товаров, хранящихся на складе (увеличение стоимости в этом узле). И это будет "голодать" по витринам магазина.

Таким образом, общая цепочка поставок страдает, если локальная оптимизация разрешена без учета всей.

Вернуться к TDD и UT. TDD - это механизм выражения требований. Система ДОЛЖНА выполнять эти ограничения. Справедливо. TDD может заменить поведение требований Use Case Drive Development или поведение User-Driven Development. Он имеет «наклонную» выгоду от сочетания рабочих нагрузок модульного теста и требований. Это выгодно, если общая рабочая нагрузка снижается. Это не так, если общая нагрузка цепочки поставок увеличивается (давайте исправим качество).

Итак, вы спросили: можете ли вы быть Agile, не занимаясь TDD (разработкой на основе тестирования)?

Что вы можете. Другой, и, возможно, лучший вопрос: - Если я применю TDD к этому проекту, приведет ли это к более эффективной доставке программного обеспечения или менее эффективной?

Процитирую любимого автора ... JRR Tolkien

Властелин колец. Братство Колец. Стр. 94 «И также сказано, - ответил Фродо, - не ходи к эльфам за советом, потому что они будут и нет, и да».

Итак, в конце концов ... это зависит. Вы должны ответить на вопрос. Какой путь наиболее эффективно приведет вас к желаемой цели?

Для TDD или нет для TDD. Это остается вопросом. :-)

PS - Я также публикую этот ответ на другом сайте. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

По сравнению с инженерным замком.

Проворный замок

Если бы вы были инженером замка, используя Agile. Вы пишете части, которые имеют определенные функции и побуждают пользователя использовать функциональные части, приспосабливая будущий дизайн к реакциям пользователя. Итак, вы строите подземелье и общаетесь с его хранителем, вы проверяете фундамент, предоставленный землей и темницей. Вы построите парапеты и спросите ночных стражей, хорошо ли это. Вы бы построили стены и попросили солдат проверить оборонительную ценность. Вы бы построили кухню и повара ее осмотрели. И во время этого процесса каждая часть на сегодняшний день будет функционировать в дополнение к текущей структуре. Поэтому, когда вы закончили темницу, вы могли переместить заключенных. И так далее. Но когда вы, наконец, закончили замок, вы обнаружите, что заключенные сбежали.

TDD Castle

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

Agile TDD Castle

Если объединить 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.