Задержка задач «размера прикуса» параллельно с невыполненной «основной» функцией?

После более чем двух лет работы в структуре отдела разработки «одинокий волк» мы внедряем Agile SCRUM. Отлично. Мне нравится Agile; будучи разработчиком, вы будете сосредоточены, заняты и продуктивны, без того, чтобы множество заинтересованных сторон толкали проект за проектом в горло, ожидая, что все это будет сделано вчера.

Однако есть один аспект перехода к SCRUM по сравнению с нашей нынешней «моделью», который, я думаю, людям за пределами развития не понравится ни в малейшей степени. Это их нынешняя способность заставлять нас делать небольшие изменения «пока вы ждете». Большая часть нашей разработки предназначена только для внутреннего потребления, и мы в основном все в одном здании. Таким образом, в течение многих лет руководителем отдела или менеджером в другом месте была обычная практика приходить к «владельцу кодовой базы» конкретного приложения и просить мелкие вещи (иногда не такие маленькие, но мы довольно хорошо не отказываемся от трех- недельные проекты на основе этих "проездов"). Даже наш босс иногда передает вещи, доведенные до него таким образом. Очень часто, если мы работаем в рассматриваемой кодовой базе в то время, мы можем просто открыть исходный файл,

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

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

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

Это вызвало реакцию у тех из нас, кто занимался с ScrumMaster обучением «э-э-э». Есть одно отставание. В двух журналах ставится вопрос о том, какой элемент № 1 действительно является самым важным, какие элементы списка определяют реальные скорость, и к какому из двух резервов фактически принадлежит статья (любое разграничение размера / сложности будет иметь некоторые случаи, которые падают относительно произвольно в ту или иную сторону). «Пусть процесс работает», - сказали мы; если изменения действительно важны для конечных пользователей, они сделают достаточно шума, чтобы заставить руководителей департаментов принимать решения о времени / деньгах на борту, и это будет врезано в сознание команды разработчиков к вершине отставания.

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

Я расскажу о нескольких моментах, которые, надеюсь, помогут вам найти свой путь:

1. « SCRUM » означает быть проворным. Требуется здравый смысл. Если изменение составляет несколько минут, я не думаю, что вам нужно отставание для этого. Если это более 2 часов, я думаю, вы должны подумать об этом. Не все, что является "легкой победой", должно быть сделано. В SCRUM вы работаете по приоритетам. Я думаю, что ПО должно получить информацию о том, что вы получаете от дополнения, и об усилиях, которые оно требует. Только тогда ПО может решить, важно это или нет. Переходя на SCRUM, иногда возникает множество вопросов, и разработчики часто говорят: «Но это займет всего несколько часов». Ну и что? Несколько часов - это время, не все, что не хватает, должно быть включено.
2. Однажды я работал над проектом, в котором у нас было «инженерное отставание» . Это отставание содержало пункты, предложенные разработчиками для улучшения продукта. Эти элементы не имели явного пользовательского значения (но имели неявное пользовательское значение). Например: рефакторинг компонента в коде. Мы описали изменение, усилия и выгоды (в этом случае вы ничего не можете представить пользователю. Но если такой рефакторинг приводит к более быстрой разработке новых возможностей, то это определенно выигрыш для пользователя). Наше ПО решило, что во время версии мы должны вкладывать 10% каждого спринта (в среднем) в такие предметы. Перед каждым спринтом, когда ПО принимало решение о резерве предстоящего спринта, он следил за тем, чтобы у нас было 10% элементов журнала инженерных заданий. Итак, 2 варианта отставания -> 1 спринт.
3. Буферы. Когда люди начинают работать в SCRUM, они часто забывают, что, как разработчики программного обеспечения, мы уходим в мир неопределенности. Это нормально, если считать 1 день работы 6 часов вместо 8. Допустим, у вас есть 15-дневный спринт, что означает, что у вас есть дополнительные 30 часов, которые идут на встречи, на то, что заняло слишком много времени, и да - и для тех маленьких вещи, которые слишком малы, чтобы помнить, но являются частью нашей повседневной работы.
4. Оставайтесь сосредоточенными - И последнее, но не менее важное, в SCRUM важно оставаться сосредоточенным. Решите, сколько ваших общих усилий и каков приоритет, чтобы инвестировать в такие задачи, и не забудьте инвестировать это время и усилия. Не стоит заниматься "мелочами" только потому, что они маленькие. У вас есть ПО, которое поможет вам принять решение, и у вас есть здравый смысл.
5. Будьте гибки - и, в конце концов, не забудьте попробовать разные методы решения проблемы, спросите себя, действительно ли это лучший способ. Улучшение на пути.

