Документирование требований на Scrum проекте / Елена Горопека / Oxagile

В докладе и live demo вы узнаете:
В чем плюсы и минусы подходов «только в Jira», «связка Jira-Confluence»?
Как организовать иерархию требований?
Какие использовать шаблоны пользовательских историй?
Каков жизненный цикл работы с пользовательскими историями, от возникновения до статуса «ready for dev»?
Телеграм-канал Елены:
t.me/harapeka
Остаёмся на связи!
/ @analystby_community
t.me/joinchat/...
/ analystby
/ analyst.by
analystby
Спасибо компании Qulix Systems за видеозапись выступлений.
Qulix Systems создает надежные IT-решения в сфере разработки/тестирования ПО, а также оказывает консалтинговые услуги. Компания была основана в 2000 году, и на данный момент в штате работает более 350 специалистов. Ежегодно на международные B2B и B2C рынки поступает около 160 проектов, успешно реализованных Qulix Systems. Больше информации о компании на сайте www.qulix.com/

[@ekaterinavolkova4348]

Неоднократно возвращаюсь к этому видео, мне как начинающему BA невероятно полезно. Елене громадное спасибо 🙏

[@elenagoropeka4786]

Хорошо, что полезно!)

[@FKNomad]

​Здравствуйте Елена, хочу задать вам как практикующему БА несколько вопросов. Насколько изменился функционал БА за прошедшее время? Каковы в данный момент основные тренды бизнес-анализа? Как уход из РФ западных компаний и в принципе разрыв отразился на бизнес-анализе?

[@ЛинаЛосева-к2ч]

Девочка огонь!) так живо и интересно всё рассказала. Отдельное спасибо за конкретный пример, который мы увидели своими глазами, а не просто сухую непонятную теорию.

[@unrealme]

Как же в тему для меня это видео! Я методом перебора пришла к ведению документации в Jira+Wiki, Елена подтвердила верность моей стратегии. Другие фишки ещё подсмотрю и применю. Спасибо огромное 🙏

[@volka_u]

самый крутой подход! проверено неоднократно! Только я бы назвала не Confluence+Jira, а просто Confluence. Фактически все требования там, а джира ссылается лишь туда.

[@zs4542]

Это просто кладезь информации для начинающего специалиста!!!!

[@isamstay]

Спасибо большое, Елена! Очень полезно и наглядно

[@oksanalesnik4922]

Очень полезное видео, спасибо большое!

[@ЮрийГригорьев-з5э]

Там где про ветки на 7 минуте рассказываешь нужно поменять на другую структуру, используя User Story Mapping. Такая работа проделывается с продактом. US ориентировать лучше на заказчика, а не на разработчика. Разработчику как не описывай, всегда будет мало :) Тут главное критерии приемки. А вот заказчику такого уровня описаний US должно хватать. И еще такая карта нужна для планирования ресурсом аналитика. И еще: US я бы писал сплошным списком в одной ветке. А вот с помощью макроса вытаскивал Acceptance Criteria в отдельную доку по управлению требованиями. Для этого необходимо разделять Критерии приемки, нумеровать их и тегировать. Так можно отслеживать изменения в конкретной, например, сущности на отдельной страничке.

[@АлексейЗабережный-з5г]

Девочка огонь!

[@LAMPOVOEIT]

2:20 Agile это не о том, что требования не пишутся в user story , а о том, что меняются бизнес приоритеты и стратегия. Если вы не написали требования в стори, а потом хотите чтобы команда сидела ночью и дописывала/меняла функционал, который вы не спланировали на начале спринта, то это завтык только того, кто пишет требований, а не разработчик без Agile философии.

[@denisgut]

Я один не понимаю зачем все НАСТОЛЬКО усложнять?

[@ЮрийГригорьев-з5э]

Ответ на поверхности, например, когда у тебя много аналитиков, а продукт 1, каждый чем-то занимается, нет синхронизации действий. Каждый изучает процесс, фичу, стори повторно, дублируя проделанную работу. Плохо ориентируется в новом, если один аналитик ушел, другой пришел. Аналитик должен помогать продуктовой команде, управляя противоречиями в требованиях на этапе проектирования, а не в конце разработки. Все это направлено на минимизацию багов, а значит ускоряет и улучшает качество продукта.

[@vitalyistr]

Сначала девочке нужно научиться говорить на русском языке, а затем учить других. Русский язык не родной.