У нас почему такая ситуация сложилась - очень высокая скорость разработки, еженедельно в продакшн выходят новые версии программного обеспечения. Программное обеспечение разрабатывается для собственных нужд, программисты свой код изрядно комментируют, и считают, что менять ничего не требуется.
В Twiki лежит много документации на уровне технических спецификаций, которые менеджмент обсуждает с программистами. Иногда они подробно расписывают Use Cases, чаще - оставляют все на уровне схемы программных модулей, которые друг с другом взаимодействуют. Мол, все обсуждено и понятно. А на деле - тестировщик постоянно дергает программистов с просьбой разъяснить да уточнить. И постоянно "не хватает времени". И постоянно непонятно, что приоритетнее тестировать. А это непонятие происходит из того, что не составляется и не обсуждается тест-план :( А чтобы составить тест-план - нужно составить тест-кейсы...
Описана типичная ситуация для небольших проектов (2-5 разработчика на проект). И так же указана типичная ошибка для таких проектов (для более крупных проектов эта ошибка "вылазит" раньше, поэтому чаще всего ее решают каким-нибудь способом).
Ошибка заключается в том, что разработчики и бизнес-заказчики (менеджеры, как я понял) общаются напрямую без специального посредника - бизнес-аналитика или системного аналитика (по RUP). В результате мало внимания уделяется документации. Программисты не хотят заниматься бумажной работой. В их понимании это пустая трата времени. Ведь они и так знают всю спецификацию почти наизусть. Рано или поздно это приводит к тому, что документация теряет свою актуальность и выбывает из практического использования. Требования и изменения в требования "размазываются" по письмам, всяким листочкам, дополнительным приложениям. Как результат, никто не может разобраться в документации (даже сам разработчик).
Выход очень прост. Работа с требованиями - это задача отдельной роли, которую выполняет бизнес аналитик. Если хотите иметь всегда актуальную информацию - выделяйте ресурсы и время на эту работу.
Здесь я не затронул другие выгоды от привлечения бизнес-аналитика. Согласен, что ведение документации и поддержание ее в актуальном состоянии не является его основной (точнее сказать, главной) задачей.
Очень часто бывает так, что не возможно повлиять на чужой участок ответственности. К примеру, невозможно заставить ПМ-а взять в проект аналитика. Значит нужно действовать с другого конца. Необходимо взять тест дизайнера (или назначить кого-нибудь на эту роль). Тест дизайнер будет постоянно поддерживать в актуальном состоянии матрицу соответствия актуальных функций проекта (требований) и тест-кейсов. Он будет "выбивать" из разработчиков информацию - откуда взять последние данные о том, какие именно требования входят в последную версию и вносить изменения в матрицу Требования-ТестКейсы.
Дополнительно можно договориться с разработчиками, что при выпуске очередного билда они дополняют файл "Build notes" о том, какая функциональность была изменена/добавлена в очередном билде. Вообще-то это можно делать автоматически, если налажен автоматизированный воркфлоу по configuration management-у. Тогда при создании автоматической сборке формируется файл с описание, какие изменения были включены в сборку.
