Комментарии 7
4. Если что-то забыли, вносим в список на следующий поход, но не берём сейчас.
Не очень удачный пример в случае магазина. В реальности если вспомнил, что забыл внести в список - просто покупаешь и всё.
Согласен, в случае покупок может такое произойти. Для этого мы оставляем немного свободы в нашем списке. Тем самым закрываем возникшую потребность. Но лучше избегать таких ситуаций и планировать заранее.
На самом деле в случае с магазином я лично использую совершенно иную стратегию. Я имею список неких базовых продуктов, которые покупаю всегда - а вот всё остальное покупаю спонтанно. Точнее, не совсем спонтанно, а по обстоятельствам, ситуативно - в зависимости от того, понравился мне продукт или нет. Т.е. я вижу мясо или рыбу, и если их внешний вид внушает мне доверие, и если я готов в ближайшие дни ужинать данным продуктом - я его покупаю. Даже если его не было в списке. То же самое с фруктами и овощами - покупаю, если они внушают доверие. Таким образом иногда я покупаю чисто базовый набор (хлеб, молоко, сметана, сыр и т.д.), а иногда в пакете с покупками оказываются котлеты, ветчина, осьминог, креветки и кусок баранины. А иногда вместо или вместе с этими продуктами есть и фрукты - если они подходящего качества.
Другими словами, я никогда не знаю, что я принесу из магазина точно. Это всегда результат множества критериев и условий, а также в некоторой степени случайность.
Более того, сегодня и разработка ПО часто происходит именно таким образом. Иногда просто невозможно запланировать и выполнить всё запланированное. Так, например, после выхода новой версии Chromium у нас возникает некоторое количество регрессий - от единиц до десятков, на исправление которых приходится тратить время и ресурсы. Более того, иногда разработчики Chromium что-то кардинально меняют в своих функциях, из-за чего нам приходится спешно заниматься реализацией собственного аналога. Или наоборот - урезанием функционала своих разработок. И, само собой, никто нас заранее не предупреждает об изменениях, приходится на ходу подстраиваться под изменяющиеся условия.
Т.е. разработка также во многом становится ситуативной, но при этом ещё и нужно следовать собственным планам. В результате что-то меняется, что-то откладывается, что-то выходит вне очереди и т.д. Возможно, развивая собственный, абсолютно независимый код, можно следовать неким собственным же правилам, но в реальности это редкий случай, как мне кажется.
У ввс в принципе с планированием странновато, если предметы гигиены идут в шуд, а не в маст. Это не столько, чтобы докопаться, сколько отсылка к тому, что якобы наглядный пример как бы для <s>дурачков</s> 101 должен быть действительно наглядным, причем методологически это важнее, чем технически.
С одной стороны, мне неудобно устраивать бесцеремонную критику статьи прямо в первых комментариях, но, @moneta_team , я не согласен. Пример с походом в магазин - это антипример работы с беклогом, работы в инкрементально-итеративном подходе.
Беклог - отсортированный список полезных вещей, которые нужно сделать. Каждый элемент беклога а) имеет ценность сам по себе б) достаточно маленького размера, чтобы успеть сделать за итерацию и в) состоит из одной фичи, а не набора; это сделано для концентрации команды и возможности "поставлять на прод чаще".
Беклог сортируется не обязательно по принципу Must Have сверху. Сверху - "имеющее наибольшую ценность для клиента сейчас" по мнению Владельца продукта.
Так вот, вылазка в магазин - это ОДИН элемент беклога. А список продуктов - результат планирования спринта, когда вы сформулировали сабтаски. Набор покупок (сабтасков) можно определить перед началом спринта, взяв в задачу только важные вещи, которые успеем купить (хватит денег, сумеем вывезти, ...), а другие хотелки выделить в новый элемент беклога (поход в магазин).
Так что беклог на бытовом примере выглядит так:
Купить важные продукты (и внутри список от Must Have до Should Have, например)
Купить стол и кресло
Купить сладости и вкусности (и внутри список Could Have, например)
Починить тормоза у машины
Оплата ЖКУ
Допэлектрика у машины (парктроник, камера)
Вы рассматриваете лимит только на один ресурс - деньги, и "берете в работу" только те покупки, на которые хватит бюджета. Отлично, а как же время? Производительность команды? Ограничения по компетенциям команды? Если спринт у вас сегодня кончается в 13:00 и цель спринта - пообедать хоть чем-то?
Элементы 1, 2, 3 выполняются в одном магазине и есть соблазн их затащить в одну работу. Но идея беклога и инкрементально-итеративного подхода в том, что если вы сольёте в одну покупку и жизненно-важные крупы, и сладости, и мебель - у вас может не хватить ресурсов и лучше делать эти три нужные вещи поодиночке, хотя в сумме выйдет больше времени и денег.
Есть ведь ограничения:
денег. Ну тут все понятно, вы их сразу увидите. Предположим даже, что денег много;
времени на выполнение: дорога туда-обратно, хождение по магазину, оплата, упаковка, поднять домой, сварить макароны;
места в машине: может быть, вместятся (пакеты с макаронами И пакеты со сладостями) ИЛИ (вместится мебель) и потребуется две поездки - это производительность;
компетенций (сил носить): приехав домой, обнаружите, что стол в одиночку донести на этаж не сможете, а уйти с пакетами варить макароны и оставить стол привязанным к багажнику (незавершенное производство) нельзя: украдут.
И вы не сделаете обед к 13:00, как планировали. Перепрыгните большую пропасть, но на 75%
Готов обсудить
Действительно, факторы, о которых вы пишите, не были учтены — они безусловно сыграют свою роль в реальном формировании бэклога. В наших примерах описан вакуум, в нём нет лишних триггеров, которые повлияют на конечный результат . Пример должен быть простым и понятным. Цель статьи — дать общее понимание людям, которые не знают, что такое бэклог, и помочь базово разобраться в вопросе. Такое объяснение можно использовать для ответа своим коллегам из вертикали продаж, чтобы аргументировать сроки реализации фичи, или при обучении джунов.
Публикации
Что такое бэклог: простое объяснение на примере списка покупок