Размер команды и продолжительность итерации проекта

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

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

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

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

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

Еще один ключевой фактор, который следует учитывать, - сложность: очевидно, что сложные серверные системы более опасны при интеграции, а простые страницы веб-интерфейса менее опасны.

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

Мой опыт показывает, что продолжительность итераций в некоторой степени зависит от размера команды,

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

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

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

I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.

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

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

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

Эта статья объясняет многие из них.

Важные IMO:

1. Общая длина выпуска
2. Как долго приоритеты могут оставаться неизменными
3. Накладные расходы на итерацию

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