Должны ли разработчики участвовать в процессах планирования отставания?

Question

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

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

Это как Scrum следует обрабатывать? Моя нынешняя команда полностью участвует во всех мероприятиях по планированию, постоянно добавляя наш вклад в отношении того, как могут быть решены функции и сколько усилий они могут предпринять. Я немного скептически настроен (и нервничаю) о компании, которая просто передает разработчикам список дел, не спрашивая их вход.

Примечание: Я понимаю, что как только начинается Sprint, список действительно является приоритетным списком дел. Моя забота заключается не в том, чтобы вносить вклад в процесс планирования с самого начала.

Answer 1

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

Answer 2

Это как Scrum следует обрабатывать?

No.

Answer 3

По крайней мере, некоторые разработчики должны быть там, чтобы работа может быть должным образом оценена и конвейерный.

Но не все разработчики должны быть там. Все может быть, это имеет смысл.

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

Answer 4

Вообще-то, конечно, они должны. Очевидно, что никогда не бывает реалистично, насколько разработчики будут , как. Тем не менее, если спринты обычно относятся к типам «Пожиратель», где разработчики вообще не получают серьезных знаний ... тогда на самом МЕНЬШЕ должны быть запланированы регулярные спринты с энтропийным сокращением, где все задачи выбираются исключительно разработчики с целью очистки дерьма вверх.

Answer 5

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

Answer 6

Я работал в месте, которое называло себя проворным. У них было 6-8 месяцев цикла выпуска. Некоторые вещи произошли из отставания, но на этапе «Сбор требований» в основном менеджеры проводили неделю или две встречи с разными людьми в компании и записывали список функций. В первый день каждой 4-недельной «итерации» команда разработчиков собиралась вместе и разбивала все на серии встреч. В последний день итерации был день развертывания, где было бы развертывание intrim, которое никто из разработчиков Dev никогда не видел.

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

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

Урок, который я извлек из своей работы, заключается в том, что методологии разработки включают в себя вещи по определенной причине. Если вы выбираете вишню из методологии, не понимая ее полностью (и, полностью понимая, я имею в виду, что на самом деле с ней работали), есть большая вероятность, что вы не будете использовать то, что действительно жизненно важно для всего. Например, в xp, kent beck сторонники полагаются на рефакторинг позже, как способ сократить передний дизайн. Однако единственная причина, по которой это действительно работает, - это то, что он также защищает TDD и парное программирование. Если у вас есть комплексный набор тестов и дополнительный набор глаз для всего, рефакторинг достаточно безопасен. Если вы просто вишневы выбираете первую часть и оставляете эти две, вы, по сути, кодируете ковбой.

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

Answer 7

Это как Scrum следует обрабатывать?

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

Вы говорили о 2 пунктах здесь: 1. Планирование спринта - члены команды Scrum должны быть здесь обязательно необходимы. 2. Backlog Grooming - Возможно, здесь не требуется. Вы должны использовать свои ресурсы с умом и здравым смыслом. Думаю, один член команды с сильным опытом разработчиков будет в порядке.

Существует еще один тип в Scrum:

Планирование выпуска - Кто-то может сказать, здесь не нужны разработчики. Но в соответствии с руководством Scrum Guide - «Планирование релиза требует оценки и определения приоритетности выпуска продукта для выпуска». Упорядочение приоритетов может быть сделано PO и предложено держателями котировок, но оценка будет наиболее точной, если это сделает кто-то, кто действительно собирается выполнять эту работу, поэтому здесь неплохо привлекать разработчиков. Опять же, ресурсы следует использовать разумно. Если имеет смысл не привлекать всех разработчиков и заставить людей вращать повороты, чтобы оценить, это не плохая идея.

я предлагаю следовать этой структуры: Спринт планирования - Часть 1: Оценка и потянув отставания в Sprint от накопившихся продуктов (ПО, СМ и команда свиньи здесь) Спринт Планирование - часть 2: Tasking, оценивающие часов задачи и ломать их вниз. (SM, и Team - свиньи, PO - это цыпленок, если PO также не принимает на себя задачи)

Answer 8

(...) Ему не разрешалось вводить какие-либо данные о том, что попало в данный Sprint, t участвовать в любых мероприятиях по планированию или уходу.

Очевидно, что они по-прежнему делают командование и управление и микро-менеджмент (команда не имеет права и самоорганизация), и они по-прежнему используют нажим на основе планирования (они Ждут» t enable pull-scheduling).

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

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

Answer 9

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

Answer 10

Ответ на ваш вопрос: Разработчики (команда) должны участвовать в совещаниях по планированию. Планирование встреч для разработчиков (команды).

Хороший подход состоит в проведении двух совещаний по планированию в начале каждого спринта: Планирование совещания 1 и совещания по планированию 2. На совещании по планированию 1 Владелец продукта уделяет приоритетное внимание (и оценка размера оцениваемого размера не выполняется на совещании по планированию) backlog для команды, и команда начинает обсуждать наиболее приоритетные истории пользователей. Для каждой Аре истории команда пользователя должна иметь возможность собирать:

• Подробных требования (например, какие поля формы входа должна иметь ...)
• Constraints (например, как быстро функциональность должна быть)
• Приемочные испытания (проверки результатов)
• эскизы пользовательского интерфейса (например, как следует поток UI выглядит)
• критерии приемки (проверки со стороны конечных пользователей - критерии приемлемости не должен быть настоящим испытанием может быть. что-то связанное с «простым в использовании» и т. д.)

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

Answer 11

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

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

Во-вторых, команда не звучит так, как будто у них есть доступ к владельцу продукта (возможно, там даже не один). Даже если команда пока не участвует в «планировании», конечно, если бы я разговаривал с владельцем продукта на совещании по планированию или имел доступ к ним в другое время, я бы со временем высказывал предложения.