Введение
«Ну вот!» – скажете Вы, прочтя заголовок данной книги. «Ещё один новоявленный пророк – самозванец учит всех жизни, как нужно выполнять программные проекты! У нас и так есть методология, которая отлично справляется со всеми проблемами. Мы адаптировали её под свои нужды, и вроде бы проблем стало меньше…»
И Вы будете правы, … но наполовину. Я ни в сколькой мере не считаю себя новоявленной мессией, который «наконец-то расскажет, как добиться успеха». Но меня действительно интересуют методы эффективной разработки ПО (и как следствие этого знания – повышение своего профессионального мастерства разработчика ИС).
Эта книга не является обоснованием в письменном виде против какой-либо определённой методологии. Хотя ранее, на форумах тематических сайтов, я позволял себе резкие высказывания по поводу различных новомодных методик разработки, которых с религиозным пылом фанатиков отстаивали их ярые приверженцы.
Вы не найдёте здесь и доводов в пользу какой-нибудь определённой методологии, как можно было бы предположить исходя из того, что я долгое время являлся ревностным сторонником методологии RUP, активно занимался её изучением и внедрением в деятельность компании, в которой работал. Причем, в тот момент времени, во мне действительно была уверенность в том, что жесткое разделение участников разработки по ролям (и соответствующим функциональным обязанностям) сможет сделать процесс разработки управляемым и успешным, а его участников – более удовлетворёнными своей работой.
В связи с этим, своей книгой я рискую навлечь на себя праведный гнев сторонников и защитников всех ныне существующих (и которые появятся годами позже) методик разработки ПО. Однако каждый должен иметь возможность высказать своё мнение, и я воспользуюсь этим правом.
Я уверен, что правда о различных методологиях заключается в том, что их не существует…
А теперь, приведите в чувство всех упавших в обморок, и признайтесь самому себе – что представляет собой сверхновая методология разработки ПО, о которой Вы узнали из последнего маркетингового заявления неважно какой корпорации? Или та методика, которую Вы уже используете в своей повседневной работе, и в которую вложено огромное количество ресурсов (учебные материалы, курсы для ведущих специалистов с выездом в другой город/страну, и, наконец, самое ценное – время)?
Вы думаете, что методика служит организующим фактором разработки, что она четко и ясно говорит, как нужно работать, чтобы добиться успеха в ИТ-области. И, наконец, Вы надеетесь получить конкурентное преимущество, «пуская пыль в глаза» потенциальным заказчикам малопонятными для них фразами типа «мы находимся на 6-ом уровне CMM», «реинженеринг бизнес-процессов», «автоматизация хаоса путем выделения ролей в альтернативных деятельностях» и т.п.
Однако, внедрение одной и той же методики в разных организациях и проектах (а зачастую и в фазах разработки одного проекта!) даёт почему-то совершенно различные результаты. То, что в одних случаях работало хорошо и является стимулирующим фактором, в других – наоборот, тормозит разработку.
В чем же секрет, спросите Вы? Я думаю, что успех проекта зависит от двух факторов:
1) доступные ресурсы (в первую очередь, это качество разработчиков, а второе – это время);
2) способ их взаимодействия.
Если есть доступные ресурсы, и они взаимодействуют максимально эффективным способом, то я считаю, что проект имеет значительно больше шансов родить что-то действительно стоящее.
Что касается методологий – то мне кажется, что все они описывают конечный набор различных способов эффективного использования ограниченных ресурсов. Моя точка зрения состоит в том, что число этих способов (удачных проектных решений – УПР) бесконечно и не нужно ограничивать себя только подмножеством их, в рамках методологии Х. Если мы хотим продвинуться в плане успешной разработки программ, то нужно собирать эти решения (аналогично паттернам проектирования) и учиться применять их в нужный момент. Эта книга является попыткой собрать известные мне методы успешной разработки в одном месте.
Приятного чтения и да прибудет с Вами великая сила!
Зачем эта книга была написана?
Эта книга была написана для того, чтобы собрать в единую коллекцию то, что я называю «золотые крупицы знания», распылённые по многочисленным источникам, таким как Интернет, литература и просто народное творчество. Фраза «одна голова хорошо, а две лучше» и принцип «разделяй и властвуй», известный еще со времен Римской империи, сделали для развития программной инженерии больше, чем Microsoft и IBM вместе взятые.
После прочтения любой книги, статьи или сообщения на форуме, меня всегда интересовало – что конкретно этот источник может дать мне полезного? Содержится ли в нём какая-нибудь новая мысль, неизвестная мне ранее? К счастью сказать, в большинстве случаев новые идеи присутствовали, но, к сожалению, были основательно «разведены» посторонней информацией, только замутняющей суть дела.
Поэтому, я старался, по мере возможности, после прочтения очередного труда, составлять его «конспект» с перечнем того, какие основные идеи (неизвестные или мало-очевидные в тот момент для меня) пытался высказать автор.
Например, вот такой результат «препарирования» у меня получился от книги [3]:
1. описание бизнес-процесса в виде текста по объему намного меньше, чем в виде графики (это действительно так – самой большой проблемой при работе с диаграммами было то, что рабочий принтер не поддерживал печать на формате А3 и A2…)
2. заказчики быстрее прочитают текст, поймут и подпишут его (согласятся с ним или выскажут свои претензии), чем выучат UML (у меня, например, много времени уходило на объяснение стрелки include/extended для связей между вариантами использования)
3. нового сотрудника можно быстрее научить писать текст в формате прецедентов Коберна, чем заставить правильно использовать UML и продукт, его поддерживающий (например, Rational Rose – графический дизайнер которой оставляет желать лучшего)
4. хорошая классификация целей – всегда нужно работать на одном уровне целей. Уровень повышается, если задать вопрос «Почему?» и понижается, если задать вопрос «Как?» (это большое искусство – быть на нужном уровне цели – диаграммы получаются мелкие и общие, или слишком большие и детализированные)
5. отличный, интуитивно понятный шаблон описания прецедента (основной сценарий из 10 шагов без «если» + расширения основного сценария + дополнительная информация)
6. хорошая идея об использовании средств многомерного анализа собранных требований (например, с помощью электронных таблиц) – применение сортировки, группировки по различным атрибутам (важность, срок, модуль, роль)
7. и, наконец, на мой взгляд, самое важное – «чем ниже уровень описания целей, тем менее полезными и наглядными становятся диаграммы». Из этого следует идея о «разделении труда» между различными CASE-средствами: для составления диаграмм высокого уровня (сценарий бизнес-процесса, схемы движения информации, диаграмма состояний основного документа системы, взаимодействие программных модулей) использовать инструменты, эффективно применяемые для рисования диаграмм, их связи друг с другом (Rational Rose, MS Visio), а для более детального описания применять «прецеденты по Коберну».
Должен признаться, что написание этой книги было несколько авантюрным занятием – всегда можно будет получить «укол в спину» от какого-нибудь «мастодонта» с 20-летним стажем разработки и отдавшего большую часть своей жизни продвижению методологии Х, в виде фразы «сделай столько проектов, сколько я, а потом будешь предлагать решения под своим соусом…».
Мне же, с 24-мя годами общего возраста (из которых всего 3 – опыт коммерческой разработки ПО) и 5-ю реализованными проектами, «по общепринятым правилам» нужно подождать лет до 40-ка, а потом уже излагать свои мысли в письменной форме.
Но к черту все эти правила! Нужно жить сегодняшним днём, и если тебе представилась возможность «прыгнуть выше головы», то нужно делать это здесь и сейчас. Вероятность поднять здоровенный железный шкаф ничтожна мала (см. фильм «Пролетая над гнездом кукушки»). Но это вообще никогда не удастся, если не сделать хотя бы одну попытку.
Мне действительно интересно то ремесло, которой я обладаю, и каждый день я стараюсь сделать свою жизнь (и профессиональную деятельность) как можно лучше и счастливее.
Конечно, на самом деле это несерьёзно – думать, что написание книги, статьи или прочего «пиара самого себя» увеличит мою или чью-то ещё образованность (подробнее, см. статью [2]). Однако всё же это имеет смысл.
Написание книги увеличивает мою «виртуальную образованность» (т.е. то, насколько хорошо меня воспринимают потенциальные и текущие работодатели). Всё это (встреча с новыми людьми, познавание новой информации) увеличивает мои шансы повысить свою «реальную образованность» (т.е. та реальная польза, которую я приношу проектам, в которых участвую). Повышение «реальной образованности» толкает меня на публикацию нового материала. И так далее.
Этой книгой мне хотелось доказать (в первую очередь самому себе), что мир проще, чем кажется на первый взгляд и добиться в нём успеха действительно реально, независимо от тех препятствий, которые постоянно возникают на нашем пути.
Есть такая байка про миллионера, который сказал: «Я могу рассказать вам, каким образом я заработал каждый свой миллион. Кроме первого». Действительно, если воспринимать то, что называется «жизненным успехом» в качестве восхождения наверх по бесконечной лестнице, то наиболее трудно сделать именно первый шаг. Я постарался сделать для себя эту книгу «экзаменом» на право подняться на первую ступень.
Ну и, наконец, это на самом деле огромный кайф – писать книгу. Аналогично сочинению музыки, рисованию картины или вырезанию скульптуры. Красота на самом деле «спасёт мир, меня и программные проекты». Когда ты видишь, как обрывки мыслей и фраз, после терпеливой обработки (мучительного поиска синонимов и выделения деепричастных оборотов) превращаются в связный текст с логичным сюжетом, испытываешь ни с чем не сравнимое удовольствие.
Программирование тоже дает такое ощущение. Это связано с тем моментом, когда разрозненная информация, требования, приказы, инструкции, слухи и досужие домыслы, относящиеся к системе, как огромные неповоротливые булыжники вдруг складываются у тебя в голове в единую скульптуру. Каждый пазл становится на своё место и остаётся только брызнуть на них живой водой. Каменная статуя просыпается и рукотворное существо начинает делать свои первые шаги…. Это одна из самых больших радостей нашей профессии.
Что было задумано
Изначально, у меня возник следующий замысел относительно книги (планировалась только «бумажная» версия). В начале, сделать обзор современных методологий разработки ПО. Затем высказать основную идею о том, что все методологии используют подмножество из общего пространства УПР (см. рис. 1).
Рис. 1 – Единое пространство УПР.
Х – ось этапов ЖЦ ПО;
Y – степень важности УПР для конкретного этапа;
1..9 – ЖЦ (1-фундамент проекта – «Управление»);
Круги – УПР, известные на данный момент;
Виды штриховок – различные методологии разработки ПО, включившие решение в перечень своих постулатов.
В середине – дать пятьдесят чистых листов. Каждый лист представлял бы собой форму для ввода удачного решения, найденного читателем (скорее писателем) в процессе разработки очередного проекта. Форма имела бы стандартную форму: название, код этапа ЖЦ, оценка эффективности, описание и дополнительные источники информации по решению.
Заканчивалась бы книга главами «Содержание» и «Библиография». Естественно, они бы тоже заполнялись вручную. У каждого есть свой «золотой набор», состоящий из книг, WEB-ресурсов и телефонов ближайших пиццерий.
Идея была в том, чтобы каждый написал свою собственную книгу и даже вписал свои инициалы на обложку.
Но затем я просмотрел свою домашнюю библиотеку, и обнаружил, что во многих из них идея о «дополнении» книги читателем уже реализована. Это так называемые листы «для заметок». Заметки у меня отсутствовали…
Поэтому, я решил подойти к творческому процессу более профессионально, и таким образом, книга обрела настоящий вид.
Также, в мои планы входит (в случае положительной оценки книги квалифицированными разработчиками и наличия у меня свободного времени) дальнейшее развитие теории «единого пространства УПР» в виде сайта в сети Интернет.
Сайт представлял бы собой информационный портал для обмена информацией между разработчиками ПО и пополнения БД УПР. Основные компоненты сайта – форум разработчиков, разбитый по темам (этапам ЖЦ, методологиям, продуктам и прочее), гостевая книга, профили пользователей сайта и самое главное – БД УПР, доступную для публичного доступа. Каждое новое УПР (или изменение описания уже существующего) оценивалось бы пользователями сайта, и в случае положительного результата, добавлялось бы в БД.
Однако получилось то, что получилось. Что касается продолжения книги, то я думаю, что оно будет написано в тот момент, когда мои профессиональные познания выйдут на качественно новый уровень. Может быть, на это понадобиться лет двадцать (как у Брукса), а может раньше.
Кстати, по поводу Брукса. Вы заметили различия между посвящениями 1975 и 1995 годов? В первом упоминаются непосредственный и самый главный начальник. Во втором же – «Нэнси, Божьему дару для меня». Наконец-то в списке жизненных ценностей появляется семья и всё, что с этим связано. Не в этом ли заключается «сущность и акциденция программной инженерии»?