Потерянные практики работы с требованиями в Agile (Евгений Савицкий, AgileDays-2014) — различия между версиями

== Видео ==

{{vimeoembed|90716364|800|500}}
{{youtubelink|_BZsW24DmHY}}{{letscomment}}


<!-- pollholder --> 










== Слайды ==
[[File:Потерянные практики работы с требованиями в Agile (Евгений Савицкий, AgileDays-2014).pdf|left|page=-|256px]]

{{----}}

== Примечания и отзывы ==
* {{ConferencePage|http://msk14.agiledays.ru/members/profile/401/#report-78}}

<!-- <blockquote>[©]</blockquote> -->

<references/>





<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-31T17:55:46.705529|vimeo_comments=0|vimeo_plays=117|youtube_comments=0|youtube_plays=35}}

[[Категория:AgileDays-2014]]
[[Категория:Управление требованиями]]
[[Категория:Agile and Business Analysis]]
[[Категория:Agile и Enterprise]]

Текущая версия на 12:22, 4 сентября 2021

Аннотация

Докладчик

Евгений Савицкий

Понятие «Требование» в последние годы очень сильно размыто в ИТ-сообществе, особенно это связано с повсеместным внедрением гибких подходов (Agile). Теперь под требованиями понимается любая заявка заказчика, оформленная в небольшую историю пользователя (или фичу, кому как удобнее).

Пара предложений описания для каждой истории, список историй как баклог продукта — очередь требований для разработки. Управление требованиями как изменение приоритетов историй в очереди.

Это отлично работает для небольших проектов и простой предметной области, но что если мы говорим об Enterprise секторе (банки, крупное производство и т.п.)? Проектные команды из десятков людей, множества согласующих подразделений, требования регуляторов и безопасников…

Agile возможен и в таком окружении — вы, правда с некоторыми трудностями, сможете внедрить Scrum или Kanban в таком проекте, но простой очереди хотелок, о которой говорит скрам, вам конечно же будет мало.

И здесь на помощь приходят забытые большинством, потерянные практики работы с требованиями, наработанные десятилетиями, и за последние годы адаптированные под потребности современных процессов.

• Как найти баланс между гибкостью и необходимым уровнем документации на проекте?
• Как облегчить жизнь команде, не прибегая к созданию 100 и более страничных документов требований, но при этом анализируя и фиксируя все необходимое?
• Как упростить процедуры согласования различными подразделениями?
• Как организовать гибкий репозиторий требований с бейзлайнами и версионированием, понятный любому инженеру проекта: разработчику, аналитику, тестировщику.

Смотрите доклад!

Видео

Слайды

Примечания и отзывы

• Страничка доклада на сайте конференции

Plays:152   Comments:0