По мере того как компания росла, на работу поступало все больше людей, привыкших к традиционному процессу разработки. Однажды ко мне пришла начальница другой команды и сказала: «Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете». «Нет проблем, – ответил я, – только расскажите мне, для кого мы делаем эти изменения и какие задачи люди будут решать с их помощью». Что я услышал в ответ? «Это нужно для соответствия требованиям». «Я вас понял, – кивнул я. – Мне только нужно знать подробнее, для кого мы внедряем эти штуки, как эти люди будут их использовать, а также какой этап их рабочего процесса изменится». Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом: «Это. Для. Соответствия. Требованиям». И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись». Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить.
—Джефф Паттон — «Пользовательские истории»
Цитата выше очень злободневная, но даже она отражает лишь часть проблемы. Удивительно, но факт — в двух из трёх компаниях, в разработке пяти из шести программных продуктов, с которыми мне довелось иметь дело, про требования вообще не задумывались. Либо применяли что-то похожее на эту концепцию к отдельным, наиболее ярко выраженным частям (как правило, базовый функционал продукта) и только на отдельных этапах. Как результат, изрядная часть продукта развивается хаотично, накапливает избыточные элементы или, наоборот, недоделки, наращивает техдолг, а значительную часть усилий команда прикладывает не к тому, что на самом деле важно.
Дальнейший мой спич имеет целью небольшой ликбез в части важности управления требованиями в разработке ПО. Учебник Вигерса заменить не претендую, но и ориентируюсь не столько на бизнес-/системных аналитиков, сколько на остальных участников — разработчиков и QA. Хотя если у аналитиков всплывёт что-то в памяти или возникнет потребность что-то добавить — тоже неплохой результат.
Продолжить чтение «На основании чего вы тестируете свой продукт? Или управление требованиями к ПО 101»
Self Engineering 