Время — деньги. Создание команды разработчиков программного обеспечения
Шрифт:
Спецификация требования должна отвечать на вопрос «что должно быть сделано?», а не «как это сделать?». Ответ на вопрос «как?» проще всего получить с помощью анализа технической осуществимости и создания прототипа пользовательского интерфейса. К сожалению, часто формулировки требований включают описание способов их реализации, что может сузить выбор возможных решений. Вместо этого следует позволить команде задействовать свой творческий потенциал, чтобы генерировать множество возможных
Рассмотрим в качестве примера вышеупомянутое приложение для обработки заказов. Одно из ключевых требований таково: «Принимая заказ на товар, нужно собрать следующую информацию: X, Y и Z». Заметьте: требование содержит формулировку самой задачи, но не способа её решения. Можно привести пример требования с описанием способа его реализации: «Пользователь должен выбрать в меню пункт New|Create Order и ввести нужную информацию в диалоговом окне». Лучше позволить команде, ответственной за разработку пользовательского интерфейса, самостоятельно найти лучший способ реализации этого требования путём работы с прототипом.
В большинстве случаев участники проекта воспринимают формулирование требований в штыки именно из-за плохо налаженного управления требованиями. Проекты страдают из-за «размазанности» и неполноты требований, отсутствия приоритетов и из-за неуправляемых изменений. В этой главе мы сосредоточились лишь на главных вещах, необходимых для поддержания проекта в управляемом и предсказуемом состоянии, не перегружая группу обработкой второстепенной информации и бумажной работой. Не забывайте всё, о чём здесь говорилось, при работе над собственным проектом.
Глава 9
Исследования, оценка технологий и моделирование
В начале любого напряжённого проекта велико искушение принять решения о применении новых технологий, компонентов и платформ лишь на основе общих допущений. Производительность, масштабируемость и даже среду разработки и инструменты нередко оценивают и подбирают «на глазок». Если сделанные допущения верны, считайте себя большим героем, сэкономившим кучу времени. Но в случае ошибки проект с самого начала обречён.
Значит ли это, что любой проект — это лотерея? Да, во многом так оно и есть: не разобравшись в некоторых вопросах планирования, о которых пойдёт речь в этой главе, вы сильно рискуете. Иногда этот риск оправдан, но чаще — нет. Почему? Да потому, что в данном случае все против вас: чем больше вы делаете допущений, тем больше риск.
Не правда ли, здорово было бы знать, как делать предположения с минимальной вероятностью ошибки? И ещё лучше, если бы основные предположения можно было проверить до утверждения окончательной даты выпуска, правда? В этой главе мы обсудим, как с помощью исследований, оценки технологий и моделирования проверить предположения и не дать проекту сойти с дистанции.
Чем полезны исследования и прототипы
Исследования, оценка и использование прототипов позволят ещё до начала работы над проектом понять все возможности
• Упрвление рисками и создание рациональных планов
На ранних стадиях реализации проекта надо определить основные технологические проблемы и наметить пути их решения. Нерешённые технологические проблемы могут внести хаос в реализацию проекта. Фактически это одна из самых распространённых причин срыва планов. Не следует утверждать план или начинать работу над проектом, пока не решены основные технологические проблемы.
• Уверенность в успехе
Когда технологии, подходы и архитектура применяются впервые, мало кто из коллектива верит, что всё заработает. Это и понятно: в отсутствие опыта решения подобных проблем шансы на успех могут казаться призрачными. Однако такого рода сомнения могут стать источником реальных проблем. От недостатка уверенности в успехе проекта страдает не только боевой дух группы, но и производительность труда. Поэтому задача — как можно раньше исключить всякие сомнения и создать уверенность, что проект может быть и будет успешным.
• Прогноз проблем с производительностью
Почти всем ясно, что производительность приложений приобретает всё более важное значение. К сожалению, оптимизация производительности — это не та задача, которую можно отложить на потом, чтобы заняться ею в конце работы над проектом. Здесь нужен другой подход: следует заранее построить модель, воплощающую важнейшие черты архитектуры проекта, и как можно раньше протестировать её, чтобы выяснить, насколько хорошо она масштабируется.
• Прорывы в технологии
Чтобы работать на рынке с жёсткой конкуренцией необходимы исследования. Следует направить часть усилий группы на прогноз нужд потребителей, а также на поиск революционных решений и идей. Прекрасные идеи, новые подходы и хитовые приложения не появляются по волшебству в одночасье — их вынашивают как младенцев.
Исследования
Хоть некоторые и считают исследовательскую работу чисто академическим занятием, она тем не менее играет важную роль в разработке ПО. В этом разделе мы обсудим основы ведения исследований в приложении к созданию программных продуктов.
Исследования бывают фундаментальные и прикладные. Первые — это процесс открытий и изобретений в надежде создать что-то полезное. Однако у результата такого исследования может и не быть коммерческого применения. С другой стороны, прикладное исследование на основе логических построений и анализа ситуации в некоторой отрасли ведёт поиск потенциально выгодных решений и пытается превратить гипотезы в конкретные идеи, которые помогут создать некоторый продукт.