Возможна ли Scrum без разработки тестов?

Ответ 1

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

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

Ответ 2

Я хотел бы рассказать о том, что сказал Дэн.

Это очень распространенное заблуждение, что Scrum/Agile диктует принципы разработки программного обеспечения. Это ошибочность по многим причинам. Как отметил Дэн, Scrum - это процесс управления программным обеспечением, а не процесс разработки программного обеспечения. При этом очень часто вы увидите много технических принципов, связанных с Scrum; методологии, такие как TDD, XP и т.д., как правило, дополняют методологию управления, которую Scrum способствует, но не требуется.

Причина, по которой CI, TDD и другие инженерные практики так часто встречаются в руке с Scrum, заключается в том, что в целом многие из них - это хорошая практика, которой следует следовать независимо от того, какая методология управления используется.

Я хотел бы затронуть пару других ошибок в вашем OP:

Однако с Scrum ожидаются разработчики:

* to all be able to work on all the bits of the application.
* to only work on one area of the application for a few days at most before 
  moving to the next area
* to mostly work on code they did not write

• Как упоминалось выше, Scrum не диктует, какой тип или вид работы работает разработчик. Сами разработчики сами решат, на какую работу взять на себя обязательство; если разработчик, работающий с базой данных, хочет работать только с DAL и связанными с ним историями, нет причин, по которым они не могут.

• Опять же, Scrum не диктует ничего о том, как создать приложение, поэтому ваш второй пункт является спорным (см. пункт 1).

• Это ошибка, поскольку нет ничего, что говорит, что разработчик должен работать только с кодом, который не принадлежит им, или что-то о том, как разработчик должен развиваться. Если разработчик в команде Scrum обнаруживает, что он работает только над кодом других, это было бы совпадением, а не из-за самого процесса схватки.

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

Ответ 3

Да, Scrum описывает подход к управлению программным обеспечением. Парадигма управления программами и проектами не должна диктовать, используете ли вы развитие, основанное на тестах.

TDD - это практика или техника разработки программного обеспечения, и хотя она хорошо работает с Scrum, я не думаю, что это сделает или прервет ваш успех с практикой.

Я лично видел, что Scrum хорошо работает на проектах среднего размера, не имея под собой основанного на тестах подхода к разработке. Это не значит, что мы не пишем автоматизированные тесты, они просто не всегда были написаны первыми.

Ответ 4

Мы работаем на Scrum, но мы не практикуем TDD. Ничто в рекомендациях Scrum не говорит вам, что вы должны использовать TDD. На самом деле, большинство гибких практик - это просто рекомендация, поскольку они доказали свою эффективность в гибких средах (или даже в несовместимых) без необходимости их использования, если вы хотите внедрить Scrum.

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

Обратите внимание, что не внедрение TDD не было "активным" решением, оно просто произошло. Нам рекомендуется "сначала писать тесты", например. при исправлении ошибки, поэтому это своего рода добровольный непредвиденный случайный способ получить представление о TDD, применяя его на регулярной основе, но это не обязательно.

Как и другие пользователи: Scrum - это структура, которая может содержать любые действия, которые вы хотите применить в своей команде разработчиков. Некоторые гибкие практики приходят естественным образом, потому что они, как правило, имеют смысл, но какие из них вы хотите использовать, а какие из них вам не нужны, зависит от вас.

Ответ 5

Да, Scrum вполне возможен и в большинстве случаев реализуется без использования подхода TDD.

Однако гибкость, предоставляемая TDD, безусловно, может быть полезной для методологии Scrum.

Ответ 6

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

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

Ответ 7

Структура Scrum довольно маленькая, она определяет несколько встреч, идеальную длину итерации, обязанности владельца продукта, мастер схватки... и, возможно, немного больше.

Однако, как только мы начали свою итерацию, в Scrum нет ничего, что диктует, как и когда разработчик (разработчики) должен что-то разработать. Существует только обязательство, которое оно будет "сделано" к концу спринта.

Scrum - это команда, готовящая к получению результатов, и команда имеет право решать, как это сделать. Если это означает, что 1 dev для истории пользователя, отлично. Если это означает, что 3 разработчика для каждой истории пользователя тоже прекрасны. Независимо от того, как команда схватки считает, что лучший способ выполнить эту работу, это должно произойти.

Чтобы ответить на вопрос, да, Scrum возможен без разработки, основанной на тестах.

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

Ответ 8

Здесь есть некоторая путаница в Scrum.

Scrum per se не говорит вам, как и когда делать технические вещи, такие как TDD (что навсегда движущаяся цель). Scrum рассказывает вам, как/когда управлять людьми, которые происходят в проекте. Это общая методика управления проектами, а не техника управления строительством.

Если ваш менеджер хочет сделать три вещи, перечисленные выше во время ваших спринтов, это прекрасно, но это не входит в рамки Scrum. Это для управления строительством, которое не является Scrum. Он может использоваться в вашем ограниченном Scrum-проекте проекте, но он не находится в официальной структуре Scrum.

Я думаю, что легко смутить это. Гибкие методы, такие как Scrum, обычно евангелизируются людьми в сети, которые все про толкают слова и "счастливые блестящие" вещи, и поэтому не всегда хорошо понимают/общаются. По крайней мере, то, что Agile методы были представлены мне, Agile апологет. Мне потребовалось 6 месяцев, прежде чем я прошел мимо шумихи/запутанной терминологии и выяснил, о чем они говорили.

Ответ 9

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

Откуда вы знаете, что ваш спринт не сломал последние 4? Как вы можете гарантировать результаты, если не знаете, что в прошлом вы ничего не нарушали.

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

SCRUM учит вас ежедневным результатам и всегда двигается вперед за счет скорости.

Когда кто-то говорит, что я хочу делать CI или Agile или Scrum, для меня это автоматически означает, что необходимо провести единичное тестирование (не интеграционное тестирование, как указано выше), но каждая отдельная движущаяся часть имеет свой собственный модуль.

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