Что означает "требования определены" а Agile
Перевод статьи из блога requirements.seilevel.com/blog.
Ссылка на статью:
http://requirements.seilevel.com/blog/2009/06/what-does-requirements-sign-off-mean-in.html
——перевод——↓
Я недавно работал с клиентом над проектом, в котором использовался Agile. Организация находилась в процессе перевода всех проектов на Agile, поэтому, естественно, у них оставалось множество не-Agile частей в их методологии. Мы находились в процессе определения требований и должен был начаться первый спринт разработки, когда руководитель проекта сказала мне, что у нас есть конечная дата для определения требований.
Подождите минутку! Придержите своих лошадей! Требования определены? В Agile?
Я напомнил ей о используемой нами методологии в данном проекте… и то, что она просит определиться с требованиями в методологии, в которой это не имеет значения… и пользователи имеют право приоритизировать любые функции в бэклоге в любое время. Поэтому, если они забудут о каких-либо функциях в процессе выявления функций, им необходимо будет лишь определиться, куда их поместить в приоритизированный бэклог и понимать, что другая функция при этом теряет приоритет. Она рассмеялась и сказала, что она прекрасно это понимает, но корпоративный процесс этого требует! Поэтому мы начали дискутировать на тему, что для нас означает “требования определены”.
В итоге, мы пришли, на мой взгляд, к достаточно интересному решению. У нас было множество требований в формате user stories и других моделей, таких как “диаграммы процессов”, “диаграммы состояний” и т.д. Также мы тесно работали с пользователями для выявления требований. Итак, мы попросили подтвердить, что к данному моменту времени не пропущено никаких серьезных требований, о которых они знают, и нет никаких значительных вопросов, которые не были сформулированы, о которых они знают. Суть в том, что они видели требования, участвуют в процессе и разработка прототипа не отклониться слишком далеко от необходимого. Но по-прежнему они имеют право добавить что-то новое после того, как увидят систему, подумают об этом или что-то в этом роде.
Что мне действительно нравится в этом подходе, так это то, что никто не загнан в угол тем, что их попросили подписать массивный документ с требованиями, который они едва понимают, или они, подписывая документ, подтверждают, что все прекрасно получилось с первого раза. Поэтому я думаю, что дух гибких методологий более или менее сохранился в нашей версии утверждения требований.
