В теме 6 ответов, и 7 участников, последнее обновление сделано пользователем 
-
Сообщения
-
Есть такая активность, как валидация (проверка) спецификации после того, как она (или её часть, или внеочередная версия) написана. Оговорюсь — перед тем, как по ней начнут писать код.
Кто на вашей памяти занимался этим, и, как вы считаете, кто должен это делать?
Возможные варианты (можете добавлять свои):
· Аналитик, который создавал спеку
· Другой аналитик на проекте
· QA
· PM
· Любой член проекта
· ЗаказчикУ меня бывали все… ну не одновременно, а обычно по одному.. бывало, что и не одного (вот это плохо)
Но если бы была моя воля (и достаточное кол-во людей и ресурсов), то я бы предпочел, чтобы это делал сперва Аналитик, который создавал спеку, а затем по одному представителю от каждой группы — QA, Разработчики, Аналитики, ПМ. А потом уже заказчик. А потом уже разработка
Повторюсь, это если достаточное количество людей и ресурсов (в первую очередь, времени).В идеале хотелось бы, чтобы спеку читали представители всех каст QA, BA, PM… ИМХО как минимум спеку до заказчика должен изучить Lead Developer или Systems Architect, чтобы можно было заранее выявить трудности имплементации. И, конечно, PM должен быть в курсе дела, итого получается следующая картина:1. BA
2. Lead Developer/Systems Architect
3. PM
4. CustomerВ моей нынешней практике получается, что, помимо аналитика-автора спецификации, спеку валидируют девелоперы (не всегда архитектор, но, по крайней мере, девелопер, который занимается данной частью проекта).ПМ — по возможности тоже. Не всегда валидируют детально, но хотя бы по ключевым моментам.
И заказчик, само собой. Ибо нередки случаи, когда изначально заказчик говорит одно, а в итоге, после всех обсуждений, выяснений и согласований, получается абсолютно другое
(к вопросу о компетенции людей со стороны заказчика 
)Мне кажется большое значение имеет валидация со стороны QA (особенно если со временем и ресурсами напряг и все члены команды физически не успевают это сделать). Поясню: на практике многие решения принимаются совместо с девелоперами, так что в целом они в курсе видения системы и откровенные косяки отсеиваются еще на этапе обсуждения. А вот QA в таких обсуждениях практически не участвуют.
QA смотрят на будущую систему совсем под другим углом — ближе к конечному пользователю. Они часто задают вопросы, которые раньше не поднимались/ были пропущены: например, аналитику часто сложно сконцентрироваться на мелочах, он старается очертить всю систему в целом, и бывает, что такие вещи, как то валидационные сообщения, ограничения на длину вводимой информации, сценарии поведения системы при действиях пользователя, которые не укладываются ни в один "правильный" воркфлоу аналитик держит "в голове", а вот в спеке они не отражены. Соответствено дальше два варианта: девелопер "креативит" (увы, не всегда удачно), или, что чаще, требование вообще остается не учтенным — "так ведь в спеке этого не было".В первую очередь спецификацию валидирует сам автор. Я, например, всегда как минимум перечитываю готовую документацию и довольно часто это помогает устранить многие "ляпы" и неточности. В дальнейшем я бы порекомендовал отдать документ на "review" другому аналитику. Вполне возможно что описание требований которое вам понятно и прозрачно поставит в тупик другого человека
. Следующим этапом будет валидация спеки разработчиками и тестировщиками. Причем и у тех и у других различные методы подхода к валидации SRS, что в принципе помогает обнаружить большую часть ошибок. Опять же из личной практики: Если разработчики обращают больше внимания на конкретное описание функционала (формулы расчета значений, ограничения на вводимые значения и т.д.), то тестировщики обращают внимание на Use cases, права доступа пользователей и т.д. Немаловажный этап — валидация спеки заказчиком. Очень часто, на практике у заказчика нет времени вдумчиво читать "метры" страниц спецификации, но так как заказчик основное действующее лицо в процессе разработки программного продукта, то я считаю что feedback или approve просто необходим.Имхо, интересная практика: одна моя знакомая PM (она же была и BA, автором спеки) довела валидацию спеки до уровня "заучивания" разработчиками. И принимала у них своего рода экзамен
Не все "здавали" с первого раза, но резальтат — одинаковое понимание требований командой разработчиков — был достигнут. Заодно, девчёнка здорово оторвалась "выставля зач0т/низач0т"
В идеале, здорово, когда спеку валидирует в первую очередь — тимлид-архитектор для проверки выполнимости и выявления неоднозначных в техническом смысле мест. Во-вторую — спонсоры проекта убеждаются что всё именно так, как они хотели.
А после утверждения вышеперечисленными — можно давать на вычитку QA и разработчикам.Соглашусь, здорово, когда есть два и более аналитиков, валидирующих работу друг друга… казалось бы, так же невероятно, как "парное программирование", однако, на проектах, где несколько человек разрабатывают требования — это происходит само собой: сверяясь походу со связанными требованиями, написанными коллегой — ты таким образом, пусть выборочно, но валидируешь.
Вы должны авторизироваться для ответа в этой теме.
