Родион Аристов
Если быть точным, в статье сказано, что при time & material состав команды от недели к неделе может меняться, и только ретейнер дает возможность не менять команду. Я просто указал, что здесь нет зависимости именно при работе над продуктом, и при time&material должно быть также - выделенная команда. Возможно, если вы осуществляете какие-то небольшие работы при схеме работы с заказчиком time & material, может быть замена исполнителей и в этом случае нет рисков. Просто статья про работу над продуктом же.
Не понял, почему остальные комментарии не относятся к теме статьи, то есть я дал комментарий к содержимому статьи, к конкретным измышлениям:
По agile не то, что бы моя позиция, сейчас подходы к разработке, основанные на agile, в тренде, agile манифесту больше 20 лет, это общеизвестно, но вы указали итерационно-инкрементальную модель работы. Интересно, почему. Может, потому что большой заказчик не готов к agile или по другой причине, просто эта самая причина не указана. Зависит от вашего опыта.
Про ТЗ сказано, что оно зло, но если вы на старте его используете, чтобы понять заказчика лучше, то оно даже полезно, и хорошо, что заказчик подготовился. Главное по строгому ТЗ не начинать продукты делать в итоге :)
Зачем нужна итеративно-инкрементальная модель, когда есть agile?
Наличие ТЗ свидетельствует о том, что клиент прорабатывал вопрос, у него есть идеи. Обсуждение ТЗ может быть полезным для команды и заказчика на старте, чтобы понять, что заказчик вообще хочет. Есть какие-то сложности в том, чтобы объяснить заказчику, что продукт будет развиваться, решения тестироваться и соответственно сам продукт будет меняться? Если да, то может, это не ваш клиент? Просто из контекста ясно, что мы проводим тесты и внедряем изменения, значит, ТЗ, где на старте все-все продумано, не подойдет априори никак, поскольку противоречит самой концепции работы над продуктом.
Если вы по Time&Material работает над продуктом заказчика и регулярно меняете исполнителей на нем, к которым у клиента есть доступ (то есть клиент знает, что спустя месяц у него другой дизайнер), то клиенту это не понравится, поскольку продукт должен делаться с хорошим погружением команды в вопросы заказчика. Вы сами менять постоянно дизайнеров и аналитиков и т.д. клиенту не будете, потому что от этого может пострадать и продукт, и отношения с клиентом, а разработка продукта - дорогое удовольствие, то есть если клиент платит хорошие деньги, настроен серьезно, работы надолго, к чему какие-то перемены, которые порождают риски?
Выходит, что при работе над продуктом по Time&Material команда будет постоянной, это разумные ожидания обеих сторон.
По t&m и ретейнеру - верно именно так, как вы написали, но только набор исполнителей не то, что может не меняться в обоих случаях, а разумно не менять в интересах обеих сторон этих исполнителей при любом подходе к работе над продуктом. Это просто странно, если вы в работе над продуктом заказчика вдолгую проговариваете, что вот, мол, мы можем поменять исполнителей, если вы будете нам платить по t&m, вы даже заказчику это не объясните, что вот при этой схеме вот так работаем, а при этой вот так, для него адекватно, что команда на его продукт - выделенная и постоянная, т.к. погружение требуется. Собственно, в статье и следовало сообщить эту разницу, но было сказано другое: ретейнер обеспечивает выделенную команду, а t&m нет. Просто ретейнер - это новомодно, поэтому о нем статьи писать тоже модно :)
Термин "итеративно-инкрементальная модель разработки" и "agile" можно сравнивать, и ясно, что agile - современный подход, а итерации и инкремент - уже нет. Итеративно-инкрементальная модель - модель, когда через 2 недели вы выпустили релиз с фичами заранее согласованными без отклонений от планов. Подходы к разработке, основанные на agile, позволяют вам оперативно перестроиться просто исходя из философии этого подхода, то есть клиент говорит: "так, ребята, мы хотели продавать помидоры, а теперь ягоды, мы понимаем, что ошиблись ранее, давайте запилим фичу с продажей ягод в приложении".
Поскольку agile говорит вам
-что сотрудничество с заказчиком важнее согласования условий договора (а по условиям договора вы делаете фичу с помидорами)
-что готовность к изменения важнее, чем то, что вы напланировали ранее (а вы спринты спланировали и делаете фичу с помидорами)
-что работающий продукт важнее документации (а у вас на ягоды документации нет, только на помидоры),
то вы беретесь делать фичу с ягодами сразу же быстро все пересогласовав оставив нюансы. Вы не говорите заказчику (или не делаете преград из этого для старта новой фичи): "так сейчас доку сделаем, переподпишем наше соглашение, переоценим фичу и т.д." В итерационной модели это будет новый спринт со всеми пересогласованиями, оплатами за уже выполненную работу итд, а в agile вы просто делаете согласно философии, понимаете? Атмосфера, в которой работают команды при этих подходах, сильно разная: в степени готовности команд к изменениями, в отношениях к изменениям, к условиям оплаты, в отношении к клиенту, в самих границах между клиентом и вами. То есть в agile лучше поймут скорые изменения и примут их в команде.
С ТЗ вы вместо автора согласились, это не зло, и я очень рад :)