×Закрыть

Четыре продакт оунера бэклог приоритизировали-приоритизировали...

... да так и не выприоритизировали. А все потому, что приоритизация — задача вовсе не такая уж простая, как многим на первый взгляд кажется. Зачем она вообще нужна, кто ее делает, и как можно существенно облегчить себе жизнь — об этом и многом другом в журнале «А хрен его знает!» этом посте. Проходите внутрь, пожалуйста, устраивайтесь поудобнее. Даже кто к agile не особо тяготеет — все равно интересный вопрос.


Приорите́т (лат. prior — первый, старший) — понятие, показывающее важность, первенство. Например, приоритет действий определяет порядок их выполнения.

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

Тут, конечно, надо вспомнить, что в проектном, «классическом» подходе это все не так уж и важно. Собрали требования, написали спецификацию, хоть по порядку разрабатывайте, хоть по алфавиту, хоть по зодиаку — как все сделаете, так и будем тестировать и внедрять. Ну постройте там себе диаграмму Гантта, поставьте end-to-begin связи — вот и отлично все будет.

А ну как требования поменяются? Или, не дай бог, вообще цель проекта?
Тут классический проджект-менеджмент разводит руками — другая цель, другие требования, все поменялось, сейчас вот заново все соберем, запланируем, будет новый срок, новые вехи, к нам какие претензии, когда так все меняется?

— Он не хотел брать на себя. Он как чувствовал. А они ему все время: «Бери на себя... бери на себя». Он взял на себя. Теперь он здесь, а они в стороне.
М. М. Жванецкий

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

Вместо спецификации с диаграммой Гантта у нас теперь беклог.

Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано.

Почему так? Потому что agile «заточен» под изменения, значит изменение ожидается. Значит, когда оно придет — мы будем готовы. Что нам хочется при изменениях? Хочется, чтобы мы не потеряли много времени и работы, а как можно скорее начали полноценное движение к новой цели.

Для этого мы делаем две вещи. Во-первых, не держим слишком много задач «открытыми». До тех пор, пока задача не закончена — мы не получим от нее никакой бизнес-ценности, зато при изменении курса все «начатые и еще не законченые» задачи как бы исчезают, все усилия, которые мы на них потратили — ушли впустую. Чем больше задач «in progress» и чем больше их среднее время нахождения в этом состоянии — тем сильнее потери от изменений. От этого возникает важный принцип — концентрироваться на как можно меньшем количестве самых важных задач, стараясь закончить их как можно быстрее.

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

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

Есть два конкурирующих подхода к приоритизации. При одинаковой цели — отразить важность задач для концентрации на важнейшей из них, реализация бывает воплощена в двух разных механизмах. В одном случае приоритет моделируется как некоторое свойство задачи и имеет какое-то значение. Во втором случае, приоритет представляет собой отношение между двумя задачами, подобное рычажным весам: можно сказать, который из двух тяжелее, но нельзя определить собственно вес.

Итак, в одном случае (приоритет-значение) мы говорим, что приоритет — это такое свойство у задачи и мы пытаемся его определить. Выразим его в значениях какой-то шкалы и получим возможность упорядочить все задачи по приоритету. Это может быть, например, число от одного до десяти. Или количество «звездочек важности» в трекере. Или значения шкалы типа «неважно, так себе, умеренно важно, важно, очень важно, вообще очень супермегаважно», что, как вы понимаете, ничем от чисел не отличается по сути.

Во втором случае (приоритет-отношение) про одну конкретную задачу мы ничего сказать не можем. Ну, задача и задача. Насколько она важна? Ну, черт ее знает, надо на остальные смотреть. Может очень важная, прям самая важная сейчас, а может и не очень. Вы мне другую задачу дайте — и я тогда точно скажу, какая важнее.

Я сейчас собираюсь показать, что второй подход — крайне правильный, а первый — полное убожество.

Проблемы первого подхода достаточно очевидны. Во-первых, возникает проблема одинаковых значений. Пусть приоритет выражается числом от 1 до 5. И у нас есть сто задач. Как много задач получат «высший» приоритет? Ну, наверное, выходит так, что не одна. Следовательно, в такой системе нет ответа на вопрос «какая ОДНА задача сейчас самая важная». То есть, вообще говоря, имея число от 1 до 5 можно сделать беклог только длиной в пять задач — дальше начнутся неоднозначности с приоритетом.

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

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

