Гибкая 40-часовая неделя [закрывается]

Толпа и управление, которое готово вложиться в него.

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

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

Упаковка времени. если Вы сталкиваетесь с основными проблемами, начинают удалять функции из спринта вместо работы дополнительные часы.

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

Я упомянул просвещенное управление?

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

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

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

Быть неспособностью для выполнения задач на 40-часовой неделе могла произойти из-за нескольких вещей.

Я вижу, что это могло произойти в ранних спринтах проекта Толпы, потому что команда не была уверена в:

1. объем работы они могут сделать в спринте и могли бы откусить больше, чем они могут жевать, и
2. их способность оценить точно, что сумма точек присуждает блокам работы, или
3. усилие, требуемое выполнить "ценность точки" работы.

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

После этого мы входим в несколько из неприятных запахов Толпы, конкретно:

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

Если какой-либо из них включает затем, Вы:

1. выполнение Толпы только номинально, и
2. "ручей без весла".

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

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

HTH

с уважением,

Ограбить

Конечно.

Для меня самые важные вещи, которые помогли (в порядке важности):

1. Многопрофильная команда - наличие программистов, тестеров, технических писателей и людей продаж/сервисов в той же команде и говорящий друг с другом ежедневно (ежедневный вызов) было большим.
2. Регулярные сборки и непрерывная интеграция
3. Частые обзоры/демонстрации заинтересованным сторонам и клиентам. Это снижает риск и время, потерянное ему только в течение периода повторения (Sprint).
4. Ежедневный Вызов или Встает, встречаясь

Добавляя ко всему вышеупомянутому (неточные оценки, плохо реализованная Толпа, и т.д.), проблема могла, чтобы быть отсутствием понимания Скорости Вашей команды, что-то столь же простое как, "сколько работы команда может выполнить", но который не настолько легко найти, поскольку это может казаться.

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

Когда это является хорошо управляемым, средства для Толпы в уменьшении "давки", которая часто происходит в конце повторения путем поощрения (требование?) последовательный темп повсюду и инструменты как скорость и burndowns работают хорошо, чтобы запланировать и отследить прогресс.

Я работал в нескольких магазинах что методы различные гибкие методологии. Самый интересный имел 4 "сессии" в течение дня, которые были приблизительно полтора часа длиной с 20-минутным промежуточным повреждением. Пятница была Персональным днем Dev, таким образом, последние две сессии были для того, что Вы хотели продолжить работать.

Ключевыми вещами для нас была коммуникация, действительно закрепляя понятие пользовательских историй, определяя сделанный для значения "в производстве" и доверии. Мы также удостоверились, что разломали истории, на разделяет на блоки, которые были не больше, чем один день длиной, и идеально 1-2 сессии разработки. Мы обычно подкачивали пар каждая сессия к любой сессии.

В настоящее время я выполняю 20 + команда разработчиков человека, которая частично распределяется. Ключевой арендатор для меня является устойчивым темпом - и это означает, что я не хочу свою работу команд> 40-часовые недели даже иногда. Очевидно, если кто-то хочет остаться поздно и работать над вещами, это их дело, но в целом я упорно борюсь, чтобы удостовериться, что мы работаем в скорости, которую 40-часовая неделя дает нам.