Четыре проблемы

сложности разработки

ПО и где они обитают

Типичная работа над проектом в IT-отрасли порой напоминает гигантский аттракцион, этакий гибрид «Американских горок» и «Замка ужасов». Когда все только начинается, то кажется, что сейчас мы взлетим! И программисты-супергерои найдут решение для какой угодно задачи. Но в ходе активной работы над проектом почему-то оказывается, что вроде бы задумка была хорошая, но тут и там все провалилось. И из всего проекта наружу торчат «костыли». Далее то, что казалось отличной идеей, стремительно несется к стандарту «сделано на коленке». В конце концов, все разработчики на проекте уже и не мечтают даже о нормальном решении, а пытаются собрать хоть какую-то «тележку», лишь бы она поехала.

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

Превратить такую проектную «карусель», с которой все разбегаются с воплями «Спасите! Я накатался!» из недостатка в особенность IT-отрасли можно. Но сначала давайте разберемся: айтишники, определенно, не самые ленивые и уж точно не самые глупые люди на Земле — почему же тогда так горят проекты?

Важнейшей отличительной чертой IT является проблема сложности. Познакомиться с ней можно, к примеру, в книге Гради Буча «Объектно-ориентированное проектирование с примерами применения».

Что же подразумевает такая зловещая формулировка? Фактически, сложность выражается так: количество ресурсов, связей и компонентов, которые требуются для решения какой-либо задачи, растет нелинейно по мере роста размеров проекта.

Давайте рассмотрим это утверждение на примере: сравним работу каменщика и программиста.

Если каменщик строит стену, то мы можем ожидать, что первый кирпич он, допустим, положит за условные 2 минуты, второй еще за 2 минуты, а сотый — уже быстрее, потому что у него выработался навык. К тысячному он, возможно, станет кирпичным виртуозом, и будет делать все просто молниеносно, с закрытыми глазами и прямо во сне.

А что у программиста? Все наоборот. Свой первый виртуальный «кирпич» он кладет за 2 минуты, второй тоже за 2 минуты, сотый кирпич кладет почему-то за час, а тысячный — за три дня… Как так? Это как раз и есть иллюстрация проблемы сложности: растет проект — меняются потребности и, соответственно, необходимые усилия, время и трудозатраты растут вслед за ним.

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

Точнее Буча проблему сложности сформулировал Льюис Кэролл в «Алисе в Зазеркалье», там Черная королева говорит: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!».

Это, к сожалению, «тащит» за собой другие малоприятные вещи: то, что программисты все время проваливаются в сроках, то, что все идет не по плану, то, что отрасль постоянно содрогается от кадрового голода и так далее.

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

Сегодня Agile получается как раз об этом: мы потратили ваши деньги, но не просто так — а с пользой, заранее мы ничего не планировали, но вот, какая удача — что-то получилось.

В следующей статье мы разберемся непосредственно с 4 проявлениями проблемы сложности при разработке ПО: алгоритмической сложностью, трудоемкостью разработки, информационной сложностью и сложностью тестирования.