Третий инвариант: любой код стоит денег. Знакомство с реальной стоимостью кода и применение систем резервного копирования. Информация, при всей ее невесомости, стоит дорого. Можно оценивать ее в человеко-часах, например. Необходимо показать студентам, что каждое изменение кода, каждый документ стоит определенных денег. И необходимо заботиться об их сохранности. При всей очевидности этого подхода реальность такова, что разработчики вполне могут откладывать создание резервной копии исходников (либо через систему бэкапов, либо, что более правильно, через систему контроля версий [В терминологии систем контроля версий такая операция называется «commit» или «фиксация изменений»]) до тех пор, пока не будет потеряна многочасовая работа. Тем не менее это мало кого волнует, хотя все всё знают. Так, например, все знают о необходимости пристегивания ремнями, в автошколе экзамены начинаются именно с этого, краш-тесты открыто демонстрируют полезность ремней безопасности, однако на улице легко можно увидеть машину с ребенком, «болтающимся» в салоне, а пойманные гаишниками водители горазды придумывать себе оправдания. Теоретическое и практическое знания – разные вещи. В данном блоке я бы применил подход, аналогичный системе рейдов ГИБДД, а именно случайное форматирование нескольких машин в классе перед зачетной сессией. Все, кто хранил документы только на локальной машине (или в каталоге файл-сервера), смогут ощутить всю прелесть использования (или игнорирования) бэкапов. Возможно, полученный эффект заставит аккуратнее относиться к информации. Несомненно, 99 процентов читателей назовут такие методы зверскими. Однако опыт показывает, что лучше потерять на этом этапе, чем при сдаче коммерческого проекта – дешевле выйдет.
Четвертый инвариант: работа с требованиями [Не секрет, что продвижение компании по CMMI-лестнице определяется умением компании бороться с хаосом, то есть умением превращать процедуру разработки ПО в воспроизводимый процесс. И фундаментом для структуризации являются требования. Если провести аналогии и утрировать, то требования описывают точку, куда должна добраться вызванная машина такси, какими характеристиками она должна обладать и в какое время она должна подъехать]. Сбор, фиксация, изменение, управление. Несмотря на более чем пятидесятилетнее существование компьютерной отрасли, многие компании-разработчики ПО по-прежнему прикладывают значительные усилия для сбора и документирования требований, а также управления ими. Недостаточный объем информации, поступающей от пользователей, требования, сформулированные не полностью, их кардинальное изменение – вот основные причины, из-за которых командам, работающим в области информационных технологий, зачастую не удается вовремя и в рамках бюджета предоставить клиентам всю запланированную функциональность. Многие разработчики не умеют спокойно и профессионально собирать требования пользователей к ПО. Однако разработка ПО включает, по крайней мере, столько же общения, сколько и обычная работа с компьютером, но зачастую мы делаем акцент на работе с компьютером и не уделяем достаточно внимания общению. Пятый инвариант: основы управления проектами и управления рисками. Управление проектами является самостоятельной дисциплиной, но в рамках курса уместно привести базовые элементы и рассказать о специфике управления проектами в области разработки ПО. Любой современный проект (не только разработка ПО) требует десятков и сотен тысяч человекочасов. Для того чтобы такой проект имел шансы на успешное завершение, необходим план его реализации (управление проектом), который должен включать в себя анализ возможных неудачных сценариев и способов борьбы с ними (управление рисками). Ведь любая затяжка сроков приводит к удорожанию продукта, если не к краху компании. Нужно хотя бы вкратце рассказать о способах управления проектами, о том, чем занимается руководитель проекта, каковы его цели, почему команда разработчиков должна иметь руководителя. Практическая демонстрация расползания сроков в MS Project на примере гипотетического проекта из десяти задачек и трех исполнителей поможет перейти к понятию «риск» и объяснить, почему продукт никогда не будет сделан к дате, которая фигурирует в первоначальной версии проекта. Следует искоренять традицию работы в авральном режиме. Эта порочная практика никогда не даст положительного результата.