Как вы справляетесь с затратами на слишком быстрые изменения?

Как и большинство современных разработчиков, я ценю принципы Agile, такие как взаимодействие с клиентами и реагирование на изменения, но что происходит, когда владелец продукта (или тот, кто определяет требования и приоритеты) слишком часто меняет требования и приоритеты? Как несколько раз в день?

Недавно я унаследовал небольшую кодовую базу, которая была глючной, неполной и даже не могла справиться с самым простым сценарием, который должен был быть. Я могу справиться с техническими проблемами, но я получаю несколько электронных писем, текстовых сообщений или телефонных звонков в день, говоря: «О Боже, ты ДОЛЖЕН работать над этим ПРЯМО СЕЙЧАС! НАИЛУЧШИЙ ПРИОРИТЕТ! Это ДОЛЖНО !!!» (это только небольшое преувеличение) Еще хуже то, что большинство вещей - это мелкие детали, которые даже не имеют отношения к тому, что на самом деле должно делать программное обеспечение, и в любом случае на их реализацию потребуется несколько дней. Я пытался объяснить, что времени так много, и что сначала нам следует сосредоточиться на самых важных вещах, но что-то теряется в переводе, потому что то же самое происходит через день или два спустя.

Есть ли какая-то роль «продукт-владелец-обработчик», углубленное изучение, метафора или цитата, которые могут помочь мне уменьшить количество затраченных усилий или хотя бы объяснить стоимость этого хаотического поведения?

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

Вот как я справился с подобной проблемой ... В те времена, когда мы были гибкими до Agile.

Для любого запроса на изменение клиент устанавливает приоритет. Разработчик может и должен только прекратить работу над задачей, чтобы работать над задачей с более высоким приоритетом. Задачами с равным приоритетом являются графики в порядке прибытия. (Приоритет задачи не может быть изменен после начала работы.)

Будет больно, когда вы говорите клиенту, что не можете работать над его задачей, потому что вы работаете над неважной задачей X, которая имеет тот же приоритет, что и его последний запрос. Затем вы говорите ему, что на этом уровне приоритета перед его последней просьбой стоят 50 простых и несущественных задач. Теперь реальный подвох - все эти задачи находятся на уровне приоритета 1 (самый высокий), установленном ... HIM ... Так что он не может оторвать вас от задачи, которую вы выполняете. Теперь, когда вы закончили перемещать оконную раму на 3 пикселя влево, чтобы освободить место для более длинного слова в исландском переводе в редко используемой опции конфигурации .....

Я также закрыл дверь в офис SD, запер ее и снял телефоны с крючка. Письма игнорировались до 10:00, 12:00 и 14:00. Несмотря на то, что люди думали и чувствовали, мир все еще вращался вокруг солнца, мы выполнили свою работу, и «Клиенты» получили программное обеспечение, которое им доставили быстрее и лучше, чем когда-либо в прошлом.

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

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

Некоторые примеры того, что ваша SOP должна определить.

• Какие процедуры должны соблюдаться, когда клиент или внутренняя организация запрашивает изменение
• Каковы последствия и / или влияние на контроль качества или проверку этого продукта?
• Каков метод для разумного определения сроков доставки? Это итерация? Следующая версия?

Без таких процедур все будут бегать на вас, как будто их преследуют зомби, и ожидайте всего СЕЙЧАС СЕЙЧАС СЕЙЧАС. Такие люди не будут уважать ваше вежливое «нет» или «пожалуйста, подождите. С твердой политикой, эти мутанты, жаждущие кода, поймут, что они не правы, когда просят вещи на такой свободной основе.

Конечный результат вас не устраивает, и это не в ваших интересах.

Кстати, вы, возможно, унаследовали чей-то беспорядок, вызванный таким вопиющим неуважением к его / ее положению и обязанностям. Людям в такой ситуации трудно производить качественный продукт. Стоит ли удивляться? Разработка программного обеспечения 101.

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

В подобных ситуациях я счел ценным подождать как минимум час, прежде чем отвечать на электронные письма. (Я бы проигнорировал тексты, если только текстовые сообщения не заменили электронную почту вашей организацией в целом.) Возможно, прочитайте их, но не отвечайте. Таким образом, вы можете сосредоточиться на реальной работе, а не на обсуждении случайных срочностей, которые могут стать неактуальными завтра, или даже двух или трех электронных писем позже. На моей последней работе, если что-то было ДЕЙСТВИТЕЛЬНО срочным, кто-то приходил и говорил со мной лично, предполагая, что я еще не видел электронные письма (если вы работаете удаленно, телефонный звонок с реальным двусторонним разговором может быть эквивалент).

Когда вы разговариваете лицом к лицу или разговариваете по телефону, полезно повторить то, о чем человек просит, своими словами, а затем задать свои вопросы о новых требованиях и приоритетах. «Если я правильно понимаю, вы говорите, что мы должны прекратить работу над Текущим Приоритетом X и теперь сосредоточиться на Приоритете Минута Y. Это большой сдвиг. Можете ли вы объяснить изменения в бизнесе? Мне может понадобиться больше информации работа, а не просто изменение пользовательского интерфейса. Будут ли изменения в других бизнес-процессах, таких как выставление счетов или инвентаризация (например)? Вы ожидаете, что эти новые элементы данных появятся во всех ежемесячных отчетах? " Также полезно сказать что-то вроде: «Вы понимаете, что если мы продолжим эту новую работу, это задержит выпуск Текущего Высшего приоритета X как минимум на (неделю, месяц,

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

Если изменения будут сочтены необходимыми, я посчитал полезным записать то, что было запрошено, и ваше понимание изменений в электронном письме, и отправить его первоначальному заявителю, спрашивая, согласны ли они с объемом изменений, опять же как уточнение. Таким образом, вы написали документацию о том, что необходимо сделать и почему это было запрошено, в случае, если есть какой-то ответ, почему вы больше не работаете над Current Top Priority X, или вам нужно объяснить, почему первоначальные сроки не соблюдаются быть встреченным

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

Похоже, никто еще не упомянул об этом, Sprint и его истории пользователей ideally should be locked till the next sprint(типичный спринт занимает 2-4 недели). Блокируя - я имею в виду, что никакие дополнительные задачи не должны быть добавлены в уже запущенный Sprint.

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

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

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

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

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

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

Agile Manifesto говорит, что один из самых фундаментальных принципов:

Добро пожаловать в меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для обеспечения конкурентных преимуществ клиента.

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

Опять же, хотя рабочий процесс продаж продукта может меняться каждую неделю, я думаю, что общий продукт не будет меняться каждую неделю. Я не могу представить себе Microsoft, которая сегодня дает нам Office, но завтра она даст нам Offooose, а через неделю Offasooooooooooos.

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

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