Всем привет, я вернулся из затянувшегося отпуска и пары срочных контрактов. Это значит, что канал возобновит работу.
Сегодня хочу поговорить о требованиях в проекте по разработке ПО. Частый вопрос, который беспокоит всех — как можно вести разработку, если требования неполные. Что делать? Я сейчас расскажу, что думаю и как поступаю, но вам от этого станет только хуже.
Давайте поймём, что такое "неполные" требования. Может, аналитик слушал заказчика, но не всё записал? Или заказчик сам не понимает, что ему нужно, а потом поймёт? Или аналитик записал не то? Не очень понятно.
Что вообще такое "полные" требования, в противоположность "неполным"? Требования пришли в конечную точку, и больше не будут меняться? Требования были изложены на 100% верно с первого раза? В крупном проекте так не бывает почти никогда.
Если задуматься, то ответ найти не удастся. Это признак того, что верный ответ находится за границами восприятия. Понятно только, что это то, что станет лучше потом. А так с требованиями бывает всегда, т.к. разработка ПО полна неопределённостей и неформальных ожиданий.
Более-менее (((адекватный))) взгляд на предмет такой — полных требований не бывает вовсе, они невозможны, они несбыточная абстракция. С этим надо согласиться. А если их не бывает, почему вас теперь это беспокоит? Вы всегда в своей практике работали с неполными требованиями, и это никого не вгоняло в панику. Более того, и все остальные тоже работают с неполными требованиями, в 99.9% случаев.
Придётся смириться, что любые требования неполные, включая те, с которыми вы когда-либо работали. Это должно немного успокоить и воодушевить. Т.е. работайте так, как работали ранее.
Собственно, вопрос сводится к тому, как вообще работать с требованиями, которые всегда изменяются. Здесь приходят на помощь несколько неидеальных, но неплохих методик:
- итеративная разработка (она была и есть даже в waterfall-модели)
- инженерия требований (как суперпроцесс над практикой анализа требований https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9)
- техника Impact Mapping, которая хорошо раскрыта, например, тут https://habrahabr.ru/post/246401/
Вы только что поняли, что полных требований не существует, и вы один на один с хаосом, а хорошего ответа нет. Стало хуже, но я предупреждал сразу.
Сегодня хочу поговорить о требованиях в проекте по разработке ПО. Частый вопрос, который беспокоит всех — как можно вести разработку, если требования неполные. Что делать? Я сейчас расскажу, что думаю и как поступаю, но вам от этого станет только хуже.
Давайте поймём, что такое "неполные" требования. Может, аналитик слушал заказчика, но не всё записал? Или заказчик сам не понимает, что ему нужно, а потом поймёт? Или аналитик записал не то? Не очень понятно.
Что вообще такое "полные" требования, в противоположность "неполным"? Требования пришли в конечную точку, и больше не будут меняться? Требования были изложены на 100% верно с первого раза? В крупном проекте так не бывает почти никогда.
Если задуматься, то ответ найти не удастся. Это признак того, что верный ответ находится за границами восприятия. Понятно только, что это то, что станет лучше потом. А так с требованиями бывает всегда, т.к. разработка ПО полна неопределённостей и неформальных ожиданий.
Более-менее (((адекватный))) взгляд на предмет такой — полных требований не бывает вовсе, они невозможны, они несбыточная абстракция. С этим надо согласиться. А если их не бывает, почему вас теперь это беспокоит? Вы всегда в своей практике работали с неполными требованиями, и это никого не вгоняло в панику. Более того, и все остальные тоже работают с неполными требованиями, в 99.9% случаев.
Придётся смириться, что любые требования неполные, включая те, с которыми вы когда-либо работали. Это должно немного успокоить и воодушевить. Т.е. работайте так, как работали ранее.
Собственно, вопрос сводится к тому, как вообще работать с требованиями, которые всегда изменяются. Здесь приходят на помощь несколько неидеальных, но неплохих методик:
- итеративная разработка (она была и есть даже в waterfall-модели)
- инженерия требований (как суперпроцесс над практикой анализа требований https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9)
- техника Impact Mapping, которая хорошо раскрыта, например, тут https://habrahabr.ru/post/246401/
Вы только что поняли, что полных требований не существует, и вы один на один с хаосом, а хорошего ответа нет. Стало хуже, но я предупреждал сразу.