Agile как сборка практик мышления

Короткая ссылка: AgileAsThinking

Ссылки сюда (1) →

Презентация

Вы находитесь на выставке машин (в контексте схемы конструктивного мышления Воловика), на которой 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. Клиповое мышление: его отличия от конструктивного, генезис и современное развитие.