Ок, если другие тоже пишут про боли скрама, мне это не запрещено я надеюсь?
Я где-то делал упор на уникальность?
Я где-то писал, что скрам невозможен?
Сазерлэнд не пишет про Скрам вокруг продукта. Наоборот он пишет про Скрам в школе, например.
Если ошибки типичные, мне запрещено о них писать?
Как мы уже начали догадываться кейс ни один их ни два и ни три. И лично я не боролся, не ждал, не переносил, не уговаривал, не увольнял и т.д. Все решилось без этого. И без продукта. Именно продукт ни в Agile Manifesto, ни у Сазерлэнда ни у Бека не требуется.
При этом я фанат Customer Development, книги Блэка, Риса, Альварес, Фицпатрика и даже Симса и даже Зерацки я с удовольствием прочел. Гибкая методология действительно совместима с Customer Development и это тема для отдельной статьи или может быть книги. Этот текст я решил не перегружать продукатми.
Я прочел предыдущие три книги. Метод Талеба — это сплошной невроз. Фу так жить.
Вы наверное заказываете все-таки такси, а не джихад-мопед, когда ехать хотите? -)
Комфорт важен. Удовольствие от жизни и работы важно.
Я постоянно участвую в таких проектах.
1. Там обычно не прописано четко, что нужно сделать, чтобы проект считать завершенным, хорошо, если нет противоречий.
2. Первым спринтом закрываем базовый функционал и отдаем заказчику тестить рабочую систему.
3. Заказчик тестит, радуется, ведь что-то сдвинулось с мертвой точки, грустит, что все не идеально, пишет лист доработок для идеала.
4. Его лист естественно никак не матчится с «огромный скоуп — фиксированная дата».
5. Идем на встречу по гибкой методолгии и договариваемся: что добавляем в огромный скоуп, что убираем из огромного скоупа, что делаем с датой.
6. Вторым спринтом закрываем открывшиеся понимание и предлагаем уже тестить на живых пользователях.
7. Вот тут у многих заказчиков проблема, никак не могут одобрить релиз. Оттягивают его, пытаются все сделать идеально. Но как бы идеально не было — все равно живые пользователи прикалываются к чему-нибудь совершенно непредсказуемому. Поэтому чем раньше первый релиз — тем лучше.
Сазерлэнд именно такие примеры в своей книге и описывает.
От себя добавлю, что если не показывать динамику, то проект могут и закрыть. А если спринтом выкатить первую грубую версию, то дальше заказчик немного прозревает и с ним уже можно на что-то адекватное договориться.
Скорее всего я это прочел в книге «Scrum и XP: заметки с передовой» Хенрик Книберг. Кстати крутая практическая книга даже в чем-то лучше Сазерлэнда, очень рекомендую!
Практика это подтверждает! Должны быть перерывы между спринтами, иначе выгорают люди.
Важна регулярность. Если все настроились на 10 утра, например, то начинают подтягивать под это свое расписание.
Вечером обычно плохо, т.к. все уже устали.
Плавающий график — тоже плохо, так из-за него кто-то может не попасть.
У меня это сработало иначе.
Поговорить не помогло -)
Я стал начинать ровно в 10:00 и заканчивать ровно в 10:10 и все привыкли не опаздывать. Тем более все хотели меньше времени тратить на планерки!
Одним человеком был Бенжамин Франклин
А историю «слышали» как цитату из книги Дейла Карнеги «Как приобретать друзей и оказывать влияние на людей».
На мой взгляд: устаревшая книга (1936г.), слабый автор, слабый материал, очень натянутый пример (XIIX века).
Насколько это рабочая методика — огромный вопрос, особенно на фоне того, что было придумано и доказано позже.
Зато написана эмоционально и все цитируют, как вы сейчас -)
Я где-то делал упор на уникальность?
Я где-то писал, что скрам невозможен?
Сазерлэнд не пишет про Скрам вокруг продукта. Наоборот он пишет про Скрам в школе, например.
Если ошибки типичные, мне запрещено о них писать?
Как мы уже начали догадываться кейс ни один их ни два и ни три. И лично я не боролся, не ждал, не переносил, не уговаривал, не увольнял и т.д. Все решилось без этого. И без продукта. Именно продукт ни в Agile Manifesto, ни у Сазерлэнда ни у Бека не требуется.
При этом я фанат Customer Development, книги Блэка, Риса, Альварес, Фицпатрика и даже Симса и даже Зерацки я с удовольствием прочел. Гибкая методология действительно совместима с Customer Development и это тема для отдельной статьи или может быть книги. Этот текст я решил не перегружать продукатми.
Вы гайды не читаете. ОООК. А я читаю и много!
Допускаете ли вы, что в статьях и книгах обычно рисуется собирательный образ? -)
2. Из мой практики я либо модерирую, либо закрываю глаза
Вы наверное заказываете все-таки такси, а не джихад-мопед, когда ехать хотите? -)
Комфорт важен. Удовольствие от жизни и работы важно.
1. Там обычно не прописано четко, что нужно сделать, чтобы проект считать завершенным, хорошо, если нет противоречий.
2. Первым спринтом закрываем базовый функционал и отдаем заказчику тестить рабочую систему.
3. Заказчик тестит, радуется, ведь что-то сдвинулось с мертвой точки, грустит, что все не идеально, пишет лист доработок для идеала.
4. Его лист естественно никак не матчится с «огромный скоуп — фиксированная дата».
5. Идем на встречу по гибкой методолгии и договариваемся: что добавляем в огромный скоуп, что убираем из огромного скоупа, что делаем с датой.
6. Вторым спринтом закрываем открывшиеся понимание и предлагаем уже тестить на живых пользователях.
7. Вот тут у многих заказчиков проблема, никак не могут одобрить релиз. Оттягивают его, пытаются все сделать идеально. Но как бы идеально не было — все равно живые пользователи прикалываются к чему-нибудь совершенно непредсказуемому. Поэтому чем раньше первый релиз — тем лучше.
Я все-таки за то, чтобы был позитив.
От себя добавлю, что если не показывать динамику, то проект могут и закрыть. А если спринтом выкатить первую грубую версию, то дальше заказчик немного прозревает и с ним уже можно на что-то адекватное договориться.
Практика это подтверждает! Должны быть перерывы между спринтами, иначе выгорают люди.
Вечером обычно плохо, т.к. все уже устали.
Плавающий график — тоже плохо, так из-за него кто-то может не попасть.
Поговорить не помогло -)
Я стал начинать ровно в 10:00 и заканчивать ровно в 10:10 и все привыкли не опаздывать. Тем более все хотели меньше времени тратить на планерки!
А историю «слышали» как цитату из книги Дейла Карнеги «Как приобретать друзей и оказывать влияние на людей».
На мой взгляд: устаревшая книга (1936г.), слабый автор, слабый материал, очень натянутый пример (XIIX века).
Насколько это рабочая методика — огромный вопрос, особенно на фоне того, что было придумано и доказано позже.
Зато написана эмоционально и все цитируют, как вы сейчас -)
А я черствый, так что мне никто слезных писем не пишет -)