Здравствуйте, akava, Вы писали:

A>Здравствуйте, akava, Вы писали:

A>>На скрам ложаться проекты разные проекты. И большие и маленькие. Ничего не мешает большой проект вести по RUP, а подпроекты и фазы вести по скраму (об этом уже упомянал

Автор: Sinix
Дата: 21.02.14

Sinix). Много чего можно. Но все же нельзя делать Скрам, если заказчик НЕ хочет сотрудничать.
A>А, да! Если вы тоже НЕ хочете сотрудничать с заказчиком, то Скрам тоже не будет работать.
A>Вы готовы открыться перед заказчиком?

A>СУВ, akava

Видите, я наблюдаю такую ситуацию: в нашей компании есть внутренний продукт — ERP-система, и мы его делаем для себя, тут мы работаем по скраму(у нас итерация месяц- специфика нашей компании, плэнинг покер, все как надо, обратная связь с заказчиком — заказчик мы же!).
Но, так же наша компания занимается разработкой на заказ очень больших проектов — минимальное время разработки год.
И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
И эти заказные проекты мы делаем по водопаду(этапы, сроки...).
Вот и я не вижу, как применить скрам вот к таким проектам?
Есть ли смысл делать такой проект по скраму, т.к. при этом подходе(продукт сдается заказчику в конце разработки) скрам выродится в водопад с этапами в длину спринта.
Меня это и волнует, проявляется явный диссонанс с идеей скрама — нет коммуникации с заказчиком(зачастую у нас заказывает чей-то субподрядчик), нет релизов(проект большой и допустим мы написали за месяц только DAL, но это ведь не релиз, или это релиз с DAL-ом?
Т.е. получается что скрам не работает при больших проектах и заказной разработке?