Software architecture workshop

use-caseПару недель назад я поделился в фейсбуке мыслью организации воркшопа по ИТ архитектуре и пообещал подробнее написать в блоге как это будет выглядеть. Software architecture workshop это собрание рабочей группы проекта часика на 3-4 в ходе которого осуществляется проектирование ИТ решения для конкретного проекта. Происходить он должен через 2-3 недели после инициации проекта к  моменту, когда заказчик может хоть как-то сформулировать требования. На вход такого воркшопа и поступает заказчик, способный сформулировать требования. На выходе получаем 2-3 варианта реализации этих требований в виде зарисовок архитектуры и список вопросов  для дальнейшей проработки, другими словами – набор задач участникам рабочей группы на фазу планирования.

Состоит воркшоп из трех частей: рисование требований (рисования в буквальном смысле, т.е. маркером на флипчарте), рисование архитектуры ИТ решения и написание списка вопросов для дальнейшей проработки. В первой части лидирует аналитик. Работая в формате фасилитатора, он должен за 30-40 минут «выудить» из заказчика 10-15 пользовательских историй (user stores), коротких  повествований о том, как будет работать новый продукт или бизнес-процесс. Истории надо кратко зафиксировать на флипчарте (один, максимум два листа). Затем команда начинает их классифицировать на стандартные и специфические, характерные только для данного проекта. Нестандартных историй должно получиться в районе 3-5 штук. Если общее количество сценариев больше 15 или нестандартных сценариев больше 5, то скорее всего у нас проблемы со scope проекта.

Небольшое отступление. Конечно, можно поступить, как это делают в SCRUM –завести backlog, в котором накапливать пользовательские истории, собираться каждые 2 недели, доставать из backlog очередную порцию историй и анализировать их. В принципе, то что я рассказываю это применение идей agile но не для разработки ПО, а только для его проектирования. В крупных организациях agile не живет, т.к. разработка обычно ведется на аутсорсинге, а процессы работы с поставщиком построены в классических канонах водопадной модели. Одним словом, разрабатывать ПО в итерационной или гибкой манере не получится, но анализировать требования и проектировать ИТ решение вполне можно

Выделив 3-5 нестандартных сценария, мы расписываем их в стиле Алистера Коберна. Каждый на отдельном листе флипчарта. Для каждой истории появляется основной  сценарий из 6-9 шагов, предусловия, триггеры и т.д. На этом первая часть нашей архитектурной мастерской завершается. Команда разбредается на 10-15 минут покурить, попить кофе. Заказчика даже можно отпустить заниматься его важными делами, но все же  будет намного лучше если он останется. Будет отвечать на вопросы, т.к. начинается самый интересный этап – проектирование архитектуры решения. (Совсем забыл. Нельзя уходить на перерыв пока заказчик не сформулирует основные нефункциональные требования – нагрузка, время отклика и т.д.)

Команда собирается после перерыва и маркер в свои руки берет архитектор. Предварительно, на тренинге по ИТ архитектуре  я научил его или её выделять из пользовательских сценариев описание предметной области.  Вооружившись цветными маркерами архитектор подчеркивает в описании сценариев основные сущности: действующих лиц, коллекции информационных объектов,  различные типы документов, бизнес-процессов, событий и пр. и отображает их в виде моделей на отдельных листах бумаге в своей архитектурной нотации(см. Архитектура в формате C4. Sketches and NoUML ). В ходе рисования возникает много всяких интересных вопросов касающихся предметной области. Надеюсь, заказчика мы еще не отпустили  и на большую часть вопрос он нам ответит. Вопросы, оставшиеся без ответа, менеджер проекта фиксирует в блокнотике или на своем iPad-e. Да-да, к этому моменту воркшопа проектный менеджер уже проснулся, отложил в сторону свой мобильный телефон и принимает активное участие в процессе. Завершается второй этап обсуждением возможных вариантов реализации. Посмотрев на архитектурные скетчи команда начинает соображать как бы реализовать проект, задействовав уже имеющиеся в компании информационные системы. Пока что просто набрасывает предложения на отдельном листке флипчарта и уходит на второй перерыв.

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

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

Отступление номер 2. Все успешные проекты похожи друг на друга, каждый неуспешный проект неуспешен по-своему. Описанные выше техники приведены во всех книжках по анализу требований и проектированию ИТ решений. Идентификация действующих лиц, описание вариантов использования, моделирование предметной области – азы деятельности аналитика и архитектора. Даже довольно старый и не модный нынче унифицированный процесс определяет себя как итерационный, инкрементальный, управляемый вариантами использования и ориентированный на архитектуру. Что же говорить про гибкие методологии, поощряющие сотрудничество и строго измеряющие прогресс. Единственная рекомендацию которую регулярно нарушают участники ИТ проектов – следовать перечисленным выше рекомендациям. Можно издать приказ о необходимости следования лучшим практикам, но сотрудник – это такое существо, которое лучше всего делает вид, что он делает, то, что от него требуется. Если мы верим, что люди основной компонент проектирования информационных систем, то и методы этой деятельности должны быть направлены на поддержку людей

Software architecture workshop: 4 комментария

  1. Вообще, отличная идея! Единственное, я бы добавил на этапе воркшопа технику сторибординга (storyboarding). Это что-то вроде рисования комиксов (или прототипов в форме wireframes) поведения пользователей в проектируемой системе. Данные артефакты послужат существенным дополнением к описанию историй пользователей, поскольку:
    1. Более наглядны, чем текст историй, а главное – позволяют стейкхолдерам видеть (и принять) будущую систему в картинках. Если оставить эту работу аналитику на потом, то это приведет к куда более грандиозным затратам на согласование будущей концепции UI.
    2. Определяют масштаб проекта по количеству/сложности разрабатываемых форм (интеграций), а также позволяют “нарезать” ожидания стейкхолдеров, например, по релизам (эти 5 форм идут сначала, потом сделаем эти, ну а в последнем релизе вот эти…)
    3. Комикс позволяет связать несколько форм (или историй) в единый законченный эпик, из которого понятно зачем и откуда идет пользователь, куда и с чем он приходит.
    4. Наверно самое главное, на формах фиксируется значимая входная и выходная информация, что является существенным подспорьем для работы архитектора в формировании модели предметной области.

    1. Евгений, спасибо за комментарий. Действительно, техника визуализации очень важна. Я вчера был на мастер-классе по скрайбингу (последовательная отрисовка рассказа в реальном времени). Это производит впечатление. Сторибординг – тоже хорошая тема. Думаю, выбор подходящей техники зависит от конкретных сценариев. Еще раз спасибо за дополнение.

  2. Всё хорошо, но было бы ещё лучше использовать русские слова, или их англоязычное написание workshop, facilitator.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *