Вы находитесь на выставке машин (в контексте схемы конструктивного мышления Воловика), на которой Agile представлен в виде узлов отдельных практик мышления и их сборок – в отличие от обычного представления в виде практик и методов организации работы. Представлена история развития отдельных узлов, обеспечивающая технологизацию выполнения соответствующей мыслительной работы с обеспечением повторяемости результата и массовизацию. При этом есть интересный эффект: технологизация одного узла не является локальной, а проявляется и на других узлах работы, это тоже показано. Частично проведена идеализация в виде явного выделения в представленных экспонатах типов мыслительных операций, и других идеальных объектов, эта работа будет продолжена.

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

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

1. Самостоятельное посещение выставки – бесплатно.
2. Обратная связь, пожелания по набору экспонатов и форме представления – приветствуются.
3. Если у посетителей есть интерес к развитию выставки, они могут сделать пожертвование на наполнение выставки экспонатами или представление в другой форме, в том числе, высказав пожелания или обременения по использованию пожертвования. Условия, при которых обременение принимается – обговариваются.
4. Я готов по контракту проводить экскурсии по выставке, отвечая на вопросы по экспонатам, рассказывая подробно про Agile связанное с ним сообщество, в которое я вхожу с 2007 года, практически от его зарождения в России.
5. Я готов по контракту проводить специализированные исследования форм мышления в различных Agile-практиках, а также других практиках, по которым у меня есть практический опыт, или участвовать в таких коллективных исследованиях, в том числе за пределами практического опыта, используя те методы, которые позволили создать данную выставку.
6. Я готов по контракту конструировать (и частично проектировать) отдельные необходимые узлы и сборки практик разных типов мышления (конструирования, позиционирования, проектирования, программирования) на основе представленных и других практик Agile, IT и других, перефункцианализируя их для работы в других областях.

Я готов рассматривать различные формы контрактования своих услуг.

В Agile есть ряд методов организации базового процесса разработки софта, при этом приветствуется их адаптация и реализация гибридных вариантов. Часть процессов уже перенесены из IT в другие отрасли и имеют там свое применение. Основой описания здесь будет Scrum-процесс, как самый распространенный в IT, и перенесенный в другие отрасли, в частности в организацию продаж и в образование (eduScrum).

Базовый процесс представлен на схеме, его шаги далее описаны как черный ящик. В каждом из шагов есть мышление в разных формах, и Agile технологизировал проведение ряда из этих шагов. Два первых шага подробно описаны далее.

Сам процесс протекает в контексте – есть некоторый продукт с определенными целями и концепцией. Определение целей и контекста продукта – за рамками данного процесса, это надо описывать отдельно.

1. Выявление потребностей пользователей. Продукт: список отдельных внешних функций, которые необходимо реализовать и их предполагаемого использования. Мышление: коммуникация и анализ, выделение разложение деятельности на части, мышление из позиции пользователя.
2. Определение релизов – этапов поставки функций. Продукт – пакеты внешних функций, объединенные в релизы со своим timeline. Мышление – оценка, выделение MVP – минимального продукта, приносящего максимальный эффект, сценарное планирование развития продукта. Коллективное предпринимательское мыследействие, его мне сложно квалифицировать однозначно.
3. Планирование спринта – очередного кванта разработки, завершающегося демонстрабельным приращением релиза, по которому возможна обратная связь от потребителей. Продукт – список задач, которые должны быть сделаны для реализации каждой из включенных в спринт внешних функций. Мышление: экспресс-проектирование с выделением типовых, конструкторских, проектировочных и исследовательских задач, инженерная оценка, баланс затрат против создаваемой ценности, приоритизация. Коллективная мыслительная процедура в один или несколько тактов.
4. Разработка в IT. Продукт – достроенный софт. Это может быть исполнение процедуры, либо мыслительная задача с применением конструкторского, проектного, исследовательского или программного типов мышления, при этом необходимость типа мышления не всегда очевидна первоначально. Для меня в IT это интересно разобрать подробнее. В других областях применение мышления при решении задач – вопрос предмета, надо разбирать отдельно. Однако, если это получится распредметить, то может получиться очень интересно. В целом разработка софта аналогична процессам строительства разных объектов в современных играх, через которые эмулируется достаточно много видов деятельности. А выход за рамки сборки по инструкции или конструирования из блоков в более сложные формы мышления – вещь редкая, но, возможно, востребованная.
5. Тестирование. Продукт – проверка доработанного софта на соответствие внешним функциям. Делится на формальную часть (чек лист без мышления), и проверку из позиции пользователя (которую надо занять).
6. Ежедневная летучка. Продукт – оперативная корректировка процесса. Рефлексивная оценка предыдущего дня и проблем. и траектории спринта в целом – успеваем или нет, и что предпринять. В замысле - коллективная мыслительная деятельность, а не формальный отчет, при этом – сжатая во времени (15 минут на 7 человек команды).
7. Выбор очередной задачи разработчиком в работу. В зависимости от организации процесса, это может быть действие по правилу, или самоопределение в ситуации.
8. Демо – представление продукта пользователям и заказчикам, получение обратной связи и ее обработка. Коммуникация, в которой стороны разговаривают на разных языках.
9. Ретро – рефлексия прошедшего спринта (или более крупных этапов работы) и формирование действий по ее улучшению, коллективная рефлексивная коммуникация. Проведение – технологизировано, есть разные сценарии и техники, зависящие от зрелости команды и, в том числе, меняющие самих людей, прививающих им навыки рефлексии.

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

