Должны ли разработчики участвовать в процессах планирования отставания?
Недавно я взял интервью у компании, которая начала внедрять Scrum для своих циклов разработки. Я спросил одного из разработчиков, каков их опыт, и похоже, что они полностью отделены от процесса планирования. Ему не разрешали вносить вклад в то, что входило в данный Спринт, и он не участвовал ни в каких мероприятиях по планированию или уходу.
По сути, в начале последнего спринта (или двух) ему был передан список дел. Он должен был разбить элементы на соответствующие задачи (чтобы они могли работать над Спринтом), но не участвовал ни в каких мероприятиях по планированию; Я скептически отношусь к тому, что ему было дано много информации о том, сколько усилий может потребоваться для изделия - я подозреваю, что архитекторы решили это за команду.
Это как Scrum должен быть обработан? Моя текущая команда в полной мере участвует во всех мероприятиях по планированию, постоянно добавляя наш вклад в то, как функции могут быть рассмотрены и сколько усилий они могут предпринять. Я немного скептически (и нервничаю) по отношению к компании, которая просто передает разработчикам список дел, не спрашивая их мнение.
Примечание. Я понимаю, что после запуска Sprint список действительно становится списком приоритетов. Я обеспокоен тем, что с самого начала не могу внести свой вклад в процесс планирования.
11 ответов
Если те, кто выполняет работу, не могут предоставить информацию о том, какой объем работы может вписаться в спринт, и пусть бизнес решит, что является наиболее важным и должно быть запланировано, чтобы соответствовать. Это не собирается работать убегать. Они используют новые модные проворные слова, но делают те же самые старые вещи.
(...) Ему не разрешали вносить вклад в то, что входило в данный Спринт, и он не участвовал ни в каких мероприятиях по планированию или подготовке.
Очевидно, что они все еще выполняют командование, управление и микроуправление (команда не наделена полномочиями и самоорганизуется), и они все еще используют планирование на основе push (они не включали планирование по запросу).
У Scrum есть и другие характеристики, но вышеприведенных пунктов более чем достаточно, чтобы сказать, что они не делают Scrum, независимо от того, как они его называют, они на самом деле не отходили от устаревшего подхода с водопадом (они просто нанесли помаду на свинью).).
Это большой намек на то, что они до сих пор совершенно не понимают, о чем Scrum, они вообще не поняли. И это не изменится без некоторого осмотра и адаптации, если они даже захотят измениться. Если у вас нет сил, чтобы это произошло, убегайте.
Я работал в месте, которое называло себя проворным. У них было 6-8 месяцев цикла выпуска. Некоторые вещи возникли из задела, но на этапе "сбора требований" менеджеры в основном проводили неделю или две встречи с разными людьми в компании и составляли список функций. В первый день каждой четырехнедельной "итерации" команда разработчиков собиралась и разбивала все на серии встреч. Последним днем итерации был день развертывания, где должно было быть интримное развертывание, которое никто из команды разработчиков никогда не видел.
В течение 8-месячного цикла релизов менеджеры связывались с заинтересованными сторонами, может быть, один или два раза за последние два месяца релиза, и в этот момент единственными проблемами, поднятыми на этих встречах, которые имели шанс быть адскими до того, как релиз был проблемы, которые были достаточно плохими, чтобы сделать все усилия бесполезными, если они не были реализованы.
Это не ловко, это вариант водопада с плохим выбором идей и методологий, выбранных из других методологий. В конце концов, у него все еще есть те же проблемы, что и у водопада.
Урок, который я извлек из своей работы, заключается в том, что методологии развития включают в себя некоторые причины. Если вы выбираете вишню из методологии, не понимая ее полностью (и под полным пониманием, я имею в виду то, что на самом деле с ней поработали), есть большая вероятность, что вы не будете использовать то, что на самом деле жизненно важно для всего этого. Например, в xp Кент Бек выступает за рефакторинг позже, чтобы сократить первоначальный дизайн. Однако единственная причина, по которой это действительно работает, заключается в том, что он также поддерживает TDD и парное программирование. Если у вас есть исчерпывающий набор тестов и дополнительные возможности, рефакторинг достаточно безопасен. Если вы просто выбираете первую часть Черри и пропускаете эти две части, вы, по сути, являетесь ковбойским программистом.
По этой причине я крайне скептически отношусь к тем покупателям, которые используют свои собственные методологии. Есть абсолютно шокирующее количество преступлений, совершаемых во имя гибких.
Это как Scrum должен быть обработан?
Точно нет. Скрам стремится повысить прозрачность. Блокируя разработчиков от планирования деятельности, они делают противоположное тому, что предлагает Scrum.
Вы говорили о 2 моментах здесь: 1. Планирование спринта - здесь обязательно должны быть члены Scrum Team. 2. Бэклог Уход - май или может не потребоваться здесь. Вы должны использовать свои ресурсы с умом и со здравым смыслом. Думаю, здесь будет хорошо с одним членом команды с большим опытом работы с разработчиками.
В Scrum есть еще один тип:
Планирование выпуска - Некоторые могут сказать, что разработчики здесь не нужны. Но согласно Scrum Guide - "Планирование релиза требует оценки и расстановки приоритетов в бэклоге продукта для релиза". Определение приоритетов может быть сделано ПО и предложено заинтересованными сторонами, но оценка будет наиболее точной, если она будет сделана кем-то, кто на самом деле собирается выполнить работу, так что это хорошая идея - привлечь сюда разработчиков. Опять же, ресурсы должны использоваться разумно. Если имеет смысл не привлекать всех разработчиков и заставлять людей вращаться по очереди, чтобы оценить, это неплохая идея.
Я предлагаю придерживаться этой структуры: Планирование Спринта - часть 1: Оценка и извлечение резервов в Спринте из журнала невыполненных работ по продукту (PO, SM и Team здесь являются свиньями) Планирование Спринта - часть 2: Задачи, оценка часов задачи и разбивка их. (SM и Team - свиньи, PO здесь курица, если PO также не выполняет задачи)
Ответ на ваш заглавный вопрос: разработчики (команда) должны участвовать в планировании совещаний. Планирование встреч для разработчиков (команды).
Хорошим подходом является проведение двух совещаний по планированию в начале каждого спринта: совещание по планированию 1 и совещание по планированию 2. На совещании по планированию 1 владелец продукта отдает приоритет (а оценка размера - оценка размера не проводится на совещании по планированию) невыполненных работ продукта. команда и команда начинает обсуждать наиболее приоритетные истории пользователей. Для каждого обсуждаемого пользователя сюжетная команда должна иметь возможность собрать:
- Подробные требования (например, какие поля должна иметь форма ввода...)
- Ограничения (например, насколько быстрым должен быть функционал)
- Приемочные испытания (проверка результатов)
- Эскизы пользовательского интерфейса (например, как должен выглядеть поток пользовательского интерфейса)
- Критерии приемки (валидация от конечного пользователя - критерии приемки не должны быть реальным тестом. Это может быть что-то, связанное с "простотой использования" и т. Д.)
Для собрания по планированию должна быть временная граница 1. Количество пользовательских историй, которые вы смогли обсудить, может соответствовать количеству пользовательских историй, которые вы сможете завершить в предстоящем спринте. В конце совещания по планированию 1 команда должна принять на себя обязательство - сказать, сколько обсужденных пользовательских историй будет сделано в предстоящем спринте. Совещание по планированию спринта 2 предназначено только для команды, потому что команда дополнительно обсуждает истории пользователей и разбивает их на задачи.
Во время совещания по спринт-планированию команда должна выяснить, как она превратит выбранный продуктовый бэклог в функциональность продукта, подлежащего отправке. Если они не являются частью этого процесса, то они не смогут совершить.
Вообще, конечно, они должны. Очевидно, что это никогда не будет реально возможным в той степени, в которой разработчики хотели бы. Однако, если спринты обычно относятся к типу "Hair On Fire", где разработчики не получают никакого серьезного вклада вообще... тогда на самом НАКОНЕЦ должны быть регулярно запланированные спринты "снижения энтропии", где все задачи выбираются исключительно разработчики с целью очистки от дерьма.
Команда может быть вовлечена в процесс планирования без формального процесса или встречи. Процесс планирования действительно очень плавный. В начале, цель должна состоять в том, чтобы добраться до стартовых спринтов как можно скорее. Тратить слишком много времени на планирование, прежде чем первый спринт чувствует себя очень водопадом и является пустой тратой времени каждого. Я, как член команды, чувствовал бы облегчение от того, что не являюсь частью этого, за исключением того факта, что это указывает на дисфункциональный характер организации. Команда всегда должна свободно высказывать идеи на постоянной основе (поскольку именно тогда происходит реальное планирование). Но две вещи, которые вы упомянули, касаются меня больше всего.
Во-первых, команда должна быть единственной, кто определит, сколько предметов в отставке они могут сделать в этом спринте. Они, безусловно, будут участвовать в оценке усилий. Это большая проблема.
Во-вторых, команда не выглядит так, как будто у них есть доступ к владельцу продукта (возможно, здесь даже нет ни одного). Даже если команда до сих пор не участвовала в "планировании", конечно, если бы я разговаривал с владельцем продукта на совещании по планированию или имел доступ к ним в другое время, я бы со временем озвучил предложения.
Я не столько волнуюсь за мой вклад, сколько за мое понимание. Недавно я участвовал в проекте, в котором не знал о проекте до того, как планы были переданы мне, якобы, завершены. Кошмар начался, когда я обнаружил, что процесс не был полностью продуман и определения данных не были завершены. Мне пришлось пройти через весь процесс снова, чтобы получить ответы, которые мне требовались.
По крайней мере, некоторые разработчики должны быть там, чтобы работа могла быть должным образом оценена и конвейерна.
Но не все разработчики должны быть там. Все может быть там - это имеет больше смысла.
С другой стороны, разработчики должны понимать, что приоритеты бизнеса - это приоритеты, независимо от того, что, по их мнению, должно произойти дальше. Каждый должен работать вместе, чтобы это не сработало.