Набор серебряных пуль

Константин Константинович Берлинский

Войны ИТ-методологов не затихают. Каждые несколько лет нам преподносится совершенно новая, быстрая, легкая, простая, эффективная методика (или новая версия «старой»). И уж она наконец-то решит главную проблему – построение качественного ПО в срок… Я думаю, что правда о методологиях заключается в том, что их не существует… Есть лишь УПР – удачные проектные решения, – которые могут сработать (или нет) в конкретной ситуации и проекте. Цель этого справочника – собрать их вместе, дать им краткое описание и подвигнуть ИТ–сообщество к дальнейшему их поиску и классификации…

Введение

«Ну вот!» – скажете Вы, прочтя заголовок данной книги. «Ещё один новоявленный пророк – самозванец учит всех жизни, как нужно выполнять программные проекты! У нас и так есть методология, которая отлично справляется со всеми проблемами. Мы адаптировали её под свои нужды, и вроде бы проблем стало меньше…»

И Вы будете правы, … но наполовину. Я ни в сколькой мере не считаю себя новоявленной мессией, который «наконец-то расскажет, как добиться успеха». Но меня действительно интересуют методы эффективной разработки ПО (и как следствие этого знания – повышение своего профессионального мастерства разработчика ИС).

Эта книга не является обоснованием в письменном виде против какой-либо определённой методологии. Хотя ранее, на форумах тематических сайтов, я позволял себе резкие высказывания по поводу различных новомодных методик разработки, которых с религиозным пылом фанатиков отстаивали их ярые приверженцы.

Вы не найдёте здесь и доводов в пользу какой-нибудь определённой методологии, как можно было бы предположить исходя из того, что я долгое время являлся ревностным сторонником методологии RUP, активно занимался её изучением и внедрением в деятельность компании, в которой работал. Причем, в тот момент времени, во мне действительно была уверенность в том, что жесткое разделение участников разработки по ролям (и соответствующим функциональным обязанностям) сможет сделать процесс разработки управляемым и успешным, а его участников – более удовлетворёнными своей работой.

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

Я уверен, что правда о различных методологиях заключается в том, что их не существует…

А теперь, приведите в чувство всех упавших в обморок, и признайтесь самому себе – что представляет собой сверхновая методология разработки ПО, о которой Вы узнали из последнего маркетингового заявления неважно какой корпорации? Или та методика, которую Вы уже используете в своей повседневной работе, и в которую вложено огромное количество ресурсов (учебные материалы, курсы для ведущих специалистов с выездом в другой город/страну, и, наконец, самое ценное – время)?

Вы думаете, что методика служит организующим фактором разработки, что она четко и ясно говорит, как нужно работать, чтобы добиться успеха в ИТ-области. И, наконец, Вы надеетесь получить конкурентное преимущество, «пуская пыль в глаза» потенциальным заказчикам малопонятными для них фразами типа «мы находимся на 6-ом уровне CMM», «реинженеринг бизнес-процессов», «автоматизация хаоса путем выделения ролей в альтернативных деятельностях» и т.п.

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

В чем же секрет, спросите Вы? Я думаю, что успех проекта зависит от двух факторов:

1) доступные ресурсы (в первую очередь, это качество разработчиков, а второе – это время);

2) способ их взаимодействия.

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

Что касается мето