G>Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.

Хочу выступить со стороны заказчика: никогда, ни разу в жизни мне не приходилось встречаться с ситуацией, когда заказчик НЕ ХОЧЕТ видеть что там происходит у подрядчиков. Напротив, ситуация обычно обратная: заказчику интересно буквально всё, а уж особенно интересен прогресс. И не в виде отчетов "мы реализовали DAL", а в виде вполне конкретной работающей системы без каких-то фич.

У меня вообще складывается ощущение, что это такой троллинг-тред.

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

G>>Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.

SD>Хочу выступить со стороны заказчика: никогда, ни разу в жизни мне не приходилось встречаться с ситуацией, когда заказчик НЕ ХОЧЕТ видеть что там происходит у подрядчиков. Напротив, ситуация обычно обратная: заказчику интересно буквально всё, а уж особенно интересен прогресс. И не в виде отчетов "мы реализовали DAL", а в виде вполне конкретной работающей системы без каких-то фич.

SD>У меня вообще складывается ощущение, что это такой троллинг-тред.

Это не троллинг-тред.
Вы пытаетесь меня в чем-то убедить, а я нет — я вижу факты.
Ну вот допустим делаем мы проект по скраму, допустим спринт 1 месяц, вот что-бы заказчики что-то хоть увидел, мне надо 5 спринтов.
Т.е. через 5 месяцев заказчик что-то увидит, вопрос, а что с предыдущими спринтами? что показать заказчику?код?

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

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

IC>>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
G>Любой agile подход работает только при условии, что вы можете как минимум раз в итерацию получать адекватный фидбек от заказчика. Не от промежуточного звена, а от того, кто будет использовать систему.
G>Иначе ни один agile подход не работает.

G>Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.

IC>>Т.е. получается что скрам не работает при больших проектах и заказной разработке?
G>Нет, срам не работает, если нет возможности получать фидбек. Это может быть на распильном проекте, где заказчику пофиг на результат. Это может быть при длинной цепочке субподряда или длинной цепочке "передачи информации", когда между командой и заказчиком 100500 менеджеров.
G>Это абсолютно нерелевантно размеру проекта.

Ну вот пример, внедряем медицинскую ИС.
Есть ТЗ уже.
Вот, ну кто там со стороны заказчика будет что-то там запускать? Вы себе госконторы представляете(там всем все пофиг). Да и как вы себе это представляете(итерации то короткие, а система огромная, ну тупо показать за первые полгода нечего кроме кода).
Надо тупо сделать, пусконаладить, получить акт внедрения и забыть про это.
А эту штуку еще год делать, вот как тут скрамом управлять?
Тут все что-то говорят-говорят, про фидбек и т.д.
А я никого не убеждаю — это факт — зачастую этого фидбека не добиться, или невозможно в итерацию его получить по тем или иным причинам.
И как вообще управлять такими проектами — бюджет, сроки утверждены, никто ничего менять не будет — следовательно ни о каких доработках и речи идти не может, т.к. это допфинансирование, а этим никто заниматься не будет.не из своего же кармана финансировать?

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

Посмотрите на проблему с другой стороны:
1. У вас есть чёткое представление, что нужно сделать (иначе как вы берётесь за дело без фидбэка?)
2. У вас есть человек, который разбирается в предметной области и способен оценить сроки по целям в целом (иначе как вы собираетесь успеть в срок с водопадом?)

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

Хотя, на мой взгляд, на таком проекте большую часть скрама можно выкинуть и оставить наноитерации, список задач в трекере (с приоритетами/развесовкой) и тимлида, который вместе с бизнес-аналитеком будет мониторить состояние очереди задач на ближайшие итерации.

IC>Вы пытаетесь меня в чем-то убедить, а я нет — я вижу факты.

Так приводите же эти факты. Пока я фактов не вижу. Только пустые заявления про "большой проект в 5 человеко-лет".

IC>Ну вот допустим делаем мы проект по скраму, допустим спринт 1 месяц, вот что-бы заказчики что-то хоть увидел, мне надо 5 спринтов.

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

IC>Т.е. через 5 месяцев заказчик что-то увидит, вопрос, а что с предыдущими спринтами? что показать заказчику?код?

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

IC>Вот, ну кто там со стороны заказчика будет что-то там запускать? Вы себе госконторы представляете(там всем все пофиг).

Скрам и прочий agile предназначен не для "распильных" проектов. На "распиле" вряд ли имеет смысл его применять. Если заказчику пофиг — проект однозначно распильный, делайте как хотите. Хоть вообще не делайте, раз все равно всем пофиг.

IC>А я никого не убеждаю — это факт — зачастую этого фидбека не добиться, или невозможно в итерацию его получить по тем или иным причинам.

Значит, вы не с теми людьми говорите. Если у заказчика совсем никто не заинтересован в проекте — зачем вы вообще его делаете? Получите деньги, распилите, и пропадите в неизвестном направлении. Тем самым и проблему управления проектом решите.

Позвольте вопрос. В чем вы хотите нас убедить? В том, что мелкие внедренческие проекты лучше делать без скрам? Пожалуйста, делайте. Надеюсь, вас там не силком заставляют?

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

