Fixed price это договор по которому вы сдаете команду на определенные деньги )

по-моему, по сути то же)

по сути это time & material и есть

😄

А вот если прицепить еще обязательства по результату, то это уже fixed price + fixed scope

Теперь мы разобрались с терминами. Можно задать вопрос еще разок :)

Да, обязательства по результату есть.

Тогда вы попали :)

Но, продукт достаточно сложный - полный цикл разработки и ввода в промышленную эксплуатацию - 12 месяцев

полный Agile (

Заказчик спрашивает сейлзов за какие деньги Вы это сделаете?

полный Agile (

😀

Ну да, тут противоречие с Agile (чувствуется)

в чем противоречие?

Скорее всего вот здесь http://joxi.ru/1A5y46WcndVQKA

На самом деле "много требований в начале" подразумевает нарушение и ценностей и принципов

Скорее всего вот здесь http://joxi.ru/1A5y46WcndVQKA

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

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

Это, конечно, предположение

много предположений)

полный Agile (

Давайте свою версию

Заказчик спрашивает сейлзов за какие деньги Вы это сделаете?

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

https://www.facebook.com/notes/pavel-kapustkin/%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-%D0%B3%D0%B8%D0%B1%D0%BA%D0%B8%D1%85-%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B9-%D0%B2-%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D0%BD%D0%BE%D0%B9-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B5/302807040077305/

Размышления о том, почему никакого особого agile-контракта нет и быть не может.

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

дайте ссылочку на MoSCoW, пожалуйста

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

Да, так пытаемся делать, но заказчику об этом не говорим. Вообще налицо конфликт интересов, потому что: 1. Все хотят заложить в бюджет фикс цифру. 2. Годовой KPI менеджмента завязан на delivery, поэтому в сроки надо уложиться. 3. На практике у IT и пользователей есть понимание, что требования меняются часто

А если еще и домен не знаком, периодически всплывают новые детали)

Один из Вопросов даже больше в том, как менеджменту объяснить, что, например, review meetings каждые 2 недели, например, в сложных проектах не всегда гарантируют минимизацию риска появления новых требований на поздних стадиях, например на 9-м месяце 12-ти месячного проекта. ???

Для этого не нужно делать водопадную разработку)

Выделяете mvp, бьете по спринтам и смотрите как быстро двигается проект

Для mvp надо собрать требования к обеим сторонам интеграции, кто и как работает, какой флоу

Выделяете mvp, бьете по спринтам и смотрите как быстро двигается проект

И что дальше?

Agile тут скорее для fail fast

Выделяете mvp, бьете по спринтам и смотрите как быстро двигается проект

опять же, если у вас налаженно сотрудничество с заказчиком)

@ysmirnov1 что такое MoSCoW? Гуглить по понятным причинам не очень просто )

Must should can wont + have

ага, интересная классификация требований

Спасибо

Четыре квадранта — что обязано быть, что желательно иметь, что хорошо бы иметь, и чего хотелось бы, но увы

Я думал, что CAN это что возможно реализовать

https://en.wikipedia.org/wiki/MoSCoW_method теперь понял

😁

Must should can wont + have

could только)

Обычно хватает critical/non critical to launch

W - чего не надо. Вот тоже инетерсный момент. Мало кто формулирует "что не будем делать". А это ИМХО важно.

W = Won't have (this time)

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

Вы создаете условия для лучшего мира

А говорите требований не было )

Разработчик-то все зафиксировал в тестах )

норм так делали, что в июне зачесались

с января

в принципе так все делают

год ждут и в последние пару спринтов все запихивают

Не уверен, что это хорошо, но в госах и во многих других компаниях это норма

зато показатель работы сотрудников на лицо.

Не приуменьшу ваши заслуги, но у каждого нормального проектника есть примерно такой же кейс.

сделать вчера это нормально

за кого то)

согласен

а какая компенсация была бы нормальной?

лунопарк с блекджеком)

а какая компенсация была бы нормальной?

Дать лычек всем присутствующим

в смысле, признание достижений бэтменов), не финансовая компенсация или и то и то ?

Лычки означают промоушен и рост зп

Варианта отказаться у нас не было, поэтому компенсацию стоило обговорить в самом начале

Сейчас они просто потеряли тех июньских, и потеряли нынешних)

Варианта отказаться у нас не было, поэтому компенсацию стоило обговорить в самом начале

логично)

Лычки означают промоушен и рост зп

а он был принципиально возможен?

Да, ребята второй год ждут

Талантливые и упрямые) но до ноября разбегутся, если кого получится я перехвачу)

а чего ждать, подошел и спросил.

Один из Вопросов даже больше в том, как менеджменту объяснить, что, например, review meetings каждые 2 недели, например, в сложных проектах не всегда гарантируют минимизацию риска появления новых требований на поздних стадиях, например на 9-м месяце 12-ти месячного проекта. ???

Agile процесс и стремление к качеству и простоте обеспечивают изменение требований даже на поздних стадиях проекта. Это если чуть перефразировать принципы манифеста. Конечно это не спасет от разворота на 90 градусов. Но плата за гибкость всегда есть.

Мне импонирует следующее свернутое определение: способность команды поддерживать постоянную скорость генерации бизнес ценностей и одновременно подстраиваться под изменения бизнеса

Agile процесс и стремление к качеству и простоте обеспечивают изменение требований даже на поздних стадиях проекта. Это если чуть перефразировать принципы манифеста. Конечно это не спасет от разворота на 90 градусов. Но плата за гибкость всегда есть.

Вот то, что за гибкость надо платить понимают далеко не все.

Цена этому техдолг

Цена этому техдолг

Это меньшее из зол. Мое имхо

Вот то, что за гибкость надо платить понимают далеко не все.

Цена за отсутствие гибкости бывает не меньше.

Обычно техдолг заканчивает разработку раньше)

мы отвечали на вопрос Павла если что)