Время — деньги. Создание команды разработчиков программного обеспечения
Шрифт:
К концу работы над BoundsChecker 3.0 энтузиазм нашего ведущего разработчика изрядно поубавился: проект отнял много времени и сил, и необходимость перемен была очевидна каждому его участнику. В это время возникла ещё одна задача: нужно было разобраться, что может дать новая технология от Microsoft под названием СОМ для наших продуктов. СОМ привлекла большое внимание, её даже считали «дорогой в будущее». Однако мы смутно представляли себе её суть, поэтому решено было взяться за обе проблемы одновременно.
В то время как остальная часть
Оценка технологий
Прежде чем приступать к проекту, обязательно нужно разобраться в технологии, намеченной для использования в нём. Это особенно важно для проектов, в реализации которых будут задействованы новые инструменты, компоненты, платформы или решении.
Сегодня практически ни одна программа не создаётся на основе одной технологии. Например, в типичном современном Web-приложении используются функции ОС, графические библиотеки, компоненты от сторонних разработчиков, Web-серверы, серверы транзакций и баз данных, поэтому приходится разбираться в возможностях самых разных технологий. Следует ещё до начала работы над проектом выяснить, соответствуют ли возможности каждой намеченной для применения новой технологии нуждам проекта. Оценка технологий позволяет решать поставленные вопросы путём тестирования и совместного обсуждения, что позволяет обнаружить новые проблемы, о существовании которых никто даже не подозревал до начала использования этой технологии.
Просто удивительно, как часто разработчики считают, что для использования новых технологий достаточно одних предположений или сведений, полученных из прессы или телеконференций. Любая команда должна тщательно изучить все новые технологии, которые она собирается применить в работе над проектом. Если значительную долю задействованных в проекте технологий составляют новые (для рынка или для самой команды), до начала работы над проектом потребуется затратить некоторое время на изучение новых технологий.
Оценивая технологию, нужно дать ответы на следующие вопросы.
• Возможности технологии: обладает ли новая технология возможностями, необходимыми для реализации проекта?
• Качество: приемлем ли уровень качества технологии?
• Совершенство: обеспечивает ли технология должную производительность, масштабируемость и устойчивость?
• Поддержка: обеспечена ли новая технология адекватной поддержкой?
• Простота
• Профессионализм команды: хватит ли у команды мастерства для применения этой технологии?
На самом деле собственно процесс оценки технологии не столь сложен, но нужно провести его довольно быстро, поскольку помимо всего прочего, именно результаты оценки технологий определяют срок утверждения окончательного плана проекта. Даже если время для вас — роскошь, при оценке любой технологии не забывайте:
• формулировать критерии: определяйте свои потребности заранее и делайте это как можно точнее с помощью критериев, данных выше;
• использовать сформулированные критерии при оценке: объективно оценивайте результаты, опираясь на факты, а не на мнения;
• учитывать отзывы заказчиков: собирайте отзывы заказчиков (как положительные, так и отрицательные) о результатах оценки; не забывайте интересоваться мнением заказчиков: удовлетворят ли новые технологии их нужды.
Моделирование
В начале работы над проектом почти всегда возникает ряд важных вопросов, связанных с реализацией той или иной технологии. Моделирование — важная методика, которая поможет получить необходимые ответы.
Создание прототипа — важный этап, который любая группа разработчиков может осуществить ещё до начала работы над проектом. Работа с прототипом поможет понять, как эффективно воплотить ключевые функции программы, оценить сложность реализации ключевых технологий и необходимое для этого время, а также свести к минимуму общий риск ошибок и срыва планов.
Рассмотрим примеры того, что может случиться, если отказаться от работы с прототипом, Определив все компоненты программы, команда решила сначала реализовать её инфраструктуру, так как без этого компонента, обычно самого важного и самого сложного, ничего не работает. В результате этот компонент был спроектирован и построен без предварительной работы с прототипом. Когда он был готов, группа решила подключить к нему другие. Но после интеграции новых компонентов стало ясно, что возможности инфраструктуры недостаточны, конструкция её плоха или не масштабируется. После этого приходится искать места, где и что пошло не так, проектировать и кодировать все заново. Перепроектирование программы и изменение её кода во время цикла разработки, очевидно, приведёт к задержке выпуска ПО.
Рассмотрим ещё один пример, на сей раз с противоположным сценарием. Участники группы отдают себе отчёт в том, что нельзя строить компоненты инфраструктуры проекта, не поняв технических требований других частей системы, поэтому решено сначала создать полную спецификацию системы. Но эта задача оказалась затруднительной, так как не все проблемы, с которыми придётся столкнуться, известны заранее. Фактически здесь возникают сплошные вопросы, на которые никто не знает ответа. Конечно, можно попытаться действовать наугад в надежде, что всё будет хорошо, но это слишком рискованно.