Удачи :)

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

В моем последнем проекте мы заметили, что разработчикам нужно немного времени каждый день, чтобы освежить или очистить свои головы и т. Д. Им было выделено бюджетное время (0,5 часа / день или 2,5 часа / неделя), в течение которого они могли делать все что угодно в пределах причина (с возможностью применения к чему-то на работе). Чтобы сохранить дисциплину, их попросили документировать свою деятельность, чтобы они могли получить кредит за любые достижения и т. Д. Наличие определенного бюджета на «баночку конфет» укладывалось в наши сроки и не давало вещам выйти из-под контроля.

Кстати, мы назвали нашу «прохлада проекта», и она оказалась источником многих хороших идей и улучшений в этой компании.

Вы должны держать маленькие истории в основном отставании.

Я сталкиваюсь с проблемами, подобными тому, что вы описываете, хотя я не использую scrum. Я вижу, что вы сталкиваетесь с проблемами приоритизации и эффективности .

По вашему старому стилю, любой неявно уполномочен сделать свою задачу текущим «главным приоритетом», если он посетит офис разработчика. Это имеет некоторые преимущества. Запрашивающая сторона чувствует, что им отвечают, и и запрашивающая сторона, и разработчик получают «быстрый выигрыш».

Недостатком является то, что частая вставка этих задач приводит к замедлению или срыву приоритетных задач, которые были согласованы с владельцем продукта. (Примечание: часто все недооценивают время, необходимое для этих «быстрых» исправлений.)

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

Часто, когда я прошу заинтересованные стороны расставить приоритеты, меня спрашивают: «Можете ли вы просто втиснуть это?». Подразумеваемое желание состоит в том, чтобы я волшебным образом выполнил новое задание, не влияя на текущий высший приоритет.

Что часто случается со мной, так это то, что заинтересованные стороны запрашивают LargeImportantProject и SmallLessImportantTask. Дилемма заключается в том, должен ли SmallLessImportantTask ждать завершения LargeImportantProject (или иметь контрольно-пропускной пункт)? Есть компромиссы, и мой опыт показывает, что владелец продукта должен решить. (Если владелец продукта не принимает решение, команда разработчиков должна догадаться.)

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

Эффективность может быть страшной, но я видел преимущества, перевешивающие стоимость двумя важными способами.

1. По мере того, как вы становитесь более эффективными, вы расширяете возможности своей команды для выполнения ценной работы, которая включает в себя запросы «приятно иметь».
2. Если запрос действительно «приятен», вероятно, вполне законно, чтобы запрос ожидал решения более важных бизнес-приоритетов.

По моему мнению; Ваша проблема в том, как задачи приоритетны в отставании. Например, «приоритет» может учитывать как важность, так и то, как быстро он может быть выполнен. То, что не так важно, но может быть выполнено за 10 минут, может иметь более высокий приоритет, чем что-то более важное, что займет несколько недель.

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

Как сказал Ави выше - «SCRUM» означает быть проворным. Требуется здравый смысл. Если изменение составляет несколько минут, я не думаю, что вам нужно отставание для этого.

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

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

• Постоянно меняющиеся требования
• Невозможность для разработчиков сосредоточиться на других областях приложения, т.е. мы герои в одной части приложения, но не стремимся коснуться любой другой.
• Различные подходы к архитектуре, решениям, внедряемым фреймворкам
• Процесс сбора требований, похоже, не работает

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

- Постоянно меняющиеся требования

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

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

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

- Различные подходы к архитектуре, решениям, принятым структурам

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

- Процесс сбора требований

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

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

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

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