Мы уделяем большое внимание архитектуре ПО

В процессе длительной работы над многими проектами мы выработали определённые принципы. Некоторые из них происходят из методики «экстремального программирования», некоторые из других методик. Что-то наше собственное изобретение. Но все эти принципы важны и неоднократно проверены на практике.

В частности, разработка происходит короткими итерациями по 2-4 недели. Итерация это минимальный этап работы. В начале итерации происходит общение с заказчиком и вырабатывается короткий и понятный перечень того, что должно быть сделано за эту итерацию. Потом начинается собственно разработка (в процессе которой мы тоже можем общаться с заказчиком), и через 2-4 недели мы выдаем запланированный результат.

Разработка программного обеспечения сложный и трудно планируемый процесс. Поэтому важно, чтобы работа шла такими небольшими и понятными порциями. Это позволяет заказчику своевременно корректировать и контролировать процесс разработки.

Важно понять, что часто заказчик на самом деле не может точно сформулировать, что нужно сделать, и как раз в процессе нескольких итераций картина проясняется.

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

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

Представитель заказчика
Для эффективной разработки, в ней должен участвовать полномочный представитель заказчика. Это должен быть человек, который понимает требования заказчика и общается с разработчиками (то есть с нами). Он должен быть уполномочен принимать решения по процессу разработки (что именно делать, в каком порядке и т.п.).

Это кажется очевидным и тривиальным, но, как это ни странно, очень часто такого человека не находится. И это очень плохо сказывается на проекте. Часто, например, решения уполномочен принимать человек, который не общается плотно с разработчиками и плохо представляет требования заказчика. А тот, кто представляет, что и как надо делать и общается с разработчиком, решений принимать наоборот не уполномочен. Это называется «отсутствие заказчика» одна из основных причин провалов проектов. То есть по сути заказчика нет, нет того, кому собственно нужно что-то сделать.

Разделение ответственности
Определять, что и в каком порядке нужно делать, может и должен заказчик, и только заказчик. Разработчик никогда не должен принимать такие решения, поскольку они связаны с бизнесом, который он не представляет.

А вот как это делать, может и должен определять только разработчик, тут наоборот заказчик совсем не компетентен и не должен вмешиваться.

Несоблюдение такого разделения областей ответственности также одна из самых частых причин провалов проектов.

Прозрачность и доступ к исходному коду
Исходные коды проекта хранятся в системе управления версиями (subversion), доступной заказчику. Это позволяет в реальном времени видеть весь процесс разработки и всегда иметь исходные тексты проекта.

В сочетании с короткими итерациями разработки это дает заказчику полное представление о происходящем.

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

Архитектура
Так же как есть архитектура здания и соответственно его архитектор, так же есть архитектура и архитектор программного обеспечения. Этот очень важный момент многими опускается, и как следствие, разработанный проект рушится под собственной тяжестью. Очень много программистов совсем не является архитекторами ПО. Это отдельная, специфическая область разработки ПО.

Мы уделяем большое внимание архитектуре ПО на всем протяжении разработки.

Скорость
Используемые нами подходы к разработке, опытный коллектив, собственные инструментальные наработки позволяют вести разработку с высокой скоростью. Как правило, в несколько раз быстрее в расчете на одного разработчика, чем в среднем на рынке заказного ПО.

Добавить комментарий