В Scrum потребности пользователя выявляются в формате user story, которые уже представляют технологичный формат, поэтому важно рассмотреть историю развития. Я буду писать об IT-варианте работы с потребностями пользователей, хотя многое – обобщается.

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

Сточки зрения мышления мы имеем

1. онтологическую работу, связанную с формированием словаря и рабочих схем
2. аналитическую работу по структуризации текста, получаемого от пользователей в интервью
3. коммуникацию с пользователем на предмет верификации им понятого и сформулированного аналитиком

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

Выяснилось, что описание функций на естественном языке – недостаточно, если в нем утеряны представления о том, как пользователи будут использовать эту систему и для каких целей. Потому что в процессе разработки возникают ситуации принятия решений с выбором альтернативных вариантов, которые надо выполнять из позиции пользователя. И если разработчик занимает эту позицию, понимая, что делает пользователь (это описано), но не понимая зачем – он принимает неверные решения.

Как результат в 1992 году появился формат описания use case, а в 1998-2001 – формат user story, который задает шаблон: «Как (роль), я хочу сделать (что именно), чтобы (достигнуть цели/решить задачу вне системы)», при этом историю необходимо уложить в 1-3 предложения (уместить на карточку). Таким образом, формат соответствует представлению действия пользователя в виде тройки Субъект – Цель – Средство.

Формат user story обеспечивает следующее:

1. Жестко требует ролевого восприятия деятельности
2. Требует формулировать цели и задачи выполнения действий
3. Позволяет занять его позицию и принимать решения из нее
4. Делит поток деятельности на малые кванты, несущие ценность (ценность понимается в смысле Lean, трактующей производство как цепочку создания ценности)

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

Онтологическая работа осталась за рамками данного формата user story. По ее разворачиванию есть практики в рамках объектно-ориентированного подхода и Domain Driven Design, предполагается, что они были применены в рамках первоначального проектирования софта или его большого фрагмента, а если в коммуникации с пользователями встречаются новые понятия, то соответствующие списки, схемы и другие артефакты дополняются по аналогии. И тут можно говорить о разных уровнях компетенции аналитиков: может делать онтологическую работу, или работает в уже заданной рабочей онтологии. О технологиях онтологической работы в IT надо писать отдельно.

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

Этот метод лучше, чем просто user story обеспечивает возможность занятия позиции пользователя и такая технологизация повлияла на несколько последующих этапов, а не только на разработку. Это будет рассмотрено далее.

При переносе Scrum за пределы IT необходимо определить способ фиксации внешних функций создаваемого продукта. Как правило, идет заимствование из этих предметных областей форматов. в которых там принято представлять выполняемые задачи, с адаптацией их для выполнения тех ограничений, которые накладывает Scrum на такой элемент. В тех областях, где речь идет об оказании услуг, может применяться формат user story или его модификации.

Результатам этапа выявления потребностей пользователя является их список. Этот список не обязан быть исчерпывающим и подробным, однако важно, чтобы в него попали все потребности, которые полагаются достаточно важными, чтобы удовлетворять их на ранних этапах. И далее происходит отдельное коллективное предпринимательское мыследействие, в ходе которого определяется состав релизов – этапов поставки функций пользователям. Так же не до конца: принцип состоит в том, что необходимо заглядывать на 2-3 этапа вперед, при этом периодичность поставки зависит от конкретного продукта.

