Development Management and Project Management: Contrast or Complement?

Tikhanychev Oleg Vasilyevich ORCID: 0000-0003-4759-2931 PhD in Technical Science Deputy Head of Department in the Office of Advanced Development, Technoserv Group  111395, Russia, Moscow, Yunosti str., 13 tow65@yandex.ru Other publications by this author

Введение

Одной из составляющих современных сложных технических систем является программное обеспечение (ПО). В постиндустриальную эпоху, роль этого компонента постоянно растёт, увеличивается объём разрабатываемого ПО, ужесточаются требования к срокам и качеству разработки.

Для повышения эффективности разработки ПО в настоящее время используются различные методологии: «гибкие» Agile, «каскадные» Waterfall, их варианты ^[1].

Под «гибкими» технологиями принято понимать обобщающий термин для целого ряда подходов и практик, основанных на последовательной доработке разрабатываемого продукта в соответствии с постоянно уточняемыми требованиями заказчика. Сущность «гибкого» подхода - минимизация рисков путём сведения разработки к серии коротких циклов ^[2,3].

Каскадная модель разработки основана на том, что процесс разработки выглядит как поток, последовательно проходящий типовые фазы работы: анализ требований, проектирование, реализация продукта, тестирование, внедрение и поддержка функционирования ^[4].

На практике указанные методологии применяются через систему прикладных технологий и набор реализующего их инструментария. В рамках этих технологий, как в программировании, так и в других областях деятельности, для повышения эффективности рабочих процессов в практике управления принято использовать различные средства автоматизации управления коллективами разработчиков (Team Foundation Server - TFS, Jira, Gemini, Savana, Redmine, Trac, TaskJuggler, Toyota Kanban, Microsoft Project, Wrike, Confluence).

Большинство специалистов перечисляют и описывают эти средства как альтернативные между собой, выбирая и оценивая качества и возможность использования каждого из них преимущественно автономно ^[5,6].

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

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

1.Особенности средств управления проектами и разработкой программ

Как показывает опыт применения средств автоматизации управления коллективами разработчиков, в том числе лично автором, при одинаковом функционале они могут различаться областью применения. Например, TFS или Jira применяются при управлении разработкой программных продуктов ^[7,8], Toyota Kanban – при разработке машиностроительной продукции ^[9]. А Microsoft Project, Wrike, Confluence или «Адванта» реализуют более широкий, но менее специализированный функционал и обеспечивают управление работой коллектива в целом. Конечно, есть отличия и внутри классов, например, между средствами управления разработкой программной продукцией и продукцией машиностроения. Наиболее заметное: при разработке промышленной продукции существенная роль возлагается на системы подбора по каталогам готовых деталей и типовых сборочных единиц, соответствующих требованиям к разрабатываемому изделию ^[10,11]. При управлении разработкой программного продукта эти системы не используются по крайней мере, пока. Но перечисленные отличия определяются подходами к требуемому результату, да и то только в текущей ситуации. С переходом к промышленным методам разработки программного обеспечения, внедрением фондов типовых алгоритмов и программ, могут измениться и указанные функции. Указанные факты подтверждают актуальность проблемы уточнения классификации средств управления коллективами разработчиков.

Сравнивая особенности вышеперечисленных систем, можно сделать вывод, что многие проблемы выбора для использования тех или иных систем возникают из-за используемой в настоящее время терминологии их описания. Все системы управления коллективами разработчиков, принято обозначать термином, сформулированным на основе прямого перевода английского понятия «project management» (управление проектами). Формально это правильно. В то же время, исходя из функционала, логичнее часть из них назвать не системами управления проектами, а системами управления разработкой (development management). В данном случае речь идёт о средствах типа TFS и Jira, обеспечивающих не только управление самим процессом разработки, но и реализацию части технологических функций: тестирование, сборка программного продукта и т.п. [12–14]. Уточнение терминологии позволит разделить и области применения инструментария, определив рациональность его выбора для реализации тех или иных функций и этапов жизненного цикла программной продукции ^[15]. Такой вывод позволяет сделать обобщение опыта автора по разработке программной продукции специального назначения в нескольких крупных проектах, включая разработку системы «Безопасный город», с использованием таких средств организации процесса как TFS, Jira и Confluence.

Уточнённая классификация систем управления коллективами разработчиков может быть обоснована на основе сравнительного анализа характеристик различных средств автоматизации управления разработкой. И синтезом на основе данных анализа предложений по классификации таких систем.

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

Как показывает анализ, внешне формы, функции и даже управляющие элементы средств управления разработкой похожи. Методы представления и управления списком задач, «доской» работ, виджеты отображения хода выполнения проекта аналогичны и в TFS, и в Jira, и в других системах управления разработкой ПО. Похожи между собой и экранные формы различных систем управления проектами, их основные функции. А вот между формами программ управления проектами и управления разработкой внешнее сходство встречается реже. И даже в случае сходства, компоненты существенно различаются по реакции и содержанию функций (рисунки 1–3).

Рис.1. Внешний вид форм панелей задач систем управления разработкой TFS (наверху) и Jira (нижний рисунок)

Рис.2. Внешний вид форм «досок» задач систем управления разработкой TFS (сверху) и Jira (нижний рисунок)

Рис.3. Внешний вид аналогичных форм средства управления проектами Wrike

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

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

- по уровню формализации задач исполнителям проекта;

- по возможности взаимодействия со сторонними системами;

- по наличию встроенных средств автоматизированного тестирования и сборки программ.

По факту, хотя и те, и другие системы управляют работой персонала, оптимизируя использование наличных ресурсов и времени, системы управления разработкой в большей степени обеспечивают управление разработчиками и технологическими процессами, а системы управления проектами – руководство коллективами и маркетинговыми процессами ^[16,17,18].

