Как вы управляете работой, не связанной с пользователем, в строгом scrum-магазине? [закрытый]

Мы-машиностроительный цех среднего размера (10-20). Мы отлично умеем расставлять приоритеты и структурировать работу над историями, с которыми сталкиваются наши пользователи,и делать их счастливыми. Но у детей сапожника нет обуви. Если речь не идет о клиентах, у нас есть 0 процесс.

Я ищу системы, которые гарантируют, что мы правильно расставляем приоритеты и выполняем работу, не связанную с пользователем, чтобы поддерживать работу магазина разработчиков: среды QA (довольно тяжелые, в нашем случае), системы непрерывной интеграции, упаковка и т. д.

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

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

(я знаю о красном ящике наверху этот текст указывает на то, что автоматический парсер вопросов Stack Overflow считает, что это субъективный вопрос, на который нельзя ответить - Я думаю, что есть, вероятно, 2 или 3 отличных ответа, которые могут быть или были доказаны жизнеспособными, - и процесс является неотъемлемой частью программирования. Итак, вот некоторый psuedocode, представляющий наш процесс. Исправьте этот алгоритм).

IBacklog GetBacklogForWork(IWork requestedWork)
{
    if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
    // Everything else. Priority largely based on spare time and who thinks its a neat idea
    return new RandomizedPriorityRepository();
}

void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
    foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
4 2
language-agnostic continuous-integration scrum

4 ответа:

Кто-то задействовано использование и в зависимости от результатов проекта. Это обязательно верно; если бы это не было правдой, зачем бы вы это делали?

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

5

IMO что-то вроде "QA environments" - это, в некотором смысле, работа с пользователем.

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

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

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

1

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

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

Альтернатива подачи его как инвестиции с таким-то и таким-то ROI в PO-теоретически сексуальная концепция, но с реальной жизнью POs я видел, что она редко работает. Его очень трудно заставить POs понять инвестиции, не говоря уже о том, чтобы быть достаточно сильным, чтобы отложить функциональность для него.

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

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

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

0