Раз это так легко и правильно, почему так все не делают?

Я вижу тому несколько причин. Во-первых — нужда в концентрации. Если нет необходимости концентрироваться на самой важной задаче — нет такого ажиотажа вокруг приоритетов, это ни на что особо не влияет. Во-вторых, как бы это ни было смешно, большинство инструментов поддержки процесса (трекеров) этого не позволяют, даже многие «заточенные под agile». На самом деле, каждый программист подтвердит — с точки зрения разработки приоритет-значение реализовать куда легче, чем приоритет-отношение.

Кроме того, их же легко перепутать. Например, когда вы слышите «это нужно сделать срочно, эта задача имеет топ-приоритет!» — это же можно воспринять по-разному. Возможно, человек отдает себе отчет и имеет в виду, что это означает — новая задача самая важная, она выигрывает в сравнении со всеми остальными задачами«. А может быть он сразу после этого говорит «и вот эта тоже — топ!». Эмм... тоже?

Сморите, какой фокус. «Вот десять задач, их нужно сделать». Ок, хорошо, понятно, в каком порядке? Какая самая важная? «О, они все очень важные!». Ну да. Это то же самое, что сказать «они все абсолютно неважные» — никакой разницы не будет. «Важная» в данном случае используется как средство мотивации коллектива, а вовсе не как приоритизация беклога.

Я лично очень люблю фразу «это важно», потому что она... ничего не значит. Я отвечаю так, когда нечего ответить, а нужно как-то продолжить разговор. Внушительно звучит и не имеет никакого смысла, очень удобно в некоторых ситуациях, рекомендую. Потому что важность — отношение, а не значение. «Это важно» — не имеет смысла. «Это важнее, чем...» — имеет смысл.

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

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

И да, если вы не понимаете, почему важно концентрировать усилия на малом количестве самых важных задач, и не делаете этого — вам, в целом, все равно, как приоритизировать, не парьтесь.

В общем — хорошей вам приоритизации, это важно! :)

P.S. Вот вам легендарное смешное видео, от которого делается грустно в контексте статьи.

LinkedIn

40 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

«приоритизации» —> приоритезации --- это тоже важно...

оказывается, правильно — приоритизация.

киньте ссылку, будьте добры. А то вроде Гугл не согласен

Да согласен, согласен.
«приоритизация» = Результатов: примерно 75 900

«приоритезация» = Результатов: примерно 45 700

пара ссылок
www.gramota.ru/.../spravka/87378

korrektor-ru.livejournal.com/211475.html

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

Оба подхода приоритезации можно совмещать: во-первых установкой дискретного приоритета {1,5} всем задачам, а вторым шагом — сортировкой внутри одного значения приоритета. Главное — постоянно пересматривать и менять дискретный приоритет (переоценка ценности результата задачи) и позицию задачи в беклоге.

Для себя из статьи подчерпнул важный посыл: держать как можно меньше задач открытыми.

К сожалению пока так не получается. В наш беклог задачи ложаться незаконченными / недоделанными.

а не приоритИзации случайно?

Отличная колонка, четко перекликается что у нас в проекте происходит.

Фазу «важность задачи определяется только в сравнении» мы уже прошли, спасибо PivotalTracker. Теперь оттачиваем дисциплину разработки — не хвататься за все задачи спринта, а делать их последовательно. Для меня, как product owner’a это важно т.к. позволяет быстро менять приоритеты и «тусовать» задачи беклога с минимальными потерями в производительности.

Тут, конечно, надо вспомнить, что в проектном, «классическом» подходе это все не так уж и важно. Собрали требования, написали спецификацию, хоть по порядку разрабатывайте, хоть по алфавиту, хоть по зодиаку — как все сделаете, так и будем тестировать и внедрять. Ну постройте там себе диаграмму Гантта, поставьте end-to-begin связи — вот и отлично все будет.

Ага, ну да, конечно. Давайте сначала синтегрирум 2 компонента а потом их напишем. Вот почему когда читаеш апологетов Аджайл складывается ощущение что до них и разработки то по сути не было?

В комментариях нигде не прозвучало слово «объём» задачи.

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

При этом растёт энергопотребление и садятся батарейки (кредит заканчивается, а работа не сделана). Поэтому все эти Agile-рассуждения годятся при неограниченом бюджете (розетка). Извините, если кто-то обиделся.

