Следует ли разрешить разработчикам участвовать в процессах планирования отставания? [закрытый]
Недавно я беседовал с компанией, которая начала внедрять Scrum для своих циклов разработки. Я спросил одного из разработчиков, каков их опыт, и похоже, что они полностью отстранены от процесса планирования. Ему не разрешалось принимать участие в том, что входило в данный спринт, и он не участвовал ни в каких мероприятиях по планированию или уходу.
В общем, в начале последнего спринта (или двух) ему вручили список дел. Он должен был разложить предметы по полочкам в их соответствующие задачи (чтобы они могли быть обработаны в течение спринта), но не участвовал в каких-либо мероприятиях по планированию; я скептически отношусь к тому, что ему было позволено много вкладывать в то, сколько усилий может занять предмет-я подозреваю, что архитекторы решили это для команды.Это то, как Scrum должен быть обработан? Моя нынешняя команда полностью участвует во всех мероприятиях по планированию, постоянно добавляя наш вклад в то, как могут быть рассмотрены функции и сколько усилий они могут занять. Я немного скептичен (и нервничает) о компании, которая просто вручает разработчикам список дел, не спрашивая их мнения.
Примечание: Я понимаю, что как только начинается спринт, список действительно является приоритетным списком дел. Меня беспокоит отсутствие вклада в процесс планирования с самого начала.11 ответов:
Если те, кто делает работу,не могут дать ввод, говоря, какой объем работы может вписаться в спринт, и пусть бизнес решает, что наиболее важно и должно быть запланировано. Его не будет работать убежать. Они используют новые модные гибкие слова, но делают те же самые старые вещи.
Очевидно, что они все еще делают командование и управление и микроменеджмент (команда не наделена полномочиями и самоорганизуется), и они все еще используют push-планирование (они не включили pull-планирование).(...) Ему не разрешалось принимать участие в том, что входило в данный спринт, и он не участвовал ни в каких мероприятиях по планированию или уходу.
Scrum имеет и другие характеристики, но вышеперечисленных пунктов более чем достаточно, чтобы сказать, что они не делают Scrum, независимо от того, как они это называют, они действительно не перешли от устаревшего водопадного подхода (они просто нанесли немного помады на свинью).
Это большой намек на то, что они все еще совершенно не знают, что такое Scrum, они вообще не поняли этого. И это не изменится без некоторой проверки и адаптации, если они даже захотят измениться. Если у вас нет силы, чтобы сделать это, убегайте.
Я работал в компании, которая называла себя agile. У них было 6-8 месячных циклов выпуска. Некоторые вещи приходили из-за отставания, но на этапе "сбора требований" менеджеры обычно проводили неделю или две, встречаясь с различными людьми в компании, и составляли список функций. В первый день каждой 4-недельной "итерации" команда разработчиков собиралась вместе и разбивала все на серии совещаний. Последний день итерации был днем развертывания, где должен был быть развертывание intrim, которое никто за пределами команды разработчиков никогда не видел.
В течение 8-месячного цикла выпуска менеджеры будут контактировать с заинтересованными сторонами, Возможно, один или два раза за последние два месяца выпуска, и в этот момент единственными вопросами, поднятыми на этих совещаниях, которые имели шанс в аду быть решенными до выпуска, были вопросы, которые были достаточно плохими, чтобы сделать все усилия бесполезными, если они не были реализованы.
Это не гибко, это вариант на водопад с плохим выбором идей и методологий черри выбрал из других методологий. В конце концов, у него все те же проблемы, что и у водопада.
Урок, который я извлек из своей работы там, заключается в том, что методологии развития включают вещи не просто так. Если вы собираете вишню из методологии, не полностью понимая ее (а под полным пониманием я подразумеваю фактическую работу с ней), есть высокий шанс, что вы не будете использовать что-то, что на самом деле это жизненно важно для всего дела. Например, в xp Кент Бек выступает за то, чтобы позже прибегнуть к рефакторингу как к способу сократить объем переднего дизайна. Однако единственная причина, по которой это действительно работает, заключается в том, что он также выступает за TDD и парное программирование. Если у вас есть полный набор тестов и дополнительный набор глаз для всего этого, рефакторинг довольно безопасен. Если вы просто выберете первую часть и оставите эти две, вы, по сути, кодируете ковбоя.Я есть крайне скептически относятся к покупателям, которые сворачивают свои собственные методики именно по этой причине. Существует абсолютно шокирующее количество преступлений, совершаемых во имя agile.
Это то, как Scrum должен быть обработан?
Определенно нет. Scrum стремится повысить прозрачность. Блокируя разработчиков от планирования деятельности, они делают противоположное тому, что предлагает scrum.
Вы говорили о 2 пунктах здесь: 1. Планирование спринта-члены команды Scrum определенно должны быть необходимы здесь. 2. Уход за отставанием-может потребоваться, а может и не потребоваться. Вы должны использовать свои ресурсы мудро и со здравым смыслом. Один член команды с сильным фон разработчика был бы здесь в порядке, я думаю.
В Scrum есть еще один тип:
Планирование выпуска-Некоторые могут сказать, что разработчики здесь не нужны. Но согласно руководству Scrum - "планирование выпуска требует оценки и приоритизации отставания продукта для выпуска". Ну, определение приоритетов может быть сделано POs и предложено держателями акций, но оценка будет наиболее точной, если это будет сделано кем-то, кто действительно собирается делать работу, поэтому это хорошая идея, чтобы привлеките сюда разработчиков. Опять же, ресурсы должны использоваться разумно. Если есть смысл не привлекать всех разработчиков и заставлять людей по очереди оценивать, то это неплохая идея.
Предлагаю следовать этой структуре: Планирование спринта-часть 1: Оценка и удаление отставаний в спринте из отставания продукта (PO, SM и Team - свиньи здесь) Планирование спринта-часть 2: постановка задач, оценка часов выполнения задач и их разбивка. (См, и команда-свиньи, по-курица здесь, если только по не принимает задания как Ну)
Во время совещания по планированию спринта команда должна решить, как она превратит выбранное отставание по продукту в функциональность отгружаемого продукта. Если они не являются частью этого процесса, то они не смогут совершить.
Ответ на ваш главный вопрос: Разработчики (команда) должны участвовать в совещаниях по планированию. Совещания по планированию предназначены для разработчиков (команды).
Хороший подход состоит в том, чтобы в начале каждого спринта проводить два совещания по планированию: совещание по планированию 1 и совещание по планированию 2. На совещании по планированию 1 владелец продукта дает приоритетный (и оценочный размер - оценка размера не выполняется на совещании по планированию) список невыполненных работ по продукту команде, и команда начинает обсуждать наиболее приоритетного пользователя рассказы. Для каждого разобщенного пользователя команда story должна иметь возможность собрать:
- подробные требования (например, какие поля должна иметь форма ввода ...)
- ограничения (например, насколько быстра должна быть функциональность)
- приемо-сдаточные испытания (проверка результатов)
- эскизы пользовательского интерфейса (например, как должен выглядеть поток пользовательского интерфейса)
- критерии принятия (валидация от конечного пользователя-критерии принятия не обязательно должны быть реальным тестом. Это может быть что-то связанное с "простота в использовании" и т. д.)
Должна существовать временная граница для планирования совещания 1. Количество пользовательских историй, которые вы смогли обсудить, может соответствовать количеству пользовательских историй, которые вы сможете завершить в предстоящем спринте. В конце совещания по планированию 1 команда должна взять на себя обязательство - сказать, сколько из обсуждаемых пользовательских историй будет сделано в предстоящем спринте. Совещание по планированию спринта 2 предназначено только для команды, поскольку команда дополнительно обсуждает истории пользователей и разбивает их на задачи.
Вообще-то, конечно, должны. Очевидно, что это никогда не будет реально возможно в той степени, в какой разработчики хотели бы . Однако, если спринты, как правило," волосы в огне " типа дел, где разработчики не получают никакого серьезного вклада вообще... тогда, по крайней мере, должны быть регулярно планируемые спринты "снижения энтропии", где все задачи выбираются исключительно разработчиками с целью очистки дерьма.
По крайней мере, некоторые разработчики должны быть там, чтобы работа могла быть правильно оценена и распределена по конвейеру.
Но не все разработчики должны быть там. Все может быть есть это имеет больше смысла. С другой стороны, разработчики должны понимать, что бизнес-приоритеты-это приоритеты, независимо от того, что они думают, что должно произойти дальше. Все должны работать вместе, чтобы это сработало.
Меня беспокоит не столько мой вклад, сколько мое озарение. Недавно я был вовлечен в проект, где я не знал о проекте до того, как планы были переданы мне предположительно завершенными. Кошмар начался, когда я обнаружил, что процесс не был полностью продуман и определения данных не были полными. В итоге мне пришлось пройти весь процесс заново, чтобы получить ответы, которые мне требовались.
Команда может быть вовлечена в процесс планирования без формального процесса или совещания. Процесс планирования действительно очень подвижен. На старте, цель должна быть, чтобы добраться до стартовых спринтов как можно скорее. Тратить слишком много времени на планирование перед первым спринтом кажется очень рискованным и бесполезным занятием. Я, как член команды, почувствовал бы облегчение, если бы не был частью этого, за исключением того факта, что это указывает на дисфункциональный характер организации. Команда всегда должна быть свободна, чтобы озвучивайте идеи на постоянной основе (поскольку именно тогда происходит реальное планирование). Но две вещи, которые вы упомянули, волнуют меня больше всего.
Во-первых, команда должна быть единственной, чтобы определить, сколько элементов невыполненной работы они могут сделать этот спринт. Они, безусловно, будут участвовать в оценке усилий. Это большая проблема.
Во-вторых, команда не звучит так, как будто у них есть доступ к владельцу продукта (возможно, здесь нет даже одного). Даже если команда не участвовала в " планировании" до сих пор, конечно, если бы я разговаривал с владельцем продукта на совещании по планированию или имел доступ к ним в другое время, я бы озвучил предложения со временем.