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

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

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

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

Все эти проблемы позволяет решить прототип. В первом примере работа с прототипом помогла бы заранее смоделировать систему. Это позволило бы понять, как собрать все компоненты. Во втором примере работа с прототипом подсказала бы проектные решения.

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

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

Как это делается

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

• Определите ключевые факторы риска

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

• Составьте план экспериментов

Следует создать план экспериментов, которые помогут ответить на поставленные вопросы. Можно искать ответ на каждый вопрос посредством отдельного эксперимента или решать несколько проблем одновременно, проводя ряд экспериментов.

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

• Попробуйте сымитировать конечный результат