IC>>Вот, ну кто там со стороны заказчика будет что-то там запускать? Вы себе госконторы представляете(там всем все пофиг).

SD>Скрам и прочий agile предназначен не для "распильных" проектов. На "распиле" вряд ли имеет смысл его применять. Если заказчику пофиг — проект однозначно распильный, делайте как хотите. Хоть вообще не делайте, раз все равно всем пофиг.

IC>>А я никого не убеждаю — это факт — зачастую этого фидбека не добиться, или невозможно в итерацию его получить по тем или иным причинам.

SD>Значит, вы не с теми людьми говорите. Если у заказчика совсем никто не заинтересован в проекте — зачем вы вообще его делаете? Получите деньги, распилите, и пропадите в неизвестном направлении. Тем самым и проблему управления проектом решите.

SD>Позвольте вопрос. В чем вы хотите нас убедить? В том, что мелкие внедренческие проекты лучше делать без скрам? Пожалуйста, делайте. Надеюсь, вас там не силком заставляют?

Я никого ни в чем не убеждаю, читайте внимательно.
Я спросил относительно того, как кто применяет скрам в больших проектах заказной разработки, вот меня и интересует опыт людей.
Что такое скрам я знаю, мы его используем для внутреннего проекта, но это внутренний проект, я могу получить обратную связь и т.д.
А меня интересует опыт применения скрама, когда бюджет и сроки определены и доделок в проекте по желанию заказчика не будет, т.к. есть бюджет, а любые доделки — время(другими словами — деньги).

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

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

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

IC>>>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
G>>Любой agile подход работает только при условии, что вы можете как минимум раз в итерацию получать адекватный фидбек от заказчика. Не от промежуточного звена, а от того, кто будет использовать систему.
G>>Иначе ни один agile подход не работает.

G>>Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.

IC>>>Т.е. получается что скрам не работает при больших проектах и заказной разработке?
G>>Нет, срам не работает, если нет возможности получать фидбек. Это может быть на распильном проекте, где заказчику пофиг на результат. Это может быть при длинной цепочке субподряда или длинной цепочке "передачи информации", когда между командой и заказчиком 100500 менеджеров.
G>>Это абсолютно нерелевантно размеру проекта.

IC>Ну вот пример, внедряем медицинскую ИС.
Отличный пример.

IC>Есть ТЗ уже.
Скорее всего это не ТЗ, а ХЗ. Или ТЗ, которое требует ЧТЗ.
Если неправ — пишите.

IC>Вот, ну кто там со стороны заказчика будет что-то там запускать?
Никто, вы будете.

IC>Вы себе госконторы представляете(там всем все пофиг).
Представляю, с кем я работал — было не пофиг, совсем не пофиг. Именно итерации и демонстрации позволили проект сделать в срок с приемлемым качеством.
Если у вас проект распильный, то нет смысла париться, надо сделать минимум, а потом закрываться бумагами.

IC>Да и как вы себе это представляете(итерации то короткие, а система огромная, ну тупо показать за первые полгода нечего кроме кода).
Потому что в голове у вас система разбита на слои. Сначала база, потом DataAccess, потом сервисы, потом контроллеры, а потом UI.
Для agile требуется резать систему на фичи (перпендикулярные слоям) и поставлять фичи по отдельности. Средний программист не способен такую декомпозицию сделать, поэтому в скраме требуется специально обученный Product Owner.
Моя статистика по проектам говорит, что если за неделю-три недели работы нечего показать, то эффективность такой работы близка к нулю.

IC>Надо тупо сделать, пусконаладить, получить акт внедрения и забыть про это.
Если распильный проект — да, вместо "сделать, пусконаладить" можно просто бумаги написать. Ведь никому работающая система и пусконаладка не нужна.

IC>А эту штуку еще год делать, вот как тут скрамом управлять?
Если же проект не распильный, то есть человек, заинтересованный чтобы система работала и работала не только на машине разработчика. Это будет первый (возможно единственный) stakeholder. С ним обсудите беклог, сделайте план релизов. После первого релиза привлекайте пользователей системы, возможно пилотное внедрение сделать, получить фидбек, пересмотреть приоритеты в беклоге проекта ну итд.

IC>Тут все что-то говорят-говорят, про фидбек и т.д.
IC>А я никого не убеждаю — это факт — зачастую этого фидбека не добиться, или невозможно в итерацию его получить по тем или иным причинам.
Так говорят программисты, потому что:
1) Нечего показать.
2) Не понимают что говорят пользователи.
Поэтому в скраме явно требуется специально обученный product owner. Если у заказчика есть заинтересованный человек, то провести ему демо и получить фидбек труда не составляет (для грамотного product owner).


IC>И как вообще управлять такими проектами — бюджет, сроки утверждены, никто ничего менять не будет — следовательно ни о каких доработках и речи идти не может, т.к. это допфинансирование, а этим никто заниматься не будет.не из своего же кармана финансировать?
А если вы не угадали потребности пользователей и заказчик отказывается подписывать акты, требует переделать, кто это будет финансировать? Или вы просто в оценках ошиблись в 2 раза.

