Действительно ли Толпа возможна без разработки через тестирование? [закрытый]

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

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

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

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

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

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

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

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

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

Однако, как только мы начали нашу итерацию, в Scrum нет ничего, что диктовало бы, как и когда разработчики должны что-то разрабатывать. Есть только обязательство, которое будет «выполнено» к концу спринта.

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

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

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

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

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

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

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

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

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

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

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

Это очень распространенное заблуждение, что 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

1. Как упоминалось выше, Scrum не определяет, над каким типом или видом работы работает разработчик. . Разработчики сами решают, какую работу взять на себя; Если разработчик с тяжелыми базами данных хочет работать только с DAL и связанными историями, нет причин, по которым они не могут.

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

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

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