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

Справочник удачных проектных решений при разработке ПО

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

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

Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте. Цель этого справочника — собрать их вместе, дать им краткое описание, и подвигнуть ИТ–сообщество к дальнейшему их поиску и классификации...

Содержание

1. Аннотация
2. Введение
3. Зачем эта книга была написана?
4. Что было задумано
5. Благодарности
6. Методологии разработки ПО
   • 6.1. RUP
   • 6.2. XP
   • 6.3. SADT
   • 6.4. MSF & MOF
   • 6.5. Iconix
7. Единое пространство решений
   • 7.1. Этап ЖЦ «Управление»
     7.1.1. Подбор команды
     
     
     7.1.2. Распределение ответственности
     
     
     7.1.3. Атмосфера в проекте
     
     
     7.1.4. Карьерный рост
     
     
     7.1.5. Производительность труда
     
     
     7.1.6. Коммуникация
     
     
     7.1.7. Планирование
     
     
     7.1.8. Организация процесса
     
     
     7.1.9. Функции разработчиков
     
     
     7.1.10. Обучение персонала
     
     
     7.1.11. Ориентация на задачи
     
     
     7.1.12. Общая среда проекта
     
     
     7.1.13. Интенсивность работы
     
     
     7.1.14. Система приоритетов
     
     
     7.1.15. Документация
   • 7.2. Этап ЖЦ «Анализ» 7.2.1. Представление информации
     7.2.2. Стратегия продвижения
     7.2.3. Две точки зрения
     7.2.4. Глоссарий терминов
     7.2.5. Диаграммы
     7.2.6. CASE-инструменты
     7.2.7. Прецеденты
     7.2.8. Реинженеринг бизнес-процессов
   • 7.3. Этап ЖЦ «Проектирование»7.3.1. Создание объектов
     7.3.2. Паттерны проектирования
     7.3.3. Компонентная разработка
     7.3.4. Концептуальная целостность
     7.3.5. Распределение ошибок
     7.3.6. «Неправильные» решения
     7.3.7. Изобретение колеса
     7.3.8. Алгоритм
     7.3.9. Расслоение системы
     7.3.10. ООП
   • 7.4. Этап ЖЦ «Кодирование»7.4.1. Стандарт кодирования
     7.4.2. Совместное владение кодом
     7.4.3. Пилот-проект
     7.4.4. Острый инструмент
     7.4.5. Структура данных
     7.4.6. Тестовые проекты
     7.4.7. Парное программирование
     7.4.8. Рефакторинг кода
     7.4.9. Инкрементная разработка
   • 7.5. Этап ЖЦ «Тестирование» 7.5.1. Постоянное тестирование
     7.5.2. Автоматизация тестов
     7.5.3. «Узкие» тесты
     7.5.4. Набор данных
     7.5.5. Окружение программы
     7.5.6. Отслеживание ошибок
     7.5.7. Юзабилити
8. Заключение
9. Библиография
10. Авторские права

Аннотация

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

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

Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте. Цель этого справочника — собрать их вместе, дать им краткое описание, и подвигнуть ИТ–сообщество к дальнейшему их поиску и классификации...

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается методологий — то мне кажется, что все они описывают конечный набор различных способов эффективного использования ограниченных ресурсов. Моя точка зрения состоит в том, что число этих способов (удачных проектных решений — УПР) бесконечно и не нужно ограничивать себя только подмножеством их, в рамках методологии Х. Если мы хотим продвинуться в плане успешной разработки программ, то нужно собирать эти решения (аналогично паттернам проектирования) и учиться применять их в нужный момент. Эта книга является попыткой собрать известные мне методы успешной разработки в одном месте.

Приятного чтения и да прибудет с Вами великая сила!

Зачем эта книга была написана?

Эта книга была написана для того, чтобы собрать в единую коллекцию то, что я называю «золотые крупицы знания», распылённые по многочисленным источникам, таким как Интернет, литература и просто народное творчество. Фраза «одна голова хорошо, а две лучше» и принцип «разделяй и властвуй», известный еще со времен Римской империи, сделали для развития программной инженерии больше, чем Microsoft и IBM вместе взятые.

