О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 3

[avost]

Начистоту?

[aidarchikable]

Спасибо за статьи. Давно мечтаю поработать в команде в которой используются инструменты управления требованиями.

[aidarchikable]

И расскажите, пожалуйста, как продавали необходимость внедрения управления требованиями владельцу продукта/менеджеру проекта? С какими подводными камнями столкнулись и какими преимуществами оперировали? Так же было бы интересно как уживается управление требованиями со скрамом.

[ARadzishevskiy]

как продавали необходимость внедрения управления требованиями владельцу продукта/менеджеру проекта?

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

[a3aquB]

>«мы постарались каждую спецификацию нижнего уровня сделать максимально схожей с атомарной задачей для разработчика»
Примеров бы побольше на эту тему.
Как сделать спецификации нижнего уровня атомарными и независимыми друг от друга и порядка их реализации

[ARadzishevskiy]

А их не надо так уж сильно стараться делать независимыми друг от друга и порядка. На самом деле очень часто в документе могут быть перекрестные ссылки. Естественно такой документ готовится в несколько проходов, дополняя разделы ссылками. А в помощь этому допущению, в большинстве трекеров, задачи могут иметь зависимости, в том числе блокировать одна другую. Тут уже можно дать волю PM или teamlead_у, разруливать ситуацию. А то меня упрекают, что у них этот подход всю работу забрал.