Проапдейтил на всякий случай. Спасибо.

Ночью лучше спать, а не читать книги по управлению проектами :) Спасибо :)

Привык в Ворде писать и в Визио рисовать. Я — раб Майкрософт :)

Грамматику лучше в личку или на мыло :)

Спасибо за идею.

Не за что :)

Пока не получается: пробовал конвертить в EPUB, к сожалению, «всё плывет, все меняется» :(

Я поэтому и выложил дополнительно на Яндексе :) На данный момент 271 скачивания с Dropbox и 172 с Яндекса, помножить на три мегабайта, получается не так много :)

По другим форматам и платформам думал, в планах есть. Посмотрим пока, каким тиражом книга разойдется :)

Я на хабре наверное опубликую, как только вопрос сдвинется с места ;)

Есть инсайд, что такие договора могут появиться после НГ :)

Я собственно и написал, что в теории беклог продукта самым, что ни есть, волшебным образом появляется у владельца продукта :) На практике необходимы определенные усилия и трудозатраты.

Про сторимаппинг из опыта могу сказать следующее (именно практические вещи):
— у команды улучшается видение целей и содержания проекта;
— у команды улучшается мотивация к успешному завершению проекта;
— выявляются целы «пласты» функционала, про который обычно забывают;
— четче и прозрачней расставляются приоритеты и планируются релизы;

Про мотивацию вопрос очень сложный и, безусловно, надо сочетать как материальные способы, так и нематериальные. Ваш кэп :)

Начал писать комментарий, а получился пост. Вообще темы интересные подняты :)

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

Ответ будет «В процессе» :)

Процентов на 80% совпал выбор лучших докладов. Я бы еще парочку добавил. И про кулуары согласен, самое интересное было между докладами, ну и в самом конце еще :)

По поводу fixed cost: опять же можно отлично использовать внутри скрам, конечно, все бенефиты скрама вы в итоге не получите.

Я бы еще добавил, что через пару спринтов, можно уже давать оценки по завершению проекта на основе реальной скорости команды и скорости добавления новых фич. Просто называете этот период «прототипирование» или «предварительное проектирование» и затем уже идет «разработка проекта».

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

Длинные митинги и их большое количество — это не скрам, а некачественная работа скрам-мастера :) Скрам — это гибкая методология с жестким таймбоксингом…