МЕТОДОЛОГИИ
Сергей Бобровский
9 лучших навыков, рекомендованных SPMN
Каждый из описываемых навыков полезен сам по себе, но совместное их использование значительно повышает суммарную эффективность. Немаловажно, что все они могут быть освоены без дополнительных расходов на оборудование, технологии и персонал.
Навык 1. Формальное управление рисками.
Любой проект по разработке ПО - рискованный. Но отсутствие процедуры управления рисками в компании - пожалуй, самый показательный признак грядущей неудачи проекта.
Поэтому необходимо уметь определять риск превышения бюджета и увеличения времени выполнения, неверного выбора и возможного отказа оборудования, ошибок при программировании и плохого сопровождения. Риск оценивается по вероятности его возникновения и возможным последствиям.
Надо смягчать последствия рисков путем их раннего выявления и максимально ранней ликвидации, профилактической работы и изменения курса проекта в обход потенциальных неудач. Неустраненные риски отслеживаются по параметрам “стоимость последствий риска” и “стоимость устранения риска”. Желательно создавать резервные запасы ресурсов для устранения непредвиденных проблем.
В рамках проекта рекомендуется постоянно вести и анализировать списки как минимум 10 важнейших рисков; списки неустраненных рисков в наиболее критических точках проекта; отчеты по устраненным, неустраненным и новым рискам; учитывать возможную стоимость последствий рисков в зависимости от имеющегося резерва.
SPMN советует также использовать анонимные каналы для получения от персонала информации о “подводных камнях” в проекте, чтобы в коллективе не создавалась атмосфера замалчивания ошибочных действий (типичная рекомендация для американской корпоративной культуры).
Одновременно следует “декриминализировать” сам риск. У сотрудников не должно быть никаких иллюзий о допустимости рисков (“выгодно затягивать проект”, “не хочу критиковать коллегу”), при этом необходимо понять, что каждый выявленный риск - это предупрежденный риск.
Навык 2. Соглашения об интерфейсах - пользовательских, внутренних (межмодульных) и внешних (для стыковки с другими компонентами и приложениями).
Интерфейсы программы - необходимая часть системных требований и ее архитектуры, но руководители проектов часто забывают проконтролировать продукт на соответствие этим соглашениям. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется заново проектировать, программировать и тестировать.
Для построения пользовательского интерфейса неплохо использовать RAD-системы. При этом его (как и все остальные интерфейсы) надо полностью определить, согласовать с заказчиком и утвердить до начала этапов проектирования и разработки. Его описание должно быть включено в системную спецификацию на уровне определения каждого экранного поля, элемента ввода-вывода и средств навигации между формами/окнами/экранами. Правильность интерфейса проверяет и утверждает только реальный пользователь каждого рабочего места из организации-заказчика.
К внешнему интерфейсу встраиваемой системы готовятся отдельные требования.
Навык 3. Формальные проверки проекта.
Нередко устранение ошибок начинается только тогда, когда проект переходит к так называемому этапу тестирования (такие этапы были придуманы 30 лет назад при создании небольших по сегодняшним меркам систем, и хотя в тестировании нет ничего плохого, выделять его в отдельный этап методологически неверно). В результате стоимость тестирования может составить 40 - 60% стоимости всего проекта. Эти ненужные усилия могут быть сокращены на порядок, однако не многие руководители знают, как это сделать.
Существует немало стандартных подходов раннего выявления ошибок - например, Fagan-проверки (M. E. Fagan, “Advances in Software Inspections”), позволяющие 80% ошибок обнаруживать в момент их внесения, или многократные просмотры кода (выявляющие 60% ошибок). Но оперативное обнаружение 90 - 100% ошибок требует использования сразу нескольких подходов. Ведущие компании одновременно применяют более десятка методик формальных проверок (анализ структуры проекта, проверки кода, редактирование документации, множественное тестирование и т. п.).
Не менее важно проверить корректность проекта на этапах формулирования требований, создания архитектуры системы и проектирования.
Формальные проверки должны выполняться небольшими группами сотрудников с четко определенными ролями вместе с пользователями организации-заказчика. Персонал необходимо постоянно тренировать в умении анализировать код на наличие ошибок. Желательно отслеживать продолжительность работ по проверкам проекта, соотношение числа найденных ошибок и затраченных на их поиск усилий и среднее время между внесением ошибки и ее устранением.
Навык 4. Управление проектом на основе метрик.
Этот навык нужен для раннего обнаружения потенциальных проблем. Как уже говорилось, стоимость устранения дефекта увеличивается в геометрической прогрессии по мере роста объема проекта.
С помощью метрик (числовых характеристик) планируются все задачи проекта. Ход их выполнения должен регулярно отслеживаться как минимум по ключевым показателям (стоимость работы и производительность труда). Дополнительно надо контролировать время, затрачиваемое на устранение дефектов, и следить за важнейшими показателями, чтобы по их отклонениям (в любую сторону - скажем, слишком резвый старт) выявлять потенциальные “подводные камни”.
Метрики основываются на эмпирических данных, например, на основе результатов схожих по размерам проектов.
Навык 5. Качество продукта должно контролироваться на детальном уровне.
Проблема реализации деталей программного проекта очень важна при разработке ПО. Иногда незначительное на первый взгляд требование заказчика выливается в глобальную переделку всего проекта. Если же проект спланирован недостаточно подробно, то обсуждать реальное положение дел в ходе его выполнения бессмысленно.
В проекте надо выделить задачи, по продолжительности и усилиям занимающие не более 5% всех работ, которые могут быть выполнены отдельной группой сотрудников как минимум на 95%. Каждая подобная задача должна быть ориентирована на выполнение однотипной работы. Результат выполнения каждой задачи оценивается группой приемки, при этом работа не может быть принята с оговорками - она должна быть выполнена полностью и без ошибок (двоичная система оценки качества “готово - не готово”).
Навык 6. Информация о ходе проекта должна быть общедоступной.
Чем больше сотрудников вовлечено в процесс контроля за ходом проекта, тем проще идентифицировать потенциальные проблемы и риски.
Надо сделать показатели хода проекта доступными как для всех сотрудников, так и для заказчика и организовать канал приема анонимных сообщений о возникающих проблемах. Чаще всего такой канал используется для сведения личных счетов, но лучше получить ложный сигнал, чем не узнать о реальной проблеме. К тому же открытость проекта будет залогом снижения числа ложных сообщений.
Навык 7. Чтобы добиться высокого качества, надо отслеживать причины возникновения ошибок.
Большинство компаний не контролируют никаких реальных источников ошибок (от которых непосредственно зависит эффективность работы), в то время как таких источников может быть множество: они связаны с ошибками программирования, отклонениями от графиков выполнения работ, превышением планируемой стоимости, неверно сформулированными требованиями, неправильно подготовленной документацией и плохим обучением персонала. Ошибки должны формально отслеживаться на каждой фазе проекта. Для этого желательно использовать средства конфигурационного управления. Каждый случай обнаружения и устранения ошибки обязательно надо документировать.
Устранять ошибки необходимо по мере их возникновения. При этом их учет удобнее всего вести в нормализованном виде (в расчете на единицу объема, например на тысячу строк кода): согласно принципу снежного кома с ростом проекта норма ошибок в нем увеличивается. Надо также контролировать среднее и максимальное время устранения ошибки и время от внесения ошибки до ее устранения на каждом этапе проекта и на протяжении первого года эксплуатации системы.
Навык 8. Конфигурационное управление.
Неконтролируемые изменения в проекте могут быстро ввергнуть его в хаос. Поэтому на практике надо руководствоваться двумя простыми правилами:
- любая часть информации, которая используется более чем одним сотрудником, должна контролироваться с помощью системы конфигурационного управления;
- любая часть информации, которая учитывается системой качества, должна контролироваться с помощью системы конфигурационного управления.
Надо отслеживать все изменения в состоянии создаваемой системы, бюджете и сроках, интерфейсах, контрольных отчетах и т. п. Без систем конфигурационного управления при этом не обойтись, потому что в крупном проекте большие объемы информации меняются очень быстро. Каждый учитываемый объект должен определяться его версией, при этом надо вести архив всех версий всех таких объектов.
Навык 9. Управление персоналом.
Главный фактор успеха проекта - качество, опыт и мотивация сотрудников. Не надо забывать, что с помощью различных методик можно значительно повысить производительность труда программистов (см. PC Week/RE, № 20/98, с. 47). С другой стороны, как бы подробно ни документировался проект, некоторые детали его архитектуры всегда будут храниться только в головах разработчиков, и руководитель проекта должен помогать сотрудникам проявлять индивидуальные творческие способности.
Выявлена высокая корреляция между суммами, вкладываемыми в обучение персонала, и общим успехом проекта, поэтому надо вести постояную деятельность по обучению и переподготовке сотрудников.
Любую возможность аврала необходимо свести к минимуму - а к авралам (как это ни парадоксально на первый взгляд) обычно приводит работа более 41 часа в неделю, что говорит о неверной организации труда и скрытых ошибках в организационной структуре.
Ключ к эффективному использованию персонала дает открытая доверительная атмосфера, основанная на правдивых отношениях.
Автору будет интересно узнать мнение читателей PC Week/RE о методологии SPMN. Напишите мне по адресу: sbo@pcweek.ru.
Окончание. Начало см. PC Week/RE, № 3/2000, с. 27.