Мне больше нравиться подход квантования времени (чем больше объём задачи, тем больше квант) и закрепление за процессорами(людьми) типа задач, что бы человек не дёргался (или процессор поменьше лазил в RAM, и обходился внетренним кешем).

На эту тему понравилось в «Ководстве» § 167. Метод прогрессивного джипега от 26 ноября 2010. (www.artlebedev.ru/.../sections/167/Так что Тёма тоже книжки читает.


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

При этом растёт энергопотребление и садятся батарейки (кредит заканчивается, а работа не сделана). Поэтому все эти Agile-рассуждения годятся при неограниченом бюджете (розетка). Извините, если кто-то обиделся.

Вы делаете просто фантастический вывод из невероятной предпосылки. Вам бы теорию заговоров писать, там такое любят.

То есть я прав, потому что по существу нечего возразить. Выключите вентилятор. Про слово объём скАжите хоть что нибудь? Про задачи, которые не деляться? Если такую задачу поставить самой приоритетной, то и получим «зависание» сроков.

про употребление «-тся, -ться» рассказать?

Андрей, приведите, пожалуйста пример огромной недилимой задачи в ИТ-проекте.

Смотря для кого неделимой. Если в Винде открыть файл с диска, например фильм, потом вынуть диск во время просмотра фильма, классное зависание наблюдается. В Убунту то же самое. Про Маки не знаю, но что-то мне посказывает, что это грехи платформы х86.

Вот сколько уже лет этот маразм я наблюдаю вместе со всем земнім шаром, начиная с дискет 1М2, задача не решена. Аналогично, написание ОС скажем в России. Если у Вас нет других специалистов, где Вы возьмёте сто Энштейнов? Значит Ваш личный Энштейн будет делать сам, а Вы будете молится: “Ну сделай всё в срок.”

Вы делаете просто фантастический вывод из невероятной предпосылки

Ну да, нет человека — нет проблем. Потому и в заднице сидим.

Извините, если сумбурно излагаю. Но на каждом уровне свои сложности. Один за вечер нарисует портрет Монны Лизы, а другой будет всю жизнь рисовать одну картину “Явление Христа народу”. Так в программировании точно так же. Пока программирование искусство, так и будет, и будут неделимые задачи.

Андрей, по моему опыту «огромные неразбиваемые задачи», которые команда берет и потом остается только молиться — это, как правило, черта waterfall-разработки.

Когда мы сначала придумываем архитектуру БД или ОРМ-модель, естественно это огромная и неделимая задача, которую разбивай-не разбивай, приоритизируй- не приоритизируй, все равно придется делать до логики и интерфейса.

Аджайл — это собственной другой подход, который запрещает делать такие вещи.

Что делать с вашим примером задачи, я не знаю, т.к. он к разработке программ не относится.

Модель водопада тут не причём. Задача с доставанием диска думаю всё таки программная. Никакими методами она не решаема потому, что юзеру некуда пожаловаться.
Я не против Аджайл, просто это не панацея, так же как и MVC. Ну почему в MVC 3 слоя: Модель, Представление и Контроллер? Потому что ерунда. Если надо на 150 кусков, разбиваем на 150 по вертикали.
Есть такое понятие — разрезание. Всегда разрезая задачу на куски, минимизируют связи между кусками. Но если у Вас в базе названия городов, то Вы обязаны провести их через контроллер, до представления. Аналогично и ввод информации.
А теперь представьте, что начались переименоваания городов, улици т.д.
Луганск -Ворошиловград-снова Луганск. То есть логика поползла в тартарары. А с льготниками законодательство за год меняется по сто раз. Плюс наименования предприятий. Немножко добавьте украинского, или английского, а сейчас и китайского и перемешайте. Третья нормальная форма не работает. А у Вас три калеки и бюджет на три ставки. Приехали.
Вот поэтому даже любому тухлому облгазу для учёта требуется словарь синонимов на гигабайтик и вся его нехилая логика. Но этого нет и не будет, пока из Киева не придавят, причём пришлют такое, что привинтить невозможно.

Кризис ПО на лицо.

Андрей, вы очень сумбурно выражаетесь.

Я вас не понимаю.

Извините, давайте по научному. Любое линейное изменение ТЗ в далёкой стадии разработки или в готовом продукте требует экспоненциальных затрат.
Вы же понимаете, почему в Ворде легко отредактировать текст, а на рисунке нет, то есть разницу между векторной и растровой формой рисунка?
Так в программировании точно так же. Готовая программа — это отрендереный векторный рисунок. И не только потому, что компилятор поработал.
Для внесения изменений в программе необходимо «распознать» смысл, как распознаётся текст на рисунке соответствующими программами.

Говорят есть хорошее документирование, если применяем Аджайл. Ага, 100 томов. Пилите Шура, пилите. Объём есть объём.

Думаю, вы имеете в виду нечто такое:

buildsecurityin.us-cert.gov/...ness_Case-2.png

И чем больше система, в которой обнаружена ошибка, или в которую вносится изменение, тем дороже это изменение.

Я правильно вас понял?

1) Yes, it is.
2) А как же.
Мало того. У Вас полная дока, но она предназначена для реляционных баз, а Ваш заказчик поумнел и хотит XML с XMLQL, а то, паскуда, ещё хуже: мне в YAML,
а Вы умеете только в TXT, HTML5, XML и CSV и в базах MySQL, Firebird, PostgreSQL, IBM DB2, Oracle и Microsoft SQL Server. всего лишь.
Вот сволочь!
Вот и Fine Reader умеет английский, русский и украинский (вобчем латиницу и кириллицу), аВам надо Тайский и японокитайкий.

