В компьютерной прессе можно встретить множество статей, посвященных описанию новых технологий и языков программирования . Гораздо меньше пишут об отладке и тестировании кода. И совсем уже мало материалов, касающихся проблем управления программными проектами. Поэтому здесь мы обращаемся в первую очередь к людям, которым по долгу службы приходится руководить программистами.
Это тяжелый и неблагодарный труд! Я сам в разное время находился и по ту, и по другую сторону барьера, поэтому очень хорошо представляю проблемы как руководителей, так и исполнителей. Насколько же тяжелее контролировать ситуацию в условиях, когда проект усложняют две дополнительные неопределенности (о них чуть позже), знают только те кому приходилось участвовать в таких разработках. Не избежали подобных трудностей и мы, когда приступили к созданию нового поколения КИС "Компас" (см. статью "Новый инструмент для нового "Компаса", PC WEEK/RE, N47.2002, с.38).
Для начала было решено разработать технологию управления проектом (work-flow). Поскольку изобретение велосипеда - процесс трудоемкий и не гарантирующий качественного результата, мы попробовали трансформировать и использовать принципы управления, которые применяются в проектах, не имеющих отношения к программированию. Благо нашлись люди с практическим опытом работы такого рода.
Особенности нашего проекта
Вскоре после начала проектирования инструментария "Мастера" для КИС "Компас" я понял, что нам придется разбираться с неопределенностями сразу двух видов. Напомню, что КИС "Компас" является конструктором. В жестком приложении во время внедрения системы на своем предприятии можно конфигурировать ее на параметрическом уровне, т.е. в тесных рамках, предусмотренных разработчиками. В конструкторе же пользователь может переделывать программу под свои нужды. "Мастера" "Компаса" - это как раз есть визуальный инструмент, позволяющий осуществлять настройку.
Всем программам-конструкторам присуща одна общая беда - потеря быстродействия приложения, связанная с интерпретацией метаданных. Чтобы уйти от этой проблемы мы решили использовать технологию .Net. В стандартную поставку .Net Framework входит компилятор языка С#, который позволяет компилировать метаданные, модифицированные пользователем, в исполняемый код. Такие метаданные обрабатываются гораздо быстрее, чем интерпретируемые. Однако сделав этот шаг мы внесли в проект вторую неопределенность: при использовании нового для инструментария разработки - языка С# и платформы .Net - сложно предварительно оценить трудоемкость задания. C одним из них - в технологии Binding - мы бились очень долго, после чего махнули рукой и переписали эту технологию почти целиком.
Прототипирование
Естественно, для начала мы применили самое стандартное средство борьбы с любыми неопределенностями - стали писать прототип. При этом мы знакомимся со средой разработки, создаем большую часть дизайна системы, тестируем все основные принципы, что можно сделать при помощи разработанного инструмента и чего нельзя. Закончив разработку прототипа мы сможем оценить трудоемкость отдельных заданий и всего проекта со значительной степенью достоверности. Время кодирования на этом этапе должно быть минимальным.
Коснемся теперь того, как мы управляем разработкой прототипа. Поскольку в процессе его написания преодолевается значительная часть обеих неопределенностей , во время разработки полнофункциональной версии ПО жить будет уже намного легче. Чтобы процесс разработки был контролируемым, надо разбить весь проект на компоненты. Но поскольку у нас нет подробной спецификации, мы можем ошибиться даже с номенклатурой компонентов. Придется также писать и инструментальные классы, реализующие функциональность , о которой в начале разработки мы и представления не имели.
К сожалению, когда программист сообщает о выполнении задания, это еще не означает что сделанный им код можно сразу использовать. Ибо все мы люди, и всем нам свойственно смотреть на предмет только с одной точки зрения. Cторонний же взгляд неизменно обнаруживает недочеты в алгоритмах, мелкие несуразицы, а бывает даже и неполностью выполенное задание. У всех нас разный жизненный опыт, разное мироощущениее, и в одни и те же слова мы подчас вкладываем диаметрально противоположный смысл. Результаты проверки обсуждаются исполнителем и рецензером, после чего составляется план доработок. Обычно имеет смысл рецензировать не работу компонента как такового, а его взаимодействие с другими частями приложения. Ибо свой компонент программист знает "от и до" , а вот другие он так же хорошо знать не может.
Настало время вспоминть о том, что мы разрабатываем не само приложение, а только его прототип. Следовательно, наша главная цель - не написание исполняемого кода, а создание спецификации на компоненты и правильная оценка трудоемкости. Время жизни первого документа начинается чуть ли не с момента написания первой строчки кода. В нем фиксируется все, что должно присутствовать в готовом приложении, но в прототипе реализовано не будет. Второй документ отражает различия между моделью (UML - диаграммами) и собственно кодом прототипа. Обычно этот документ появляется на этапе доработок. Для определения сроков осуществления работ было решено установить сначала (методом экспертной оценки) суммарную трудоемкость первоначального кодирования на каждом этапе. Все остальные трудозатраты рассчитываются как процент от трудоемкости кодирования. Это позволяет автоматически корректировать большую часть показателей и получать тем не менее вполне приемлемый результат. Принятые в нашем проекте проценты указаны в "Этапах...".
Хочется верить, что наш опыт управления проектом в условиях двойной неопределенности пригодится и другим командам разработчиков.
C автором - руководителем проекта компании "Компас" - можно связаться по e-mail:yaxy@compass.spb.ru
