вторник, января 30, 2007

Дефект требований.

Дефект требований - это самый страшный дефект, который вообще может существовать в мире разработки софта. Дефект требований - это когда проектировщики все правильно спроектировали, программисты все правильно запрограммировали, тестировщики все правильно протестировали. А в результате заказчик говорит что все работает «не так». Такая ситуация уже сама по себе неприятна. А теперь добавьте к этому, что дефект требований вылазит во время эксплуатации, или, в крайнем случае, во время приемки заказчиком (customer acceptance tests). Как учили нас все классики, начиная с дедушки Брукса - это самое неподходящее время для появления дефектов, потому что цена их устранения в это время самая высокая. И вот вместо того, чтобы радостно делить премии и отправляться на очередной team building с пивом по поводу успешного завершения проекта, вы сидите в выходные дни, без оплаты и лихорадочно пытаетесь переделать половину системы не разрушив при этом другую половину.
Хорошо, если ваша команда работает по классической методе. В этом случае вы дружно идете мочить аналитика проекта. А если вы работаете по какому ни будь Agile (XP, Scrum, etc.)? Представитель заказчика - священная корова, его бить нельзя. Даже когда он говорит: «Извините ребята, я вчера поговорил с финансовым директором. Так вот, все эти юзерстори работают неправильно. Все надо переделать». Хоть бить этого парня и нельзя, но надо постараться от него избавиться. В том, что следующую итерацию вам придется переписывать старые юзерстори виноват именно он. А отвечать за это придется скорее всего вам.

3 комментария:

Elena Makurochkina комментирует...

С точки зрения ответственности с Agile-ом весело. Делается все командой, решения принимаются «коллективные», персональной ответственности нет.
Когда нет персональной ответственности, то виноватой выбирается менее агрессивная сторона. Т.ч., если повезет, может и заказчик после разбора полетов оказаться виноватым. Но бывает это редко… Заказчики, обычно, более агрессивные, чем разработчики.

Sergey Rozovik комментирует...

Я вот подумал: а ведь в Agile модели разработки, дефектов требований вообще не должно возникать. А они есть. Странно на первый взгляд. Но только на первый... Все мы люди, а людям свойственно ошибаться. И поэтому такие ситуации время от времени возникают. Тут главное иметь mitigation strategy на этот случай. Впрочем, это уже совсем другая история под названием "управление рисками".

Анонимный комментирует...

Здравствуйте!

А мне кажется нужно добавить
в команду одного человека специально натренированного чтоб тот выяснял что же на самом деле хочет заказчик, или обучить этому одного из членов команды.
Проблемма в простом непонимании.
Реальность заказчика, отличается от реальности членов команды.
То что для команды белое,для заказчика черное.
В одинаковых вещах, заказчик и команда воспринимают разные смыслы.
Как ни парадоксально, но это факт.
Этим не должна заниматся команда.
Эта проблемма - дело НЛП.