Пока среди аналитиков ведутся обсуждения, как оценить эффект от внедрения Средства Управления Требованиями (СУТ) – мы просто взяли систему и сделали на ней некое подобие пилотного проекта (как и все пионеры внедрения СУТ).
Какие целевые критерии успеха мы для себя определили? На самом деле довольно абстрактные, но позитивные. К сожалению, у нас не было накоплено никаких метрик, а по пилотному проекту их собирать особого смысла не было. В итоге мы будем ограничиваться только нашими ощущениями и голословными высказываниями.
В процессе аналитической работы на наших проектах наблюдаются следующие проблемы:
- Требования с незначительной периодичностью теряются;
- В требованиях тяжело найти нужную версию;
- Влияние новых требований на проект оценивается аналитиком, опираясь исключительно на его опыт и незатуманенную память;
- Надо делать 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
Борис Сторонкин
Уведомление: Статья “Предпосылки к внедрению Devprom ALM как средства управления требованиями” | Алексей Киселев / Alexey Kiselev
Вот если бы еще добавить скрины, впечатления и анализ результатов, пользы от статьи было бы в разы больше:). Продолжение в ближайшее время планируется?
Да, планируется, но это будет не так скоро, как хотелось бы. Скорее всего, в следующей части будет наша модель работы с требованиями и впечатления со скринами. Об итогах интереснее говоряить после завершения боевого проекта.
Коллеги, ваша эйфория понятна, но всё-таки, на мой взгляд, отсутствует взаимосвязь между «проблемы-пожелания-причины выбора-что получили».
Хотелось бы увидеть явное описание того, например, как Девпром будет решать ваши проблемы, а именно:
Написанное в «нам хотелось» бы также скорее некие частности ваших текущих процессов и инструментов.
1. Да, вы уже сами ответили на вопрос. Хотя при изначально заданных трассировках вероятность таких потерь уменьшается, это я в свое время при работе в РеквизитПро проверил.
2. Конкретно нас интересует только текущий срез, поиск по старым версиям нам не требуется. Вроде как Девпром используется и на продуктах, но это не наш случай.
3. Вопрос что надо считать. Если бюджет, то нет, такая задача не стоит, ничего сказать не могу. В любом случае аналитику надо переоценивать работы и т.п., подсчет бюджета проекта ведется/, соответственно, при внесении трудозатрат анаитиком, ваш проектный менеджер увидит измененную картину. А вот для того, чтобы аналитик ничего не пропустил есть матрица трассировок и указание на те связи, на которые может влиять изменение текущего требования.
4. Идет трассировками, нам достаточно, логику нашей текущей работы не нарушает.
Семь бед? Трассировка — ваш ответ! :)
Надеюсь, вы понимаете, что я хочу указать на общие недостатки статьи минимум, или подхода (хотя он скорее скрыт за описанием в статье).
Если будете на ЛАФе, я бы с удовольствием лично побеседовал о вашем опыте с Девпромом.
К сожалению, в этом году не удалось, а так бы я тоже с удовольствием пообщался.
Про вопросы я всё понимаю, но мы не продуктовый депатрамент и требования, характерные для продукта, не выставляем. Отсюда нам несколько проще, ибо нет веток и хитрых требований к версионности (нам достаточно хранить историю).
А про трассировки - уйти от екселя в сторону чего-то более вменяемого в вопросах трассирования для нас приятно, да и время экономит (за счет автоматизированного их ревью и т.п.).
По поводу работы с одним большим документом. Коллеги из Девпрома уже разработали плагин к MS Word, который осуществляет взаимную синхронизацию между требованиями в файле Word и требованиями в Девпром: http://devprom.ru/docs/%D0%9F%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD-%D0%BA-MS-Word
Павел, да, мы его активно тестируем, коллеги из Девпрома стараются его улучшить, чтобы форматирование по ГОСТ не пропадало. Пока всё хорошо.
В силу ряда понятных причин аналитик не может опробовать на реальных проектах большое количество разных инструментов для управления требованиями.
Поэтому обзоры «с полей» от независимых экспертов всегда интересны — за это вам спасибо).
Однако должна согласиться с Денисом — статье не хватает конкретики.
Как именно вы использовали инструмент, какой у вас был проект (даже с учетом NDA можно дать некоторые детали о размерах команды, количестве аналитиков, это собственная разработка или продуктовая и т.д.).
Какие у вас были сложности вы перечислили, но как вы их решали с помощью инструмента пока не понятно. К тому же наверняка у инструмента есть и ограничения, не для всх задач и всех проектов он подойдет.
Было бы очень интересно в следующих частях обзора обо всем этом узнать)
Да, так и планируется, причем на новой версии 3.0
Уведомление: Статья “Использование системы управления требованиями Devprom в проектах заказной разработки по ГОСТ” | Алексей Киселев / Alexey Kiselev