После прочтения любой книги, статьи или сообщения на форуме, меня всегда интересовало — что конкретно этот источник может дать мне полезного? Содержится ли в нём какая-нибудь новая мысль, неизвестная мне ранее? К счастью сказать, в большинстве случаев новые идеи присутствовали, но, к сожалению, были основательно «разведены» посторонней информацией, только замутняющей суть дела.

Поэтому, я старался, по мере возможности, после прочтения очередного труда, составлять его «конспект» с перечнем того, какие основные идеи (неизвестные или мало-очевидные в тот момент для меня) пытался высказать автор.

Например, вот такой результат «препарирования» у меня получился от книги [3]:

• описание бизнес-процесса в виде текста по объему намного меньше, чем в виде графики (это действительно так — самой большой проблемой при работе с диаграммами было то, что рабочий принтер не поддерживал печать на формате А3 и A2...)
• заказчики быстрее прочитают текст, поймут и подпишут его (согласятся с ним или выскажут свои претензии), чем выучат UML (у меня, например, много времени уходило на объяснение стрелки include/ extended для связей между вариантами использования)
• нового сотрудника можно быстрее научить писать текст в формате прецедентов Коберна, чем заставить правильно использовать UML и продукт, его поддерживающий (например, Rational Rose — графический дизайнер которой оставляет желать лучшего)
• хорошая классификация целей — всегда нужно работать на одном уровне целей. Уровень повышается, если задать вопрос «Почему?» и понижается, если задать вопрос «Как?» (это большое искусство — быть на нужном уровне цели — диаграммы получаются мелкие и общие, или слишком большие и детализированные)
• отличный, интуитивно понятный шаблон описания прецедента (основной сценарий из 10 шагов без «если» + расширения основного сценария + дополнительная информация)
• хорошая идея об использовании средств многомерного анализа собранных требований (например, с помощью электронных таблиц) — применение сортировки, группировки по различным атрибутам (важность, срок, модуль, роль)
• и, наконец, на мой взгляд, самое важное — «чем ниже уровень описания целей, тем менее полезными и наглядными становятся диаграммы». Из этого следует идея о «разделении труда» между различными CASE-средствами: для составления диаграмм высокого уровня (сценарий бизнес-процесса, схемы движения информации, диаграмма состояний основного документа системы, взаимодействие программных модулей) использовать инструменты, эффективно применяемые для рисования диаграмм, их связи друг с другом ( Rational Rose, MS Visio), а для более детального описания применять «прецеденты по Коберну».

Должен признаться, что написание этой книги было несколько авантюрным занятием — всегда можно будет получить «укол в спину» от какого-нибудь «мастодонта» с 20-летним стажем разработки и отдавшего большую часть своей жизни продвижению методологии Х, в виде фразы «сделай столько проектов, сколько я, а потом будешь предлагать решения под своим соусом...».

Мне же, с 24-мя годами общего возраста (из которых всего 3 — опыт коммерческой разработки ПО) и 5-ю реализованными проектами, «по общепринятым правилам» нужно подождать лет до 40-ка, а потом уже излагать свои мысли в письменной форме.

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

Мне действительно интересно то ремесло, которой я обладаю, и каждый день я стараюсь сделать свою жизнь (и профессиональную деятельность) как можно лучше и счастливее.

Конечно, на самом деле это несерьёзно — думать, что написание книги, статьи или прочего «пиара самого себя» увеличит мою или чью-то ещё образованность (подробнее, см. статью [2]). Однако всё же это имеет смысл.

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

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

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

Ну и, наконец, это на самом деле огромный кайф — писать книгу. Аналогично сочинению музыки, рисованию картины или вырезанию скульптуры. Красота на самом деле «спасёт мир, меня и программные проекты». Когда ты видишь, как обрывки мыслей и фраз, после терпеливой обработки (мучительного поиска синонимов и выделения деепричастных оборотов) превращаются в связный текст с логичным сюжетом, испытываешь ни с чем не сравнимое удовольствие.

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

Что было задумано

Изначально, у меня возник следующий замысел относительно книги (планировалась только «бумажная» версия). В начале, сделать обзор современных методологий разработки ПО. Затем высказать основную идею о том, что все методологии используют подмножество из общего пространства УПР (см. рис. 1).

Рис. 1 — Единое пространство УПР.

Х — ось этапов ЖЦ ПО;

Y — степень важности УПР для конкретного этапа;

1..9 — ЖЦ (1-фундамент проекта — «Управление»);

