О вреде функциональных спецификаций (обсуждение статьи) (страница 2)




В теме 19 ответов, и 10 участников, последнее обновление сделано пользователем Аватар (tilya) tilya 6 г, 8 мес. назад.

Показано 5 ответов - от 16 до 20 (всего 20)
  • Автор
    Сообщения
  • 24.03.2011 в 09:14 # 5884
    Аватар (tilya)
    tilya
    Подписчик

    А как отслеживать статусы требований?

    Ну, мы кстати используем статусы для каждой странички в 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 поддерживает историю версий), т.е. страничку можно исправить, но таска будет ссылаться на ранее утвержденную версию, т.е. программист будет читать (при реализации) ту версию, которую утвердили. Или же, если согласовали (лично) реализовывать по новым требованиям, то просто в таске меняется ссылка на новую версию странички с требованиями.

    Поделиться:

    Цитировать

    24.03.2011 в 09:32 # 5885
    Аватар (skan201)
    skan201
    Подписчик

    [quote="skan201"][quote="tilya"]
    В нашей компании например, используется спека в WIKI и она вся строится на базе спроектированных прототипов пользовательского интерфейса и описания требований к ним. Причем, наша спека очень динамичная, в том смысле, что часто дополняются требования или вносятся изменения. Правда есть один момент, мы разрабатываем собственный продукт, ориентированный на массового пользователя, поэтому это тоже влияет на то, что все наше проектирование очень сильно ориентировано на пользователя. Также мы чуть свободнее в сроках, чем компании, которые занимаются заказной разработкой.

    А как отслеживать статусы требований?[/quote]

    Это не ответ, а просьба уточнить вопрос:
    а какие статусы вы бы хотели отслеживать и зачем?[/quote]

    Статусы используемые в управлении требованиями: Proposed, Approved, Rejected, Implemented, Verified, ну и т.д. Как мы узнаем степень выполнения работ по тому или иному требованию?

    Более того, мне интересно, как мы можем указать в WIKI атрибуты требований, например, источник требований и приоритет.

    Поделиться:

    Цитировать

    24.03.2011 в 09:34 # 5886
    Аватар (skan201)
    skan201
    Подписчик

    [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 страница <-> Несколько требований?

    Поделиться:

    Цитировать

    24.03.2011 в 09:43 # 5887
    Аватар (tilya)
    tilya
    Подписчик
    Вкратце по самой организации страничек :)

    Все страницы организованы в виде дерева. Каждая страница описывает некую функциональность (обычно некоторый экран).

    Страница имеет составное имя: Название функциональности + номер странички. Номер странички включает номера всех его родителей + свой собственный.

    Пример куска дерева страниц:
    -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
    бла-бла-бла

    Ну и активно в тексте требований используются ссылки на другие странички (т.н. системный подход в спеке).

    Поделиться:

    Цитировать

    24.03.2011 в 09:57 # 5888
    Аватар (tilya)
    tilya
    Подписчик

    Как мы узнаем степень выполнения работ по тому или иному требованию?

    Более того, мне интересно, как мы можем указать в WIKI атрибуты требований, например, источник требований и приоритет.

    Приоритеты требований мы не ставим в Wiki, мы ставим приоритеты таскам в жире. Также мы составляем продукт бэклог на итерацию, и на каждую запись цепляем таски из джиры. По окончанию итерации смотрим, как этот беклог выполнился.

    По поводу источника требований: у нас собственный продукт и два эксперта: один в сфере бизнеса, другой в сфере UI. Поэтому для нас это наверное не актуально)

    Поделиться:

    Цитировать

Показано 5 ответов - от 16 до 20 (всего 20)

Вы должны авторизироваться для ответа в этой теме.