Если софт лишь малая часть проекта. Например: "Национальный центр управления в кризисных ситуациях МЧС России" Без софта эту штуку було несколько сложно сдать. А весь проект более 3 миллирдов долларов.

Сергей, вот не надо мне про кризисные центры и необходимость upfront requirements для них :)

Я ровно за разработку подобной системы отвечал буквально пару месяцев назад :)

Все там отлично реализуется с lean методами.

Ну я участвовал в этом с 2005 по 2008...

Ключевой вопрос - зачем делать проекты с попыткой вычислить скорки настолько заранее,

Мне кажется, что это естественное желание заказчика - понимать сколько ему необходимо финансировать разработку. Нет?

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

Мне кажется, что это естественное желание заказчика - понимать сколько ему необходимо финансировать разработку. Нет?

Да пофиг, если софт это 1% цены проекта.

Мне кажется, что это естественное желание заказчика - понимать сколько ему необходимо финансировать разработку. Нет?

Разумеется. но вы жеж с такой оценкой все равно ему эого сказать не можете :)

Да, а остальные 99% запускаются к определенной дате. При этом, если к этой дате не будет 1%, то 99% - это деньги на ветер

Потому что 100% верные требования до старта - утопия )

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

ну и не всегда это 1%

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

За 6 месяцев я могу этого только хотет.

А вот на следующую неделю я могу уже получить довольно точный прогноз

а кто ответственый когда us в статусе OPEN?

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

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

Я это понимаю. Но это не значит, что планировать нельзя. Вопрос только в том, что у нас имеет бОльший приоритет: деньги, сроки или функционал

Потому и придумали agile contracts

В которые не фиксируются все требования сщ 100% точностью заранее.

И котоыре признают, что мы на старте мало знаем и требования поменяются.

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

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

И которые работают, если у вас scrum - это scrum, а не "дизайн заранее, тестирование в следующем спринте" :)

ну вообще, если мы говорим о проектах, то там рамки должны быть обозначены на старте

просто по определению

а скрам, да, он ничего не говорит про сроки

Да. Количество спринтов, доменная область, структура и стоимость команды.

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

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

не гарантирует

+1

очень сильно хочет гарантировать, но не гарантирует

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

и еще она там хитро формулирует, чего даст в конце спринта

Можно взять reliabble scrum :)

"Цель спринта" это называется

Хотя на самом деле гарантирует - в рамках спринта

так это не команда формулирует. а PO

Можно взять reliabble scrum :)

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

xDDD

:) он для этого используется :)

тааааак. а как менеджер подпишет устав без сроков?

сформирован план-график и тд

?

Например никак?

а как он сформирует сроки?

Любым доступным методом.

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

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

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

Т.е. цикл развернут в обратную сторону.

Просто потому, что требования могут и будут меняться

Приоритеты будут меняться

Даже бюджет будет меняться.

Потому эффективный метод управление проектом по разработки софта - строить проект вокруг lean и agile методов.

Делать очень короткие циклы поставки и включать работу с требованиями в сам проект как паралелльный activity stream

А сроки ограничивать, работая с клиентом над определением цели, ожидаемого бенефита от проекта и того, сколько он готов проинвестировать в этот проект.

ну ожидаемая цель - это вообще довольно сильный инструмент. она и скоуп сильно можно поменять

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

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

Да, такое тоже возможно

Потому как раз цель надо задавать прямо и измеримо.

SMART, все дела :)

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

в каждый момент - смарт. потом прошел год... и....

Это, конечно, возможно, но как от этого защищает устав, получение требований заранее и предсказание сроков?:)

Ну, если отбросить очевидное "мы вам все сделали как вы сказали, а дальше ваши проблемы" :)

для сложного проекта всегда должна быть документация с описанием скоупа как минимум, даже если работаете по agile. документация должна быть живой, но правки должны быть согласованы. если делаешь грубо говоря сайтик, то посути пофиг когда сделаешь первой фичу А или фичу Б. а если эти фичи компоненты сложной системы где одно не работает без другого без достаточного горизонта планирования все закончится тем, что ничего не заробатает в итоге

agile документация != отсутсвию документации, agile планирование != отстутсвию планирования и тп

Все верно.

Потому я выше и упоминал про value-stream mapping, use cases и BPML :)

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

Подпишусь под каждым словом, в том числе по вышесказанному.

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

Либо да, либо нет)

Во, норм пошел разговор

тааааак. а как менеджер подпишет устав без сроков?

Ну Скрам это все таи больше про продуктовую разработку. Проект имхо не так ровно туда ложится.

А в чем отличие проекта от продукта?

Ничем. Продукт это и есть проект.

Даешь холивар)

А в чем отличие проекта от продукта?

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

Тарам-пам-пам

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

Результат проекта - не продукт?

Сервисы в продукте это сначала проект