«Ну вот!» – скажете Вы, прочтя заголовок данной книги. «Ещё один новоявленный пророк – самозванец учит всех жизни, как нужно выполнять программные проекты! У нас и так есть методология, которая отлично справляется со всеми проблемами. Мы адаптировали её под свои нужды, и вроде бы проблем стало меньше…»
И Вы будете правы, … но наполовину. Я ни в сколькой мере не считаю себя новоявленной мессией, который «наконец-то расскажет, как добиться успеха». Но меня действительно интересуют методы эффективной разработки ПО (и как следствие этого знания – повышение своего профессионального мастерства разработчика ИС).
Эта книга не является обоснованием в письменном виде против какой-либо определённой методологии. Хотя ранее, на форумах тематических сайтов, я позволял себе резкие высказывания по поводу различных новомодных методик разработки, которых с религиозным пылом фанатиков отстаивали их ярые приверженцы.
Вы не найдёте здесь и доводов в пользу какой-нибудь определённой методологии, как можно было бы предположить исходя из того, что я долгое время являлся ревностным сторонником методологии RUP, активно занимался её изучением и внедрением в деятельность компании, в которой работал. Причем, в тот момент времени, во мне действительно была уверенность в том, что жесткое разделение участников разработки по ролям (и соответствующим функциональным обязанностям) сможет сделать процесс разработки управляемым и успешным, а его участников – более удовлетворёнными своей работой.
В связи с этим, своей книгой я рискую навлечь на себя праведный гнев сторонников и защитников всех ныне существующих (и которые появятся годами позже) методик разработки ПО. Однако каждый должен иметь возможность высказать своё мнение, и я воспользуюсь этим правом.
Я уверен, что правда о различных методологиях заключается в том, что их не существует…
А теперь, приведите в чувство всех упавших в обморок, и признайтесь самому себе – что представляет собой сверхновая методология разработки ПО, о которой Вы узнали из последнего маркетингового заявления неважно какой корпорации? Или та методика, которую Вы уже используете в своей повседневной работе, и в которую вложено огромное количество ресурсов (учебные материалы, курсы для ведущих специалистов с выездом в другой город/страну, и, наконец, самое ценное – время)?
Вы думаете, что методика служит организующим фактором разработки, что она четко и ясно говорит, как нужно работать, чтобы добиться успеха в ИТ-области. И, наконец, Вы надеетесь получить конкурентное преимущество, «пуская пыль в глаза» потенциальным заказчикам малопонятными для них фразами типа «мы находимся на 6-ом уровне CMM», «реинженеринг бизнес-процессов», «автоматизация хаоса путем выделения ролей в альтернативных деятельностях» и т.п.
Однако, внедрение одной и той же методики в разных организациях и проектах (а зачастую и в фазах разработки одного проекта!) даёт почему-то совершенно различные результаты. То, что в одних случаях работало хорошо и является стимулирующим фактором, в других – наоборот, тормозит разработку.
В чем же секрет, спросите Вы? Я думаю, что успех проекта зависит от двух факторов:
1) доступные ресурсы (в первую очередь, это качество разработчиков, а второе – это время);