I Вступление

Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.

За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воотчую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.

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

В данной публикации я хочу еще раз подытожить свой опыт в этом вопросе и спроектировать элементы системы, как я ее вижу. Формат публикации не позволяет привести полное ТЗ, поэтому я постараюсь описать наиболее важные с моей точки зрения детали, а так же сами рассуждения по выбору тех, или иных решений. Кому интересно прошу со мной…

II Анализ рынка решений

Исследовать — значит видеть то, что видели все, и думать так, как не думал никто
Альберт Сент-Дьерди

Наверное одна из самых популярных систем такого класса — Jira, которая иногда заявляется как система управления проектом. Хотя на мой взгляд, она далеко не дотягивает до такого уровня. Может если только, как часть системы, совместно с Confluence, MSProject и прочими инструментами. Гораздо гармоничнее она вписывается в классификацию — система для организации взаимодействия с пользователями. Еще подобные системы, из тех что на слуху, с разной глубиной предоставляемых функций: Redmine, MeisterTask, Zoho, TaskWorld, MantisBT.

А еще есть системы по управлению репозиториями, дополненные возможностями управлять задачами и вести простенькую базу знаний. Например, GitLab. Есть и другие ниши из которых могут пробиваться подобные решения.

1. Стандартизация функций систем, представленных на рынке

Агрегируя потенциал вышеупомянутых средств, можно выделить следующие востребованные функции:

• Учет по множеству проектов;
• Поддержка системы доступа пользователей, основанная на ролях;
• Организация работ с задачами для исполнителей;
• Учёт временных затрат исполнителей;
• Визуализация работ на диаграмме Ганта и календарях;
• Учет требований к разрабатываемым продуктам, которые можно связать с задачами пользователям для их реализации;
• Организация обсуждений проблем, задач и т.п. между пользователями;
• Учет документов и управление файлами;
• Оповещение участников проекта об изменениях;
• Организация настраиваемых произвольных реквизитов для инцидентов, временных затрат, проектов, пользователей и т.д.;
• Организация управления версиями и выпусками продукта;
• Формирование разнообразных отчетов для анализа.

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

2. Недостатки существующих систем

По факту большинство систем такого рода неплохо поддаются настраиванию под конкретные нужды команд, но все равно есть множество спорных нюансов, о которых упомяну вкратце:

1. Самое принципиальное с моей точки зрения стеснение при использовании подобных систем – это размежевание всего пула работ на управление требованиями и управление задачами (трекеры и сопутствующие ингредиенты). Например у компании Atlassian для организации работ по этим направлениям, продукты разделены на уже упомянутую Jira и вики систему — Confluence. Между ними конечно установлена связь, при помощи разнообразных ссылок, но все же этого бывает недостаточно. Подобное разделение вполне понятно и оправдано с маркетинговой точки зрения, поскольку обеспечивает компоновку среднестатистической системы из элементов линейки продуктов. Но с другой стороны, это сразу вносит допущения и ограничения в получаемый на выходе продукт.
   
   Я частенько наблюдаю вот такую ситуацию. Например, перед командой стоит вызов — добавить некий новый функционал в уже действующий продукт. Для начала, в вики системе заводится описание проблемы с предложенным решением. Затем оно постепенно обрастает паутиной из пары десятков комментариев с обсуждениями различных частей этого решения. В результате, чтобы прояснить картину на чем же остановились в текущий момент, приходится метаться между разными комментариями, описанием проблемы и решения. Все усложняется в геометрической прогрессии, когда на этот букет еще навешиваются грозди задач.
2. Поскольку основной упор в подобных системах делается на управление взаимодействием в команде (треккер), то подсистема отвечающая за управление требованиями, обычно сильно хромает на фоне продуктов, специализирующихся на этом поприще. Сей момент тоже легко объяснить, например, тем, что сегмент аналитики очень специфичен, насыщен тонкостями, знакомство с которыми большинству участников проекта, не просто не нужно, а вообще противопоказано. Ведь для передачи этих абстракций на этап реализации в конкретном коде, нужны лишь выжимки, из которых удалены все промежуточные суждения, малопонятные диаграммы, а описания деловых процессов нормализованы и транслированы в алгоритмы.
   
   На самом деле, в реальном проекте не так уж много людей, которым взаправду необходима сквозная трассировка информации от потребностей пользователей, до реализованных функций в конкретной версии продукта. Чаще всего, таковыми лицами выступают архитекторы и системные аналитики, которые впрочем не всегда готовы активно биться за свои интересы в системе управления проектами. Ведь это не только накладно по времени, но еще и требует жертв, в виде взваливания на себя дополнительной ответственности и потерянных безвозвратно нервов.
   
   Хотя наверное, если кто-то такую систему организовал бы, вся команда была бы в выигрыше. Ведь это позволяло бы обеспечить детализацию всей системы, на подсистемы, их на модули и контуры, их на сервисы и функции и т.д. А те, в свою очередь связывать не только с элементами на формах пользователя, но и с конкретными версиями продукта, веток кода, в которых эти функции реализованы и т.п. При всем при этом, детализацию хорошо бы визуализировать в виде схем (архитектуры решения), с переходами, погружающими вглубь по уровням конструкции.
   
   Но, пожалуй, самый весомый профит – это получение возможности связать каждый элемент этой разнородной структуры, с требованиями разных уровней, из которых и можно узнать почему же продукт сделали именно так, а не иначе, и чьи интересы за этим стоят. Например, можно отслеживать вариацию решений одного и того же требования верхнего уровня в разных проектах.