2.Функциональные особенности средств управления разработкой и управления проектами

Процесс разработки ПО, в соответствии с требованиями нормативной документации, состоит из тех же этапов, что и создание автоматизированных систем управления, в составе которого оно реализуется:

- формирование требований, разработка концепции автоматизированной системы;

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

- разработка проектных решений по созданию системы в рамках эскизного и технического проектов;

- разработка опытного образца и рабочей конструкторской документации, приёмо-сдаточные испытания и сертификация системы;

- производство, ввод в действие;

- сопровождение эксплуатации системы.

Работа по каждому из этих этапов организуется в соответствии с типовым циклом управления: от целеполагания до постановки задач и контроля их выполнения.

Для реализации тех или иных функций типового цикла управления, на практике используется достаточно широкий перечень систем различного назначения: ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BI-системами (Business Intelligence) графического представления данных, средствами командно-сетевого планирования (КСП-системы), PLM-систем (Product Lifecycle Management), систем автоматизированного тестирования (Automation Testing System – ATS), средствами интеграции приложений (EAI – Enterprise Application Integration) и других [19–21]. Наличие EAI является достаточно важным фактором, учитывая, что системы управления производством редко разрабатываются под конкретный проект, чаще используются готовые системы, имеющиеся в активе предприятия ^{[22, 23]}.

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

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

Таблица 1 – Соответствие функционала систем управления процессами и разработкой возможностям других систем автоматизированного управления

Анализ указанных различий позволил определить, пусть в первом приближении, возможность и целесообразность использования компонентов перечисленных систем в тех или иных ситуациях работы над проектами по разработке ПО (см. таблицу 2).

Таблица 2 – Возможности использования средств управления процессами и управления разработкой

В таблице:

++ означает высокую эффективность использования;

+ приемлемая эффективность;

- означает низкую эффективность применения технологии в данных условиях;

+/- эффективность применения варьируется в зависимости от особенностей использования.

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

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

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

3.О практическом использовании средств управления проектами

Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на:

- системы управления проектами (project management);

- системы управления разработкой (development management).

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

Рис.4. Организация комплексного использования средств управления проектами и разработкой

Практика показала, что средства управления проектами и средства управления разработками – это эффективным инструменты как каждый в своей области, так и при совместном применении. Но, как всякие инструменты, они имеют границы применимости, в рамках которых они выдают ожидаемую эффективность. С другой стороны, при использовании вне указанных рамок (таблица 2), эти средства не просто показывают нулевой прирост эффективности, они мешают выполнению проекта, заставляя разработчиков выполнять лишнюю работу. Данный вывод сделан автором на основании практического опыта: когда в небольших коллективах на коротких проектах прямая постановка задач начинает дублироваться работой в TFS или Jira, аналитики, описав программисту процесс, вместо перехода к следующему этапу вынуждены повторно описывать уже выполняемые задачи. Что увеличивает затраты времени, практически не влияя на качество работы. И то, что результаты постановок задач фиксируются в электронной форме, служит слабой компенсацией потерянного времени.

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

Наиболее явное преимущество совместного использования средств управления проектами и управления разработкой и, пожалуй, одно из самых существенных – возможность создания тематических слоёв отображения состояния управляемого процесса. На профессиональном сленге разработчиков такие слои называют «стейкхолдерами» (stakeholders), от английского понятия, обозначающего причастных к процессу лиц или организаций, непосредственно заинтересованных в его результате. Организация таких слоёв позволит управленцам всех уровней оперативно оценивать реализацию требований относительно разрабатываемой системы или её свойств, удовлетворяющих их потребностям и ожиданиям (стандарты ISO/IEC 15288:2015, ISO/IEC 29148:2011). Повышая тем самым эффективность контроля процесса разработки, как одного их важнейших этапов цикла управления. И, соответственно, обеспечивая оперативное реагирование на изменения в динамике производственного процесса, сокращая время и затраты.

В то же время, в использовании указанных средств могут возникать определённые проблемы. Определяются они тем, что системы управления проектами и разработкой реализуются, преимущественно, программными средствами зарубежной разработки. Для их эффективной работы необходим сетевой режим, периодическое обновление рабочих модулей. В той ситуации, когда разрабатываемый проект содержит конфиденциальную информацию, данный факт может стать критичным. Занесение в сетевой проект требований к разрабатываемой системе, описания её архитектуры, может вызывать определённые опасения. Впрочем, проблема решаема. Существует достаточно широкий средств управления проектами, включённых в «Единый реестр российских программ для электронных вычислительных машин и баз данных» ^[24,25], в том числе систем отечественной разработки: 1С-Битрикс24, «Адванта» (А2), «Rubius Project Manager», «Яндекс.Трекер» и множества других. Остаётся только выбрать средство, отвечающее требованиям конкретного проекта или организации по функционалу. После этого выбора остаётся организовать комплексное применение средств управления проектами и разработкой, которое, как показала практика, обеспечивает оптимизацию использования перманентно ограниченных сил и средств для решения ресурсоёмких задач. Оптимизацию, как по распределению ресурсов, так и времени на разработку программного продукта.

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

Заключение

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

В дальнейшем, вероятно, потребуется актуализация терминологии предметной области на основе предложенной классификации и уточнение применяемой нормативно-технической документации ^[26,27]. Это достаточно объёмная задача, но её решение обещает определённый прирост эффективности разработки ПО. Которое, в настоящее время, является неотъемлемой и очень важной частью практически любой сложной технической системы. Исходя из этого, решение сформулированной в статье научно-практической задачи является актуальным и требующим скорейшей реализации.