Круги — УПР, известные на данный момент;

Виды штриховок – различные методологии разработки ПО, включившие решение в перечень своих постулатов.

В середине — дать пятьдесят чистых листов. Каждый лист представлял бы собой форму для ввода удачного решения, найденного читателем (скорее писателем) в процессе разработки очередного проекта. Форма имела бы стандартную форму: название, код этапа ЖЦ, оценка эффективности, описание и дополнительные источники информации по решению.

Заканчивалась бы книга главами «Содержание» и «Библиография». Естественно, они бы тоже заполнялись вручную. У каждого есть свой «золотой набор», состоящий из книг, WEB-ресурсов и телефонов ближайших пиццерий.

Идея была в том, чтобы каждый написал свою собственную книгу и даже вписал свои инициалы на обложку.

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

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

Также, в мои планы входит (в случае положительной оценки книги квалифицированными разработчиками и наличия у меня свободного времени) дальнейшее развитие теории «единого пространства УПР» в виде сайта в сети Интернет.

Сайт представлял бы собой информационный портал для обмена информацией между разработчиками ПО и пополнения БД УПР. Основные компоненты сайта — форум разработчиков, разбитый по темам (этапам ЖЦ, методологиям, продуктам и прочее), гостевая книга, профили пользователей сайта и самое главное — БД УПР, доступную для публичного доступа. Каждое новое УПР (или изменение описания уже существующего) оценивалось бы пользователями сайта, и в случае положительного результата, добавлялось бы в БД.

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

Кстати, по поводу Брукса. Вы заметили различия между посвящениями 1975 и 1995 годов? В первом упоминаются непосредственный и самый главный начальник. Во втором же — «Нэнси, Божьему дару для меня». Наконец-то в списке жизненных ценностей появляется семья и всё, что с этим связано. Не в этом ли заключается «сущность и акциденция программной инженерии»?

Благодарности

Итак, кто оказал на мое развитие наибольшее влияние и кому я за это благодарен:

• Мои родители — они меня родили ;-) Хотелось бы жить не во время победившего мирового терроризма, но ничего уж тут не поделаешь.
• Моя сестра — за поддержку.
• Технический Университет Молдовы — за получение не самого хорошего высшего технического образования, но лучшего из возможных в республике. Как сказано в книге [15] — «Поставь себе цель. Получи такое образование, какое только можешь, но затем, ради Бога, делай что-нибудь!».
• Стратан Виктор — за отличное объяснение в теории и практике паттернов проектирования, ООП и т.п. Первая версия Rational Rose 98, полученная мной — его заслуга.
• Сердцев Виталий — после наблюдения его шаманства с ассемблером, С++, низкоуровневого программирования, я стал «серьёзно» увлекаться собственной профессией и до сих пор об этом не жалею. Вспоминаю слова нашего завкафедры В. Бешлиу: «Вы пришли в Политех из разных мест и с разными целями, но если вы его закончите, то станете настоящими патриотами своей профессии».
• Смолов Александр — когда баланс между радостями и печалями профессии начинает сдвигаться в сторону последних (см. книгу [6]), я сажусь за компьютер и в течение месяца борюсь с пришельцами в старом добром XCOM (см. сайт [15]), принесенных мне Александром на трёх дискетах со слониками. Грустные мысли от этого проходят, но потом еще долго снятся зеленые человечки ;-)
• Драгонер В.В. — куратор моего диплома. Была поставлена амбициозная цель по созданию аналога Rational Rose. Я написал компилятор исходных текстов С++; Сердцев — графическую оболочку для браузера объектов и диаграмм; Смолов — озвучивание на русском языке результатов анализа текстов через движок MSTextToSpeech. Проект благополучно провалился (к сдаче диплома было готово не более 50% заявленных требований), но неудачи иногда более полезны, чем успехи. Был получен опыт работы с Розой, прочтены материалы о Rational и многое другое.
• Папроцкий И.Б. и Старащук А.И. — работа в ГП «Registru» (см. статью [1]) под их руководством имела огромное значение на мой профессиональный и карьерный уровень.
• Золотухина Е.Б. — за потрясающий курс по системному анализу и разработке ИС.
• Дурлештяну Эдуард (компания BitGenerator) — вместе работать было тяжело, но очень интересно. К большому моему сожалению, тяжесть «перевесила» интерес.
• И, наконец, Топорец Игорь — мой непосредственный начальник на данный момент и настоящий профессионал своего дела. Многие поставленные цели мне удалось достичь быстрее благодаря нему. Очень надеюсь и на обратное (т.е. что я тоже помог достижению его целей).

