Всем привет!
Стало интересно, возможен ли SCRUM в больших проектах и заказной разработке.
Например, заказчик — крупное предприятие, ему нужна ERP-система. Срок разработки для команды из 5 человек — 1 год.
Как тут применить SCRUM, когда допустим месяц будет только проектироваться БД, месяц будет писаться слой сервисов. Все завершиться пусконадалкой.
Проект, как водится, начнем с аналитики, тз, потом будут работать архитектор, и потом программирование.
Вот как тут применить SCRUM?
Или вот такие огромные проекты для внешних заказчиков только водопадом управляются?
Здравствуйте, IComparable, Вы писали:
IC>Проект, как водится, начнем с аналитики, тз, потом будут работать архитектор, и потом программирование. IC>Вот как тут применить SCRUM?
Вопрос пока выглядит как "мы собираемся работать по водопаду, как нам применить SCRUM"
Для начала три вопроса:
* Что вы хотите получить от скрама?
* Что мешает проектировать БД/писать сервисы etc порциями, по мере определения задач на итерацию?
* После релиза продукт нужно сопровождать/расширять, без поставленных итераций тут не обойтись. Что мешает начать вводить итерации сейчас?
Здравствуйте, IComparable, Вы писали:
IC>Вот как тут применить SCRUM?
А зачем его вообще применять? Какую пользы вы хотите получить от скрама в вашем конкретном случае?
IC>Или вот такие огромные проекты для внешних заказчиков только водопадом управляются?
Если для вас кроме скрама и водопада ничего нет, откройте для себя какую-нибудь книжку по управлению IT проектами. Тот же PMBOK, например, мозги здорово ставит на место.
Здравствуйте, IComparable, Вы писали:
IC>Всем привет! IC>Стало интересно, возможен ли SCRUM в больших проектах и заказной разработке. IC>Например, заказчик — крупное предприятие, ему нужна ERP-система. Срок разработки для команды из 5 человек — 1 год. IC>Как тут применить SCRUM, когда допустим месяц будет только проектироваться БД, месяц будет писаться слой сервисов. Все завершиться пусконадалкой. IC>Проект, как водится, начнем с аналитики, тз, потом будут работать архитектор, и потом программирование. IC>Вот как тут применить SCRUM? IC>Или вот такие огромные проекты для внешних заказчиков только водопадом управляются?
Зависит от того, что вам надо — сделать у заказчика автоматизацию или завершить проект. Скрам предназначен для первого варианта использования и не предназначен для вторго.
По первому варианту последовательность действий примерно такая:
1. Поверхностно изучаем процессы заказчика, выделяем основные элементы для автоматизации.
2. Выделяем двухнедельных спринт, на котором мы будем автоматизировать занесение бухгалтером в базу, к прмеру, списка сотрудников, и получение их из нее.
3. Делаем примитивную программу. Показывам бухгалтеру. Бухгалтер долго смеется, оказывается что работа со списком сотрудников в представлении гендира и главбуха — совершенно разные вещи. Составляем список изменений на втору итерацию, добавлем занесение информации о больничном.
4. Делаем вторую версию, показываем, получаем фидбек, добавляем фичей.
И так крутимся пока либо все не автоматизируем, либо не кончится бюджет либо заказчик не поймет, что та автоматизация котору он придумал, посмотрев кино с волшебниками и драконами, и то что делается в реальной жизни — это немного разные вещи.
Пример исключительно иллюстративный, не имеет ничего общего с реальностью.
Здравствуйте, Eye of Hell, Вы писали:
EOH>И так крутимся пока либо все не автоматизируем, либо не кончится бюджет либо заказчик не поймет, что та автоматизация котору он придумал, посмотрев кино с волшебниками и драконами, и то что делается в реальной жизни — это немного разные вещи.
По-моему, это не скрам, а культ карго в чистейшем виде. Нормальный подход обязательно предусматривает набор целей на следующий мажорный релиз как минимум. Эти цели весьма однозначны и прописаны в прилагаемый к договору ТЗ, так что отвертеться без потерь не получится.
Ну а как именно оно будет достигаться исполнителем: водопадом, скрамом или ночными хакфестами в пижамах, — заказчику глубоко параллельно.
S>По-моему, это не скрам, а культ карго в чистейшем виде. Нормальный подход обязательно предусматривает набор целей на следующий мажорный релиз как минимум. Эти цели весьма однозначны и прописаны в прилагаемый к договору ТЗ, так что отвертеться без потерь не получится.
Конечно культ карго. Я не только product backlog опустил, но также ретроспективу, стори поинты и много всего другого. Мне так проще рассказать автору вопроса о моем опыте использования скрам. Ну а что я не крут — тут уже ничего не поделаешь, не всем же быть победителями
Здравствуйте, Sinix, Вы писали:
S>Ну а как именно оно будет достигаться исполнителем: водопадом, скрамом или ночными хакфестами в пижамах, — заказчику глубоко параллельно.
Тут еще может сказаться специфика проектов ERP. Насколько я слышал решение о внедрении ERP принимается где-то вверху, а с интеграторами контактируют люди, которые не хотят внедрения ERP решения. И ни то что не помогают, они даже мешат. (Поправьте меня, если я не прав.)
Поэтому скрам, ИМХО, тут никак не сработает. Даже если сильно постараться.
Насколько я представляю ERP специфику (сам не работал, мы поставляем данные в SAP на крупном заводе в команде есть саповцы, кучу знакомых внедряют SAP).
Для таких проектов больше подходит RUP настроенный ближе к водопаду, чем к итеративным методологиям (да, РУП, оказывается, настраивается).
Здравствуйте, akava, Вы писали:
S>>Ну а как именно оно будет достигаться исполнителем: водопадом, скрамом или ночными хакфестами в пижамах, — заказчику глубоко параллельно. A>Тут еще может сказаться специфика проектов ERP. Насколько я слышал решение о внедрении ERP принимается где-то вверху, а с интеграторами контактируют люди, которые не хотят внедрения ERP решения. И ни то что не помогают, они даже мешат. (Поправьте меня, если я не прав.)
Угу, тут как повезёт, всё очень зависит от масштаба продукта, уровня аналитиков и от того, как далеко от коллектива принимают решение о покупке ERP.
A>Насколько я представляю ERP специфику (сам не работал, мы поставляем данные в SAP на крупном заводе в команде есть саповцы, кучу знакомых внедряют SAP). A>Для таких проектов больше подходит RUP настроенный ближе к водопаду, чем к итеративным методологиям (да, РУП, оказывается, настраивается).
Угу. Для работы с крупным заказчиком вообще лучше подходят методики, заточенные на достижение компромисса цели-сроки. Другое дело, что скрам в принципе не противоречит планированию по крупным итерациям и скраму в промежутках.
Здравствуйте, Sinix, Вы писали:
A>>Насколько я представляю ERP специфику (сам не работал, мы поставляем данные в SAP на крупном заводе в команде есть саповцы, кучу знакомых внедряют SAP). A>>Для таких проектов больше подходит RUP настроенный ближе к водопаду, чем к итеративным методологиям (да, РУП, оказывается, настраивается). S>Угу. Для работы с крупным заказчиком вообще лучше подходят методики, заточенные на достижение компромисса цели-сроки. Другое дело, что скрам в принципе не противоречит планированию по крупным итерациям и скраму в промежутках.
Скрам (в промежутках), как и весь эджайл, во главу угла ставит обратную связь от заказчика (пусть даже им будет наш аналитик). Получить ее будет очень сложно.
Так же для скрама вожна возможность частого delivery. Насколько я знаю, SAP это не позволяет (у нас есть выделенная delivery team которая занимается Транспортом наших изменений).
Важно так же иметь возможность распаралелить задачи, для этого нужно каждому свою песочницу. Что невозможно для SAP. Мы работаем удаленно с песочницей в люксембурге.
Много еще чего есть. Люди внедряющие ЕРП скажут лучше.
В общем, я не вижу как тут скрам можно прикрутить. Только в качестве решения внутренних (в команде) вопросов. Но, ИМХО, это того не стоит.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IComparable, Вы писали:
IC>>Проект, как водится, начнем с аналитики, тз, потом будут работать архитектор, и потом программирование. IC>>Вот как тут применить SCRUM? S>Вопрос пока выглядит как "мы собираемся работать по водопаду, как нам применить SCRUM"
S>Для начала три вопроса: S>* Что вы хотите получить от скрама? S>* Что мешает проектировать БД/писать сервисы etc порциями, по мере определения задач на итерацию? S>* После релиза продукт нужно сопровождать/расширять, без поставленных итераций тут не обойтись. Что мешает начать вводить итерации сейчас?
Ну мы от скрама пока ничего не хотим, мы хотим понять, подходит ли скрам для нас.
Вот меня и заботит по поводу того, что скрам ставит во главу угла обратную связь от заказчика, так же частые итерации.
А у нас такая специфика: заказчкит говорит вот хочут то и то, мы ему — надо год работы и много денег.
Мы делаем реально большие проекты.
Сейчас мы работаем так: вот получили от заказчика деньги, подписан договор, к нему ТЗ.
Любое отступление от ТЗ — это доплата со стороны заказчика.
Мы физически не можем показать заказчику часть функционала, т.к. из этого года(на вскидку) месяцев 9 пишется все кроме допустим гуя(ну нечего посмотреть заказчику, короме кода сервисов, дала и прочего).
Да и заказчик ничего смотреть не хочет — ему нужен конечный продукт — никто не будет смотреть, как его части сделаны.
Другими словами — есть дата сдачи проекта вот к ней и должно все быть готовым. А проекты большие — там даже обратную связь не от кого получить нельзя толком, т.к. заказчики большие корпорации.
И сейчас мы делаем так: вот проект, разбили на части(сроки для каждой части есть) и делаем, короче — водопад.
Вот как на такой процесс скрам ложиться?
И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IComparable, Вы писали:
IC>>Проект, как водится, начнем с аналитики, тз, потом будут работать архитектор, и потом программирование. IC>>Вот как тут применить SCRUM? S>Вопрос пока выглядит как "мы собираемся работать по водопаду, как нам применить SCRUM"
S>Для начала три вопроса: S>* Что вы хотите получить от скрама? S>* Что мешает проектировать БД/писать сервисы etc порциями, по мере определения задач на итерацию? S>* После релиза продукт нужно сопровождать/расширять, без поставленных итераций тут не обойтись. Что мешает начать вводить итерации сейчас?
Ну мы от скрама пока ничего не хотим, мы хотим понять, подходит ли скрам для нас.
Вот меня и заботит по поводу того, что скрам ставит во главу угла обратную связь от заказчика, так же частые итерации.
А у нас такая специфика: заказчкит говорит вот хочут то и то, мы ему — надо год работы и много денег.
Мы делаем реально большие проекты.
Сейчас мы работаем так: вот получили от заказчика деньги, подписан договор, к нему ТЗ.
Любое отступление от ТЗ — это доплата со стороны заказчика.
Мы физически не можем показать заказчику часть функционала, т.к. из этого года(на вскидку) месяцев 9 пишется все кроме допустим гуя(ну нечего посмотреть заказчику, короме кода сервисов, дала и прочего).
Да и заказчик ничего смотреть не хочет — ему нужен конечный продукт — никто не будет смотреть, как его части сделаны.
Другими словами — есть дата сдачи проекта вот к ней и должно все быть готовым. А проекты большие — там даже обратную связь не от кого получить нельзя толком, т.к. заказчики большие корпорации.
И сейчас мы делаем так: вот проект, разбили на части(сроки для каждой части есть) и делаем, короче — водопад.
Вот как на такой процесс скрам ложиться?
И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
Здравствуйте, IComparable, Вы писали:
IC>И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
Если вас интересует что такое Скрам и Эджайл, то есть отличный ролик в котором за 15 минут (реальных) на русском рассказывают о принципах гибкого управления продуктом. Это перевод на русский язык видео-презентации Хенрика Книберга Agile Product Ownership in a nutshell, сделанный Борисом Вольфсоном. Ссылка на видео.
Ролик настолько мне понравился, что я составил содержание ролика для удобства и привлечения внимания. Разбиение на части весьма условно, в ролике все идет одной частью. Часто было сложно выделить пункты, потому сильно не пинайте, а лучше предлагайте как это исправить.
Введение 00:00
00:00 Роли участников команды
01:08 Выпуск фич продукта
01:42 Добавление хотелок
02:05 Превращение хотелок в продукт
Планирование работ 02:38
03:24 Очередь хотелок: бэклог.
03:37 Важное слово "НЕТ"
04:13 Приватизация (ценность vs размер фичи)
Оценка (игра в угадайку) 05:18
05:38 Относительная оценка фич между собой
05:55 Обратная связь
06:25 backlog grooming (оценка и разбиение фич)
07:05 Коммуникации -секрет успеха
Решения владельца продукта 07:50
07:50 Риски
08:28 Снижение рисков (прототипирование, получение знаний)
09:18 short term vs long term
Противостояние ролей в Scrum 10:23
Определение сроков разработки (прогноз) 11:31
12:00 Burn up (продуктивность команды)
12:40 Конус неопределенности
12:51 Fixed scope project
13:05 Fixed time (price)
13:22 Fixed scope&time
Масштабирование (большой проект, несколько команд) 14:48
Здравствуйте, IComparable, Вы писали:
IC>Вот меня и заботит по поводу того, что скрам ставит во главу угла обратную связь от заказчика, так же частые итерации.
Если быть точным, то он, как и весь Эджаил, ставит во главу угла коммуникации. В том числе между заказчиком и исполнителями. Обратная связь это как раз пример такой коммуникации. А частые итерации это способ получить обратную связь раньше.
IC>А у нас такая специфика: заказчкит говорит вот хочут то и то, мы ему — надо год работы и много денег. IC>Мы делаем реально большие проекты. IC>Сейчас мы работаем так: вот получили от заказчика деньги, подписан договор, к нему ТЗ. IC>Любое отступление от ТЗ — это доплата со стороны заказчика.
Я сейчас могу спросить: А почему это проблема? Что вас в таком подходе не устраивает? Но буду, потому как все сведется к непониманию и длинным сообщениям ни о чем. Но себе на этот вопрос я предлагаю все же ответить. Ответили, и опять спрашивайте "почему это плохо". Распутывайте цепочку до тех пор, пока вопрос "почему это плохо" не станет смешным. (этот способ я узнал от Стратоплана и он мне очень понравился. Подробности можно посмотреть тут, секция Вопросы на прояснение критики).
IC>А у нас такая специфика: заказчкит говорит вот хочут то и то, мы ему — надо год работы и много денег. IC>Мы делаем реально большие проекты. IC>Сейчас мы работаем так: вот получили от заказчика деньги, подписан договор, к нему ТЗ. IC>Любое отступление от ТЗ — это доплата со стороны заказчика.
Если это действительно проблема, то решения тоже есть. Например разделение работы на фазы. На начальных фазах упор делается на анализ и выснения требований. в зависимости от результатов фазы составляется объем работ на следующие, а так же принимается решение о целесообразности продолжения.
Но это сложно и геморойно, особенно заявлять заказчику о возможности неудачи с самого начала.
И все я же я еще раз рекомендую ознакомиться с RUP. ИМХО, это именно то что вам нужно.
В любом случае я не верю, что до подписания договора ваши аналитики не исследуют бизнесс заказчика вдоль и поперек.
IC>Мы физически не можем показать заказчику часть функционала, т.к. из этого года(на вскидку) месяцев 9 пишется все кроме допустим гуя(ну нечего посмотреть заказчику, короме кода сервисов, дала и прочего).
А кто сказал что будет легко? Даже не в ERP, где инструменты не в пример гибче, приходится потрудиться, чтобы показать что-нибудь как можно раньше..
IC>Да и заказчик ничего смотреть не хочет — ему нужен конечный продукт — никто не будет смотреть, как его части сделаны. IC>Другими словами — есть дата сдачи проекта вот к ней и должно все быть готовым. А проекты большие — там даже обратную связь не от кого получить нельзя толком, т.к. заказчики большие корпорации.
На самом деле заказчик хочет смотреть. Просто ему никто не объяснил зачем это ему делать. Но объяснять сложно, геморойно, чревато отказами от работ. Поэтому так мало кто поступает. Проще сказать: "откиньтесь на спинку кресел, мы решим все ваши проблемы", а уже потом (и не мне, а кому-то еще) придумать 1000 причин почему получилось не так.
IC>Вот как на такой процесс скрам ложиться? IC>И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
На скрам ложаться проекты разные проекты. И большие и маленькие. Ничего не мешает большой проект вести по RUP, а подпроекты и фазы вести по скраму (об этом уже упомянал
Здравствуйте, akava, Вы писали:
A>На скрам ложаться проекты разные проекты. И большие и маленькие. Ничего не мешает большой проект вести по RUP, а подпроекты и фазы вести по скраму (об этом уже упомянал
Sinix). Много чего можно. Но все же нельзя делать Скрам, если заказчик НЕ хочет сотрудничать.
А, да! Если вы тоже НЕ хочете сотрудничать с заказчиком, то Скрам тоже не будет работать.
Вы готовы открыться перед заказчиком?
Здравствуйте, akava, Вы писали:
A>Здравствуйте, akava, Вы писали:
A>>На скрам ложаться проекты разные проекты. И большие и маленькие. Ничего не мешает большой проект вести по RUP, а подпроекты и фазы вести по скраму (об этом уже упомянал
Sinix). Много чего можно. Но все же нельзя делать Скрам, если заказчик НЕ хочет сотрудничать. A>А, да! Если вы тоже НЕ хочете сотрудничать с заказчиком, то Скрам тоже не будет работать. A>Вы готовы открыться перед заказчиком?
A>СУВ, akava
Видите, я наблюдаю такую ситуацию: в нашей компании есть внутренний продукт — ERP-система, и мы его делаем для себя, тут мы работаем по скраму(у нас итерация месяц- специфика нашей компании, плэнинг покер, все как надо, обратная связь с заказчиком — заказчик мы же!).
Но, так же наша компания занимается разработкой на заказ очень больших проектов — минимальное время разработки год.
И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
И эти заказные проекты мы делаем по водопаду(этапы, сроки...).
Вот и я не вижу, как применить скрам вот к таким проектам?
Есть ли смысл делать такой проект по скраму, т.к. при этом подходе(продукт сдается заказчику в конце разработки) скрам выродится в водопад с этапами в длину спринта.
Меня это и волнует, проявляется явный диссонанс с идеей скрама — нет коммуникации с заказчиком(зачастую у нас заказывает чей-то субподрядчик), нет релизов(проект большой и допустим мы написали за месяц только DAL, но это ведь не релиз, или это релиз с DAL-ом?
Т.е. получается что скрам не работает при больших проектах и заказной разработке?
Здравствуйте, IComparable, Вы писали:
IC>Т.е. получается что скрам не работает при больших проектах и заказной разработке?
Я не понимаю почему из того, что вы даже не пытались делать свой проект по скраму вы делаете такой вывод?
IC>Видите, я наблюдаю такую ситуацию: в нашей компании есть внутренний продукт — ERP-система, и мы его делаем для себя, тут мы работаем по скраму(у нас итерация месяц- специфика нашей компании, плэнинг покер, все как надо, обратная связь с заказчиком — заказчик мы же!). IC>Но, так же наша компания занимается разработкой на заказ очень больших проектов — минимальное время разработки год. IC>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов). IC>И эти заказные проекты мы делаем по водопаду(этапы, сроки...). IC>Вот и я не вижу, как применить скрам вот к таким проектам? IC>Есть ли смысл делать такой проект по скраму, т.к. при этом подходе(продукт сдается заказчику в конце разработки) скрам выродится в водопад с этапами в длину спринта. IC>Меня это и волнует, проявляется явный диссонанс с идеей скрама — нет коммуникации с заказчиком(зачастую у нас заказывает чей-то субподрядчик), нет релизов(проект большой и допустим мы написали за месяц только DAL, но это ведь не релиз, или это релиз с DAL-ом?
Вы проигнориловали все мои ответы выше. Извините, не вижу смысла отвечать на эти.
Здравствуйте, IComparable, Вы писали:
IC>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов).
Любой agile подход работает только при условии, что вы можете как минимум раз в итерацию получать адекватный фидбек от заказчика. Не от промежуточного звена, а от того, кто будет использовать систему.
Иначе ни один agile подход не работает.
Если вы являетесь непосредственным субподрядчиком для генподрядчиков, то можно найти адекватного PO у генподрядчика, и работать по T&M. Если же цепочка длиннее, то scrum не будет работать никак.
IC>Т.е. получается что скрам не работает при больших проектах и заказной разработке?
Нет, срам не работает, если нет возможности получать фидбек. Это может быть на распильном проекте, где заказчику пофиг на результат. Это может быть при длинной цепочке субподряда или длинной цепочке "передачи информации", когда между командой и заказчиком 100500 менеджеров.
Это абсолютно нерелевантно размеру проекта.
Здравствуйте, gandjustas, Вы писали:
IC>>И часто бывает, что мы даже не знаем финального заказчика(мы конечное звено в цепочке перезаказов). G>Любой agile подход работает только при условии, что вы можете как минимум раз в итерацию получать адекватный фидбек от заказчика. Не от промежуточного звена, а от того, кто будет использовать систему.
Насколько я понимаю agile, фидбек не обязательно должен исходить от заказчика. Он может исходить от нашего аналитика, субподрядчика или еще от кого-то.
Ясное дело, что в этом случае мы получим продукт, который хочет получить "аналитик, субподрядчик или еще кто-то".
Но ведь и с реальными пользователями то же самое. Если в Скраме будет участвовать представитель заказчика, то мы получим систему, удовлетворяющую его нуждам. Что может совершенно не соответствовать потребностям другого подразделения или высшего руководства.
Получается что Скрам возможен и без контакта с заказчиком, но тогда на аналитика (например) ложится ответственность за предоставление адекватной информации о нуждах пользователей.
IC>Стало интересно, возможен ли SCRUM в больших проектах и заказной разработке.
В заказной разработке — очень даже.
С большими проектами сложнее, я бы сказал, что зависит от специфики проекта. Многие большие проекты регламент-driven, суть начинаются с того, что прописываются все процедуры внесения изменений и процесс разработки.
IC>Например, заказчик — крупное предприятие, ему нужна ERP-система. Срок разработки для команды из 5 человек — 1 год.
Это не большой, а маленький проект. Средние начинаются от 15 человеко-лет, большие — 50 и больше.
IC>Как тут применить SCRUM, когда допустим месяц будет только проектироваться БД, месяц будет писаться слой сервисов. Все завершиться пусконадалкой.
Вы не поняли суть SCRUM. Команда, работающая по SCRUM, не делает итераций типа "спроектировали БД". Вместо этого каждую итерацию выдается готовый (за вычетом "пусконаладки" aka "интеграции с окружением заказчика") продукт.
IC>Вот как тут применить SCRUM?
Классически. By the book.
IC>Или вот такие огромные проекты для внешних заказчиков только водопадом управляются?
Перетаньте уже народ смешить "огромными" проектами в 5 человеко-лет.
IC>Ну мы от скрама пока ничего не хотим, мы хотим понять, подходит ли скрам для нас.
Вероятнее всего, не подходит, поскольку вы не понимаете, что есть scrum.
Чтобы скрам подошел, вам нужен хотя бы один тренер. Который понимает, что как работает, и что зачем делается.
IC>Мы делаем реально большие проекты.
Большие проекты начинаются от 50 человеко-лет. Можете назвать хотя бы парочку таких?
IC>И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
Прекрасно применим, и, более того, позволяет добиться куда лучшего компромисса по срокам и фичам. В вашем традиционном варианте сроки как правило не выдерживаются.
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>Это абсолютно нерелевантно размеру проекта.
Ну вот пример, внедряем медицинскую ИС.
Есть ТЗ уже.
Вот, ну кто там со стороны заказчика будет что-то там запускать? Вы себе госконторы представляете(там всем все пофиг). Да и как вы себе это представляете(итерации то короткие, а система огромная, ну тупо показать за первые полгода нечего кроме кода).
Надо тупо сделать, пусконаладить, получить акт внедрения и забыть про это.
А эту штуку еще год делать, вот как тут скрамом управлять?
Тут все что-то говорят-говорят, про фидбек и т.д.
А я никого не убеждаю — это факт — зачастую этого фидбека не добиться, или невозможно в итерацию его получить по тем или иным причинам.
И как вообще управлять такими проектами — бюджет, сроки утверждены, никто ничего менять не будет — следовательно ни о каких доработках и речи идти не может, т.к. это допфинансирование, а этим никто заниматься не будет.не из своего же кармана финансировать?
Посмотрите на проблему с другой стороны:
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).
)