Результатом этапа является упаковка отдельных потребностей, выраженных в user story или в другом формате, в пакеты, соответствующие релизам и выделение MVP (minimum viable product), то есть законченного функционала, представляющего интерес для группы пользователей, и оправдывающей использование продукта.

Участники коммуникации.

1. Стейкхолдеры или их представители, которые могут оценить сравнительную важность удовлетворения интересов конкретных групп пользователей. Для создания продуктов – это вес групп пользователей в целевом сегменте, с учетом стратегии продаж. Для заказной разработки – руководители отделов, чья работа изменится (облегчится) после внедрения системы, знающие существующие проблемы и настоятельность их решения.
2. Опытные разработчики, которые способны быстро, без детального проектирования, оценить трудоемкость реализации конкретных историй, а также удерживать взаимосвязь отдельных историй, в том числе изменяя оценку при перестановке порядка реализации. Это – отдельная компетенция. Иногда предварительная оценка проводится заранее, но они все равно участвуют в ходе коммуникации.
3. Руководитель проекта или другое лицо, отвечающее за бюджет проекта.
4. Бизнес-аналитики, знающие контекст потребностей пользователя, а также выполняющие роль коммуникаторов между другими участниками, которые говорят на разных профессиональных языках.

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

Технически Story Mapping проводится на большой доске (стене), куда на стикерах клеятся карточки user story и другие, которые относятся к поставкам продукта.

Процедура Story Mapping

1. Представляем последовательность поставок с желаемыми параметрами:
   1. адресаты поставки (группы пользователей)
   2. поставляемая ценность (функциональный блок)
      • ценность понимается в смысле Lean, концепции цепочек создания и поставки ценности (value chain)
   3. желаемые сроки поставки
      • размечаем доску, располагая на ней стикеры с временными метками и поставки, подписанные на стикерах (потребуется двигать)
   • Представления о желаемой последовательности поставок обычно имеются заранее у кого-то из стейкхолдеров, но здесь она презентуется всем участникам.
2. Располагаем на доске подготовленные user story в соответствии с планом релизов. Ранжируя их заодно на (а) ключевые, обеспечивающие поставку этой ценности; (б) обязательные, достраивающие функционал до необходимой целостности, и (в) дополнительные. И учитывая еще предполагаемую зависимость user story с точки зрения реализации
3. Примерно оцениваем user story с точки зрения производства. Предварительная оценка может быть заранее, но перестановка может приводить к ее изменению, из-за технических работ. связанных с каждой первой user story определенного типа, образующей серию.
4. Считаем баланс с учетом предполагаемой мощности производства. Обычно получается, что мощность производства не позволяет обеспечить требуемый состав и сроки релизов. И дальше начинается балансировка, которая технически заключается в перестановке user story.
   1. Содержательно стейкхолдеры варьируют содержание и сроки поставок, могут вводить дополнительные поставки, разработчики думают над вариантами реализации с разной трудоемкости.
   2. В ходе коммуникации так же согласуются критерии качества реализации – они различны для разных историй, в зависимости от характера обеспечиваемой функции для пользователя. Технически это происходит в коммуникации, по тем историям, в которых оценка user story не соответствует ожиданиям стейкхолдера. При вскрытии может оказаться что это связано с тем, что история – первая из какой-то серии и создает базу для ее реализации, либо история представляет собой «кроличью нору» - простую внешне, но сложную внутри, или разработчики сильно усложнили потребности пользователя и действительно можно проще и быстрее.

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

Выше были представлено одна сборка процесса и подробно – два ее узла. Остальные узлы тоже могут быть представлены подробно. Помимо этого на выставке могут быть представлены следующие узлы и сборки (список пополняется).

1. Практики онтологической работы по созданию рабочих онтологий и схем в рамках объектно-ориентированного подхода (ООП) и DDD (Domain Driven Design)
2. Практика технологичного удержания целостности при коллективной оценке состояния и продвижения сложного организационного проекта или программы в OMG Essence с заменой линейного движения многопоточным.
3. Практики работы с конфликтами в моральной (в смысле вводного доклада Петра на игре) рамке, проработанные в Холакратии
4. Сборки координации работы, ведущейся независимыми самодвижущимися участниками. объединенных рамочными целями и организованностями в Холакратии
5. Практика воспроизводства и развития Agile – распространение новых практик не через теоретическое осмысление, а через практические тренинги.
6. Клиповое мышление: его отличия от конструктивного, генезис и современное развитие.