Комментарии 5
Статья понравилась, спасибо!
Хочу отметить, что есть проекты с разной степенью готовности к наличию требований. Очень часто нужно проверить гипотезу или сделать "хоть как-нибудь, лишь бы заработало". Прежде чем утверждать что требования нужны, стоит всегда задавать вопрос а зачем? Стоит ли время потраченное на описание и соблюдение требований меньше чем цена положительного эффекта от этих требований?
Есть классный принцип DDD. У него есть 2 варианта расшифровки:
Давай давай деплой и в этом случае требований нет, есть бизнес необходимость или научный интерес.
Предметно-ориентированное проектирование и в этом случае часто требования описываются уже при описании общего языка.
К чему это я. Мне не понравилась фраза "Требования служат фундаментом для каждого проекта и необходимы для глубокого понимания командой всех аспектов предстоящей работы.". По моему мнению фундамент для каждого проекта это экономическая выгода или "научный" интерес. А понимание аспектов предстоящей работы основывается на глубоком вникании в суть предстоящей работы и начинается с того, что язык общения всех членов команды сводится к единому и понятному набору слов и понятий.
А вот требования это уже суррогат, который необходим для того, что не забыть о чем договорились или чего хотели изначально и к чему пришли в процессе работы. Требования вторчны по отношению к целям проекта, а не фундамент.
Спасибо большое за обратную связь!
А разве цель проекта одновременно не является требованием к этому проекту?
Ведь если проект не отвечает цели, ради которой его создавали, то проект закроют или исправят. Так же как и функционал, который не отвечает требованиям. Более того к формулировке цели есть свои требования. Например, цель должна:
Быть достижима в рамках этого проекта
Предусматривать итоговый результат
Если цель предполагает получение прибыли, то должна быть возможность количественной оценки объемов, сроков и размеров прибыли и т.д.
Давай давай деплой и в этом случае требований нет, есть бизнес необходимость или научный интерес.
А разве бизнес необходимость не является бизнес требованием? Да, соглашусь, что могут быть проекты, где разработка требований будет дороже, чем разработка функционала. Но я убежден, что не существует проектов без требований. Я думаю, что не может быть вторично то, что лежит в основе проекта.
Поясню. Ни что на проекте не делается просто так. Любая задача появляется из-за какого-то требования:
Нужна новая кнопка. Зачем? Что бы пользователям было удобнее.
Нужен новый дизайн. Зачем? Что бы привлекать больше пользователей.
Нужен рефакторинг кода. Зачем? Что бы сделать его быстрее, качественнее, надёжнее и т.д.
Да пусть они не формализованы, не протестированы, может даже не записаны, но все равно это требования и на основе этих требований будет проходить разработка.
А вот формализовать требования нужно, в том числе, что бы не сделать вместо зелёного квадратное в конце проекта.
Только в реальной жизни требования являются важной составляющей практически любого проекта, особенно больших и в критически важных сферах, потому как наличие требований позволяет как минимум устранить разночтение
Идея хорошая!
Вспоминается Козьма Прутков: "Нельзя объять необъятное". Попытка в одной статье собрать всё про требования похвальна, но утопична. Конечно требования это "фундамент" или "каркас" любой системы, не только айтишной.
Если необходимы мои комменты:
Трассировка требований - отдельная большая тема.
Как уже упоминали коллеги выше - избегать лозунгов и общих фраз, только если как "перевод внимания". Новички материал не поймут, а кто шарит будут говорить "многобукффф".
Критерии требований - ссылаться на Бабку и Вигерса.
Чек листы импонируют как средство для всей команды.
Без упоминания автором видно не вооруженным взглядом - писал тестировщик, с претензиями к коллегам :) ИМХО, претензии это хорошо, плохо когда пофиг, только надо агрессию(как базовую эмоцию) перевести в конструктивное русло и через коммуникации отлаживать процесс разработки. В жизни - с аналитиками общаться больше, по эджайл-манифесту - вся наша жизнь в коммуникации. Писать без поучения коллег, а что вам хочется/не нравится/мешает/ в вашей работе. Как психологи рекомендуют жаловаться на жизнь - не ругая других, а говоря что вам не нравится и что сами чувствуете. Говорят, таким образом нельзя обидеть, потому что говоришь про себя!
ЗЫ: Возможно, материал неплохо смотрелся под названием "Требования глазами тестировщика". Правда, полезный, нужный и классный материал если получится через несколько итераций.
Как написать требования к IT-продукту и их протестировать, чтобы результат соответствовал ожиданиям