Vision

или чем знимается разработчик во время анализа требований

В одном из последних постов "100% требований. Или "дьявол кроется в деталях" я писал о бессмысленности попыток собрать 100% требований к системе, и о том, как выкручиваться, когда тебя толкают на этот путь.

Но с другой стороны, прежде чем преступить к работе, надо понять, что же мы собираемся сделать. В среде Agile, бытует мнение что подобной проблемы не существует. Что делать решает заказчик. Что скажет, то и сделаем. Это прискорбное заблуждение. Во первых, как сказал один мой уважаемый читатель, "Клиент никогда не знает точно, что ему надо". Во вторых пресловутый коммуникационный барьер, с которым борется Agile, еще никто до конца не поборол. Заказчик рассказывает вам, что он хочет, вы интерпретируете его рассказы с позиции своей не компетенции, все это искажает картину.

Agile не отменяет анализ требований, он его усложняет. Усложняет тем, что не дает никакой внятной методики того, как это делать. Игра в планирование, из XP, это в большей степени планирование, чем анализ.

Для начала работы нам надо иметь видение - vision. В разных проектных методиках есть документ с названием Vision, но для разработчика или проектировщика vision - это несколько иное. Для разработчика Vision - это целостное видение проблемы, и путей ее решения. Заметьте, не будущей системы, а именно проблемы. Часто бывает ровно наоборот. Вспоминая, как начинались мои прошлые проекты, я всегда могу припомнить момент, когда менеджер или представитель заказчика говорил, "нам надо сделать систему..." и далее в одном предложении, что надо сделать. Это затравка. Молодой и неопытный разработчик клюет на нее как голодный карась, и уже через минуту он готов рассказать как он все сделает. Так когда-то поступал и я, пока не стал ленивым и флегматичным :) В этот момент в голове разработчика создается устойчивый стереотип. Потом, когда выяснится истинная сущность проблемы, этот стереотип может сыграть с нами злую шутку. Это классический пример того, когда дизайн бежит впереди требований. Потому я и говорю, что vision - это прежде всего целостное видение проблемы. Необходимо понять, суть автоматизируемого процесса, его смысл. Выделить сущности и их связи. Понять как будущая система улучшит процесс. В общем, обычный системный анализ, описанный во всех книжках.

Если вы можете описать заказчику сущность будущей системы в трех - пяти предложениях, значит у вас естьвидение. Запишите эту формулировку, она вам пригодится (например, хороший стиль - начинать с этой формулировки документы, описывающие архитектуру). Это уже синтез, о котором нигде не пишут. На этом этапе вы хорошо понимаете что надо сделать, и примерно понимаете, как это сделать. По поводу "как" у вас может быть полная ясность в случае простого типового проекта, или большие сомнения, если проект сложный или уникальный. Но в любом случае, это отправная точка, с которой можно начинать разработку. Заметьте, это далеко не 100% требований. Я затрудняюсь определить это число в процентах, может быть 20% (пресловутая пропорция 20/80), а может немного больше.

Сторонники классических подходов могут возразить, что невозможно разрабатывать имея такую большую неопределенность в требованиях. Очень даже возможно, надо только подходить к разработке с головой.
Возможно официально разработка еще не стартовала (да, да, с вас требуют определить 100% требований, либо имеет место другая административная волокита), но в вашей команде уже должна кипеть работа.
Есть три типа активностей в разработке, которые можно выполнять на этом этапе (и совместить их с дальнейшим анализом требований).

Первое, это прототипы. Как не странно, прототипы это мощное оружие для анализа требований в руках умелого разработчика. Прототипы делают для заказчика. Я подробно писал про прототипы здесь, не буду повторяться. Добавлю лишь, что предпочитаю выбрасывать прототипы, а не выращивать из них готовую систему.

Второе, это proof of concepts (или, по русски, доказательство реализуемости). Почти всегда, в образе будущей системы есть такие мутные места, что не понятно как это сделать, будет это работать или нет. Лично меня они более всего раздражают. Proof of concepts нужны, чтобы понять, можно реализовать ту или иную фичу, и как это сделать. Подобно прототипам, proof of concepts снижают неопределенность на этапе анализа, но мы пишем их не для заказчика, а для себя. Это не должен быть кусок будущей системы, вы должны проверять только принцип, делать все максимально абстрактно. Выполнять proof of concepts поручают лучшим разработчикам команды. Опять же, полученный код лучше выкинуть. Дело в том, что часто в этом коде не проверяются входные параметры, не обрабатываются исключения и т.д., т.е. не соблюдаются стандарты и соглашения, по понятным причинам. Так что проверили, и выкинули :)

Третье, это инфраструктура. Часто с самого начала вполне ясны некоторые аспекты будущей системы. Например требования к авторизации, локализации, или к взаимодействию с другими системами. Такие инфраструктурные части требуют времени на разработку, но не видны пользователю. Если требования к ним достаточно ясны можно заняться разработкой этих компонентов.

Вот так, итеративно дорабатывая прототип, устраняя сомнения по поводу реализуемости отдельных частей и создавая компоненты инфраструктуры, мы параллельно проясняем требования и детали будущей системы. В XP для этого есть термин нулевая итерация, в RUP это фаза Elaboration - анализа и проектирования (помните как на известном раповском графике в этой фазе нарастает активность выполнения :). Все эти активности плюс активное взаимодействие с заказчиком, а вовсе не груды Use Case и UML диаграмм, залог получения полных, достоверных и непротиворечивых требований. Впрочем, фиксировать требования тоже необходимо, но вовсе не для достижения просветления. Они вам потом понадобятся...