Создание команды — это высшая магия, все что может сделать скрам-мастер это создать предпосылки для ее возникновения. Кстати эта фраза из Алистера Кокберна «Cooperative Game». Согласен на 100%
А что такое мотивация? Куча денег? Вы сами согласились работать за эти деньги. Вас не замечают? Значит вы не сделали ничего особенного. У вас дерьмовый коллектив? Так вы же его часть. Вас заставляют писать плохой код? Я сам разработчик и если я хочу писать классный код я беру и его пишу. Если я хочу просто быстро на колене что-то собрать то я сам в этом виноват.
Представьте, что всем все равно. Всем наплевать, что будет с проектом. Если вы сами найдете в проекте интерес (А он обязательно есть даже в большой легаси системе и самой неинтересной технологии) вы получите персональную мотивацию. А дальше все просто, успех порождает успех. Начнете тестировать, упростится процесс добавления фичерсов, уменьшится время дебага сможете выделить время для настройки круиза, заработает круиз установите ковередж тул, опять же выиграете время для крупного рефакторинга (Отлично подход человека у которого есть интерес к тому что он делает расписан у Джефриса в Adventure to C#)
В ситуации когда менеджер запрашивает эстмейты у разработчиков, он практически не рискует получить эстимейт больше, чем время реально необходимое для выполнения здач. Виной тому неистребимый оптимизм разработчиков. Если придумать решение можно за 5 минут то и реализовать можно за не намного большее время :-) А вот для того, чтобы выйти на более-менее точный эстимейт нужно грамотно делать декомпозицию задач. У нас замечательно работает написание разработчиками приемочных критериев для юзер стори. Сколько они нового узнают, надо видеть :-) И эстимейты получаются более точные, когда известны детали. Не нужно забывать анализировать статистику предыдущих итераций и корректировать эстимейты на величину отставания (это 99% случаев).
В случае завышенных эстимейтов попросите разработчиков рассказать, чем именно они собираются заниматься все то время, что они заэстимейтили. Обычно причина ошибки в том, что по каждой из подзадач берется максимальный эстимейт, а потом они все суммируются, когда нужно взять среднее буферное время по всем здачам.
в какой-то книге о Тайм менеджменте я прочитал о подходе который называется «съешьте лягушку» и суть которого сводится к тому, чтобы неприятные вещи не откладывать и делать в первую очередь. Очень перекликается со статьей Лизы. А вообще конечно всё это очевидные вещи и завести бы какого-то персонального ментора, который бы чаше о них напоминал ;-)))
забыл добавить, что перегиб в сторону слишком маленьких стори, чреват неправильными эстимейтами. У Рона Джефриса (помоему) они называются Песок. Чем больше в итерациях песка, тем больше будет неучтенного времени, которое будет потрачено на переключение после завершения одной стори на другую.
К сожалению большинство принципов алгоритмические. Такой подход противоречит человеческой природе. Я пробовал само организовываться подобным образом и к сожалению не смог заставить работать себя в режиме конвейера. Попробуйте может для вас это будет работать.
Представьте, что всем все равно. Всем наплевать, что будет с проектом. Если вы сами найдете в проекте интерес (А он обязательно есть даже в большой легаси системе и самой неинтересной технологии) вы получите персональную мотивацию. А дальше все просто, успех порождает успех. Начнете тестировать, упростится процесс добавления фичерсов, уменьшится время дебага сможете выделить время для настройки круиза, заработает круиз установите ковередж тул, опять же выиграете время для крупного рефакторинга (Отлично подход человека у которого есть интерес к тому что он делает расписан у Джефриса в Adventure to C#)
В случае завышенных эстимейтов попросите разработчиков рассказать, чем именно они собираются заниматься все то время, что они заэстимейтили. Обычно причина ошибки в том, что по каждой из подзадач берется максимальный эстимейт, а потом они все суммируются, когда нужно взять среднее буферное время по всем здачам.