Обсуждение

Может Вам это уже очевидно, но размышляя о об управлении требованиями я пришел к мысли, что главное отличие и самое существенное в ХР и всей последующей волне agile от традиционных тяжеловесных подходов - это способ управления требованиями - те самые user stories. И как мне кажется, такое понимание помогает отделить главное от второстепенного, того же парного программирования, например. Если управлять требованиями таким образом, то все остальное (постоянное общение с заказчиком, частые релизы, рабочий софт, юнит-тесты, рефакторинг) появятся сами собой с необходимостью. И наоборот, сколько не пиши юнит-тесты, не прелагай работать парами, не убеждай, что нужен рефакторинг - ничего не выйдет и никто тебя слушать не будет, если есть уже подписанные документы требований и плана проекта, а дедлайн все ближе.

Не все так просто. Use cases и user stories, конечно, различаются -- но они про функциональные требования. А головная боль при работе с требованиями во многом идет от нефункциональных требований, и много-много практик как раз завязано на обеспечение нефункциональных требований. Заметим, что в языке URN два подъязыка -- один про use cases, а другой про goals. Это не случайно. Но это уже другая история, про содержание, а не про форму. Я же сейчас про форму, моделирование метода. При работе с требованиями крайне важна инкрементальность, порождение при добавлении или вычеркивании какого-то элементарного требования волны изменений во всех остальных моделях. Это "интерактивное программирование", о котором я несколько раз писал. Это rocket science на сегодняшний день, и именно это нужно будет проработать. Issue trackers именно от этой группы описаний. Но фишка в том, что есть и другие группы описаний требований, и их упускать из виду тоже нельзя.