Толпа и мотивация [закрываются]

По моему опыту, разработчики вносят цифры из-за неопределенности. Понятны ли владельцы ваших продуктов в своих бизнес-требованиях? Достаточно ли малы истории, чтобы сравнивать их?

Два ваших варианта выбора указывают мне на то, что вы имеете фундаментальное непонимание Scrum. Скрам обещает получить не тот же результат, а только быстрее.Это способность быстро выполнять итерацию, реагировать на отзывы и менять курс. Основа Scrum - это самодостаточная команда. Если у вас нет команд, которым вы доверяете, скорее всего, Scrum не для вашей организации.

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

На самом деле невозможно "дополнить" оценки в схватке. После нескольких спринтов скорость станет средней, и команда будет «знать», сколько очков она может набрать. Нет ничего, что можно было бы подкладывать.

Я думаю, что ваши утверждения перевернуты, потому что

Выполняйте работу всякий раз, когда мы уменьшаем объем, качество или увеличиваем ресурсы

- точное описание Waterfall; не разборки. В scrum у нас есть дедлайны, это называется окончанием спринта. В схватке мы НИКОГДА не жертвуем качеством, потому что знаем, что в конечном итоге это будет стоить нам больше. В схватке мы не добавляем ресурсы, потому что знаем, что люди образуют «команду», и нарушение этого баланса пагубно сказывается на производительности.

Почему вы вообще беспокоитесь о времени выполнения задач? Единственный раз, когда я видел хорошие оценки разработчика, - это когда они были вынуждены дать оценку для неизвестной функции. Мы не делаем этого в схватке. Мы знаем, каковы условия принятия функции, прежде чем мы ее примем.

Основа наиболее гибких методы - это trust . Если вы не доверяете своей команде, зачем вы их наняли? Если вы думаете, что они не справятся с задачей, лучше не начинать проект, потому что он почти наверняка обречен на провал - либо потому, что вы правы, а команда состоит из неумелых разработчиков, либо потому, что вы ошибаетесь, но недостаток доверия и чрезмерный контроль душит команду и фактически подрывает их приверженность и энтузиазм.

OTOH: если вы уверены, что наняли лучших из имеющихся, что они талантливы и мотивированы, лучше всего дать им хороший вызов, позволить им поработать и попытаться устранить все препятствия на их пути.

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

Суть гибких методов заключается в том, что разработчики - это те люди, которые знают / оценивают стоимость конкретной функции. Если руководство настаивает на оценке и ресурсов, объема и времени, выделенных на проект, это почти всегда приводит к катастрофе. Если OTOH-разработчикам доверяют и доверяют, они обычно справляются со своей задачей. В Scrum команда вместе разрабатывает оценки и борется с проблемами / проблемами, возникающими во время спринта. В хороших проектах члены команды быстро соединяются с командой и чувствуют личную ответственность за проект. Это может доходить до тех пор, пока отстающие члены добиваются результатов, а не отбрасывают команду назад.

Кроме того, гибкие методологии способствуют повышению ответственности перед сверстниками. У вас не должно быть только одного человека, оценивающего предметы. Сделайте это групповой вещью и убедитесь, что (в основном) все согласны с оценкой. Если вся ваша команда вступила в сговор против вас, чтобы подставить оценки, у вас гораздо больше проблем, чем вы думаете.

Кроме того, есть много возможностей для оценки и оправдания в традиционных усилиях водопада / BDUF (большой дизайн впереди). Я бы сказал, что скрам, с ежедневными скрам-встречами, помогает сдерживать это больше, чем помогает продвигать его.

Некоторое время назад я написал в блоге сообщение об оценочных антипаттернах. Это забавное чтение, но, к сожалению, все закономерности - это то, что я видел или слышал от коллег. Мы рассмотрели около 3 из них в нашем текущем проекте; Не думаю, что есть какая-то команда, которой удастся полностью их избежать!

http://lizkeogh.com/2009/11/30/estimation-anti-patterns/

Также обратите внимание на системное мышление, теорию игр и извращенные стимулы. Если разработчики дополняют оценки, это потому, что среда, в которой они работают, поощряет их делать это. Изменение этой среды поможет им.

Хорошие ответы на этот вопрос уже есть. По сути, если вы предполагаете, что разработчики обманывают вас, сообщая о часах, которые они фактически не работали (но потратили на то, чтобы играть в любую MMORPG, которая сейчас в моде), почему вы вообще вообще с ними работаете? И если вы им доверяете, почему вы думаете, что они «подкладывают»?

Кстати - это совершенно нормально для команд, которые плохо знакомы со Scrum, сначала переоценивают (и вынуждены отказываться от предметов из Sprint), а затем - получая таким образом ожоги - недооценивают, чтобы это не повторилось с ними снова, а затем, как указывали другие скорость работы команды выровняется, и люди будут лучше понимать, что они могут сделать за спринт.

Еще один намек на то, что вы можете сделать: не подвергайте сомнению их часы работы, не пытайтесь «управлять» ими, говоря им, сколько времени должно занять то или иное время. Скорее спросите их , как они хотят достичь того или другого, какие решения они хотят использовать и почему? Хорошие гики часто склонны чрезмерно заниматься проектированием - если что-то выглядит намного больше, чем вы ожидали, вероятно, здесь возникло недопонимание относительно того, что создается, и которое необходимо прояснить.

Один из подходов, позволяющих полностью избежать этой ситуации, - оценивать в сюжетных точках, то есть задавать вопрос: "Требует ли эта история больше или меньше работы по сравнению с той?".