Комментарии 7
Спасибо за статью.
А можно пример таблицы онлайн посмотреть?
Спасибо!
А можно пример таблицы онлайн посмотреть?
Спасибо!
Да, конечно, вот здесь можно посмотреть и даже потыкаться (все данные даны для примера).
Раньше тоже использовал Excel. затем перешел на Jira. На мой взгляд, это самый удобный способ вести требования и если указывать в задачах на разработку ссылку на требование, автоматически достигается трассируемость.
Jira требует регистрации в ней пользователя (например, бизнес заказчик не имеет к ней доступа, ему это и не нужно), т.е. её содержимое доступно не всем, к тому же она стоит денег и явно не подходит под описание «простой способ» :)
Но и, конечно, преимуществ в ней огромное множество. Думаю, тут нужно ориентироваться на собственный комфорт и возможности. Первоначальные требования я собираю вот в такой документ (который доступен и заказчику тоже), а уже полноценные требования можно формировать в задачах в Jira (ну либо в отдельном ТЗ, на пункты которого можно ссылаться в задачах).
Но и, конечно, преимуществ в ней огромное множество. Думаю, тут нужно ориентироваться на собственный комфорт и возможности. Первоначальные требования я собираю вот в такой документ (который доступен и заказчику тоже), а уже полноценные требования можно формировать в задачах в Jira (ну либо в отдельном ТЗ, на пункты которого можно ссылаться в задачах).
Если можно, расскажите немного подробнее, как Вы это делаете в Jira.
Мой ответ на ваш вопрос попал в электромагнитную аномалию, и задержался в пути. Поэтому не знаю, актуален ли он еще :)
Тем не менее, расскажу. Процесс был примерно таким:
1. Для требований был заведен отдельный проект с суффиксом REQ (предложение команды сделать префикс ANAL я отмел, по понятным причинам). То есть название было типа XSTARTUPREQ.
2. Для задач по разработке был заведен отдельный проект с суффиксом DEV — соответственно, XSTARTUPDEV
3. Требования заводились в XSTARTUPREQ, детализировались на аналитические подзадачи, проходили по своему аналитическому воркфлоу и в конце пути появлялся комментарий с гиперссылкой на статью в Wiki, где хранился, вкусный и читаемый документ, описывающий фичу или даже новый аспект системы
4. После этого требование переводилось в состояние «Передано в разработку», а в проекте XSTARTUPDEV появлялась одна или несколько корневых задач, которые при необходимости детализировались до подзадач. Эти задачи жили уже по воркфлоу.
5. У требований и задач разработки обязательно заполнялся атрибут «релиз» который принимал значения «0.1», 0.5 MVP", «1.0 DEMO», «1.0.1», «1.0.2», «1.5.0» и так далее и отдельно «Бэклог», который в моем случае имел значение «Долгий ящик». Если я поддерживал список задач в актуальном состоянии, я всегда видел в каком статусе находится мой текущий релиз в части аналитических задач и в каком — в части девелоперских.
Все это можно сделать и в одном проекте, я так тоже пробовал. Но есть нюансы в отслеживании задач. С одним проектом удобнее увязывать задачи между собой (достаточно ввести номер), но мне лично было менее удобно отслеживать разные по типу активностей задачи. Поэтому победила в итоге схема с двумя проектами.
Реальные названия были не XSTARTUPREQ и XSTARTUPDEV, а покороче. Вообще название проекта в Джире нужно задавать не больше 8 знаков на мой взгляд. А лучше 5-6.
Тем не менее, расскажу. Процесс был примерно таким:
1. Для требований был заведен отдельный проект с суффиксом REQ (предложение команды сделать префикс ANAL я отмел, по понятным причинам). То есть название было типа XSTARTUPREQ.
2. Для задач по разработке был заведен отдельный проект с суффиксом DEV — соответственно, XSTARTUPDEV
3. Требования заводились в XSTARTUPREQ, детализировались на аналитические подзадачи, проходили по своему аналитическому воркфлоу и в конце пути появлялся комментарий с гиперссылкой на статью в Wiki, где хранился, вкусный и читаемый документ, описывающий фичу или даже новый аспект системы
4. После этого требование переводилось в состояние «Передано в разработку», а в проекте XSTARTUPDEV появлялась одна или несколько корневых задач, которые при необходимости детализировались до подзадач. Эти задачи жили уже по воркфлоу.
5. У требований и задач разработки обязательно заполнялся атрибут «релиз» который принимал значения «0.1», 0.5 MVP", «1.0 DEMO», «1.0.1», «1.0.2», «1.5.0» и так далее и отдельно «Бэклог», который в моем случае имел значение «Долгий ящик». Если я поддерживал список задач в актуальном состоянии, я всегда видел в каком статусе находится мой текущий релиз в части аналитических задач и в каком — в части девелоперских.
Все это можно сделать и в одном проекте, я так тоже пробовал. Но есть нюансы в отслеживании задач. С одним проектом удобнее увязывать задачи между собой (достаточно ввести номер), но мне лично было менее удобно отслеживать разные по типу активностей задачи. Поэтому победила в итоге схема с двумя проектами.
Реальные названия были не XSTARTUPREQ и XSTARTUPDEV, а покороче. Вообще название проекта в Джире нужно задавать не больше 8 знаков на мой взгляд. А лучше 5-6.
Это, наверное, вопрос к PavelSandovin?
Что касается проектов, в которых работаю я, то в части ведения требований в джире основная задача, чтобы описание требования было полное и понятное разработчику — будь то ссылка на ТЗ (или пункт в нём) или описание непосредственно в задаче (на разных проектах это происходит по-разному).
Задами должны быть покрыты все требования. Соблюдены связи родительское-дочернее требование. Если разработчику требуется разъяснение по задаче, он должен понимать, у кого он может их получить, соответственно, задача, где возник вопрос, ставится на этого человека. В каких-то случаях получение разъяснений через общение (задача ни на кого не переназначается тогда), но окончательное решение должно быть кем-то обязательно зафиксировано.
Что касается проектов, в которых работаю я, то в части ведения требований в джире основная задача, чтобы описание требования было полное и понятное разработчику — будь то ссылка на ТЗ (или пункт в нём) или описание непосредственно в задаче (на разных проектах это происходит по-разному).
Задами должны быть покрыты все требования. Соблюдены связи родительское-дочернее требование. Если разработчику требуется разъяснение по задаче, он должен понимать, у кого он может их получить, соответственно, задача, где возник вопрос, ставится на этого человека. В каких-то случаях получение разъяснений через общение (задача ни на кого не переназначается тогда), но окончательное решение должно быть кем-то обязательно зафиксировано.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой способ организовать требования на этапе сбора требований (или первый шаг к формированию уютного бэклога)