Методологии разработки ПО

• RUP
• XP
• SADT
• MSF & MOF
• Iconix

RUP

Rational Unified Process — Рациональный Унифицированный процесс.

RUP был создан в 1996г. корпорацией Rational при участии Гради Буча, Айвара Якобсона и Джима Румбаха.

Это поистине фундаментальная работа по описанию успешных методик создания ПО. Жизненные циклы ПО, потоки работ, роли, деятельности, артефакты, продукты, поддерживающие большую часть этапов ЖЦ. Не зря эту методику называют «тяжеловесной». Поддержка языка UML. RUP в качестве самостоятельной базы знаний по объему и значению может сравниться разве что с MSDN.

Основная идея RUP — максимально четко распределить работу каждого участника процесса разработки. Самая большая проблема, по моему мнению, заключается в том, что трудно (или даже невозможно) найти таких людей, которые будут делать только то, что им сказано. Как скоро им надоест заниматься одним и тем же? Не теряется ли чувство ответственности (и как следствие — удовлетворение от результата) за выполненную работу при жестком фиксировании участков работ? Служит ли наличие согласованных интерфейсов по обмену информацией гарантией качества и эффективности работы?

Продукты, поддерживающие методику — в первую очередь, это продукты самой компании Rational . Основной продукт Rose (используется практически на всех этапах разработки), SoDA (автодокументирование), RequisitePro (управление требованиями), ClearQuest (запросы на изменения), ClearCase (версионность), Administrator (управление репозиторием проекта), WorkBrench (настройка корпоративных процессов), Quantify (тестирование скорости кода), Purify (определение утечек памяти), PureCoverage (тест охвата кода), Robot (автоматизированное тестирование), SiteLoad (нагрузочное тестирование), SiteCheck (проверка «мертвых» Web -ссылок). В настоящее время доступен RUP , интегрированный в среду разработки Microsoft . NET (под названием Rational XDE ).

XP

Extreme Programming — Экстремальное программирование.

Рождением (а точнее датой «официальной» регистрации) можно считать 2001г., когда в США, штате Юта 17 сторонников «легковесных» процессов разработки выработали манифест с основными постулатами. Идеологами методики можно считать Кента Бека, Уорда Каннингема и Рона Джеффриса.

Основные принципы: тесная коммуникация, постоянное тестирование, минимум документации и максимум гибкости. Впрочем, лучше привести текст манифеста:

«Мы открываем лучшие способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить:

• Индивидуумов и взаимодействия выше процессов и инструментов
• Работающее ПО выше всеобъемлющей документации
• Сотрудничество с заказчиками выше согласований условий договора
• Реагирование на изменения выше соблюдения плана

Это означает, что, хотя элементы в правой части также имеют свою ценность, но больше мы ценим элементы, расположенные слева».

Довольно краткие и понятные формулировки, делающие доступными высказанные идеи самым широким массам. ХР впервые озвучила некоторые совершенно революционные принципы разработки. «Это вам не понадобится», «Ищите самое простое решение, которое может сработать», «Любые сидящие рядом два разработчика могут поменять всё что угодно в системе», «Заказчик в любой момент может изменить требования» и др.

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

Осталась следующая критика:

• Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм документов по взаимодействию (ТЗ, ТП). Во-вторых, в более быстрых итерациях (нужно помочь заказчику сформулировать и откорректировать своё видение системы)
• Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке сложных систем. Если приложение простое, зачем тратить на него своё время?». В сложном и интересном проекте, с «богатой» предметной областью было бы преступной халатностью не сформировать в самом начале каркас системы, основные принципы его функционирования. Конечно, «настоящие ХР-шники» стоически воспримут информацию в середине проекта о том, что обнаружился прецедент, заставляющий переделать большую часть кода (или ещё хуже выбросить его). Но я считаю это совершенно недопустимым.
• Десятки userstory (бумажки с несколькими предложениями, характеризующими прецедент пользователя), оставшиеся после завершения проекта, не могут служить в качестве надежной документации. Получается, что ХР нацелена на быструю разработку ПО, но не на его сопровождение. Приведу цитату из книги [4] по поводу неудачи проекта 3 C, выполненного посредством ХР (расчет зарплаты для Chrysler — могу подтвердить, что зарплата при своей внешней простоте одна из самых трудных областей бухгалтерии, в которой «утонула» не одна команда программистов). «Когда ушло достаточно много сотрудников, незаписанные сведения о проекте и групповая память были утрачены». Я думаю, что апологеты ХР переусердствовали с минимизацией документации. Что для студентов может выглядеть привлекательным, серьезных разработчиков должно насторожить.

