Долгострой в разработке ПО: о проблемах управления требованиями

[valis]

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

[docsvision]

Согласна с Вами. В проектах по внедрению проблема изменений ощущается острее, чем при разработке продукта. В продукте мы обобщаем требования и можем «сгладить острые углы», при работе же с одним заказчиком – приходится отстаивать с боем каждую доработку.

[ogr]

А привлекается ли к оценке требований архитектор продукта? По идее, он должен снижать вероятность возникновения «айсбергов», т.к. точно знает, какое изменение в системе к какому списку связанных баг/фич приведет.

[docsvision]

Да, разумеется, архитектор проводит оценку и может выявить внутрисистемные связи с точки зрения разработки. Однако определение «айсберга» на уровне бизнес-логики – задача целиком аналитика.

[valis]

Архитектор тоже не супергерой, который по любому запросу через пол часа выдаст список хотя-бы потенциальных фитч. В любом случае анализ порой является довольно сложным и ресурсоемким процессом и на практике (правда довольно редко) эти «айсберги» всплывают чуть ли не на стадии тестирования.

[docsvision]

У нас – супергерой :) Если серьёзно, то мы в производстве пересмотрели подход к оценкам, ещё на этапе анализа каждая фича проходит трёхуровневое ревью – главным бизнес-аналитиком, архитектором и представителем группы тестирования. Это значительно повышает шанс на обнаружение неучтенных нюансов и возможных проблем, хотя и повышает в целом время, затраченное на проектирование.

[gandjustas]

Вы так и до коллективной оценки по методу planning poker дойдете…

[docsvision]

Метод этот, несомненно, интересный, но, боюсь, в нашем случае неприменим – для тяжёлых фич такие оценки будут из разряда потолочных.