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

Целевая аудитория¶

Программный продукт создаётся людьми. Непосредственно в процессе создания участвуют: дизайнеры, программисты-разработчики, архитекторы, тестировщики, менеджеры проекта, менеджеры продукта. Все эти роли находятся между собой в каких-то отношениях. Типы и количество этих отношения зависят от конкретной команды. А команда в данной статье — это как раз те, кто непосредственно участвует в создании продукта. Также есть те, которые участвуют менее непосредственно, это: внедренцы, техподдержка, служба продаж и служба рекламы (и прочих внешних сношений). Часто бывает так, что один человек может играть одновременно несколько ролей, например, программиста и дизайнера или программиста, архитектора и тестировщика. Не хочу судить, правильно это или нет, однако такое бывает и часто. И даже выскажу крамольную для кого-то мысль, вопрос правильности вообще очень опасный вопрос, можно погнаться за «правильностью» и в итоге потерять продукт. Можно наплевать на «правильность» и захватить монопольно весь рынок. Так что нужно очень осторожно и аккуратно относиться ко всяким рекомендациям и наставлениям.

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

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

Задачи системы¶

Из предыдущего раздела уже можно понять, что главной функцией системы является обеспечение эффективной коммуникации. Но нужно чётко понимать, что под словом «коммуникация» подразумевается не только непосредственное общение, но также и разнообразная проектная документация. А под словом «эффективная» подразумевается, что элементы коммуникации работают интегрированно и эффективно, например, проектная документация — это не беспорядочный набор статичных файлов, а некая динамическая система, оперирующая с конкретными сущностями из пространства понятий проекта (features, uses cases, releases и т.п.).

Уже очевидно, что система должна охватывать все этапы создания продукта. Примерный их список:

• сбор требований (requirements gathering);
• анализ требований (requirement analysis);
• проектирование;
• реализация/программирование;
• тестирование;
• внедрение
• сопровождение/техподдержка.

Для каждого из этапов существуют некие документы (части проектной документации), а задача системы — установка и поддержание связей между всеми документами.

Другой задачей системы является автоматизированный анализ данных. Такой анализ в принципе возможен, поскольку данные хранятся в формализованном виде (то, что выше я назвал «эффективной коммуникацией»). Результатом автоматизированного анализа могут являться различные таблицы, схемы, графики — всё то, что позволяет руководителям проекта находиться в курсе происходящего, оценивать темпы работы и контролировать сроки исполнения поставленных задач.

Ключевые функциональные элементы¶

Одна из главных целей системы — автоматизация проектной бюрократии. Поэтому важнейшим компонентом является работа с электронными документами. Под «работой» подразумевается создание и поддержание электронных документов, их анализ, интеграция разных документов.

Проблемы создания и применения¶

Все компании разные¶

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

Психологические аспекты¶

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

Интерфейс¶

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

Приоткрываем детали¶

Итак, общих слов уже сказано немало, можно попробовать порассуждать о более конкретных вещах.

Во-первых, данные. Данные должны быть формализованы. Максимально возможная формализация не нужна, но какой-то уровень должен быть явно и чётко зафиксирован. Пока вполне достойно выглядит модель блоков данных разных типов. Например, блок с информацией об одном из вариантов использования (use case), или блок с тесткейсом. У каждого блока есть своя история изменений. Кроме того, блоки могут объединяться в более крупные структуры, у которых также могут быть какие-то свои этапы жизненного цикла, которые необходимо отслеживать.

Во-вторых, пользовательский интерфейс. Пока самым оптимальным вариантом видится только веб-интерфейс. Это на сегодняшний день самое простое кроссплатформенное решение.

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

В целом представляется некий сайт, зайдя на который, участник проекта получает доступ к определённым фрагментам данных. Некоторые фрагменты он может редактировать, некоторые — создавать, некоторые — обсуждать. Например, пользователь с ролью «начальник группы QA» имеет права на создание тесткейсов (test case) и наборов тестов (test suite/test plan); в тесте могут быть ссылки на фрагменты из других подсистем, например, из подсистемы с юзкейсами (use cases) из конкретного юзкейса есть ссылка на конкретные тесткейсы, которые тестируют данный юзкейс; и благодаря формализованности данных, всегда можно найти юзкейсы, которые не покрыты тестами, а также генерировать разнообразные отчёты по выполнению набора тестов.