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

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

Бизнес-процесс под названием "управление жизненным циклом приложений" (Application Lifecycle Management - ALM) намного менее разработан на настоящий момент, чем те процессы, которые он поддерживает. Бизнес-процедуры при разработке программного продукта когда-то имели вспомогательное значение. Теперь они критически важны, ведь от компаний-разработчиков ПО требуется предоставлять в короткие сроки непосредственно своим клиентам продукт более высокого качества. Это означает, что организации и группы разработчиков ПО должны начать думать над тем, как наилучшим образом интегрировать дисциплины разработки, применяя целостный интегрированный ALM-подход.

Важность интеграции непросто оценить, но без неё у вас нет перспектив

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

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

Из-за того что одна команда задаёт тон работе, возникает тенденция к ингорированию всей предыдущей работы и даже исключения изменений, внесенных другими участниками проекта, оставляя заполнение пробелов специальным процессам, электронным таблицам и вики-страницам. Результат - непродуктивные, бесполезные совещания; но, что более важно, проблемы, которые следует исправлять, часто пропускаются, что приводит к снижению качества ПО, увеличению числа дефектов, удорожанию проектов и срыву сроков.

"Всеобщая интеграция" отвергается из-за следующих причин:

• Ответственность – Легко решить, кто ответственен за одну дисциплину, но кто ответственен за взаимодействие между двумя? Например, кого назначить ответственным за улучшение отношений между разработчиками и тестерами? Без четкого разделения ответственности, улучшений добиться непросто.
• Географические, организационные и политические границы – Реальность любой крупной организации такова, что организационные структуры развиваются и поддерживаются управленческими и политическими ограничениями. Сломать эти барьеры зачастую довольно трудно, если вы преследуете такую нематериальную цель, как продуктивность совместной работы.
• Измерение – В истории разработки ПО неточные измерения не редкость, но даже ограниченные измерения зачастую концентрируются на одной дисциплине, такой как тестирование, разработка или планирование. Интеграцию трудно измерить по природе, а без точной меры трудно на чём-либо концентрироваться или что-либо улучшать.
• Инерция – Перемены никогда не даются легко — это всегда неопределённость, а большинство сотрудников настроены негативно по отношению к ним, из-за прежних неэффективных решений руководства.

Организация рабочего процесса и соблюдение требований требуют комплексного подхода

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

Для хорошей трассируемости существуют следующие препятствия:

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

Всё дело в числах

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

Например, за счёт связи разработчика с тестером, существующие требования могут быть пересмотрены, что дает потенциальную возможность найти более изящное решение. Дэниел Муди (Daniel Moody) и Питер Уолш (Peter Walsh), исследователи, работавшие над этим вопросом, обсуждают возросшее значение информации в своей работе "Оценка значимости информации: подход оценки активов". Они говорят о том, что распространение информации приводит к увеличению её ценности – чем больше людей её используют, тем больше экономических преимуществ можно получить. IDC также не учитывает юридические требования и требования на соответствие, наложенные на информацию в некоторых организациях. Например, изменение в системе, которое привело к уязвимости в безопасности ПО и случаям мошенничества, но при этом не было должным образом задокументировано, приведёт к судебным разбирательствам и большим штрафам.

В общих чертах, затраты из-за неинтегрированных данных можно разделить на несколько категорий:

• Доступ к необходимым данным – вместо доверия цифрам, которые приводит IDC, можно подсчитать эффект от необеспечения доступа к нужным данным самостоятельно. Например, можно контролировать группу разработчиков в течение некоторого времени и отмечать, сколько времени занимает у них поиск необходимого требования, дефекта, элемента кода или сборки.
• Сбор информации - пересмотрите количество времени, потраченное на создание таблиц или электронных писем, собирающих информацию, таких как списки дефектов, статусы требований или списки задач.
• Цена откровения – для него гораздо сложнее предоставить точные числа, но задача может быть решена путём пересмотра уже интегрированных проектов и поиска конкретных изменений и изящных решений, которые были найдены ранее.
• Трассируемость данных – если у вас есть данные Х, что с ними связано? Например, если вы обнаружили дефект, вы должны быть в состоянии найти необходимые требования и сборку, которые описывают причину и эффект. Недостаточная трассируемость информации может рассматриваться как потеря в уровне соответствия требованиям; если данных нет на месте, компания-разработчик будет нести ответственность, если что-нибудь пойдёт не так, а компания не может предоставить доказательства соответствия спецификации.

Почему настало время для интегрированного подхода

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

1. Выработать хорошее понимание структуры данных – Создание информационной модели данных разработки программного продукта многим кажется пустой потерей времени. Тем не менее, хорошее понимание ключевых артефактов и их взаимосвязей чрезвычайно важно для процессов управления жизненным циклом приложений (ALM) и внедрения этой модели. Чем важнее становится разработка программных продуктов для бизнеса, тем больше становится количество управленческих отчётов. Отчётность позволяет совершенствовать требования к данным для ALM и даёт неплохой набор требований для попытки внедрения модели ALM.
2. Обращать внимание на средства разработки ПО для получения ключевых данных – Такие утилиты поддерживают ключевые дисциплины разработки ПО, но редко поддерживают непрервные бизнес-процессы. Материал, описанный в информационной модели, должен быть чем-то подкреплён, а это требует чёткого понимания данных, полученных от вышеназванных утилит и способности дополнить эти данные при необходимости.
3. Автоматизировать интеграцию – Таблицы, электронные письма и лекционные доски позволяют наладить коммуникацию и наглядно продемонстрировать, как одна концепция влияет на другую. Без продуманного подхода к автоматизации интеграции, эти взаимоотношения сложно поддерживать или контролировать. Интеграция должна происходить между утилитами так, как это прописано в информационной модели.

Заключение

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

Оригинал статьи

Об авторе

Dave West является главным продуктоводом в компании Tasktop. В данной роли он формиует roadmap по продуктам компании и их позиционирование на рынке, в тесном сотрудничестве с клиентами и партнерами.

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• SDLC - жизненный цикл разработки системы
• Внедрение ALM
• Как именно Agile ALM может помочь?
• Инструментарий Agile ALM
• Внедрение Agile ALM