Пока среди аналитиков ведутся обсуждения, как оценить эффект от внедрения Средства Управления Требованиями (СУТ) — мы просто взяли систему и сделали на ней некое подобие пилотного проекта (как и все пионеры внедрения СУТ).

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

В процессе аналитической работы на наших проектах наблюдаются следующие проблемы:

• Требования с незначительной периодичностью теряются;
• В требованиях тяжело найти нужную версию;
• Влияние новых требований на проект оценивается аналитиком, опираясь исключительно на его опыт и незатуманенную память;
• Надо делать Excel-таблицы для выявления степени покрытия требований заказчика постановками;
• Так как людей запрещено приковывать к батареям и/или отбирать у них паспорта, а аналитики относятся к категории людей, то необходимо хранить полную историю изменений требований, их взаимосвязи (особенно, если речь идёт о связанных нескольких проектах) источники. А ещё их надо уметь быстро и правильно находить. Это трудоемкая задача, которую тяжеловато делать исключительно в вышеупомянутом Excel и Word: сразу хочется как-то автоматизировать поддержание актуальности ссылок, дабы не пребывать в глубочайшей депрессии в момент их актуализации.

Часть из этих бед можно было бы решить при помощи «донастройки» Jira, но потом мы пришли к выводу, что между Jira и некогда любимым всеми нами RequisitePro наблюдается непреодолимая пропасть, многокилометровая заминированная пустыня и ещё неизвестно, что… Вообще, что бы нам хотелось:

• Иметь одно большое ТЗ, не побитое на 100500 маленьких документов, которые потом пришлось бы собирать воедино для отправления заказчику после завершения очередного этапа.
• Работать именно в этом большом ТЗ, а не выгружать его для каждой правки и загружать обратно в Jira.
• Трассировать отдельные куски этого документа с постановками, тест-кейсами, задачами на разработку и так далее.
• Автоматизированно отслеживать взаимосвязи между артефактами (включая требования разных типов, тест-кейсы и т. д.).
• Уметь трассировать куски одного такого документа с кусками другого.
• Не использовать дорогой и древний RequisitePro.

Итого, не имея никаких метрик и осознавая свои потребности, мы выбрали ALM Devprom. Почему?

• Devprom имеет оперативную и качественную поддержку на русском языке (почта, телефон, специальный чат в Skype), проводит бесплатные консультации у нас в офисе. На этом, кстати, мы отсеяли бесплатный Redmine;
• Простотой установки, обновления системы (без привлечения системных администраторов), а также настройкой шаблонов/жизненных циклов/справочников/проектов и всего такого прочего;
• Devprom учитывает наши пожелания, как одного из лидеров рыночного сегмента заказной разработки, и оперативно (неделя-месяц) дорабатывает СУТ (в том числе в рамках поддержки процесса разработки по ГОСТ 19 и 34);
• Devprom не слишком дорога для покупки: одна лицензия стоит около 7.т.р. (хотя лицензия нужна и для просмотра информации в Devprom, а не только редактирования);

И да, Devprom обеспечивал реализацию наших полумифических ожиданий.

Данное решение было принято примерно 3 месяца назад, а на сегодняшний день мы имеем:

• Установленную новую версию 3.0 (которая пока не доступна широкому кругу, но скриншотом я поделюсь);
• Поползновения в реализации системы по интересующему нас вектору (чего стоит планируемое внедрение baseline, доработка механизма экспорта/импорта в Word/Excel и доработка хранения версий отдельных документов);
• Практически готовый шаблон для создания новых проектов в рамках компании;
• Загруженный пилотный проект;
• Готовность к старту реального проекта.

Ключевым здесь является последний пункт, потому что за отсутствием конкретных метрик мы можем опираться только на ощущения задействованного в проект аналитика. Есть некоторые опасения, что появится много лишней работы, которую аналитик и в предварительную оценку даже не внесет. С другой стороны, есть ожидания, что наибольшая выгода от внедрения СУТ будет заметна на завершающих этапах, при доработках системы, а также при изменениях в команде (замена/добавление аналитиков).

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

Авторы:

Алексей Киселев
(akiselev87.wordpress.com), Аналитик, IBS

Борис Сторонкин
Ведущий аналитик, IBS

Впервые опубликовано на analyst.by.