Настраиваем процессы внутри компании. В качестве issue tracking выбрали Jira(до этого использовали Trac, но сейчас его возможностей уже не хватает). В результате анализа текущих проблем в компании выяснили, что у нас провал по работе с требованиями. Сбор требований, их анализ и формализация. Поэтому при планировании нового процесса я сделал акцент именно на этом. Процесс описывает реализации новой функциональности по запросу клиента от момента получения клиентского запроса. Речь идет о функциональности, реализация которой потребует от нескольких недель до нескольких месяцев, т.е. варианты "а поменяйте мне цвет этой кнопочки на розовый" не рассматриваются.
По результатам получилось следующее:
Выделены следующие стадии:
1. Сбор требований.
2. Анализ и формализация требований.
3. Формирование спецификаций.
4-... Планирование и разработка.
В ходе этих трех стадий формируются следующие документы:
1. Customer requirements (разношерстные требования клиента в произвольной форме)
2. Functional requirements (список функций/сервисов системы которая она должна предоставлять + приоритеты)
3. Use cases
4. Business rules
5. GUI requirements
Теперь встал вопрос как лучше оформить это в Jira и имеет ли смысл это делать вообще. Пока я вижу два варианта:
1. Оформить каждый документ, как компонент и создавать задачи по выполнению которых будут формироваться документы(делаться компоненты).
2. Оставить компоненты в стороне и описать создание каждого документа как задачу и задачи связанные с работой над этим документом описывать как subtasks.
Я бы создал сначала отдельный проект в Jira, назвав его, скажем, Requirements, завел в нем соответствующие компоненты и создавал таски по этим компонентам.
И заводил бы тикеты в Development проекте на их основе, линкуя их к таскам в Requirements.
Здравствуйте, MaximVK, Вы писали:
MVK>Выделены следующие стадии: MVK>1. Сбор требований. MVK>2. Анализ и формализация требований. MVK>3. Формирование спецификаций. MVK>4-... Планирование и разработка.
MVK>В ходе этих трех стадий формируются следующие документы: MVK>1. Customer requirements (разношерстные требования клиента в произвольной форме) MVK>2. Functional requirements (список функций/сервисов системы которая она должна предоставлять + приоритеты) MVK>3. Use cases MVK>4. Business rules MVK>5. GUI requirements
MVK>Теперь встал вопрос как лучше оформить это в Jira и имеет ли смысл это делать вообще. Пока я вижу два варианта: MVK>1. Оформить каждый документ, как компонент и создавать задачи по выполнению которых будут формироваться документы(делаться компоненты). MVK>2. Оставить компоненты в стороне и описать создание каждого документа как задачу и задачи связанные с работой над этим документом описывать как subtasks.
1. Зачем вам так много документов? Достаточно вполне иметь (если это нужно) "первичку" от пользователей, которую по большому счету и требованиями сложно назвать. Это needs/requests скорее всего. На основании которых и будут собственно разработаны требования. В пределе для полного описания требований вам будет достаточно документа Vision (где в частности будут жить то, что вы называете "Functional requirements", хотя это уже имеет свое название -- Features). И SRS, в котором вы можете включить как уровень пользовательских требований (это не запрещено, если только вы не связаны контрактом с жестким форматом документов) в виде use cases, таки и собственно детализированные функциональные и нефункциональные требования (Business rules и прочия). Хотя, возможно, под этими терминами вы понимаете несколько другое, чем я.
2. В случае если мы создаем систему, эти документы разрабатываются с нуля. В случае развития/модификации системы -- просто нужно иметь актуальные версии требований для котнкретной версий вашей системы, и если позволяет инструментальное средство генерировать эти документы "на лету", то и актуальные версии документов. Которые, например, ложаться в систему версионного контроля вместе с исходниками релиза.
3. С точки зрения разработки и управления требованиями к ПО, Jira может помочь в большей степени как источник тех самых изменений, которые после утверждения, должны быть внесены в требования (в их классическом виде), чем собственно инструмент в котором требования будут физически размещаться. Хотя, есть подход, и в ряде случаев он вполне оправдан, при использовании практик XP, когда все что мы имеем, из того что можно назвать требованиями -- это user stories. Тогда вполне себе они могут быть размещены в Jira и от них будут отпочковываться детализированные задачи на разработку, с пояснениями и т.п. Таким образом можно будет собрать воедино картину требований для конкретного релиза. Повторюсь, чьо это хорошо для "слабоформализованных" проектов или проектов типа "fire and forget", маленьких проектов, или же для проектов по "неспешному" развитию системы где не важно иметь формализованную документацию.
Здравствуйте, MaximVK, Вы писали:
MVK>Теперь встал вопрос как лучше оформить это в Jira и имеет ли смысл это делать вообще. Пока я вижу два варианта: MVK>1. Оформить каждый документ, как компонент и создавать задачи по выполнению которых будут формироваться документы(делаться компоненты). MVK>2. Оставить компоненты в стороне и описать создание каждого документа как задачу и задачи связанные с работой над этим документом описывать как subtasks.
Думаю, что Jira не совсем подходит для хранения требований т.к.
1) Workflow в Jira все-таки очень привязан к bug tracking, поменять там что-то можно, но от основы далеко не уйдешь.
2) Jira не очень заточена для работы с большим количеством компонентов. Если их там будет сотня или две — как Вы их искать будете ? Уверены, что оно не будет тормозить ?
3) Subtasks — тоже не решение,они в Jira не могут быть вложенными (что для управления требованиями важно), из задачи нельзя сделать подзадачу (и наоборот). Вот захотите какое-нибудь требование детализировать — что тогда ?
Думаю, стоит смотреть в сторону специализированных систем для управления требованиями, или, наоборот, generic issue tracking systems (из старых — ClearQuest, TeamTrack, из новых — TrackStudio).
Здравствуйте, MaximVK, Вы писали:
MVK>Буду признателен за любые советы и комментарии.
Для начала вы попробуйте написать хорошие требования в самом
обычном текстовом редакторе (MS Word или что вы там используете).
Проблему автоматизации процесса управления требований
лучше решать тогда, когда вы научитесь писать сами требования.
Не перееоценивайте роль тулов...
Здравствуйте, Gareth, Вы писали:
G>Я бы создал сначала отдельный проект в Jira, назвав его, скажем, Requirements, завел в нем соответствующие компоненты и создавал таски по этим компонентам. G>И заводил бы тикеты в Development проекте на их основе, линкуя их к таскам в Requirements.
Я не думаю, что это правильно создавать проект. Т.к. будет мешанина проектов. Параллельно идет несколько проектов, а так к этим проектам появиться еще несколько с такими же названиями + слово Requirements.
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, MaximVK, Вы писали:
MVK>>В качестве issue tracking выбрали Jira(до этого использовали Trac, но сейчас его возможностей уже не хватает).
N>Извините, что не в тему, но можете рассказать про Trac — точнее, чего в нем не хватает? N>Хорошо знаю JIRA, но почти не знаком с Trac.
— Слабый issue workflow и невозможность описать свой.
— Time tracking только через плагины, но несколько корявые
— Невозможность создавать подзадачи
— Плохо с аттачментами файлов
Видимо я ввел своим постом в заблуждение. Я не в коей мере не рассматриваю Jira как средство управления/хранения требований. Более того, я твердо убежден, что если процесс не работает с ручкой и бумагой, то никакие средства не помогут. Все описанные мной документы — это обычные word-овые файлы.
Вопрос у меня возник с другим. Как с точки зрения task management-а управлять/контролировать процесс работы на требованиями(первые три описанных мной этапа). И как в этом деле удобней использовать Jira.
Здравствуйте, maximkr, Вы писали:
M>Думаю, что Jira не совсем подходит для хранения требований т.к. M>1) Workflow в Jira все-таки очень привязан к bug tracking, поменять там что-то можно, но от основы далеко не уйдешь.
Найн. Джира позволяет определять совершенно произвольный workflow, любое их количество и в любой комбинации смешивать их в проектах. Поменять там можно все, и это никак не привязано к bug tracking.
M>2) Jira не очень заточена для работы с большим количеством компонентов. Если их там будет сотня или две — как Вы их искать будете ? Уверены, что оно не будет тормозить ?
Тормозить не будет. Но, действительно, будет неудобно. Только фокус в том, что Jira позволяет вводить custom fields для записей, что позволяет вводить произвольное количество аналитических признаков, и работать с ними будет удобно. Компоненты — не единственный и не лучший способ.
M>3) Subtasks — тоже не решение,они в Jira не могут быть вложенными (что для управления требованиями важно), из задачи нельзя сделать подзадачу (и наоборот). Вот захотите какое-нибудь требование детализировать — что тогда ?
Тогда надо использовать linked tasks. На которые не накладывается никаких ограничений.
M>Думаю, стоит смотреть в сторону специализированных систем для управления требованиями, или, наоборот, generic issue tracking systems (из старых — ClearQuest, TeamTrack, из новых — TrackStudio).
Они менее гибки и не так хорошо поддаются кастомизации, как JIRA. Как это не странно .
Здравствуйте, Gareth, Вы писали:
G>Здравствуйте, MaximVK,
G>Я бы создал сначала отдельный проект в Jira, назвав его, скажем, Requirements, завел в нем соответствующие компоненты и создавал таски по этим компонентам.
А зачем отдельный проект создавать? Можно просто ввести новый тип таска — requirement. Навесить на него свой workflow и свои поля, и вперед.
G>И заводил бы тикеты в Development проекте на их основе, линкуя их к таскам в Requirements.
Угумс. Именно так.
Здравствуйте, byur, Вы писали:
B>1. Зачем вам так много документов?
Меня тоже смущает количество документов и в описании процесса я оговариваю тот факт, что перечислены возможные типы документов. Для каждого документа определена степень его желательности и описаны риски, которые могут возникнуть в связи с его отсутствием.
B>Достаточно вполне иметь (если это нужно) "первичку" от пользователей, которую по большому счету и требованиями сложно назвать. Это needs/requests скорее всего. На основании которых и будут собственно разработаны требования.
За это отвечает документ Customer requirements. Это описание того, что хочет клиент в произвольной форме вплоть до сканов салфеток. Т.е. эти требования не формализованы. Если термин customer requirements подразумевает нечто иное, то лучше, конечно, его заменить.
B>В пределе для полного описания требований вам будет достаточно документа Vision (где в частности будут жить то, что вы называете "Functional requirements", хотя это уже имеет свое название -- Features). И SRS, в котором вы можете включить как уровень пользовательских требований (это не запрещено, если только вы не связаны контрактом с жестким форматом документов) в виде use cases, таки и собственно детализированные функциональные и нефункциональные требования (Business rules и прочия). Хотя, возможно, под этими терминами вы понимаете несколько другое, чем я.
Да, есть небольшая путаница в терминологии. Надо будет восполнить пробел. Собственно говоря, весь комплект приведенных мной документов укладывается в SRS (за исключением документа называемого customer requirements). У меня оформляется в разных документах — не могу сказать, хорошо это или плохо.
B>3. С точки зрения разработки и управления требованиями к ПО, Jira может помочь в большей степени как источник тех самых изменений, которые после утверждения, должны быть внесены в требования (в их классическом виде), чем собственно инструмент в котором требования будут физически размещаться. Хотя, есть подход, и в ряде случаев он вполне оправдан, при использовании практик XP, когда все что мы имеем, из того что можно назвать требованиями -- это user stories. Тогда вполне себе они могут быть размещены в Jira и от них будут отпочковываться детализированные задачи на разработку, с пояснениями и т.п. Таким образом можно будет собрать воедино картину требований для конкретного релиза. Повторюсь, чьо это хорошо для "слабоформализованных" проектов или проектов типа "fire and forget", маленьких проектов, или же для проектов по "неспешному" развитию системы где не важно иметь формализованную документацию.
Собственно говоря, я и не планирую использовать Jira как инструмент для управления требованиями. Jira используется лишь как issue management system. Т.е. в jira может появиться, например, задача "Описать такой-то use case". И по выполнению задачи в jira произдойдет только изменения статуса задачи и ничего больше. А сам use case документ будет лежать в каком-нить вордовом документе или вообще будет написан на бумажке от руки.
Здравствуйте, Gaperton, Вы писали:
M>>Думаю, что Jira не совсем подходит для хранения требований т.к. M>>1) Workflow в Jira все-таки очень привязан к bug tracking, поменять там что-то можно, но от основы далеко не уйдешь. G>Найн. Джира позволяет определять совершенно произвольный workflow, любое их количество и в любой комбинации смешивать их в проектах. Поменять там можно все, и это никак не привязано к bug tracking.
Workflow-то настроить можно, только толку от этого будет не очень много,т.к. на свои переходы нельзя повесить (насколько я понял) ни e-mail notification, ни задать permission. Т.е. jira знает про event "Issue Resolved", про permission "Resolve Issue", есть отчет "resolution time report", но вот трекать в системе наем людей (у них принципиально нет состояния resolved) не получится — я не могу указать что только менеджер может делать переход Hire и Fire и кому в этом случае отправлять notification-ы.
Если нужны сложные обработки запросов от пользователей (задача должна быть про-approve-лена 2 людьми в любом порядке прежде чем мы начинаем ее писать) — опять в морг, нет там permission "Approve Issue".
Отдельный момент — Workflow может быть только у задач, но не может быть у категорий или проектов (например, new, development, production, retired, closed). Соответственно оформить requirement компонентом можно, только потом ни кастом-поля к нему добавить нельзя, ни состояние сменить.
M>>2) Jira не очень заточена для работы с большим количеством компонентов. Если их там будет сотня или две — как Вы их искать будете ? Уверены, что оно не будет тормозить ? G>Тормозить не будет. Но, действительно, будет неудобно. Только фокус в том, что Jira позволяет вводить custom fields для записей, что позволяет вводить произвольное количество аналитических признаков, и работать с ними будет удобно. Компоненты — не единственный и не лучший способ.
Да, я отреагировал на предложение хранить requirement в виде компонентов. Это плохая идея, согласен.
M>>3) Subtasks — тоже не решение,они в Jira не могут быть вложенными (что для управления требованиями важно), из задачи нельзя сделать подзадачу (и наоборот). Вот захотите какое-нибудь требование детализировать — что тогда ? G>Тогда надо использовать linked tasks. На которые не накладывается никаких ограничений.
В иерархии главное — это что ее смотреть можно на любое количество уровней вглубь. Если использовать связи, то найти все что относится к данному требованию (т.е. задачи, которые ссылаются на данную и все что ссылается на них рекурсивно) будет проблематично. Ну т.е. связи между задачами почти никогда не заменяют иерархии, это для другого.
M>>Думаю, стоит смотреть в сторону специализированных систем для управления требованиями, или, наоборот, generic issue tracking systems (из старых — ClearQuest, TeamTrack, из новых — TrackStudio).
G>Они менее гибки и не так хорошо поддаются кастомизации, как JIRA. Как это не странно .
Ну, может быть они сложнее/дороже (а потому и менее популярны), но любая из этих систем на порядок лучше поддается кастомизации чем Jira, вот честное слово. Jira никогда и не стремилась быть особенно кастомизябельной, все улучшения в этом направлении делались после многолетних пинаний пользователей. В качестве доказательства — цитата от разработчиков:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=3388&tstart=0
====
There are many cases where it would be useful to have issue-level
concepts (type, lifecycle, priority, due date, scheduling, custom fields)
apply to projects, and project-level concepts (permissions,
notifications, URLs) apply to issues. Effectively treating projects as
aggregate issues.
JIRA will evolve to greater levels of generality as users request it.
You might want to file an enhancement request for project-level custom
fields on jira.atlassian.com.
In general, JIRA needs to keep a balance between simplicity for 80% who
don't need advanced features, and generality for the 20% who do. Giving
users the source (or just JSP source, as illustrated above) lets us err
on the side of simplicity.
====
Здравствуйте, maximkr, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
M>>>Думаю, что Jira не совсем подходит для хранения требований т.к. M>>>1) Workflow в Jira все-таки очень привязан к bug tracking, поменять там что-то можно, но от основы далеко не уйдешь. G>>Найн. Джира позволяет определять совершенно произвольный workflow, любое их количество и в любой комбинации смешивать их в проектах. Поменять там можно все, и это никак не привязано к bug tracking.
M>Workflow-то настроить можно, только толку от этого будет не очень много,т.к. на свои переходы нельзя повесить (насколько я понял) ни e-mail notification, ни задать permission.
Это все можно делать. У нас так сделано и работает. Вы можете вообще создать задачи и флоу с чистго листа, и все перечисленное будет работать.
M>Т.е. jira знает про event "Issue Resolved", про permission "Resolve Issue", есть отчет "resolution time report", но вот трекать в системе наем людей (у них принципиально нет состояния resolved) не получится — я не могу указать что только менеджер может делать переход Hire и Fire и кому в этом случае отправлять notification-ы.
Мы применяем JIRA для трекинга найма людей и кадрового учета. У них есть состояние resolved — когда вы увольняете человека, он уходит сам, или вы отказываете кандидату. Вы, разумеется, можете указать, кто именно может выполнять каждый отдельный переход — то настраивается. У нас — настроено.
M>Если нужны сложные обработки запросов от пользователей (задача должна быть про-approve-лена 2 людьми в любом порядке прежде чем мы начинаем ее писать) — опять в морг, нет там permission "Approve Issue".
Задачи апрувала вешаете сабтасками задачи, переход не осуществляете, пока подтаски не закрыты. Все. Это можно делать административно — у проверки всегда есть модератор, который выбирает этих людей.
M>Отдельный момент — Workflow может быть только у задач, но не может быть у категорий или проектов (например, new, development, production, retired, closed). Соответственно оформить requirement компонентом можно, только потом ни кастом-поля к нему добавить нельзя, ни состояние сменить.
Рекваремент надо оформлять задачей, разумеется.
M>>>3) Subtasks — тоже не решение,они в Jira не могут быть вложенными (что для управления требованиями важно), из задачи нельзя сделать подзадачу (и наоборот). Вот захотите какое-нибудь требование детализировать — что тогда ? G>>Тогда надо использовать linked tasks. На которые не накладывается никаких ограничений.
M>В иерархии главное — это что ее смотреть можно на любое количество уровней вглубь. Если использовать связи, то найти все что относится к данному требованию (т.е. задачи, которые ссылаются на данную и все что ссылается на них рекурсивно) будет проблематично. Ну т.е. связи между задачами почти никогда не заменяют иерархии, это для другого.
Любопытно. Спрошу у наших.
M>>>Думаю, стоит смотреть в сторону специализированных систем для управления требованиями, или, наоборот, generic issue tracking systems (из старых — ClearQuest, TeamTrack, из новых — TrackStudio).
G>>Они менее гибки и не так хорошо поддаются кастомизации, как JIRA. Как это не странно .
M>Ну, может быть они сложнее/дороже (а потому и менее популярны), но любая из этих систем на порядок лучше поддается кастомизации чем Jira, вот честное слово. Jira никогда и не стремилась быть особенно кастомизябельной, все улучшения в этом направлении делались после многолетних пинаний пользователей. В качестве доказательства — цитата от разработчиков:
Возможно. Но для нас возможностей и гибкости JIRA хватает. Нам нравится
Здравствуйте, MaximVK, Вы писали:
MVK>Вопрос у меня возник с другим. Как с точки зрения task management-а управлять/контролировать процесс работы на требованиями(первые три описанных мной этапа). И как в этом деле удобней использовать Jira.
В таком ракрусе, возможно вполне достаточно будет заводить таски a-la "разрбаотать такой-то документ" или внести изменения и т.п ...
G>Задачи апрувала вешаете сабтасками задачи, переход не осуществляете, пока подтаски не закрыты. Все. Это можно делать административно — у проверки G>всегда есть модератор, который выбирает этих людей.
Интересно. А я думал сделать через workflow.
G>Рекваремент надо оформлять задачей, разумеется.
Т.е. все requirements оформляются ввиде задач? Но если requirement уже записан и формализован, то что можно с ним еще делать(ну разве приоритет еще ему поставить)? А если не формализован, а должен быть выделен из запроса клиента, то получается просто задача "Проанализировать клиентский запрос и выделить формализованные требования.". Я что-то не понимаю?
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, Gaperton, Вы писали:
G>>Задачи апрувала вешаете сабтасками задачи, переход не осуществляете, пока подтаски не закрыты. Все. Это можно делать административно — у проверки G>всегда есть модератор, который выбирает этих людей. MVK>Интересно. А я думал сделать через workflow.
Лучше сабтасками, как у нас. В том случае у вас есть гибкость.
1) Вы можете назначать сколько угодно проверяющих, в т.ч. имеете возможность вообще пропустить проверку, не назначив ни одного.
2) на сабтаски вы вешаете собственный workflow — это удобно.
3) Вы, таким образом, отслеживаете активности и по проверке, и по задаче. Проверяющие узнают, что им надо проверить, когда на них задача заассайнится.
G>>Рекваремент надо оформлять задачей, разумеется.
MVK>Т.е. все requirements оформляются ввиде задач? Но если requirement уже записан и формализован, то что можно с ним еще делать(ну разве приоритет еще ему поставить)?
Приоритет выставить, разумеется. Привязать к нему связанные задачи и материалы.
MVK>А если не формализован, а должен быть выделен из запроса клиента, то получается просто задача "Проанализировать клиентский запрос и выделить формализованные требования.". Я что-то не понимаю?
Да, примерно так. Один из популярных вариантов такой. По результатам запроса клента создается "feature request", "defect", или "suggestion". Далее — переход из состояния requirement в task регламентируется workflow — на начальных состояниях это требование, а на конечных — уже задание для разработчика. Задание в процессе движения по workflow меняет нескольких assignee.
Garrrrr говорит мне, что разработал workflow для JIRA для управления требованиями вообще — не на основе внешних запросов. Но я пока не смотрел.
Здравствуйте, Gaperton, Вы писали:
G>>Я бы создал сначала отдельный проект в Jira, назвав его, скажем, Requirements, завел в нем соответствующие компоненты и создавал таски по этим компонентам. G>А зачем отдельный проект создавать? Можно просто ввести новый тип таска — requirement. Навесить на него свой workflow и свои поля, и вперед.
Использовать централизованный проект удобно, когда, скажем, на основе одних и тех же requirements девелопятся несколько клиентских приложений.
.