Должен поделиться собственным ощущением от «работы в стиле ХР». В отличие от RUP (или любой другой методики с фиксированием результатов этапов, посредством тех. задания, тех. проекта и т.п.) ХР дает ощущение неуверенности и анархии в начале проекта. Бизнес-требования и архитектура меняются так быстро, что, просидев пару дней дома можно потом не узнать структуру базовых классов (даже если ты сам её придумал).

Сразу начинаешь понимать положение ХР о 40-часовой рабочей недели без переработок. Зачем до 22_00 трудиться в поте лица над модулем, который завтра может вообще не понадобиться?

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

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

Продуктов, поддерживающих методику просто нет. И это, наверное, самое главное достоинство. Не станешь же, в самом деле, считать «ХР-продуктом» текстовый редактор или средство обеспечения версионности.

SADT

Structured Analysis and Design Technique — Методология структурного анализа и проектирования.

Известна как разработка компании SofTech , либо как только функциональный вариант в правительственной версии (IDEF0). Её начали применять с 1973г. во многих областях, таких как бизнес, производство, оборона, связь и организация проектирования.

Диаграммы в стандарте IDEF 0 имеют несомненное преимущество для функционального моделирования системы. Однако представление модулей системы в виде блоков с набором входов и выходов и набором управляющих воздействий на них хорошо раскрывает только высокоуровневые структурные особенности системы. В этом SADT успешно конкурирует с диаграммами деятельности языка UML .

В SADT я не нашел механизмов для дальнейшей разработки системы, от сбора требований к реализации, тестированию и внедрению. Возможно, такая задача и не ставилась идеологами. Методика серьезно проигрывает остальным по охвату этапов ЖЦ ПО, сконцентрировавшись только на сборе требований и бизнес-моделировании.

SADT в полной мере реализует идею «большого предварительного проектирования в начале разработки» с целью уменьшить «просачивание» ошибок на более поздние этапы ЖЦ, где дороже их исправление. Из-за жесткой декомпозиции процесса разработки методику можно считать «прародителем» RUP .

MSF & MOF

Microsoft Solutions Framework (Набор решений от MS) и Microsoft Operations Framework (Набор операций от MS).

По замыслу составителей методики, она объединяет лучшие принципы каскадной и спиральной моделей разработки ПО, так сказать «лучшее из двух миров». Естественно, для достижения успешного результата предлагаются решения и продукты непосредственно от Microsoft.

Однако нельзя не признать огромную заслугу компании Microsoft в сфере компьютерной индустрии. Стоит изучить MSF только из-за того, что «так делает лидер».

Например, меня заинтересовало исследование, посвященное объединению ролей в малых проектах. Это особенно актуально для СНГ, т.к. большая часть ИТ-проектов, декларируемых здесь как большие и сложные, по меркам западных компаний являются мелкими и средними.

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

Толковая документация по практике оценки рисков при создании ПО. Ну и конечно, замечательные УПР в области продажи продуктов.

Iconix

Что-то среднее между очень громоздким RUP и весьма компактной ХР. Я считаю самым важным отличием от остальных методик введение диаграмм для анализа пригодности. Книга замечательная, начиная от TOP10 ошибок для каждого этапа разработки ПО и заканчивая постоянными напоминаниями вида «Над этим долго не работайте, сейчас у вас нет полной информации, чтобы тратить на это много времени».

Единое пространство решений

