Всем привет!
Стало интересно, возможен ли 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>И вообще ,применим ли скрам для вот такой заказной разработки для внешнего заказчика, или прерогатива скрама — внутренняя разработка, или разработка небольших проектов?
Прекрасно применим, и, более того, позволяет добиться куда лучшего компромисса по срокам и фичам. В вашем традиционном варианте сроки как правило не выдерживаются.
