Человеческий фактор в программировании

Безусловно, команда Ernst amp; Young была именно той командой, чья вера в процесс проверялась на прочность. Уже в самом начале, едва очутившись в конференц-зале, они умудрились сжечь свою совершенно новую систему на базе Pentium. Быстрый перенос программного обеспечения на лэптопы позволил продолжить работу, хотя и с меньшей мощностью аппаратного обеспечения.

Наконец, когда они перешли от журналов и блокнотов к клавиатурам и мониторам, дело опять осложнилось. На первый взгляд казалось, что соперники добились непреодолимого превосходства, тем более что некоторые из них уже демонстрировали какие-то рабочие компоненты. Однако в программировании поверхностные впечатления зачастую оказываются обманчивыми. На самом деле, к середине дня в контрольной точке, когда судьи оценивали команды программистов и проверяли их результаты по выполненным функциональным пунктам, парни из Ernst amp; Young превратили свое методичное спокойствие во внушительное лидерство. Тща-тельный анализ и планирование давали свои результаты — даже в этих жестких условиях.

Тем не менее, как говорится, был еще не вечер.

По результатам начальной оценки на последнем месте оказалась команда из Xpedite Professional Services Pty. Ltd. под руководством Сью Стивене (Sue Stevens). Пока другие команды усердно наращивали функциональность, они сосредоточились на деталях и тщательно продумывали код, направив все усилия на обработку ошибок и исключений. Однако этот метод, очевидно, не подходил для чрезвычайно плотного цикла разработки, установленного на соревновании. На полпути команда Xpedite решила поменять свою стратегию.

Когда подошло время финальной оценки, команда Ernst amp; Young начала объединять различные компоненты своей методично построенной системы. В спешке, когда все файлы переносились на одну машину, они нечаянно записали черновые версии поверх рабочих файлов. Мы все совершали такую ошибку, случайно перепутав направление копирования. Я и сам совершил ее всего за несколько месяцев до этого, когда переносил файлы Power Point, созданные для другой конференции. К счастью, у меня были резервные копии. К несчастью, у команды Ernst amp; Young их не было. Затерев большую часть своих данных, к финалу они пришли с меньшим количеством функциональных пунктов по сравнению с результатами в середине соревнований.

Польза

Тем временем команда Xpedite переключила свое внимание с деталей на человеческий фактор пользовательского интерфейса. Когда другие команды все еще строили грубую функциональную схему, они стали рассматривать реальные потребности оператора по переработке отходов и создавать более ценные компоненты. Вместо стандартных таблиц и меню они применили особые окна, разработанные с учетом нужд потребителя. В результате с последнего места, которое они занимали во время ланча, к обеду они переместились на первое.

Итак, что же можно извлечь из опыта этих доблестных команд? Более чем когда-либо очевидно, что быстрое создание прототипов не может заменить методичность в работе. По существу, именно сочетание инструментов быстрого визуального проектирования (см. главу 23) с разумным процессом анализа и разработки будет более эффективным при слишком сжатых сроках. Время, затраченное на осмысление и планирование, экономит время на разработку.

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

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

И наконец, еще об одном, хотя это и кажется очевидным. Хорошее управление версиями необходимо даже при очень коротких циклах программной разработки. Даже под непомерным давлением сроков — или, возможно, особенно под таким давлением — время, затраченное на создание резервных копий и версий, идет только на пользу. По сути, управление резервными копиями и версиями было необходимо включить в ускоренный метод разработки, применявшийся командой Ernst amp; Young. Именно это они и пообещали сделать к следующему соревнованию.

Из журнала Software Development, том 3, № 10, октябрь 1995 г.

32 Re: Архитектура