Одновременная разработка
Итак, два приема мы уже усвоили, теперь дело за третьим - одновременной разработкой приложения.
Сначала люди, которые занимаются требованиями и работают вместе с программистами, получают ровно столько требований к системе, сколько нужно команде архитекторов, чтобы приступить к ее дизайну. Лучше всего, если один человек является одновременно и архитектором, и программистом. В худшем случае - это разные люди, которые работают бок о бок. В обоих случаях, если программирование начинается вскоре после выбора архитектуры системы, работающий (или не работающий) код даст самую верную информацию о слабых сторонах дизайна и о том, какие его части необходимо исправить сразу же, на ранних стадиях работы.
Некоторым такой стиль работы может показаться странным и даже неправильным, но я сам бывал поражен тем, что большинство команд программистов так или иначе сами приходят к использованию этой стратегии. Причина проста: им было понятно, что в противном случае их ожидает полный провал, неважно, что там полагается делать согласно официально принятому в компании процессу. Вспомните ваш последний успешный проект (или несколько проектов), и посмотрите, не использовали ли ваши программисты в разной степени эту же тактику.
Масштаб пересечения различных видов деятельности зависит от вполне конкретных вещей: "узких мест" процесса разработки, свободного времени сотрудников, нестабильности отдельных частей работы и т.п. Я обнаружил, что в разных проектах мы использовали совершенно разные стратегии одновременной разработки, в зависимости от вышеперечисленных факторов. Однако я всегда ищу, какие еще виды работ можно выполнять одновременно.