Возьмём к примеру Гугловские Карты. Никогда не работали? Полный бред В Пятигорске улиц нет. В Одессе все номера домов не по порядку. В Минске нет номеров домов. В другие страны, лучше не суйтесь.

Прекрасно! ))

Помогите мне пожалуйста увидеть, как тот факт, что большие системы дорого менять, связан со статьей Алексея?

Где большая система? Fine Reader? Вы что? Или GoogleMap? Он просто в браузере сидит. На сервере сидит база и всё. Напишите за 2 дня добавление в Fine Reader для марсианского? Хоть с использованием Agile, хоть без.

Agile как раз потому и крут, что он под именно такие ситуации и заточен,

А ну как требования поменяются? Или, не дай бог, вообще цель проекта?

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

Вы ещё скажите, что драйвер TCP большая система. Вон на IPv6 никак не перейдут

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

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

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

г) начинаем работать по приоритетам, начиная с самого важного

Упс! Оказалось, что первая же задача непосильна нашим кадрам (ибо наняли студентов). Что делать? Как бы вы поступили?

(Для меня здесь начинается Аджайл как искусство сделат наилучшее из возможного с имеющимися ресурсами)

Наилучшее из возможного: свалить што ли?
До разбивки ОС на задачи: уже много лет ищу русскую полную спецификацию на х86. НЕТУТИ!

Учите английский, учите английский. То есть за 20 лет НИКТО английский не выучил.

вы бы свалили.

я бы не свалил.

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

Алексей — мастер «аргументированного» диалога :) не впервые замечаю

Аргументы оказались несовместимы с моим диалоговым аппаратом. Мне бы че попроще.

Вы описали качественную и количественную оценки задач. Качественная — оценка относительной важности, количественная — абсолютной. Оба подхода вполне применимы.

Качественная оценка скажет вам, что фича A приоритетнее фичи B. Количественная — что фича A принесет владельцу продукта $10000 в год. Зная оценочную стоимость разработки, можно подсчитать ROI и, как вариант, в результате опустить фичу A в конец списка.

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

Есть подозрение, что создание «мат модели количественной оценки задач» это NP-complete задача сама по себе. :)

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

Не, я считаю — не надо путать теплое с мягким. Между приоритетом и бизнес-ценностью есть таки огромная разница.

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

Я настаиваю, приоритет как способ концентрации на важном, это все-таки отношение, относительная оценка.

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

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

Количественная оценка важности зависит от того, что Вы копаете, золото или навоз. А трудовременные затраты одинаковые. И дедлайн тут может изменяться в широчайших пределах. Или самородок на второй день, или стог сена за месяц.

Я согласен с Алексеем — относительная оценка важнее. Создание мат моделей — неблагодарное занятие, потому что при равновесных приоритетах принимается бизнес-решение о смещении приоритетов со всеми вытекающими рисками. И решение это в подавляющем большинстве случае — смесь авантюры с текущим представлением о целесообразности :) Как это моделировать?

И ещё — зная стоимость разработки, не всегда можно посчитать РОИ :)

Подписаться на комментарии