Глава 2. Сертификация и оценка процессов создания ПО
2.1. Понятие зрелости процессов создания ПО. Модель оценки зрелости СММ
Организации, работающие в области разработки, поставки, внедрения и сопровождения ПО и системной интеграции, все больше ощущают, что в основе их конкурентоспособности лежат качество и низкий уровень себестоимости, технологичность производства.
Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х гг. американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.
Сегодня на западе компания-разработчик практически испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что исполнитель не может оказать некачественную услугу.
Оценка технологической зрелости компаний может использо-ваться:
заказчиком при отборе лучших исполнителей (например, в тендере);
компаниями-производителями ПО для систематической оценки состояния своих технологических процессов и выбора направлений их совершенствования;
компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;
аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;
консалтинговыми фирмами, занимающимися реструктури-зацией компаний и служб поставщиков информационных технологий и связанных с ними услуг.
По мере повышения технологической зрелости организации процессы создания и сопровождения ПО становятся более стандар-тизованными и согласованными. При этом формализация процессов позволяет стандартизовать ожидаемые результаты их выполнения и обеспечить предсказуемость результатов выполнения проектов.
Зрелость процессов (software process maturity) это степень управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.
Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения.
Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.
В организациях, достигших технологической зрелости, процессы создания и сопровождения ПО принимают статус стандарта, фиксируются в организационных структурах и определяют производственную тактику и стратегию. Введение их в статус закона влечет за собой необходимость построения необходимой инфраструктуры и создания требуемой корпоративной культуры производства, которые обеспечивают поддержку соответствующих методов, операций и процедур ведения дел даже после того, как из организации уйдут те, кто все это создал.
Модель СММ развивает положения о системе качества организации, формируя критерии ее совершенства – пять уровней технологической зрелости, которые в принципе могут быть достигнуты организацией-разработчиком. Наивысшие – четвертый и пятый уровни – это фактически характеристика организаций, овладевших методами коллективной разработки, в которых процессы создания и сопровождения ПО комплексно автоматизированы и поддерживаются технологически.
Начиная с 1990 г. SEI при поддержке правительственных структур США и Организаций-разработчиков ПО постоянно разви-вает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.
СММ представляет собой методический материал, определяющий правила формирования системы управления созданием и сопровождением ПО и методы постепенного и непрерывного повышения культуры производства. Назначение СММ – предоставление организациям-разработчикам необходимых инструкций по выбору стратегии повышения качества процессов путем анализа степени их технологической зрелости и факторов, в наибольшей степени влияющих на качество выпускаемой продукции. Фокусируя внимание на небольшом количестве наиболее критичных операций и планомерно повышая эффективность и качество их выполнения, организация, таким образом, может добиться неуклонного постоянного повышения культуры создания и сопровождения ПО.
СММ – это описательная модель в том смысле, что она описывает существенные (или ключевые) атрибуты, которые определяют, на каком уровне технологической зрелости находится организация. Это нормативная модель в том смысле, что детальное описание методик устанавливает уровень организации, необходимый для выполнения проектов различной сложности и продолжительности по контрактам с правительственными структурами США. СММ не является предписанием, она не предписывает организации, каким образом развиваться. СММ описывает характеристики организации для каждого из уровней технологической зрелости, не давая каких-либо инструкций как переходить с уровня на уровень. Организации может потребоваться несколько лет для перехода с первого на второй уровень и совсем мало времени для перехода с уровня на уровень далее.
Процесс совершенствования технологии создания ПО отражается в стратегических планах организации, ее структуре, используемых технологиях, общей социальной культуре и системе управления. На каждом уровне устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов. Выход на каждый уровень технологической зрелости является результатом появления определенного количества компонентов в процессах создания ПО, что в свою очередь приводит к повышению их производительности и качества. На рис. 2.1 показаны пять уровней технологической зрелости СММ. Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.
Рис. 2.1. Пять уровней технологической зрелости СММ
Уровни со второго по пятый могут характеризоваться через операции, направленные на стандартизацию и (или) модернизацию процессов создания ПО, и через операции, составляющие сами процессы его создания. При этом первый уровень является как бы базой, фундаментом для сравнительного анализа верхних уровней.
На уровне 1 (начальном) основные процессы создания и сопровождения ПО носят случайный характер и выполняются хаотично. Успех выполнения проекта всецело зависит от индивидуальных усилий персонала. На этом уровне, как правило, в организации не существует стабильной среды, необходимой для создания и сопровождения ПО.
На первом уровне процессы являются аморфными («черными ящиками»), и их обозримость весьма ограничена. С самого начала состав и назначение операций практически не определены, что порождает значительные трудности в определении состояния проекта и его продвижения. Требования по выполнению процессов задаются бесконтрольно. Разработка ПО в глазах менеджеров (особенно тех, кто сам не является программистом) иногда выглядит как черная магия.
На втором уровне выполнение требований пользователя и создание ПО контролируемы, поскольку определена база для процессов управления проектом. Процесс создания ПО может рассматриваться как последовательность «черных ящиков», которые можно контролировать в точках перехода из одного «ящика» в другой – зафиксированных этапах. Даже если руководитель не знает, что делается «внутри ящика», точно установлено, что должно получиться в результате выполнения процесса, и определены контрольные точки его начала и завершения. Поэтому управление может распознавать проблемы в точках взаимодействия «черных ящиков» и своевременно на них реагировать.
На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкретных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стандартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведения о его текущем состоянии.
На четвертом уровне выполнение процессов жестко привязывается к инструментальным средствам, что дает возможность определения количественных характеристик их трудоемкости и качества выполнения. Руководители, имея объективную базу количественных измерений, получают возможность точного планирования стадий и этапов выполнения проекта, прогнозирования продвижения проекта, и могут своевременно и адекватно реагировать на возникающие проблемы. С уменьшением возможных отклонений от заданных сроков, стоимости и качества в процессе выполнения проекта их возможность предвидения результатов постоянно возрастает.
На пятом уровне в целях повышения качества продукции и повышения эффективности ее создания постоянно и планомерно проводится работа по созданию новых усовершенствованных методов и технологий создания ПО. Внимание обращается при этом не только на уже используемые, но и на новые более эффективные процессы и технологии. Руководители могут количественно оценивать влияние и эффективность изменений в технологии создания и сопровождения ПО.
Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого – 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.
Для достижения высших уровней СММ требуется десять и более лет. Но даже уровень 3 позволяет смело выходить на международную арену. Для использования СММ компании не надо искать сотрудников с какими-то уникальными способностями, ей достаточно понять общую идею. В описании модели СММ детально указано, что надо делать, чтобы развиваться в соответствии с этой моделью. Следовать регламентированным действиям СММ способен любой менеджер среднего класса.
Последняя версия СММ 1.1 в основном ориентирована на крупные компании, занимающиеся реализацией больших проектов, но она вполне может использоваться и группами из двух-трех человек или отдельными программистами для выполнения небольших проектов (продолжительностью до трех месяцев). В таких случаях модель СММ может сыграть жизненно важную роль, поскольку поступление новых заказов во многом определяется качеством реализации предыдущих проектов. Маленькие группы вполне удовлетворятся уровнем 2, так как для небольшого проекта отклонение от срока на пару недель непринципиально.
С 2002 г. официально распространяется специальная интеграционная версия CMMI. Это новая разработка SEI охватывающая все аспекты деятельности компании: от разработки и выбора подрядчика до обучения, внедрения и сопровождения. Кроме того, модель CMMI расширена подходами из системной инженерии. В эту модель вошли наработки, сделанные в ходе проектирования версии СММ 2.0 (она не была закончена), основные изменения в которой были направлены на уточнение процессов для компаний четвертого и пятого уровней, что наиболее актуально для крупномасштабных американских проектов.
Модель СММ достаточно весома и важна, однако не стоит применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для компаний, которые занимаются разработкой ПО для Министерства обороны США.
К недостаткам СММ относятся следующие.
1. Модель сосредоточена исключительно на управлении проектом, а не на процессе создания программного продукта. В модели не учтены такие важные факторы, как использование определенных методов, например прототипирования, формальных и структурных методов, средств статического анализа и т.п.
2. В модели отсутствует анализ рисков и решений, что не позволяет обнаруживать проблемы прежде, чем они окажут воздействие на процесс разработки.
3. Не определена область применения модели, хотя авторы признают, что она является универсальной и подходящей всем организациям. Однако авторы не дают четкого разграничения организаций, которые могут или не могут внедрять СММ в свою деятельность. Небольшие компании находят эту модель слишком бюрократичной. В ответ на эту критику были разработаны стратегии совершенствования технологического процесса для малых организаций.
В качестве альтернативы СММ предлагается обобщенная классификация процессов совершенствования технологической зрелости, которая подходит для большинства организаций и программных проектов. Можно выделить несколько общих типов процессов совершенствования.
1. Неформальный процесс. Не имеет четко выраженной модели совершенствования. Его с успехом может использовать отдельная команда разработчиков. Неформальность процесса не исключает таких формальных действий, как управление конфигурацией, однако при этом сами действия и их взаимосвязи не предопределены заранее.
2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними.
3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).
4. Процесс непосредственного совершенствования. Имеет поставленную цель совершенствования технологического процесса, для чего существует отдельная строка в бюджете организации и определены нормы и процедуры внедрения нововведений. Частью такого процесса является количественный анализ процесса совершенствования.
Эту классификацию не назовешь четкой и исчерпывающей – некоторые процессы могут одновременно относиться к нескольким типам. Например, неформальность процесса является выбором команды разработчиков. Эта же команда может выбрать определенную методику разработки, имея при этом все возможности непосредственного совершенствования процесса. Такой процесс подпадает под классификацию неформальный, методически обоснованный, непосредственного совершенствования.
Необходимость приведенной классификации обусловлена тем, что она предоставляет основу для комплексного совершенствования технологии создания ПО и дает возможность организации выбирать разные типы процессов совершенствования. На рис. 2.2 показаны соотношения между разными типами программных систем и процессами совершенствования их разработки.
Многие технологические процессы в настоящее время имеют CASE-средства поддержки, поэтому их можно назвать поддерживаемыми процессами. Методически обоснованные процессы поддерживаются инструментальными средствами анализа и проектирования.
Главная цель объектного анализа – представить предметную область (ПрО) как множество объектов со свойствами и характеристиками, которые достаточны для их определения и идентификации, а также для задания поведения объектов в рамках выбранной системы понятий и абстракций. На произвольном шаге объектного анализа все понятия (сущности) ПрО – суть объекты. Каждый объект – это уникальный элемент, имеет, по крайней мере, одно свойство или характеристику и уникальную идентификацию во множестве объектов.
Рис. 2.2. Применимость процессов совершенствования
Предметная область сама является самостоятельным объектом или может быть объектом в составе другой предметной области.
Анализ ПрО проводится с помощью объектно-ориентирован-ных методов и соответствующих стандартов. Конечная цель объектно-ориентированного анализа ПрО – определение объектной модели (ОМ) с помощью выделенных объектов, отношений между ними и их свойствами и характеристиками.
При построении модели ОМ в предметной области также выявляются функциональные задачи, формулируются требования к их проектированию и реализации. Требования, задачи и модель ОМ – необходимые условия построения архитектуры системы для анализируемой ПрО.
2.2 Методика SPMN
Признанные мировые лидеры, создающие качественное ПО (их единицы во всем мире), активно используют принцип лучшего практического навыка. Этот принцип ориентирован на улучшение деталей работы и быстрое достижение конечного результата. В нем нет абстрактного «улучшения процесса», а есть конкретные рекомендации, использующие числовые характеристики проекта. Другое преимущество – возможность их немедленного применения в противовес «тяжелой» модели СММ, для сертификации по которой нужны годы труда. Несмотря на определенное число очень успешных результатов внедрения СММ, эта методика не получила массового признания среди небольших фирм в силу сложности и слишком больших усилий, требуемых для ее внедрения. Продолжающиеся неудачи в крупных программных проектах заставили Министерство обороны США сформировать подразделение SPMN (Software Program Managers Network), которое было призвано помочь военным быстро наладить эффективные процессы управления проектами в организациях-разработчиках ПО.
Для SPMN были определены четыре главные цели ее работы.
1. Внедрить в Министерстве обороны лучшие практические навыки создания ПО.
2. Позволить руководителям проектов сфокусировать свои усилия на разработке качественного ПО, а не на следовании должностным инструкциям и формальным методикам, которые только ухудшали состояние проекта.
3. Позволить руководителям проектов использовать лучшие мировые практические навыки с учетом локальной корпоративной культуры.
4. Дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.
В SPMN было создано три подразделения.
1. Группа оперативных советов определила важнейшие практические навыки (всего их набралось девять). В выявлении лучших навыков участвовали такие общепризнанные эксперты, как Гради Буч, Эдвард Йордон и др. В дополнение к лучшим навыкам они разработали технологию Панели управления ходом программного проекта (Software Project Control Panel), описывающую ключевые индикаторы состояния проекта. Были также определены важнейшие цели типичного проекта, способы их количественной оценки и границы допустимых состояний. Составлен справочник ответов на вопросы, часто задаваемые руководителям проектов, и выделен набор самых плохих практик.
2. Группа периодических обновлений, состоящая из 180 специалистов по программной инженерии, которые обработали 163 методики 56 компаний и выделили 43 лучших практических навыка, расширивших и дополнивших девять ключевых навыков.
3. Группа управления, контролирующая работу двух предыдущих групп и определяющая способы ее улучшения.
Подход, предложенный отделом SPMN, называется СВР (Critical Best Practices, критически важные практические навыки). Он позволяет тактическими изменениями в работе организации очень быстро (за полтора-два года) примерно на 80 % достичь третьего уровня СММ (на что обычно требуется около десяти лет). При этом подход СВР проверен на сотнях реальных крупных программных проектов.
Рекомендации по применению практических навыков достаточно очевидны. В самом общем виде подход СВР предлагает:
• сфокусироваться на количественных параметрах завершения проекта (дате, бюджете, объеме);
• придумать быстро реализуемую стратегию выполнения проекта;
• измерять продвижение к цели;
• измерять активность разработки.
Результаты работы SPMN показали, что ход выполнения крупных проектов обычно находится на грани хаоса, и существует ряд факторов, от которых зависит, перейдет ли система в неуправляемое состояние. Чтобы правильно управлять проектом, надо придерживаться следующих принципов.
1. Ошибки и логические неувязки надо выявлять как можно раньше и устранять сразу после обнаружения. Между внесением ошибки разработчиком и ее выявлением должно пройти минимальное время (в проектах Министерства обороны США среднее время между внесением ошибки и ее устранением составляло 9 месяцев). Практика почасовой оплаты программистов (имевшая место при выполнении госзаказов в США) совершенно недопустима. Надо также совершенствовать механизмы выявления типичных причин ошибок и способы их устранения.
2. Необходимо планировать работу на основе правильно выбранных показателей. Невозможно реализовать крупный проект, если не подготовить в его рамках максимально подробный план всех видов деятельности с учетом производительности сотрудников, объема проекта, бюджета и других ресурсов.
3. Надо минимизировать неконтролируемые изменения проекта с учетом того, что они вносятся разработчиками на всех этапах, начиная с требований к системе и заканчивая ее пользовательскими интерфейсами.
4. Необходимо эффективно использовать сотрудников. Знания, опыт и мотивация сотрудников – важнейшие факторы успеха. Акцент в управлении проектами должен быть смещен на производительность труда, качество работы, выполнение планов и удовлетворение пользователя. Для этого требуются большие усилия по подготовке профессиональных руководителей проектов и изменения текущих способов их подготовки.
Девять лучших навыков, рекомендованных SPMN
Каждый из описываемых далее навыков полезен сам по себе, но их совместное использование значительно повышает общую эффективность. Немаловажно, что эти навыки могут быть внедрены без дополнительных расходов на оборудование, технологии и персонал.
Навык 1 – формальное управление рисками. Любой проект по разработке ПО – рискованный. Но отсутствие процедуры управления рисками в компании – это, пожалуй, самый показательный признак грядущей неудачи проекта. Поэтому необходимо уметь определять риск превышения бюджета и времени выполнения, неверного выбора и возможного отказа оборудования, ошибок программирования и плохого сопровождения. Риск оценивается по вероятности возникновения и его последствиям.
Надо смягчать последствия рисков путем их раннего выявления и максимально ранней ликвидации, профилактической работы и изменения курса проекта «в обход» потенциальных неудач. Неустраненные риски надо отслеживать по параметрам «стоимость последствий риска» и «стоимость устранения риска». Желательно создавать резервные запасы ресурсов для устранения непредвиденных проблем.
В рамках проекта рекомендуется постоянно вести и анализировать списки 10 важнейших рисков; списки неустраненных рисков в наиболее критических точках проекта; отчеты по устраненным, неустраненным и новым рискам; учитывать возможную стоимость последствий рисков в зависимости от имеющегося резерва.
Навык 2 – соглашения об интерфейсах: пользовательских, внутренних (межмодульных) и внешних (для стыковки с другими компонентами и приложениями).
Интерфейсы программы – это необходимая часть системных требований и ее архитектуры, но руководители проектов часто забывают контролировать соответствие продукта этим соглашениям. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется заново проектировать, программировать и тестировать.
Для построения пользовательского интерфейса неплохо использовать подход RAD. При этом пользовательский интерфейс (как и все остальные) надо полностью определить, согласовать с заказчиком и утвердить до начала этапов проектирования и разработки. Его описание должно быть включено в системную спецификацию на уровне определения каждого экранного поля, элемента ввода/вывода и средств навигации между формами/окнами/экранами.
Правильность интерфейса проверяет и утверждает только реальный пользователь каждого рабочего места из организации-заказ-чика. Для встраиваемой системы готовятся отдельные требования к ее внешнему интерфейсу.
Навык 3 – формальные проверки проекта. Нередко устранение ошибок начинается, только когда проект переходит к этапу тестирования. Такие этапы были придуманы 30 лет назад для создания небольших по сегодняшним меркам систем, и хотя в тестировании нет ничего плохого, выделять его в отдельный этап методически неверно. Стоимость этапа тестирования может достигать 4060 % стоимости всего проекта. Эти ненужные усилия можно сократить на порядок, однако немногие руководители знают, как это сделать.
Не менее важны усилия по проверке корректности проекта на этапах формулирования требований, создания архитектуры системы и проектирования. Для выполнения формальных проверок надо использовать небольшие группы сотрудников с четко определенными ролями, привлекая при этом пользователей организации-заказчика. Персонал необходимо постоянно тренировать в умении анализировать код на наличие ошибок. Желательно отслеживать продолжительность усилий по проверкам проекта, число найденных ошибок по отношению к затраченным на их поиск усилиям и среднее время от внесения ошибки до ее устранения.
Навык 4 – управление проектом на основе метрик. Этот навык нужен для раннего обнаружения потенциальных проблем. Как уже говорилось, стоимость устранения дефекта в проекте увеличивается в геометрической прогрессии по мере роста проекта.
С помощью метрик (числовых характеристик) планируются все задачи проекта. Ход их выполнения надо регулярно отслеживать, как минимум, – по ключевым показателям (стоимость работы и производительность труда). Надо дополнительно контролировать время, затрачиваемое на устранение дефектов, и следить за важнейшими показателями, чтобы по их отклонениям (в любую сторону – например, слишком резвый старт) выявлять потенциальные «подводные камни». Метрики основываются на эмпирических данных, например, на основе результатов анализа схожих по размерам проектов.
Навык 5 – качество продукта должно контролироваться на глубоком уровне. Проблема реализации мелких деталей программного проекта очень важна при разработке ПО. Иногда мелкое на первый взгляд требование заказчика выливается в глобальную переделку проекта. Если же проект спланирован недостаточно подробно, обсуждать реальное положение дел в ходе его выполнения бессмысленно.
В проекте надо выделить задачи объемом не более 5 % по продолжительности и усилиям, которые могут быть выполнены отдельной группой сотрудников как минимум на 95 %. Каждая подобная задача должна быть ориентирована на выполнение однотипной работы. Результат выполнения задачи оценивается группой приемки, при этом работа не может быть принята с оговорками: она должна быть выполнена полностью и без ошибок (двоичная система оценки качества «готово/не готово»).
Навык 6 – информация о ходе проекта должна быть общедоступной. Чем больше сотрудников вовлечено в процесс контроля над ходом проекта, тем проще идентифицировать потенциальные проблемы и риски. Надо сделать показатели хода проекта доступными всем сотрудникам и заказчику и организовать канал приема анонимных сообщений о возникающих проблемах. Чаще всего такой канал используется для сведения личных счетов, но лучше получить ложный сигнал, чем не узнать о реальной проблеме. К тому же открытость проекта – это залог снижения числа ложных сообщений.
Навык 7 – чтобы добиться высокого качества, надо отслеживать причины возникновения ошибок. Эффективность работы компании непосредственно зависит от наличия ошибок в проекте. Большинство компаний не контролируют их реальные источники: ошибки программистов, отклонения в графиках выполнения работ, превышение планируемой стоимости, неверно сформулированные требования, неправильно подготовленную документацию и плохо обученный персонал. В каждой фазе проекта ошибки должны отслеживаться формально. Для этого желательно использовать средства конфигурационного управления. Каждый случай обнаружения и устранения ошибки обязательно надо документировать.
Устранять ошибки необходимо по мере их возникновения. При этом учет ошибок удобнее всего вести в нормализованном виде (в расчете на единицу объема, например, на тысячу строк кода). Согласно принципу «снежного кома», с ростом объема проекта норма ошибок в нем увеличивается. Также надо контролировать среднее и максимальное время устранения ошибки и время от внесения до устранения ошибки в течение каждого этапа проекта и на протяжении первого года эксплуатации системы.
Навык 8 – управление конфигурацией. Неконтролируемые изменения в проекте могут быстро ввергнуть его в хаос. Поэтому на практике надо руководствоваться двумя простыми правилами:
любую информацию, которую использует более чем один сотрудник, надо контролировать с помощью системы управления конфигурацией;
любую информацию, учитываемую системой качества, надо контролировать с помощью системы управления конфигурацией.
Надо отслеживать все изменения в состоянии создаваемой системы, бюджете и сроках, интерфейсах, контрольных отчетах и т.п. Без систем управления конфигурацией при этом не обойтись, потому что в крупном проекте большие объемы информации меняются очень быстро. Каждый учитываемый объект должен определяться его версией, при этом надо вести архив всех версий всех таких объектов.
Навык 9 – управление персоналом. Главный фактор успеха проекта – качество, опыт и мотивация сотрудников. Не надо забывать, что с помощью различных методик производительность труда программистов можно значительно повысить. К тому же, как бы подробно ни документировался проект, некоторые детали его архитектуры всегда хранятся только в головах разработчиков, и руководитель проекта должен помогать сотрудникам проявлять индивидуальные творческие способности.
Выявлена высокая степень корреляции между суммами, вкладываемыми в обучение персонала, и общим успехом проекта, поэтому надо постоянно проводить обучение и переподготовку сотрудников. Любые авралы необходимо минимизировать. К авралам (как это на первый взгляд ни парадоксально) обычно приводит работа более 40 часов в неделю, что говорит о неверной организации труда и скрытых ошибках в организационной структуре.
|