3. Следующий момент, который дает слабину во всей концепции, рассматриваемого нами класса систем, это безоговорочная ориентированность на задачу. «Задачи являются центральным понятием всей системы, описывающим некую задачу, которую необходимо выполнить» (1). К чему это приводит?
   
   Для описанного в вики-системе требования, в трекере появляется набор задач с разными типами: на оценку, на проектирование, на реализацию, на тестирование, на передачу заказчику и т.п. В каждой из них тоже есть небольшое описание – экскурс в проблему, и помимо ссылки на требование в вики, ссылки на смежные задачи, Вся гирлянда, в лучшем случае, оформлена, как главная задача и подзадачи (уровень вложенности ограничен). В самих задачах могут быть свои комментарии, со ссылками на прочие комментарии и т.п.
   
   В процессе выполнения могут меняться исполнители, ожидаемые версии продукта, приоритеты исполнения, метки, компоненты и прочее, прочее, прочее… Весь этот клубок задач необходимо как-то синхронизировать, поддерживая в актуальном состоянии и обеспечивая непротиворечивость данных. Глядя на подобную пеструю картинку многообразия, чувствуется большая, большая натяжка. Пожалуй слово «большая» уместно употребить и в третий раз.

Все вышеперечисленное и еще некоторые другие моменты, вскрывают червоточины во вроде бы красивых и “сочных” решениях.

3. Вызовы при создании системы поддержки производства информационных систем

На практике можно наблюдать две крайности в построении подобных продуктов:

1. Упрощение и минимизация требований и размазывание их по задачам. Вносит сумятицу, несогласованность в процесс разработки;
2. Формирование в системе огромного массива информации, касающейся требований к разрабатываемой системе, с запутанной структурой и сложной навигацией по ним. Требует очень много усилий, для поиска нужной информации, понимания всего контекста проекта в целом;

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

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

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

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

III Проектирование базовой структуры системы

— Я создам идеальное общество, создам такой мир, в котором будут жить только ответственные и добрые люди!
— И в этом идеальном мире ты окажешься единственным злодеем…
(Тетрадь смерти)

Давайте начнем скруглять озвученные в предыдущей части угловатости.

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

1. Деление решаемых проблем по типам

Чтобы не лепить в кучу несовместимое, тщательно отделим зерна от плевел. Рассматривая весь процесс создания информационной системы: «Проектирование – Реализация – Внедрение», удобно поделить проблемы на 3 основные типа, связанные с:

• Сбором требований и проектированием решения;
• Непосредственно самой реализацией решения в коде;
• Сборкой, выпуском и разворачиванием продукта на боевых площадках.

Эта трёхходовка выявляет основные объекты, выступающие костяком, на который нанизан весь техпроцесс. Это:

• Требование пользователя. Исходная постановка задач на автоматизацию;
• Спецификации на разработку (Software Requirements Specification, SRS). Формализованные требования заказчика, трансформированные в формат максимально пригодный для эффективного их воплощения в коде, а также тестирования и приемки;
• Сборка продукта. Артефакты, связанные с версией итогового или промежуточного продукта, готовой к поставке.

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

Модель данных может быть организована, как показано на рис.1.


Рисунок 1. – Модель классификации задач

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

На основании вышесказанного давайте воспроизведем всю картину процесса работы с системой управления разработкой информационных систем целиком.

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

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

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

Сама же задача теперь отодвинута в системе с центральной позиции вглубь, поскольку акцент мы вынесли на объекты, в рамках которых эта задача и выполняется, а ей же самой остается лишь роль назначения исполнителя и уточнения самого действия. Ну и отчет конечно будет формироваться по задаче. Таким образом в заголовке задачи теперь должны превалировать глаголы. В моей практике встречаются менеджеры, которые создавая задачю (task) не используют ни одного глагола, и каждый раз возникает вопрос к автору: «А что же всё-таки надо сделать, где пресловутое побуждение к действию?».

Задача в ходе своего жизненного цикла проходит разные стадии, которые проецируются в системе статусом. Например так, как представлено на рис.2.


Рисунок 2. – Модель перехода состояний задания

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

В следующей части рассмотрим детально каждый пул работ по-отдельности «Часть 2».