В теме 19 ответов, и 10 участников, последнее обновление сделано пользователем 
tilya 13 г, 9 мес. назад.
-
Сообщения
-
А как отслеживать статусы требований?
Ну, мы кстати используем статусы для каждой странички в Wiki (есть спец. плагины для этого).
Мы используем следующие статусы:
1. Writing in progress (страничка пишется аналитиком или правится после реджекта). Этот статус устанавливается автоматом, как только начинаешь править страничку.
2. Review Required (страничка готова для апрува). Апрувнуть или реджектнуть могут QA, Tech Lead, Expert (это три отдельных апрува/реджекта)
3. Approval QA (страничка понятна QA и ее требования пойдут в жиру). Апрувы от Tech Lead и Expert не обязательны, но дают дополнительное удовлетворение
4. Reject QA/Tech Lead/Expert (страничка отклонена одним из участников, т.е. ее надо исправить). Что не удовлетворяет или не понятно указывается в коментах к страничке.При этом мы можем править требования даже, когда по ним идет разработка в итерации, но пойдут изменения в эту итерацию или будут CR в следующую согласовывается лично.
В жире в тасках идут ссылки на версии страничек с требованиями (Wiki поддерживает историю версий), т.е. страничку можно исправить, но таска будет ссылаться на ранее утвержденную версию, т.е. программист будет читать (при реализации) ту версию, которую утвердили. Или же, если согласовали (лично) реализовывать по новым требованиям, то просто в таске меняется ссылка на новую версию странички с требованиями.
[quote="skan201"][quote="tilya"]
В нашей компании например, используется спека в WIKI и она вся строится на базе спроектированных прототипов пользовательского интерфейса и описания требований к ним. Причем, наша спека очень динамичная, в том смысле, что часто дополняются требования или вносятся изменения. Правда есть один момент, мы разрабатываем собственный продукт, ориентированный на массового пользователя, поэтому это тоже влияет на то, что все наше проектирование очень сильно ориентировано на пользователя. Также мы чуть свободнее в сроках, чем компании, которые занимаются заказной разработкой.А как отслеживать статусы требований?[/quote]
Это не ответ, а просьба уточнить вопрос:
а какие статусы вы бы хотели отслеживать и зачем?[/quote]Статусы используемые в управлении требованиями: Proposed, Approved, Rejected, Implemented, Verified, ну и т.д. Как мы узнаем степень выполнения работ по тому или иному требованию?
Более того, мне интересно, как мы можем указать в WIKI атрибуты требований, например, источник требований и приоритет.
[quote="skan201"]
А как отслеживать статусы требований?Ну, мы кстати используем статусы для каждой странички в Wiki (есть спец. плагины для этого).
Мы используем следующие статусы:
1. Writing in progress (страничка пишется аналитиком или правится после реджекта). Этот статус устанавливается автоматом, как только начинаешь править страничку.
2. Review Required (страничка готова для апрува). Апрувнуть или реджектнуть могут QA, Tech Lead, Expert (это три отдельных апрува/реджекта)
3. Approval QA (страничка понятна QA и ее требования пойдут в жиру). Апрувы от Tech Lead и Expert не обязательны, но дают дополнительное удовлетворение
4. Reject QA/Tech Lead/Expert (страничка отклонена одним из участников, т.е. ее надо исправить). Что не удовлетворяет или не понятно указывается в коментах к страничке.При этом мы можем править требования даже, когда по ним идет разработка в итерации, но пойдут изменения в эту итерацию или будут CR в следующую согласовывается лично.
В жире в тасках идут ссылки на версии страничек с требованиями (Wiki поддерживает историю версий), т.е. страничку можно исправить, но таска будет ссылаться на ранее утвержденную версию, т.е. программист будет читать (при реализации) ту версию, которую утвердили. Или же, если согласовали (лично) реализовывать по новым требованиям, то просто в таске меняется ссылка на новую версию странички с требованиями.[/quote]
Интересное решение. А если 1 страница <-> Несколько требований?
Вкратце по самой организации страничек
Все страницы организованы в виде дерева. Каждая страница описывает некую функциональность (обычно некоторый экран).
Страница имеет составное имя: Название функциональности + номер странички. Номер странички включает номера всех его родителей + свой собственный.
Пример куска дерева страниц:
-Req1 — FR-01
—Req2 — FR-01-01
——Req3 — FR-01-01-01
——Req4 — FR-01-01-02
—Req5 — FR-01-02Описание требований на страничке делается в следующем формате:
1. Краткое описание функциональности.
2. Основной мокап (может отсутствовать, если описывается не экран, а некоторое поведение например, URL валидация).
3. Требования (лучше чтобы были как можно более атомарные требование 1-2 предложения)Каждое требование нумеруется следующим образом: Номер странички + Латинская буква + Название (может отсутствовать, используются больше как метки, чтоб цеплялся глаз)
Пример странички Req2 — FR-01-01:
Описание: бла-бла-бла
макет (здесь должна быть картинка
)FR-01-01-A — Name1
бла-бла-блаFR-01-01-B
бла-бла-блаFR-01-01-C — Name2
бла-бла-блаНу и активно в тексте требований используются ссылки на другие странички (т.н. системный подход в спеке).
Как мы узнаем степень выполнения работ по тому или иному требованию?
Более того, мне интересно, как мы можем указать в WIKI атрибуты требований, например, источник требований и приоритет.
Приоритеты требований мы не ставим в Wiki, мы ставим приоритеты таскам в жире. Также мы составляем продукт бэклог на итерацию, и на каждую запись цепляем таски из джиры. По окончанию итерации смотрим, как этот беклог выполнился.
По поводу источника требований: у нас собственный продукт и два эксперта: один в сфере бизнеса, другой в сфере UI. Поэтому для нас это наверное не актуально)
Вы должны авторизироваться для ответа в этой теме.
