Comments 12
В своё время доводилось работать в проекте с очень похожим workflow работы с требованиям, в принципе действительно удобно. Использовали для хранения требований confluence, с ним тоже проблем не было.
А что вы скажите о детализации требований в виде формального описания «примеров», например в терминах given/when/then (gherkin к примеру)? Ибо в большинстве случаев вот эти партянки табличек никто читать не хочет. И если девелоперам это приходится делать, то клиенты в большинстве случаев делают это… не достаточно серьезно. Во всяком случае я наблюдаю эту проблему в сфере аутсорса, где со стороны клиента как правило не самое заинтересованное лицо.
От себя же хочу заметить, что очень часто начинающие бизнес аналитики при декомпозиции задачи частенько операются на UI. В итоге о некоторых «фичах» я лично узнавал из приемочных критериев к другим фичам. Вообще как-то редко доводилось видеть православные юз кейсы, в которых только то что важно (бизнес логика) и ни намека на UI. Как с этим быть? Как людям это объяснить?
От себя же хочу заметить, что очень часто начинающие бизнес аналитики при декомпозиции задачи частенько операются на UI. В итоге о некоторых «фичах» я лично узнавал из приемочных критериев к другим фичам. Вообще как-то редко доводилось видеть православные юз кейсы, в которых только то что важно (бизнес логика) и ни намека на UI. Как с этим быть? Как людям это объяснить?
Пробовал на одном проекте использовать gherkin (cucumber если точнее), в принципе всё достаточно неплохо получалось (даже прикрутили i18n для написания юз. кейсов на русском), но в итоге всё это поддерживать оказалось слишком сложно из-за быстрого увеличения кол-ва требований. Хотя возможно просто дело было в недостаточной организации процесса.
Из плюсов могу сказать, что с помощью cucumber действительно очень круто получалось делать интеграционные тесты прямо из требований, очень понравилось.
Из плюсов могу сказать, что с помощью cucumber действительно очень круто получалось делать интеграционные тесты прямо из требований, очень понравилось.
Если честно, впервые прочитала о gherkin из вашего комментария. Выглядит круто, но при первом обращении смущает, как будут при таком оформлении выглядеть альтернативные сценарии (если таких накопится достаточно много). При оформлении в формате юзкейсов к каждому шагу основного сценария можно расписать альтернативный сценарий(ии), и выглядит это всё достаточно гармонично и легко читается.
Хотя, как мне кажется, многое зависит здесь от привычки и особенностей восприятия каждого. В общем, надо пробовать:) За наводку спасибо — поинтересуюсь у разработчиков о том, как им такой формат оформления.
Что касается чтения клиентами, то «недостаточно серьёзно» — распространённая проблема, и, думаю, дело здесь не только в том, как оформлены требования (хотя это, конечно, тоже имеет существенное значение).
Для начала нужно убедиться, что писателя 1.есть понимание, что документ с требованиями в рамках описания того, «как это должно работать», может решать разные задачи и давать ответы на разные вопросы — в зависимости от того, какие инструменты использовать; 2. есть понимание, какую задачу должен выполнять конкретный описываемый документ; 3. есть понимание, какой инструмент поможет справится с этой задачей качественнее. А далее — учиться применять нужный инструмент, оттачивать это умение.
Но понимание не приходит из ниоткуда — либо это опыт, либо информация извне. Если речь идёт о начинающих бизнес аналитиках (хотя я всё-таки склоняюсь, что в данном контексте речь идёт о системных аналитиках), то значит нужно разговаривать. Нужно заявлять о том, что вам нужно, и в каком виде хотелось бы это получить. Это моё мнение. Я в своей работе сталкиваюсь с обратными явлениями: время от времени пытаюсь получить фидбек от разработчиков по тому, что и как им комфортнее усваивать информацию, но получить какие-то внятные пожелания не всегда удаётся к сожалению)
Хотя, как мне кажется, многое зависит здесь от привычки и особенностей восприятия каждого. В общем, надо пробовать:) За наводку спасибо — поинтересуюсь у разработчиков о том, как им такой формат оформления.
Что касается чтения клиентами, то «недостаточно серьёзно» — распространённая проблема, и, думаю, дело здесь не только в том, как оформлены требования (хотя это, конечно, тоже имеет существенное значение).
Для начала нужно убедиться, что писателя 1.есть понимание, что документ с требованиями в рамках описания того, «как это должно работать», может решать разные задачи и давать ответы на разные вопросы — в зависимости от того, какие инструменты использовать; 2. есть понимание, какую задачу должен выполнять конкретный описываемый документ; 3. есть понимание, какой инструмент поможет справится с этой задачей качественнее. А далее — учиться применять нужный инструмент, оттачивать это умение.
Но понимание не приходит из ниоткуда — либо это опыт, либо информация извне. Если речь идёт о начинающих бизнес аналитиках (хотя я всё-таки склоняюсь, что в данном контексте речь идёт о системных аналитиках), то значит нужно разговаривать. Нужно заявлять о том, что вам нужно, и в каком виде хотелось бы это получить. Это моё мнение. Я в своей работе сталкиваюсь с обратными явлениями: время от времени пытаюсь получить фидбек от разработчиков по тому, что и как им комфортнее усваивать информацию, но получить какие-то внятные пожелания не всегда удаётся к сожалению)
Вся прелесть gherkin в том, что фичаспеки формируются по сути в формате дискуссии. Например мы описали основную выжимку юзкейса (что это, какую ценность несет и кому) и далее начинаем приводить примеры как это должно работать. Заинтересованное лицо может прочитать эти примеры и сказать «а что будет если у нас будет то-то то-то», и по итогу либо запишет сценарий, который нужно дополнить, либо опишет свое предлоложение о том как это все должно работать.
Прелесть тут в том, что это легко читается и можно сформировать представление о том зачем нужна фича и как она должна работать. Оптимизация цикла обратной связи.
Для разработчиков в этом есть отдельный профит, поскольку все эти примеры формируют приемочные тесты, и есть почти для каждой платформы тулза которая умеет по ним прогонять тесты (cucumber, specflow, behat и т.д.). То есть мы можем уже риски потихоньку снижать и практиковать ATDD и т.д. По сути это значит что тесты пишутся с точки зрения бизнеса, что несомненно важно. Все же девелоперы довольно часто отвратительно формализуют/переваривают требования (как правило потому что голова забита не важной технической ерундой) и плохо пишут тесты.
Прелесть тут в том, что это легко читается и можно сформировать представление о том зачем нужна фича и как она должна работать. Оптимизация цикла обратной связи.
Для разработчиков в этом есть отдельный профит, поскольку все эти примеры формируют приемочные тесты, и есть почти для каждой платформы тулза которая умеет по ним прогонять тесты (cucumber, specflow, behat и т.д.). То есть мы можем уже риски потихоньку снижать и практиковать ATDD и т.д. По сути это значит что тесты пишутся с точки зрения бизнеса, что несомненно важно. Все же девелоперы довольно часто отвратительно формализуют/переваривают требования (как правило потому что голова забита не важной технической ерундой) и плохо пишут тесты.
Сергей, а приводить примеры — прям там же, в тексте описания?
А системные сценарии как вписываются? Ну, например, в зависимости от того, какой радиобаттон выбрал пользователь, мы обращаемся или в БД, или отправляем запрос в стороннюю систему, это будет прописано прямо в самом сценарии? Или здесь только пользовательские сценарии?
А системные сценарии как вписываются? Ну, например, в зависимости от того, какой радиобаттон выбрал пользователь, мы обращаемся или в БД, или отправляем запрос в стороннюю систему, это будет прописано прямо в самом сценарии? Или здесь только пользовательские сценарии?
Простите, а вы вот это с радиобаттанами и базой данных прямо в юзкейсе описываете? Так это ж плохие юзкейсы тогда.
Да, там только описание работы фичи, без привязки к деталям реализации. Если хотите, можете отдельно еще в UML порисовать но это уже зависит от того, делаются ли такие штуки.
К примеру у меня — апишки. То есть радиобаттонов нет. И база данных — это мне решать как что хранить, бизнес аналитик может предоставить мне список сущностей и нарисовать как они взаимодействуют, но база данных это деталь реализации.
Рекомендую почитать: http://stakeholderwhisperer.com/posts/2014/10/introducing-modelling-by-example
Да, там только описание работы фичи, без привязки к деталям реализации. Если хотите, можете отдельно еще в UML порисовать но это уже зависит от того, делаются ли такие штуки.
К примеру у меня — апишки. То есть радиобаттонов нет. И база данных — это мне решать как что хранить, бизнес аналитик может предоставить мне список сущностей и нарисовать как они взаимодействуют, но база данных это деталь реализации.
Рекомендую почитать: http://stakeholderwhisperer.com/posts/2014/10/introducing-modelling-by-example
Коллеги, всё здорово, но кодировать версионность через дату лучше всё-таки не через ДДММГГ, а наоборот — ГГММДД. Сортировка и положение в списках записей будут корректными.
Второй маленький вопросик — а если в одну дату несколько записей с одним и тем же кодом? Может такой быть? Не вызывает путаницы?
Второй маленький вопросик — а если в одну дату несколько записей с одним и тем же кодом? Может такой быть? Не вызывает путаницы?
Sign up to leave a comment.
Организация функциональных требований на крупном проекте