1.  

   • Этап ЖЦ «Управление»

     1. Подбор команды
     
     
     2. Распределение ответственности
     
     
     3. Атмосфера в проекте
     
     
     4. Карьерный рост
     
     
     5. Производительность труда
     
     
     6. Коммуникация
     
     
     7. Планирование
     
     
     8. Организация процесса
     
     
     9. Функции разработчиков
     
     
     10. Обучение персонала
     
     
     11. Ориентация на задачи
     
     
     12. Общая среда проекта
     
     
     13. Интенсивность работы
     
     
     14. Система приоритетов
     
     
     15. Документация

Подбор команды

Наиболее полно освещающая эту тему, на мой взгляд, мне показалась книга «Цель — собрать команду проекта» (Computerworld , #16/2004, Кэтлин Меламьюка) . Очень важно, что в ней рассмотрен процесс найма специалистов именно в области разработки ИС, хотя многое применимо и для других областей.

Также, мне показались довольно информативными (хотя и не без примеси саморекламы) работы Алистэра Коуберна на сайте maxkir.com

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

Спорное утверждение. Суперзвездами не рождаются, ими становятся. Все мы когда-то были начинающими программистами, поэтому я думаю, талантливые новички тоже имеют право быть в команде крупного проекта.

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

Распределение ответственности

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

Можно привести цитату Александра II: «Россией управлять несложно, ...но бессмысленно». Большие системы требуют большего управления. Однако, внутренняя самоорганизация, по моему мнению, эффективнее жесткого внешнего управления. В книге «Проектирование компонентов уровня данных и передача данных между уровнями» приведен пример с компанией IBM, в которой более широкое делегирование полномочий от центра структурным подразделениям позволило кардинально увеличить управляемость всей компании.

Я думаю, что если не доверяешь людям, которые участвуют в проекте, то лучше вообще не начинать такой проект. Поэтому, лучше дать людям власти столько, сколько они смогут «унести». В конечном счете, если кто-то не справится с работой, его всегда можно уволить.

Когда каждый отвечает за свою узкий участок работы, это, по моему мнению, приводит к большим проблемам с качеством продукта и бессмысленной борьбе функциональных подразделений за перекладку ответственности между собой.

Атмосфера в проекте

Хорошие человеческие отношения между участниками проекта очень важны как для удачного завершения текущего проекта, так и для работы в будущем. В книге [4] говорится: «Удачная методология использовалась в проекте или нет, можно определить, если задать разработчикам вопрос — захотят ли они еще раз участвовать в аналогичном проекте или нет».

То же самое относится и к атмосфере проекта. Если рабочий день проходит в бесконечных разрешениях конфликтов; работники четко разделены на «касты» и не делятся информацией и знаниями с «противоположным лагерем»; нет благоприятных гигиенических факторов работы, наподобие отдельного телефона, звукоизоляции, удобного рабочего места, достойной оплаты труда и т.п., то вряд ли можно ожидать от работника, что он захочет испытать подобное еще раз (см. книгу «Автоматизация хаоса», Андрей Акопянц).

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

Я считаю это ошибкой. Необходимо использовать любую возможность для повышения производительности труда, начиная от бесплатной пиццы за внеурочную работу и заканчивая персональными абонентами в фитнес зал для поддержки спортивной формы сотрудников.

Карьерный рост

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

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

Работодатель должен (несмотря на кажущуюся убыточность вложений на «быстрый» Интернет, новые книги, курсы и даже поездки на конференции типа PDC — см. статью «Формула успеха», Автор Eric Sink, Перевод: Лев Курц) обеспечить рост (профессиональный, карьерный) своих сотрудников. В конечном счете, все остаются в выигрыше — сотрудник становится более удовлетворенным работой, а организация получает более профессиональные кадры.

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

Я согласен с мыслью, высказанной в той же статье «Формула успеха»:

Производительность труда

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

Намного выгоднее, решить возникшую проблему еще в зародыше, когда она еще не привела к явному конфликту. Люди — слишком ценный ресурс, чтобы их терять в процессе неуклюжих действий по решению проблемы.

Коммуникация

Очень многое в проекте зависит от скорости и способов передачи информации. Конечно, хотелось бы (как того требует методология XP) наличия единой комнаты (deathmatch room), в которой бы бок о бок находились бы все разработчики, совместно с представителем заказчика, и никто кроме них. Однако, в большинстве случаев это невозможно (не собираться же, в самом деле, всем разработчикам в актовом зале компании).

Поэтому, необходимо использовать максимально эффективную из доступных средств коммуникации.

Для больших бюрократических (чаще государственных) организаций подойдут документы в бумажном виде, передающиеся от одного согласующего лица другому. Для малых ISV (Independent Software Vendor — независимый разработчик ПО) ничего лучше, чем совместная работа разработчиков «на расстоянии вытянутой руки» пока не придумано. Компании, имеющие в наличии «распределённые» географически команды, используют видеоконференции и различные средства взаимодействия через Web.

Кроме эффективной коммуникации необходимо применять и её отсутствие, т.е. противодействовать так называемым «информационным сквознякам» — см. книгу «Rational Rose, BPwin и другие — аспект анализа бизнес-процессов». Нет ничего хуже, чем во время разработки слышать (видеть и т.п.) постороннюю информацию, не имеющую отношения к текущему проекту (например, сидеть в одной комнате со служащими отдела сопровождения, продаж или рекламы).

Планирование

Первое правило планирования — используйте его, каким бы бессмысленным оно вам не казалось. У большинства разработчиков ПО сложился весьма заметный пессимизм по отношению к планам (и совсем пренебрежительное отношение к людям, занимающимся планированием). Программирование — это не строительство, где точно известно, что кирпичную стену размером 5 на 2 метра строитель сложит за час, а раствор марки Х застывает за 10 минут.

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

Цель планирования — «Знать, на сколько проект отстаёт и вовремя перераспределить задачи, чтобы пусть и с меньшей функциональностью, но уложиться в график» — см. книгу «Чтобы было яснее», ThoughtWorks , Мартин Фаулер.

Большие и детально проработанные планы, как правило, проваливаются — слишком велика погрешность в каждой компоненте графика. Поэтому, я считаю рациональным практику «маленьких победоносных войн» (итеративная разработка), когда определяются наиболее приоритетные задачи, выполнимые в пределах 1-4-х недель и команда планирует и старается выполнить их в заявленные малыесроки.

Организация процесса

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

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

Еще хуже, когда чересчур жесткая фиксация процесса разработки мешает эффективной разработке проекта, «не влезающего» в рамки, очерченные методикой. Как правило, каждый проект уникален, поэтому я считаю рациональным использовать набор УПР, и гибко их использовать в той или иной ситуации.

Как можно понять из книги «Rational Rose, BPwin и другие — аспект анализа бизнес-процессов», «главное — отрубить противнику руку, а не воспользоваться определенным боевым стилем».

Главная черта успешной ИТ-компании, занимающейся коммерческой разработкой ПО, по моему мнению, является гибкость в вопросах «настройки» под различные типы клиентов (проектов, предметных областей), а не сертификаты на соответствие «N-го» уровня CMM (см статью «Взрывная волна CMM»).

Функции разработчиков

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

Я не буду с этим спорить. Но я считаю, что есть одно важное различие между ведением военных действий (и их успешным завершением) и разработкой программных проектов. Оно заключается в том, что люди на войне (по мнению штаба) взаимозаменяемы. Т.е. ради захвата района Х, можно пустить на «пушечное мясо» дивизию Y, а потом провести мобилизацию и заново создать дивизию Y.

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

Существует такой вопрос: «Сколько разработчиков должен задавить грузовик, чтобы проект провалился? Худший ответ — одного». То есть речь идет не только об уникальности каждого сотрудника, но и об устойчивости команды в случае потери одного из них.

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

Обучение персонала

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

«Новый человек» в начале своей работы нуждается в благоприятном окружении и чувстве связности своей работы c работой остальной компании. Этого можно добиться путем участия новичка в обсуждениях текущих проектов (даже не имеющих отношения к основной работе, поставленной перед сотрудником). Главное — добиться ощущения единой команды и её усиления посредством использования знаний, опыта и вообще эффекта «свежей головы» новичка.

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

Иногда руководство видит единственное решение в «спасении проекта» только в добавлении новых людских ресурсов. В таких случаях, я считаю, необходимо проанализировать, на что тратят время ключевые разработчики, и поставить перед ними только приоритетные задачи (доработку проекта), а второстепенные задачи передать на исполнение другому персоналу, в т.ч. новичкам.

Ориентация на задачи

В книге «Rational Rose, BPwin и другие — аспект анализа бизнес-процессов» приводился пример с тестировщиками, которых сильно беспокоило отсутствие видимого прогресса в работе программистов. Чтобы минимизировать отвлечение программистов от работы, было принято решение вывесить список задач в проекте и отметки об их выполнении в коридоре, доступном для всеобщего обозрения. Вопросы сразу прекратились.

Данный пример демонстрирует, как важно для морального духа команды иметь «перед глазами» информацию о текущем прогрессе каждого элемента проекта. Данная техника оказывает самое благотворное влияние на разработчиков, в связи с ощущением того, что «прошел ещё один день, и зачеркнуто еще X пунктов». Каждому захочется выделиться, чтобы сделать больше, чем остальные.

При этом не важно, какими инструментами это будет достигнуто: планом в MS Project, списком задач в MS SharePoint или просто файлом MS Word с нумерованным списком задач и местом для галочки.

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

Поэтому, скорее всего можно представить разработчика, который знает, что до выходных ему нужно сделать функции X, Y и Z и который отказывается от обеда, чтобы успеть до этого срока. Нежели того же сотрудника, активноработающего в отсутствие четкого представления о прогрессе команды и доли своего участия в нём.

Общая среда проекта

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

Вопрос не только в составлении такого набора документов, но и в том, чтобы все участники проекта имели доступ к этой информации.

В той же книге забавно было наблюдать, как автор полностью поменял свою точку зрения «в отношении сокрытия информации» под влиянием идей Дэвида Парнаса.

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

И вот почему:

• Яркие технические решения в разных частях системы провоцируют их обсуждение разными людьми и как следствие — повышается их качество
• Заставив «гуру» выложить свои идеи на бумаге, увеличивается скорость обучения низко-квалифицированных сотрудников
• Четкое разделение потоков информации усиливает изоляцию групп (аналитиков, программистов, тестеров) друг от друга
• И, наконец, лучше иметь обилие информации (с возможностью выбора наиболее полезной на данный момент), чем её недостаток.

Интенсивность работы

Совет будет несколько смешной, но действенный: «Дозируйте свою энергию, больше отдыхайте». В книге «Rational Rose, BPwin и другие — аспект анализа бизнес-процессов» приведён почти анекдотический случай. Во время работы автора в центральном банке Норвегии выяснилось, что рабочий день длится только до 15:30 (все уходят домой и общаться просто не с кем). В 17:00 отключается освещение, кроме аварийного, а в 19:00 вообще всё замирает. Так начальство заботится о том, чтобы сотрудники не перетрудились на рабочих местах.

Однако, смысл в том, что постоянное перенапряжение вредно. Лучше каждый день быть производительным на все 100%, чем в понедельник работать до 22:00, а в течение остальной недели проявлять активность дохлой рыбы на солнцепеке.

Многие проблемы решаются быстрее (во всяком случае, не кажутся такими страшными), если предварительно хорошо отдохнуть.

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

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

Система приоритетов

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

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

В этом ключе привлекательна методика ХР, предполагающая наличие заказчика «в одной комнате с программистами» и наиболее быстро реагирующая на изменение его требований.

Однако я всегда с большим скепсисом относился к такому стилю взаимодействия с заказчиком. Заказчик в большинстве случаев слабо осведомлен о возможностях, предоставляемых программной инженерией. Поэтому, основная черта успешной разработки, по моему мнению, — это не общение по телефону в стиле «хорошо, ваша новая задумка будет реализована в первую очередь, а написание остальных приостановлено», а как можно более раннее выявление возможностей системы, стратегически важных для бизнеса.

Документация

Речь идёт не о доступности информации в проекте (это УПР уже обсуждалось), а о составлении открытой и качественной проектной документации вообще (см. статью «Формула успеха»).

Существует распространённое мнение, согласно которому «настоящий программист» не использует (разрабатывает, читает и т.п.) никакую документацию, тем более диаграммы (см. книги по ХР), а комментарии кода вообще издают неприятные запахи (сказано было другое, но подразумевалось это — см. книгу «Парное программирование: преимущества и недостатки»).

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

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

Наличие качественной документации — гарантия устойчивости проекта (не будет мест, понятных только одному разработчику). Она дисциплинирует как этапы разработки (чтобы выложить мысли на бумаге, придется «причесать» их в понятный всем вид), так и облегчает процесс сопровождения (работники службы поддержки — чаще всего не первоначальные разработчики, и без документации им будет совсем плохо).