- PVSM.RU - https://www.pvsm.ru -
Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.
За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воотчую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.
Вообще тема автоматизации управления процессами разработки и внедрения ИТ продуктов очень интересна и амбициозна, особенно для аналитиков и архитекторов. Ведь они жаждут получить в «одном флаконе», сквозную трансляцию всех процессов, начиная еще со сбора требований, далее к проектированию и моделированию, и уже через них протоптать дорожку непосредственно к разработке. И ведь мало им своего собственного хотения, так они еще подзадоривают менеджеров проектов и продуктов, открывающимися при таком подходе горизонтам к почти безграничным возможностям оценки и планирования проектных работ.
В данной публикации я хочу еще раз подытожить свой опыт в этом вопросе и спроектировать элементы системы, как я ее вижу. Формат публикации не позволяет привести полное ТЗ, поэтому я постараюсь описать наиболее важные с моей точки зрения детали, а так же сами рассуждения по выбору тех, или иных решений. Кому интересно прошу со мной…
Исследовать — значит видеть то, что видели все, и думать так, как не думал никто
Альберт Сент-Дьерди
Наверное одна из самых популярных систем такого класса — Jira, которая иногда заявляется как система управления проектом. Хотя на мой взгляд, она далеко не дотягивает до такого уровня. Может если только, как часть системы, совместно с Confluence, MSProject и прочими инструментами. Гораздо гармоничнее она вписывается в классификацию — система для организации взаимодействия с пользователями. Еще подобные системы, из тех что на слуху, с разной глубиной предоставляемых функций: Redmine, MeisterTask, Zoho, TaskWorld, MantisBT.
А еще есть системы по управлению репозиториями, дополненные возможностями управлять задачами и вести простенькую базу знаний. Например, GetLab. Есть и другие ниши из которых могут пробиваться подобные решения.
Агрегируя потенциал вышеупомянутых средств, можно выделить следующие востребованные функции:
Сколько раз просматривал черновик этого списка, столько вносил изменения или добавлял что-то. Процесс почти бесконечный…
По факту большинство систем такого рода неплохо поддаются настраиванию под конкретные нужды команд, но все равно есть множество спорных нюансов, о которых упомяну вкратце:
Я частенько наблюдаю вот такую ситуацию. Например, перед командой стоит вызов — добавить некий новый функционал в уже действующий продукт. Для начала, в вики системе заводится описание проблемы с предложенным решением. Затем оно постепенно обрастает паутиной из пары десятков комментариев с обсуждениями различных частей этого решения. В результате, чтобы прояснить картину на чем же остановились в текущий момент, приходится метаться между разными комментариями, описанием проблемы и решения. Все усложняется в геометрической прогрессии, когда на этот букет еще навешиваются грозди задач.
На самом деле, в реальном проекте не так уж много людей, которым взаправду необходима сквозная трассировка информации от потребностей пользователей, до реализованных функций в конкретной версии продукта. Чаще всего, таковыми лицами выступают архитекторы и системные аналитики, которые впрочем не всегда готовы активно биться за свои интересы в системе управления проектами. Ведь это не только накладно по времени, но еще и требует жертв, в виде взваливания на себя дополнительной ответственности и потерянных безвозвратно нервов.
Хотя наверное, если кто-то такую систему организовал бы, вся команда была бы в выигрыше. Ведь это позволяло бы обеспечить детализацию всей системы, на подсистемы, их на модули и контуры, их на сервисы и функции и т.д. А те, в свою очередь связывать не только с элементами на формах пользователя, но и с конкретными версиями продукта, веток кода, в которых эти функции реализованы и т.п. При всем при этом, детализацию хорошо бы визуализировать в виде схем (архитектуры решения), с переходами, погружающими вглубь по уровням конструкции.
Но, пожалуй, самый весомый профит – это получение возможности связать каждый элемент этой разнородной структуры, с требованиями разных уровней, из которых и можно узнать почему же продукт сделали именно так, а не иначе, и чьи интересы за этим стоят. Например, можно отслеживать вариацию решений одного и того же требования верхнего уровня в разных проектах.
Для описанного в вики-системе требования, в трекере появляется набор задач с разными типами: на оценку, на проектирование, на реализацию, на тестирование, на передачу заказчику и т.п. В каждой из них тоже есть небольшое описание – экскурс в проблему, и помимо ссылки на требование в вики, ссылки на смежные задачи, Вся гирлянда, в лучшем случае, оформлена, как главная задача и подзадачи (уровень вложенности ограничен). В самих задачах могут быть свои комментарии, со ссылками на прочие комментарии и т.п.
В процессе выполнения могут меняться исполнители, ожидаемые версии продукта, приоритеты исполнения, метки, компоненты и прочее, прочее, прочее… Весь этот клубок задач необходимо как-то синхронизировать, поддерживая в актуальном состоянии и обеспечивая непротиворечивость данных. Глядя на подобную пеструю картинку многообразия, чувствуется большая, большая натяжка. Пожалуй слово «большая» уместно употребить и в третий раз.
Все вышеперечисленное и еще некоторые другие моменты, вскрывают червоточины во вроде бы красивых и “сочных” решениях.
На практике можно наблюдать две крайности в построении подобных продуктов:
Первый способ чаще всего используется в небольших проектах, требующих быстрых решений с плохо формализованными требованиями. Недостатки подхода сглаживаются за счет проведения большого количества совещаний, обсуждений, обеспечивая постоянное привлечение внимания к проблемам и текущим актуальным решениям. Но в связи с этим, возникает большое количество дополнительной информации, которая остается за бортом системы по управлению процессом разработки и оседает в головах, почте, мессенджерах, комментариях кода и т.п. Если проект приостанавливается на некоторое время, а позже требует развития, могут возникнуть большие проблемы с непониманием контекста реализованных решений, их актуальностью и т.п. Зачастую возникают риски, связанные с отсутствием технических возможностей к масштабированию.
Второй способ чаще применяется в больших долгосрочных проектах, которые неизбежно связаны со сложными, измененяемыми в ходе реализации требованиями, или при создании линейки тиражируемых продуктов, которые необходимо будет кастомизировать. Трудности появляются еще в процессе оформления требований в системе, возрастают при их изменениях в разных проектах, версиях продуктах и т.п. Трудности, связанные со сложностью восприятия контекста всего проекта, его отдельных частей и их взаимодействия, углубляются и при попытках подключить к проекту новых исполнителей, и при необходимости развития продукта. Такой подход требует привлечение высококвалифицированных специалистов, дополнительного обучения, значительных временных затрат Цена поддержки такой системы может быть высока.
Вообще в больших, сложных проектах есть узкое место – контекст проекта. Детальное описание того, что и как необходимо реализовать. Иногда, это огромный массив информации, который лишь как-то структурирован. Хуже, когда эта информация размазана по разнородным артефактам, или сознанию заинтересованных лиц. То есть, выставляя новое задание разработчику, необходимо понимать, что ему придется потратить дополнительное времени на ознакомление с контекстом решаемой задачи и текущей реализацией взаимодействующих с его решением компонентов.
Вот как раз эти проблемы и должен помочь эффективно решить рассматриваемый нами продукт, поддерживающий процесс разработки и внедрения информационной системы.
— Я создам идеальное общество, создам такой мир, в котором будут жить только ответственные и добрые люди!
— И в этом идеальном мире ты окажешься единственным злодеем…
(Тетрадь смерти)
Давайте начнем скруглять озвученные в предыдущей части угловатости.
По идее анализ может начинаться с рассмотрения процессов, которые мы будем автоматизировать. Но если их описание затолкать в данную статью, она получится чересчур загроможденной и будет тяжело восприниматься аудиторией. Тем более, что я уже проводил подобный анализ и сейчас просто сошлюсь на свою публикацию «Производство информационных систем» [1].
Чтобы не лепить в кучу несовместимое, тщательно отделим зерна от плевел. Рассматривая весь процесс создания информационной системы: «Проектирование – Реализация – Внедрение», удобно поделить проблемы на 3 основные типа, связанные с:
Эта трёхходовка выявляет основные объекты, выступающие костяком, на который нанизан весь техпроцесс. Это:
Поскольку мы автоматизируем процессы производства, то связующим звеном всей конструкции конечно выступит Задача, куда же без нее. Таким образом имеет смысл ввести соответственно три типа задач: «Задача по требованию», «Задача по спецификации», «Задача по сборке».
Задачи, связанные с организацией самого процесса производства, его финансирования, определения договорных отношений и т.п., мы в данном случае оставляем за рамками рассмотрения.
Модель данных может быть организована, как показано на рис.1.
Рисунок 1. – Модель классификации задач
Все типы задач целесообразно наследовать от одного класса, на который можно навесить глобальные атрибуты задания, включая и «отчет» о его выполнении.
На основании вышесказанного давайте воспроизведем всю картину процесса работы с системой управления разработкой информационных систем целиком.
Итак, сначала возникают требования пользователя. Являются они не сами по себе, а в ходе выполнения выставленных для этого исполнителям (аналитической группе) задач. В результате выполнения этого же пула работ, формируются Спецификации на реализацию решения в коде. С сим к процессу могут подключиться ведущие специалисты из цеха разработки.
Далее, по готовым спецификациям выстраивается новый пул задач исполнителям (программистам), уже в ходе решения которых, могут потребоваться сборки готового (или не очень) продукта.
Следующим шагом, используя параметры и характеристики сборки, а так же мест их дислокации, в службу поддержки и внедрения вливается своя свита задач, надлежащее решение которых и приводит к полноценному использованию информационной системы заказчиком.
Таким образом, отталкиваясь ли от задач, или от самих основных объектов: Требование, Спецификация, Сборка, мы может проследить весь путь от проблемы до конкретного решения в продукте, а также все активности продвигающие это решение по непростому, тернистому пути.
Сама же задача теперь отодвинута в системе с центральной позиции вглубь, поскольку акцент мы вынесли на объекты, в рамках которых эта задача и выполняется, а ей же самой остается лишь роль назначения исполнителя и уточнения самого действия. Ну и отчет конечно будет формироваться по задаче. Таким образом в заголовке задачи теперь должны превалировать глаголы. В моей практике встречаются менеджеры, которые создавая задачю (task) не используют ни одного глагола, и каждый раз возникает вопрос к автору: «А что же всё-таки надо сделать, где пресловутое побуждение к действию?».
Задача в ходе своего жизненного цикла проходит разные стадии, которые проецируются в системе статусом. Например так, как представлено на рис.2.
Рисунок 2. – Модель перехода состояний задания
Возможно такой подход и заставит тратить чуть больше времени в проекте, но это только на начальном этапе. Эти затраты будут с лихвой отыграны за счет снижения хаоса в системе и более строгой организации самого техпроцесса.
В следующей части рассмотрим детально каждый пул работ по-отдельности.
Автор: ARadzishevskiy
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/278627
Ссылки в тексте:
[1] «Производство информационных систем»: https://habrahabr.ru/post/350972/
[2] ru.wikipedia.org/wiki/Redmine: https://ru.wikipedia.org/wiki/Redmine
[3] Источник: https://habrahabr.ru/post/354126/?utm_campaign=354126
Нажмите здесь для печати.