Вероятно, я был первым членом Agile-сообщества, который написал что-либо по существу на тему «ценности» и оптимизации экономических показателей с помощью Agile-методов в форме книги из 63 000 слов, опубликованной в 2003 году. В то время Agile-сообщество не сильно интересовалось такими темами, как «определение приоритетов невыполненных итераций на основе ценности», поэтому моя заявка на конференцию Agile-2003 была отклонена. Самое современное на тот момент представление в сообществе экстремального программирования заключалось в том, чтобы определять приоритеты на основе технического риска. Agile был в значительной степени внутренне ориентированным движением. Да, в Манифесте Agile упоминалось о «ценности», но когда дело дошло до практического руководства, то её просто там не оказалось. В то время, когда я писал «Agile-менеджмент», я думал, что определить «ценность» легко.
Я был одержим литературой по оптимизации производственных процессов, такой как «Теория ограничений», и был убеждён, что всё, что нам нужно сделать, это определить ценность функций, а затем использовать эту информацию для определения приоритетов и, следовательно, оптимизации экономических показателей. Сейчас, 13 лет спустя, я могу сказать вам, что я менее уверен чем когда-либо, что мы знаем, как определить «ценность» каким-либо значимым способом, чтобы впоследствии это могло привести к детерминированному подходу по оптимизации экономических показателей.
Что означает «ценность»? Если вы прочитаете текст статьи Шора/Ларсен, то он подразумевает довольно простую концепцию: «Представляет ли эта история ценность для наших клиентов?». Ответить на этот вопрос довольно просто. Поэтому, если мы примем это на таком уровне, мы сопоставим с уровнем организационной зрелости 2: мы можем идентифицировать клиента; и мы понимаем, что может представлять значимую ценность для этого клиента; мы способны отсеивать задачи и другие элементы внутренней ценности, которые не имеют значения для клиента. Таким образом, наблюдается некоторое улучшение в согласовании и единстве целей.
У нас есть клиентоориентированность. Последователи Канбан Метода признают некоторую синергию с ценностями и принципами Канбан. «Проблема с ценностью» начинается, когда вы пытаетесь выйти за рамки понятия «является ли это ценным» и вместо этого пытаетесь количественно оценить ценность. В 2003 году я посвятил две главы книги «Agile-менеджмента» попыткам разобраться с этим. Честно говоря, в большинстве случаев вывод был бы таков: профессиональная сервисная работа не может быть сведена к количественной оценке ценности, в лучшем случае её можно свести к многомерной качественной оценке. Теперь я преподаю этот метод оценки в качестве учебного занятия от 1 до 1,5 дней в рамках мастер-класса по Канбан-коучингу в учебных программах по ESP.
Если мы посмотрим на определения Agile Fluency от 2-х до 4-х звёзд, то подразумевается, что нам нужен более сложный подход к определению и пониманию ценности. В оригинальной статье (при условии, что она датирована 2012 годом) заявляют, что эта проблема решена в Lean Startup или в Бережливой разработке ПО. Честно говоря, это нереально. Lean Startup поможет вам проверить гипотезу о том, что ценность может существовать. Я действительно не знаю ничего в области бережливой разработки ПО, что даёт конкретное представление об анализе ценности. Тем не менее, совокупность знаний по Бережливой разработке в книгах Райнертсена или Кеннеди, предоставляет некоторые методы. Стало довольно модным определять стоимость, используя варианты подхода Рейнертсена к «стоимости задержки». Я всё ещё считаю, что этот материал находится на начальной стадии и имеет проблемы, а анализ того, почему это так, является предметом ещё одной продолжающейся серии статей на этом сайте, которая началась со статьи
«Что мы знаем о продолжительности: Часть 1». Таким образом, переход от Agile Fluency к 2-звездочному уровню подразумевает, что нам нужны лучшие способы определения ценности. У нас есть некоторые методы для этого в базе знаний Канбан с 2007 года — например, качественная оценка стоимости задержки и присвоение классов сервиса рабочим элементам. Это согласуется с моим анализом того, что Канбан-система и доски могут вывести вас на 4-й уровень организационной зрелости, как описано в моей статье
«Паттерны Канбан и организационная зрелость». Метод оценки рисков, который я сейчас формализовал в учебных планах ESP, вместо того, чтобы пытаться объединить его с Канбаном (как мы делали с 2009 по 2014 год), обеспечивает комплексный, хотя и, по общему признанию, качественный, сложный и недетерминированный метод как для оценки стоимости, так и для выбора, упорядочивания и планирования с использованием оценки стоимости. Большая часть этой работы была доступна публично в 2012 году, хотя она и не представлена в удобной книге, но значительная её часть появилась в моём выступлении на конференции Agile 2009.