Читаем без скачивания Время — деньги. Создание команды разработчиков программного обеспечения - Эд Салливан

Глава 9

Исследования, оценка технологий и моделирование

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

Значит ли это, что любой проект — это лотерея? Да, во многом так оно и есть: не разобравшись в некоторых вопросах планирования, о которых пойдёт речь в этой главе, вы сильно рискуете. Иногда этот риск оправдан, но чаще — нет. Почему? Да потому, что в данном случае все против вас: чем больше вы делаете допущений, тем больше риск.

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

Чем полезны исследования и прототипы

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

• Упрвление рисками и создание рациональных планов

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

• Уверенность в успехе

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

• Прогноз проблем с производительностью

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

• Прорывы в технологии

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

Исследования

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

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

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

Из собственного опыта

Отладчик ядра SoftICE, созданный NuMega, был хитом на рынке программ для 16-разрядных платформ Microsoft DOS и Microsoft Windows. Нам даже без особых проблем удалось заставить его работать в Windows 95. Однако рынок неуклонно двигался к Windows NT, что вынудило нас заняться адаптацией SoftICE для работы с этой ОС, иначе рост прибылей нашей компании неизбежно снизился бы. Но эта задача казалась просто невыполнимой: новая система управлением виртуальной памятью Windows NT делала реализацию многих функций SoftICE чрезвычайно затруднительной и требовала от большинства участников группы разработчиков SoftICE знания недокументированных внутренних механизмов и структур данных Windows. Большинство работников компании (и не только они) сомневалось, что SoftICE когда-либо будет перенесён на Windows NT.

К счастью, среди нас оказался Фрэнк Гроссман, у которого хватило веры в осуществимость этой идеи и желания, чтобы провести соответствующие исследования. Он работал над этой проблемой день и ночь в течение двух недель, пока не создал довольно простой прототип, на примере которого смог продемонстрировать основные методики, необходимые для поддержки Windows NT. Ему достаточно было показать этот прототип группе, и дело было сделано: все поверили, что заставить SoftICE работать в Windows NT всё-таки можно. На реализацию сложных функций программы ушёл почти год, но в итоге мы создали продукт, в появление которого никто не верил. Проведённые исследования позволили нам не только обеспечить стремительный рост потока прибылей, но и воздвигнуть мощный барьер на пути у конкурентов, а полученные знания мы теперь можем использовать при разработке других продуктов.

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

• Проведение исследований во время работы над неосновными выпусками программы

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

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

• Дайте проявить себя каждому ведущему разработчику

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