В целом, был кейс, когда опубликовали дедлайн по переходу на новую версию. Мы попросили через нашего продакта, чтобы ВБ сдвинули дату. У нас получилось. Вывод такой: до них можно достучаться. Можно пробовать.
Спасибо за ваш комментарий. Что вы имеете ввиду под сценариями в виде блок-схем? Если вы про usecases, то они у нас прописаны в документации на фронт. Писала про это в статье: https://habr.com/ru/company/ru_mts/blog/686570/ А для микросервисов достаточно того, что описано в статье. По крайней мере доп.запросов не было еще.
У нас именно так. Как правило, когда аналитик передает такую доку в разработку, то она считается очень хорошо проработанной, поэтому меняется очень мало. Но если меняется, то да, разработчик просит аналитика актуализировать.
Очень интересно. Спасибо большое за рекомендации. У нас в стриме как-то не прижился, к сожалению, OpenAPI. Но, возможно, стоит пересмотреть отношение к этому формату
Спасибо за пояснение. Да, это было бы удобно в случае, если аналитик может базово кодить или разработчик сам проектирует API. Время до выпуска апи на тест сократилось бы.
По нашим процессам - это ТЗ для разработчика, он смотрит на доку и пишет код. А вы предлагаете заносить эту инфу в код.. Кто, как вы думаете, это должен делать? Поделитесь, плиз, видением..
Cпасибо за комментарий. Мы тоже об этом думаем, но пока не пришли к подходу хранения доки рядом с кодом. Что-то более общее, это вы про что? Сможете привести пример? и что из этих разделов кажется слишком мелких для condluence?
Спасибо! Буквально сегодня узнала, что еще 2 бывших коллеги переходят в айти из подбора. Это действительно классный пример. И вам желаю удачи во всех делах!
Добрый день! У нас этот момент разнится от команды к команде.
В идеальной ситуации PO ставит задачу на дизайнера по созданию макетов. После того как макеты готовы, аналитик описывает их в документации в разделе "Дизайн". Но бывают команды, которые делают внутренние продукты, они дизайнеров не привлекают, а аналитик как раз рисует прототип для разработчика. Этот прототип помещают в раздел "Дизайн". Так я работала в своей первой команде. Использовала Drawio, он у нас идет встроенным макросом в confluence. Также в создании дизайна принимает участие UX дизайнер, в случае, если он есть у команды.
Спасибо за комментарий, расскажу подробнее про нашу документацию. В сивквенсах мы описываем все взаимодействующие системы настолько схематично, насколько возможно. Очень полезно для второй линии и для развития продукта (надо понимать, где должны быть изменения). Решили хранить именно во фронтовом ФТ, так как разматывать сценарий от пользователя, который хочет что-то сделать, до мастер-системы проще, чем наооброот. В сценариях действительно только запрос/ответ. Сценарий сделан чисто для фонта.
Правило про обязательность сиквенса появилось на заре попытки стандартизировать ФТ. Тогда мы пришли к выводу, что в документации должно быть упоминание всех используемых систем и последовательности обращения к ним.
Добрый день. Да, скоуп артефактов используется разработчиками и тестеровщиками. Перед тем, как отправить документ разработчикам, он проходит ревью. Как правило ревью делают другие аналитики, в т.ч руководитель со стороны аналитиков. Сами артефакты пишутся в тесной работе с PO команды, чтобы полноценно перенести все бизнес требования в более детальные требования для разработчиков. Задача, как правило, приходит от PO команды, он же является источником бизнес требований. Если БТ зафиксированы в документе, то СА просто включает этот текст в набор своих артефактов(и доуточняет то, что упущено в БТ), если не зафиксированы, то СА интервьюирует PO и фиксирует БТ, как правило, в свободной форме.
По поводу БА.. У нас в продуктовых командах, чаще всего таковых нет, есть только PO и СА, которые делят функционал БА между собой.
Спасибо за комментарий! Да, действительно, точь-в-точь повторить можно с купленными макросами.
Но для тех у кого их нет, но кто хочет использовать наш шаблон, есть два пути.
Первsй путь: попытаться их купить. Если компания большая, то как правило этот процесс реально устроить. Второй путь: подойти творчески и сконцентрироваться на сути, а не на инструментах. Например, наши вкладки можно просто заменить на заголовки, а схемы вставлять скринами со ссылками на оригинальный файл.
Да просто не увидела плюсов, по сравнению с другими продуктами. Ну а потом сменила работу и у нас в банке он как-то не пользовался любовью, ну я и забила на него.
Спасибо за ваш комментарий и замечания. - С BPMN вероятно неудачная формулировка получилась. Отлично, что подметили. - В статье мы рассказывали про требования для фронта, методы мы тоже проектируем, но для них есть отдельный шаблон. Возможно, это тема для еще одной статьи. Если кратко, то шаблон метода состоит из:
- названия метода - алгоритма - описания параметров на вход - описания параметров на выход - примеров запроса и ответа - описание ошибок
Спасибо! Продумывать архитектуру у нас действительно задача аналитика, в сложных моментах привлекаем enterprise архитектора. В статье мы рассказывали про ФТ на фронт, но это не все, чем мы занимаемся, постановки на бэк мы тоже пишем. И в этой картине мира логично, что мы дружим между собой все написанное. А не превращается все это в хаос благодаря наличия у всех понимания целевой архитекутры и надзору архитектора.
В целом, был кейс, когда опубликовали дедлайн по переходу на новую версию. Мы попросили через нашего продакта, чтобы ВБ сдвинули дату. У нас получилось. Вывод такой: до них можно достучаться. Можно пробовать.
Добрый день. Спасибо за комментарий. Возможно, но если так, то второе. Задумка была, именно, написать о том, из чего состоит наш шаблон.
Спасибо за ваш комментарий. Что вы имеете ввиду под сценариями в виде блок-схем? Если вы про usecases, то они у нас прописаны в документации на фронт. Писала про это в статье: https://habr.com/ru/company/ru_mts/blog/686570/
А для микросервисов достаточно того, что описано в статье. По крайней мере доп.запросов не было еще.
У нас именно так. Как правило, когда аналитик передает такую доку в разработку, то она считается очень хорошо проработанной, поэтому меняется очень мало. Но если меняется, то да, разработчик просит аналитика актуализировать.
спасибо за ваш комментарий. Да, действительно начинающим аналитикам очень важны шаблоны, по ним легче всего начать описывать функциональности
Спасибо за информацию!
Очень интересно. Спасибо большое за рекомендации. У нас в стриме как-то не прижился, к сожалению, OpenAPI. Но, возможно, стоит пересмотреть отношение к этому формату
Спасибо за пояснение. Да, это было бы удобно в случае, если аналитик может базово кодить или разработчик сам проектирует API. Время до выпуска апи на тест сократилось бы.
По нашим процессам - это ТЗ для разработчика, он смотрит на доку и пишет код. А вы предлагаете заносить эту инфу в код.. Кто, как вы думаете, это должен делать? Поделитесь, плиз, видением..
Cпасибо за комментарий. Мы тоже об этом думаем, но пока не пришли к подходу хранения доки рядом с кодом.
Что-то более общее, это вы про что? Сможете привести пример? и что из этих разделов кажется слишком мелких для condluence?
Спасибо! Буквально сегодня узнала, что еще 2 бывших коллеги переходят в айти из подбора. Это действительно классный пример. И вам желаю удачи во всех делах!
Добрый день!
У нас этот момент разнится от команды к команде.
В идеальной ситуации PO ставит задачу на дизайнера по созданию макетов. После того как макеты готовы, аналитик описывает их в документации в разделе "Дизайн". Но бывают команды, которые делают внутренние продукты, они дизайнеров не привлекают, а аналитик как раз рисует прототип для разработчика. Этот прототип помещают в раздел "Дизайн". Так я работала в своей первой команде. Использовала Drawio, он у нас идет встроенным макросом в confluence.
Также в создании дизайна принимает участие UX дизайнер, в случае, если он есть у команды.
Спасибо за комментарий, расскажу подробнее про нашу документацию.
В сивквенсах мы описываем все взаимодействующие системы настолько схематично, насколько возможно. Очень полезно для второй линии и для развития продукта (надо понимать, где должны быть изменения). Решили хранить именно во фронтовом ФТ, так как разматывать сценарий от пользователя, который хочет что-то сделать, до мастер-системы проще, чем наооброот.
В сценариях действительно только запрос/ответ. Сценарий сделан чисто для фонта.
Правило про обязательность сиквенса появилось на заре попытки стандартизировать ФТ. Тогда мы пришли к выводу, что в документации должно быть упоминание всех используемых систем и последовательности обращения к ним.
Добрый день.
Да, скоуп артефактов используется разработчиками и тестеровщиками. Перед тем, как отправить документ разработчикам, он проходит ревью. Как правило ревью делают другие аналитики, в т.ч руководитель со стороны аналитиков. Сами артефакты пишутся в тесной работе с PO команды, чтобы полноценно перенести все бизнес требования в более детальные требования для разработчиков.
Задача, как правило, приходит от PO команды, он же является источником бизнес требований. Если БТ зафиксированы в документе, то СА просто включает этот текст в набор своих артефактов(и доуточняет то, что упущено в БТ), если не зафиксированы, то СА интервьюирует PO и фиксирует БТ, как правило, в свободной форме.
По поводу БА.. У нас в продуктовых командах, чаще всего таковых нет, есть только PO и СА, которые делят функционал БА между собой.
Спасибо за комментарий!
Да, действительно, точь-в-точь повторить можно с купленными макросами.
Но для тех у кого их нет, но кто хочет использовать наш шаблон, есть два пути.
Первsй путь: попытаться их купить. Если компания большая, то как правило этот процесс реально устроить.
Второй путь: подойти творчески и сконцентрироваться на сути, а не на инструментах. Например, наши вкладки можно просто заменить на заголовки, а схемы вставлять скринами со ссылками на оригинальный файл.
Да просто не увидела плюсов, по сравнению с другими продуктами. Ну а потом сменила работу и у нас в банке он как-то не пользовался любовью, ну я и забила на него.
Спасибо за ваш комментарий и замечания.
- С BPMN вероятно неудачная формулировка получилась. Отлично, что подметили.
- В статье мы рассказывали про требования для фронта, методы мы тоже проектируем, но для них есть отдельный шаблон. Возможно, это тема для еще одной статьи. Если кратко, то шаблон метода состоит из:
- названия метода
- алгоритма
- описания параметров на вход
- описания параметров на выход
- примеров запроса и ответа
- описание ошибок
Спасибо! Продумывать архитектуру у нас действительно задача аналитика, в сложных моментах привлекаем enterprise архитектора. В статье мы рассказывали про ФТ на фронт, но это не все, чем мы занимаемся, постановки на бэк мы тоже пишем. И в этой картине мира логично, что мы дружим между собой все написанное.
А не превращается все это в хаос благодаря наличия у всех понимания целевой архитекутры и надзору архитектора.
Я пробовала, но остановилась на других инструментах. Но спасибо за напоминание о нем, расскажем коллегам, может кто-то остановится на нем.