6991
правка
Изменения
м
→Ирина Сурова. ЗАО «Лаборатория Касперского». Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA.
И у них наработались шаблоны, применяемые на многих проектах. Если кратко, то устроено оно так. Все начинается от бизнес-требований, которые фиксируются в TFS и представляют собой некоторое требование уровня бизнеса, некоторая фича. Которая попадает к системным аналитикам в EA и они ее декомпозируют на функциональные системные требования. Функциональные Системные требования попадают назад в TFS как подчиненные, для этого налажена синхронизация. А еще по ним из EA можно выгрузить содержательный документ.
Производится маппинг требуемых изменений на компоненты, и далее. , независимо от декомпозиции на функциональные системные требования, бизнес-требование делится на change request к компонентам. При этом связь системных требований и change request тоже присутствует. По ним change request в командах, отвечающих за компоненты, с учетом описания функциональных системных требований, делается оценка. При этом могут порождаться подчиненные change request к библиотечным компонентам и инфраструктуре. С запросами к инфраструктуре — отдельная ветка, потому что там около 150 сервисов, и команды не очень представляют внутреннее устройство. Поэтому была сделана «служба единого окна», маршрутизирующая change request к инфраструктуре.
Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, заключающимися в исполнении бизнес-требований, и их реализация должна быть вставлена в релизы.
После получения совокупности оценок и с их учетом происходит планирование релиза. А потом, по этой же структуре — контролируется ход работ. При этом, естественно, работы декомпозируются на отдельные задачи, которые выполняются. И добавляются тест кейсы. Получается трассировка полного цикла. Что касается изменения требований в ходе работ, что структура верхнего уровня, сформированная при оценки, меняется редко — потому что она верхнеуровневая. А вот содержание функциональных системных требований изменяется, EA это поддерживает, и влечет изменение декомпозиции на задачи.
Вокруг TFS накручены
* роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы
После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно. , чтобы скоуп проекта был суммой соответствующих item’ов независимо от формы, и совпадал смысл ключевых статусов прохождения.
== Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения ==
