Хорошая параллель. Я согласен с Джоэлем Спольски в некоторых его выводах. В частности, в том, что в процессе разработки нужно учитывать особенности разрабатываемого ПО. И я этим активно пользуюсь.
Серые квадраты нарисованы для тех, кто отвечает за организацию процесса разработки программного обеспечения. Программистам обычно эти схемы не показывают, потому как активность программистов — несколько точек в одном из этих серых квадратов.
Умышленно не говорю о написании кода. Реализация и поставка системы — тема очень большая, кроме кодирования в неё входит много других активностей. На эту тему надо говорить отдельно.
Согласен. Но я не случайно написал в статье, что схема процесса является результатом обобщения моего личного опыта. Так сложилось, что для заказчиков, с которыми я работаю, и для моего руководства указанная схема оказалась наиболее удобной. Я не говорю о том, что мой обзор полный. Напротив, цель статьи — указать на особенности процесса разработки, с которыми мне приходилось сталкиваться.
Буду признателен, если Вы укажете на какие-либо нюансы, которые могли бы улучшить приведённую мной схему, или расскажете о схеме, которую используете Вы.
Я сознательно употребляю термин «разработка требований», поскольку аналитикам и архитекторам часто приходится приложить немалые усилия для того, чтобы выяснить реальные потребности заказчика и сопоставить их с потребностями бизнеса своей организации.
Если этого не сделать, то можно попасть в две крайности: либо в список требований будет содержать много никому не нужных функций, которые придётся реализовать, отладить и сопровождать, либо список окажется не полным, и в итоге ПО окажется никому не нужной, а репутация исполнителя — сильно подмоченной. То и другое выливается в значительно (на порядок) бОльшие затраты, чем затраты на качественную разработку требований в начале проекта.
В большинстве проектов, где аналитики просто занимаются «сбором требований», исполнитель умудряется попасть в обе эти крайности одновременно.
Серые квадраты нарисованы для тех, кто отвечает за организацию процесса разработки программного обеспечения. Программистам обычно эти схемы не показывают, потому как активность программистов — несколько точек в одном из этих серых квадратов.
Умышленно не говорю о написании кода. Реализация и поставка системы — тема очень большая, кроме кодирования в неё входит много других активностей. На эту тему надо говорить отдельно.
Буду признателен, если Вы укажете на какие-либо нюансы, которые могли бы улучшить приведённую мной схему, или расскажете о схеме, которую используете Вы.
Если этого не сделать, то можно попасть в две крайности: либо в список требований будет содержать много никому не нужных функций, которые придётся реализовать, отладить и сопровождать, либо список окажется не полным, и в итоге ПО окажется никому не нужной, а репутация исполнителя — сильно подмоченной. То и другое выливается в значительно (на порядок) бОльшие затраты, чем затраты на качественную разработку требований в начале проекта.
В большинстве проектов, где аналитики просто занимаются «сбором требований», исполнитель умудряется попасть в обе эти крайности одновременно.