Если фиксированный бюджет, то надо управлять объемом работ и ожиданиями заказчика. Причем ожидания важнее объема, правильно выстроенные ожидания делают заказчика довольным и он с радостью все акты подпишет, еще и денег вам принесет на доработки. У меня сейчас один такой есть, несмотря на то что есть ТЗ, причем довольно подробное.

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

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

IC>>>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
G>>Любой agile подход работает только при условии, что вы можете как минимум раз в итерацию получать адекватный фидбек от заказчика. Не от промежуточного звена, а от того, кто будет использовать систему.
A>Насколько я понимаю agile, фидбек не обязательно должен исходить от заказчика. Он может исходить от нашего аналитика, субподрядчика или еще от кого-то.
A>Ясное дело, что в этом случае мы получим продукт, который хочет получить "аналитик, субподрядчик или еще кто-то".
Считается что фидбек должен быть от заинтересованного лица. В заказной разработке это заказчик (желательно MUTE). При создании рыночного продукта — пользователи. В организационном проекте могут быть совсем разные зиантересованные лица.


A>Но ведь и с реальными пользователями то же самое. Если в Скраме будет участвовать представитель заказчика, то мы получим систему, удовлетворяющую его нуждам. Что может совершенно не соответствовать потребностям другого подразделения или высшего руководства.
Тут важно кто будет принимать систему. Если один человек, то достаточно удовлетворить его потребности, возможно никак не коррелирующие с бизнесом (читай "откат"). Но чаще всего заинтерсованный заказчик представляет из себя четверку:
Manager, User, Technical, Economic (MUTE). То есть со стороны заказчика обычно представлены роли Менеджера, Конечного пользователя системы, Технаря, и Экономиста. Роли могут совмещаться. Например если систему делать для ИТ, то се роли могут быть одним человеком. Если для бизнеса, то обычно 3-4 человека.
Бывают проблемные моменты, когда система делается для бизнеса, но заказчиком является ИТ служба. У вас по сути целых две роли выпадают — менеджер и пользователь. Грамотный PO должен знать что делать в такой ситуации.

A>Получается что Скрам возможен и без контакта с заказчиком, но тогда на аналитика (например) ложится ответственность за предоставление адекватной информации о нуждах пользователей.
В теории. На практике так не получается. Потому что 90% аналитиков работают на объем, а не на результат.

Проблема кстати решается очень просто — PO должен получать деньги от маржинальности проекта, но не быть при этом прямым руководителем команды разработки. Тогда он сам найдет нужны людей в заказчике, будет проводить демонстрации итп. И вообще начнет из кожи ввон лезть, чтобы проект был успешен.

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

G>>Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.

SD>Хочу выступить со стороны заказчика: никогда, ни разу в жизни мне не приходилось встречаться с ситуацией, когда заказчик НЕ ХОЧЕТ видеть что там происходит у подрядчиков. Напротив, ситуация обычно обратная: заказчику интересно буквально всё, а уж особенно интересен прогресс. И не в виде отчетов "мы реализовали DAL", а в виде вполне конкретной работающей системы без каких-то фич.

Уверен что 99,9% заказчиков думают также. Проблема чаще всего заключается в том, чтобы организовать процесс, при котором регулярно можно что-то показывать.
Это кажется легко, а на деле готовый к поставке продукт сделать выходит по затратам в 3 раза больше, чем просто все закодить. Поэтому другой подход нужен.

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

Попробуйте задать более конкретный вопрос.
Кто? Например, мы. Как? Вы не поверите, но — by the book. Проект, впрочем, у нас тоже маленький, как и у вас, порядка 7-8 человеко-лет. Напоминаю вам в очередной раз, что большие начинаются от 50, суть на порядок больше вашего.

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

Fixed Price Contract? В таких контрактах вы не можете варьировать ничего. Это значит, что у вас все есть upfront: полное и подробное описание того, как должна работать система. Это, по сути, значит, что у вас есть полный набор acceptance tests, и ваша задача — закодировать ПО таким образом, чтобы все эти тесты проходили.
Я верно вас понимаю?

Или у вас bardak-style contract, то есть заранее известен бюджет, но что конкретно делается — в тумане, и никому не нужно? Тогда возвращайтесь к моему второму сообщению про "распильные" проекты и поступайте как там написано.

G>Уверен что 99,9% заказчиков думают также. Проблема чаще всего заключается в том, чтобы организовать процесс, при котором регулярно можно что-то показывать.
G>Это кажется легко, а на деле готовый к поставке продукт сделать выходит по затратам в 3 раза больше, чем просто все закодить. Поэтому другой подход нужен.

Да я-то как раз это понимаю
И потому на выходе из спринта не требую готовый к поставке продукт. Достаточно демонстрации единичного настроенного экземпляра. Условие, по сути, только одно — мышка и клавиатура у меня в руках, и в пределах сценариев, промаркированных 'done', разрешается делать что угодно в любой последовательности, причем ожидается, что система либо сработает как надо, либо выдаст ошибку "не доделано" (если там требуется какой-то смежный сценарий, который еще не done).