Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘Стандарты и методологии’ Category

CMMI DEV v1.3 – Управление Организационными Показателями

Posted by Шамрай Александр на Декабрь 5, 2014

Перевод Шамрай А.В.

Процессная область Управления Процессами уровня зрелости 5

Назначение

Назначением Управление Организационными Показателями (ОУП) является активный контроль эффективности деятельности Организации для удовлетворения своих бизнес-целей.

Вступительный комментарий

Процессная область Управление Организационными Показателями позволяет организации управлять организационными показателями через итеративный анализ агрегированных проектных данных, выявление пробелов в показателях на основе бизнес-целей, и через выбор и внедрение улучшений для исправления проблем.

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

Бизнес-цели, которые эта процессная область может затрагивать, включают следующие:

  • Улучшение качества продукта (например, функциональность, атрибуты качества)
  • Повышение продуктивности
  • Повышение эффективности и производительности процессов
  • Повышение согласованности в достижении бюджета и графика
  • Сокращение времени цикла
  • Улучшение удовлетворенности клиентов и конечных пользователей
  • Уменьшение времени разработки или производства для изменения функциональности, добавления новых функций или адаптации к новым технологиям
  • Улучшение эффективности цепочки поставок с участием нескольких поставщиков
  • Улучшение использования ресурсов во всей организации

Организация анализирует данные показателей продукта и процесса из проектов, чтобы определить способны ли они удовлетворить цели качества и показателей процесса. Базовые показатели процесса и модели выполнения процесса, разработанные с использованием процессов Показатели Организационных Процессов, используются как часть анализа. Анализ Причин и Принятие Решений может также использоваться для выявления потенциальных областей усовершенствования или конкретных предложений по улучшению.

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

Реализация улучшений и их влияние на цели качества и показателей процесса зависит от возможности эффективного выявления, оценки, реализации и внедрения улучшений в организационные процессы и технологии.

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

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

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

Процессная область Фокусирование на Организационных Процессах не включает в себя предположений о количественной основе для выявления улучшений, ни их ожидаемых результатов. Эта процессная область расширяет практики Фокусирования на Организационных Процессах, сосредоточив внимание на улучшение процесса на основе количественного понимания набора стандартных процессов организации и технологий и их ожидаемого качества и показателей процесса.

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

Связанные процессные области

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятии мер для улучшения показателей процесса.

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

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставления результатов измерений.

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

См. процессную область Показатели Организационных Процессов для получения дополнительной информации об установке целей качества и выполнения процесса и установке базовых показателей и моделей процессов.

См. процессную область Организационное Обучение для получения дополнительной информации об обеспечении обучения.

Перечень специфических целей и практик

  • СЦ 1 Управлять Бизнес Показателями
    • СП 1.1 Поддерживайте Бизнес Цели
    • СП 1.2 Анализируйте Данные Показателей Процессов
    • СП 1.3 Выявляйте Потенциальные Области для Улучшения
  • СЦ 2 Выбрать Улучшения
    • СП 2.1 Выявляйте Предложения по Улучшению
    • СП 2.2 Анализируйте Предложения по Улучшению
    • СП 2.3 Выполняйте Валидацию Улучшений
    • СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения
  • СЦ 3 Внедрить Улучшения
    • Планируйте Внедрение
    • Управляйте Внедрением
    • Оценивайте Эффекты от Улучшений

Специфические практики по целям

СЦ 1 Управлять Бизнес Показателями

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

Управление бизнес показателями требует следующее:

  • Поддержки бизнес целей организации
  • Понимания способностей организации для достижения бизнес целей
  • Постоянного улучшения процессов, относящихся к достижению бизнес-целей

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

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о
создании базовых показателей и моделей.

По мере улучшения организацией ее показателей процесса или изменения бизнес-стратегий, определяются новые бизнес-цели и связанные цели качества и показатели процесса, которые являются производными.

Специфическая цель 2 направлена на выявление и анализ предложений для устранения недостатков в достижении целей качества и показателей процесса.

СП 1.1 Поддерживайте Бизнес Цели

Поддерживайте бизнес-цели на основе понимания бизнес-стратегий и фактических результатов.

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

Пример рабочих продуктов

1. Пересмотренные бизнес-цели

2. Пересмотренные цели качества и показателей процессов

3. Утверждение руководством пересмотренные бизнес цели и цели качества и показателей процессов

4. Информирование о всех пересмотренных целях

5. Обновленные меры показателей процесса

Подпрактики

1. Периодически оценивайте бизнес-цели, чтобы убедиться, что они соответствуют бизнес-стратегии.

Руководство отвечает за понимание рынка, создание бизнес-стратегии и бизнес целей.

Т.к. бизнес-стратегии и организационные показатели изменяются, бизнес-цели должны периодически пересматриваться, чтобы определить необходимость их обновления. Например, бизнес-цель может отдаляться, если показатели процесса показывают, что бизнес-цель достигается в течение длительного времени или изменилась связанная бизнес-стратегия.

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

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

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

3. Устанавливайте приоритеты для бизнес-целей, основываясь на документированных критериях, таких как способность обеспечить новый бизнес, сохранить существующих клиентов или достигнуть других ключевых бизнес-стратегий.

4. Поддерживайте цели качества и показателей процесса для обеспечения изменений в бизнес-целей.

Бизнес-цели, цели качества и цели показателей процесса обычно развиваются с течением времени. После того как существующие цели будут достигнуты, они должны контролироваться, чтобы убедиться, что они продолжают быть достижимыми, в то время как новые бизнес-цели и связанные цели качества и показателей процесса определены и управляемы.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании целей качества и показателей процесса.

5. Пересматривайте меры процесса для их соответствия целям качества и целям показателей процесса.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о мерах для показателей процесса.

СП 1.2 Анализируйте Данные Показателей Процесса

Анализируйте данные показателей процесса для определения способности организации достичь установленные бизнес-цели.

Результирующие данные после выполнения измерений показателей процесса, которые были определены с помощью процессов Показатели Организационных Процессов, анализируются для создания базовых показателей выполнения процесса, которые помогают понять текущие возможности организации. Сравнение базовых показателей и целей качества и показателей процесса помогает организации определить ее способность достигать бизнес-цели. Для обеспечения организационного анализа эти данные обычно собираются из данных показателей процесса на проектном уровне.

Пример рабочих продуктов

1. Анализ текущих возможностей на основе бизнес-целей

2. Недостатки показателей процесса

3. Риски, связанные с достижением бизнес целей

Подпрактики

1. Периодически сравнивайте цели качества и показателей процесса с текущими базовыми показателями процесса для оценки способности организации достичь ее бизнес-цели.

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

2. Выявляйте недостатки, где фактические показатели процесса не отвечают бизнес-целям.

3. Выявляйте и анализируйте риски, связанные с проблемой достижения бизнес целей.

4. Подготовьте отчеты по результатам анализа показателей выполнения процесса и анализа рисков для руководства организации.

СП 1.3 Выявляйте Потенциальные Области для Улучшения

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

Потенциальные области для улучшения определяются путем активного анализа для определения областей, которые могут иметь недостатки в показателях процесса. Процессы Анализ Причин и Принятие Решений могут использоваться для диагностики и устранения корневых причин.

Результат этих мероприятий используется для оценки и определения приоритетности возможных улучшений и может привести либо к инкрементальным, либо к инновационным предложениям, как описано в специфической цели 2.

Пример рабочих продуктов

1. Потенциальные области для улучшения

Подпрактики

1. Определяйте потенциальные области для улучшения на основе активного анализа о недостатках в показателях процесса.

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

2. Документируйте обоснование для потенциальных областей на совершенствование, включая ссылки на применяемые бизнес-цели и данные о показателях процесса.

3. Документируйте ожидаемые затраты и выгоды, связанные с потенциальными областями для улучшения.

4. Предоставьте всем заинтересованным лицам набор потенциальных областей для улучшения для дальнейшей оценки, определения приоритетов и использования.

СЦ 2 Выбрать Улучшения

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

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

Оценки предложений основаны на следующем:

  • Количественное понимание текущего качества и показателей процесса организации
  • Удовлетворение целями качества и показателей выполнения процесса организации
  • По оценкам затрат и влияния разработки и внедрения улучшений, ресурсов и финансовых средств для внедрения
  • По оценкам выгод для качества и показателей процесса, вызванных внедрением улучшения

СП 2.1 Выявляйте улучшения

Выявить и классифицировать предлагаемые улучшения.

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

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

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

Инновации можно привнести извне, выполняя активный мониторинг инноваций, используемых в других организациях или документально подтвержденных в исследовательской литературе. Инновации можно также обнаружить оценкой изнутри (например, путем изучения полученного опыта в проектах). Инновации вдохновляются необходимостью достижения целей качества и целей показателей процесса, необходимостью улучшения базовых показателей выполнения или внешней бизнес-средой.

Примеры инкрементальных улучшений включают следующие:

  • Добавление элемента к контрольному списку коллегиальной оценки.
  • Объединение технической оценки и управленческой оценки для поставщиков в единую оценку.
  • Введение обходного пути для инцидента.
  • Замена на новый компонент.
  • Внесение незначительных обновлений к инструменту.

Примеры инновационных улучшений обычно включают дополнительные или крупные обновления к следующему:

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

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

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

Пример рабочих продуктов

1. Предлагаемые инкрементальные улучшения

2. Предлагаемые инновационные улучшения

Подпрактики

1. Выявляйте предлагаемые улучшения.

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

Примеры источников для улучшения включают следующее:

  • Выводы и рекомендации из оценки процесса
  • Цели качества и цели показателей процесса организации
  • Анализ данных о проблемах клиентов и конечных пользователей, а также удовлетворенности клиентов и конечных пользователей
  • Результаты оценки производительности процесса и продукта
  • Измерения эффективности деятельностей процесса
  • Измерения эффективности проектных рабочих сред
  • Примеры улучшений, которые были успешно приняты в других местах
  • Отзывы о предыдущих улучшениях
  • Спонтанные идеи от руководителей и сотрудников
  • Предложения об улучшениях из процессов Анализ Причин и Принятие Решений, которые являются результатом выполненных действий с доказанной эффективностью
  • Анализ мер технических показателей
  • Анализ данных о причинах дефектов
  • Анализ показателей проекта и организации по сравнению с целями качества и продуктивности

<См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации о реализации активов организационного процесса и учета опыта.

 

2. Определяйте предлагаемые улучшения как инкрементальные или инновационные.

3. Исследуйте инновационные улучшения, которые могут улучшить процессы и технологии организации.

Обычно исследование инновационных улучшений включает в себя следующее:

  • Поддержание осведомленности о соответствующих ведущих технических работах и тенденциях технологий
  • Поиск коммерчески доступных инновационных улучшений
  • Сбор предложений для инновационных улучшений из проектов и организации
  • Оценка процессов и технологий, используемых извне, и их сравнение с процессами и технологиями, используемыми в организации
  • Выявление областей, где успешно используются инновационные усовершенствования, и оценка данных и документации опыта использования этих улучшений
  • Выявления улучшений, которые интегрируют новые технологии в продукт и проектные рабочие среды

СП 2.2 Анализируйте Предложения по Улучшению

Анализируйте предлагаемые улучшения на предмет их возможного воздействия на достижение целей качества и показателей процесса организации.

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

Пример рабочих продуктов

1. Предлагаемые предложения по улучшению

2. Отобранные улучшения для проверки

Подпрактики

1. Анализируйте затраты и выгоды предлагаемых улучшений.

Модели показателей выполнения процесса обеспечат понимание влияния изменений процесса на возможности процесса и его показатели.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании модели показателей процесса.

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

Критерии для оценки затрат и выгод, включают следующее:

  • Вложения к достижению целей качества и показателей процесса организации
  • Влияние на снижение определенных рисков проекта и организационных рисков
  • Способность реагировать быстро на изменения требований проекта, рыночных ситуаций и бизнес-среды
  • Влияние на связанные процессы и активы
  • Стоимость определения и сбора данных, которые поддерживают измерения и анализа процесса, а также технологии улучшения
  • Ожидаемый срок влияния улучшения

2. Выявляйте потенциальные барьеры и риски внедрения каждого предлагаемого улучшения.

Примеры барьеров внедрения улучшения включают следующее:

  • Перспективы относятся к слишком узкой области
  • Непрозрачное или слабое бизнес обоснование
  • Отсутствие краткосрочных выгод и видимых успехов
  • Непрозрачное отражение того, что ожидается от каждого
  • Слишком много изменений в один момент времени
  • Отсутствие участия и поддержки со стороны соответствующих заинтересованных сторон

<Примеры факторов риска, которые влияют на внедрение улучшений, включают следующее:

  • Совместимость улучшений с существующими процессами, результатами и навыками потенциальных конечных пользователей
  • Сложность улучшений
  • Сложность реализации улучшения
  • Возможность продемонстрировать важное значение улучшения перед широким внедрением
  • Обоснование для больших первоначальных инвестиций в таких областях, как инструменты и обучение
  • Неспособность преодолеть «технологические смещения», где текущая реализация успешно используется большой и высокого уровня зрелости базой конечных пользователей

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

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

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

5. Документируйте результаты оценки каждого выбранного предложения улучшения в предложении по улучшению.

Предложение должно включать постановку задачи, план (включая стоимость и расписание, управление рисками, метод для оценки эффективности в целевой среде) для реализации улучшения и количественные критерии успеха для оценки фактических результатов внедрения.

6. Определяйте подробные изменения, которые необходимы для реализации улучшения и документируйте их в предложении по улучшению.

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

Определение метода валидации включает в себя определение количественных критериев успеха, которые будут использоваться для оценки результатов валидации.

Поскольку инновации, по определению, представляют собой крупные изменения с высоким уровнем воздействия, наиболее инновационные усовершенствования должны быть опробованы (пилотная эксплуатация). При необходимости можно использовать другие методы валидации, включая моделирование и симуляцию.

8. Документируйте результаты процесса отбора.

Результаты процесса отбора, как правило, включают следующее:

  • Распоряжение для каждого предложения по улучшению
  • Обоснование распоряжения для каждого предложения по улучшению

СП 2.3 Выполняйте Валидацию Улучшений

Выполняйте валидацию выбранных улучшений.

Выбранные улучшения, проверяются в соответствии с их предложениями по улучшению.

Примеры методов валидации включают в себя следующее:

  • Обсуждение с заинтересованными сторонами, возможно, в рамках официальной оценки
  • Демонстрации прототипа
  • Пилотная эксплуатация для предлагаемых улучшений
  • Моделирование и симулирование

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

В пилоте может использоваться процессная документация, размеченная промежуточно выделенным текстом или в виде черновиков.

Пример рабочих продуктов

1. План валидации

2. Отчеты для оценки валидации

3. Задокументированные уроки, извлеченные из проведения валидации

Подпрактики

1. Планируйте валидацию.

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

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

2. Выполните оценку и получите согласие соответствующих заинтересованных сторон для планов валидации.

3. Проконсультируйтесь и получите поддержку от тех, кто выполняет проверку.

4. Выполните пробное внедрение в соответствии с планом валидации для выбранных улучшений пилотной эксплуатации.

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

6. Отслеживание ход валидации на основе их планов.

7. Выполняйте оценку и документирование результатов валидации.

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

Оценка и документирование результатов пилота обычно включает в себя следующие мероприятия:

  • Анализ результатов пилотной эксплуатации с заинтересованными сторонами
  • Принятие решения о прекращении пилота, переработке реализации улучшения, перепланировании и продолжении пилота или начале внедрения
  • Обновление распоряжения для предложений по улучшению, связанных с пилотными работами
  • Выявление и документирование новых предложений по улучшению в случае необходимости
  • Выявление и документирование накопленного опыта и возникших проблем в ходе пилота, включая обратную связь для команды апробирующей улучшения и изменения для улучшения

СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения

Выбирайте и реализуйте улучшения для внедрения во всей организации на основе оценки затрат, выгод и других факторов.

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

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

Пример рабочих продуктов

1. Улучшения, выбранные для внедрения

2. Обновленные процессная документация и материалы для обучения

Подпрактики

1. Устанавливайте приоритеты для внедрения.

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

2. Выбирайте улучшения для внедрения.

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

3. Определяйте, как внедрять каждое улучшение.

Примеры, где улучшения могут быть внедрены, следующие:

  • Среды определенных проектов или общие рабочие среды
  • Семейства продуктов
  • Проекты организации
  • Организационные группы

4. Документируйте результаты процесса отбора.

Результаты процесса отбора, как правило, включают следующее:

  • Критерии выбора предлагаемых улучшений
  • Характеристики целевых проектов
  • Распоряжение каждого предложения по улучшению
  • Обоснование для распоряжения каждого предложения по улучшению

5. Оценивайте любые изменения, которые необходимы для реализации улучшений.

Примеры изменений, необходимых для внедрения улучшения, включают следующее:

  • Описания процессов, стандарты и процедуры
  • Рабочие среды
  • Обучение и тренинги
  • Навыки
  • Существующие обязательства
  • Существующие мероприятия
  • Постоянная поддержки конечных пользователей
  • Организационная культура и характеристики

6. Обновляйте активы организационного процесса.

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

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

СЦ 3 Внедрить Улучшения

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

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

СП 3.1 Запланируйте внедрение

Устанавливайте и поддерживайте планы внедрения выбранных улучшений.

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

Эта конкретная практика дополняет специфическую практику Внедряйте Активы Организационных Процессов в процессной области Фокусирование на Организационных Процессах и добавляет использование количественных данных для внедрения и определения значимости улучшений.

См. процессную область Фокусирование на Организационных Процессах
для получения дополнительной информации о внедрении активов организационных процессов и включении полученного опыта.

Пример рабочих продуктов

1.Планы внедрений для выбранных улучшений

Подпрактики

1. Определяйте, каким образом следует скорректировать каждое улучшение для внедрения.

Усовершенствования в ограниченном контексте (например, для одного предложения для улучшения) возможно потребуется изменить для выбранной части организации.

2. Определяйте стратегии, которые учитывают потенциальные барьеры для внедрения каждого улучшения, которые были определены в предложениях улучшений.

3. Определите целевой набор проектов для внедрения улучшения.

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

4. Устанавливайте меры и цели для определения значения каждого улучшения в отношении целей качества и целей показателей процесса организации.

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

Примеры мер для определения значимости улучшения включают следующее:

  • Измеренные улучшения выполнения проекта или процесса организации
  • Время на возврат затрат по улучшению
  • Количество и типы проектных и организационных рисков, сниженных путем улучшения процесса или технологии
  • Среднее время, необходимое для реагирования на изменения в требованиях проекта, рыночной ситуации и бизнес-среде

См. процессную область Измерение и Анализ для получения дополнительной информации об установке мер и мероприятий анализа, и предоставления результатов измерений.

5. Документируйте планы внедрения выбранных улучшений.

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

6. Выполняйте оценку и получите одобрение соответствующих заинтересованных сторон для планов внедрения выбранных улучшений.

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

7. Пересматривайте планы по внедрению выбранных улучшений по мере необходимости.

СП 3.2 Управляйте Внедрением

Управляйте внедрением выбранных улучшений.

Эта конкретная практика может пересекаться с конкретной практикой Реализовывайте Предложения Мероприятий в процессной области Анализ Причин и Принятие Решений (например, когда анализ причин и принятие решений используется организационно или в нескольких проектах).

Пример рабочих продуктов

1. Обновленные учебные материалы (с учетом внедренных улучшений)

2. Документально подтвержденные результаты мероприятий внедрения улучшения

3. Пересмотренные меры улучшений, цели, приоритеты и планы внедрения

Подпрактики

1. Отслеживайте внедрение улучшений с помощью планов внедрения.

2. Координируйте внедрение улучшений во всей организации.

Координация внедрения включает в себя следующие мероприятия:

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

3. Внедряйте улучшения в контролируемой и дисциплинированной манере.

Примеры методов для внедрения улучшений включают следующее:

  • Внедрение улучшений инкрементально, а не как одно внедрение
  • Обеспечение всеобъемлющего консалтинга для ранних приемников улучшения вместо пересмотренных формальных обучений

4. Координируйте внедрение улучшений в процессы определенных для проектов в соответствующих случаях.

См. процессную область Фокусирование на Организационных Процессах
для получения дополнительной информации о внедрении активов организационных процессов и включении полученного опыта.

5. Предоставляйте консультации в случае необходимости для поддержки внедрения улучшений.

6. Обеспечивайте обновленные учебные материалы или разрабатывайте пакеты для распространения с учетом улучшения активов организационного процесса.

См. процессную область Организационное Обучение для получения дополнительной информации об обеспечении обучения.

7. Подтвердите, что внедрения всех улучшений завершены в соответствии с планом внедрения.

8. Задокументируйте и оцените результаты внедрения улучшений.

Документирование и анализ результатов включает в себя следующее:

  • Выявление и документирование накопленного опыта
  • Пересмотр мер улучшений, целей, приоритетов и планов развертывания

СП 3.3 Оценивайте Эффекты от Улучшения

Оценивайте эффекты от внедренных улучшений на качество и показатели процессов с использованием статистических и других количественных методов.

См. процессную область Измерение и Анализ для получения дополнительной информации об установке мер и деятельности анализа, и предоставления результатов измерений.

Эта конкретная практика может пересекаться со специфической практикой Оценивайте Эффект Реализованных Мероприятий в процессной области Анализ Причин и Принятие Решений (например, когда анализ причин и принятие решений применяется организационно или в нескольких проектах).

Пример рабочих продуктов

1. Документально подтвержденные меры эффектов, вызванные внедренными улучшениями

Подпрактики

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

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

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании целей качества и показателей выполнения процесса и установке базовых показателей и моделей процесса.

Posted in CMMI, Стандарты и методологии | Отмечено: , , | Leave a Comment »

CMMI DEV v1.3 – Количественное Управление Проектом

Posted by Шамрай Александр на Ноябрь 28, 2013

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 4

Назначение

Назначением Количественного Управления Проектом (КУП) является управление проектом на основе количественных показателей для достижения целей качества и выполнения процесса проекта.

Вступительный комментарий

Процессная область Количественное Управление Проектом включает в себя следующие мероприятия:

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

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

Определенный процесс проекта — это набор взаимосвязанных подпроцессов, которые образуют комплексный и последовательный процесс для проекта. Практики Комплексного Управления Проектом описывают установку определенного процесса проекта с использованием выбора и доводки процессов из набора стандартных процессов организации. (См. определение «определенный процесс» в глоссарии).

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

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

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

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

Таким образом количественное управление включает статистическое мышление и правильное использование различных статистических методов. (См. определение «количественное управление» в глоссарии).

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

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

Примеры других групп и функций, которые могут извлечь выгоду от использования этой процессной области, включают следующее:

  • Функции проверки качества или контроля качества
  • Определение и улучшение процесса
  • Функции внутреннего исследования и разработки
  • Функции идентификации и управления рисками
  • Функции технологий исследования
  • Исследования рынка
  • Оценка удовлетворенности заказчиков
  • Проблемы отслеживания и отчетности

Связанные процессные области

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятие мер для улучшения выполнения процесса.

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставления результатов измерений.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

См. процессную область Управление Организационными Показателями для получения дополнительной информации об упреждающем управлении показателями организации для удовлетворения ее бизнес-целей.

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

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

См. процессную область Управление Соглашениями с Поставщиками для получения дополнительной информации об управлении приобретением товаров и услуг от поставщиков.

Перечень специфических целей и практик

  • СЦ 1 Подготовить Количественное Управление
    • СП 1.1 Устанавливайте Цели Проекта
    • СП 1.2 Составляйте Определенный Процесс
    • СП 1.3 Выбирайте Подпроцессы и Атрибуты
    • СП 1.4 Выбирайте Меры и Техники Аналитики
  • СЦ 2 Количественно Управлять Проектом
    • СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов
    • СП 2.2 Управляйте Выполнением Проекта
    • СП 2.3 Выполняйте Анализ Корневых Причин

Специфические практики по целям

СЦ 1 Подготовить Количественное Управление

Проведена подготовка для количественного управления.

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

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

СП 1.1 Устанавливайте Цели Проекта

Создавайте и поддерживайте проектные цели качества и выполнения процесса.

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

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

Пример рабочих продуктов

1. Проектные цели качества и выполнения процесса

2. Оценка риска не достижения целей проекта

Подпрактики

1. Анализируйте организационные цели для качества и выполнения процесса.

Эта оценка гарантирует, что члены проекта понимают более широкой бизнес-контекст, в котором существует проект. Цели проекта для качества и выполнения процесса разрабатываются в контексте этих всеобъемлющих организационных целей.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации об установке целей качества и выполнения процесса.

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

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

Примеры атрибутов качества и выполнения процесса, для которых могут быть определены потребности и приоритеты, включают в себя следующее:

  • Продолжительность
  • Предсказуемость
  • Надежность
  • Ремонтопригодность
  • Удобство использования
  • Своевременность
  • Функциональность
  • Точность

3. Определяйте и документируйте измеряемые цели качества и выполнения процесса для проекта.

Определение и документирование целей проекта включают следующее:

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

Примеры поддающихся измерению атрибутов качества включают следующее:

  • Среднее время между сбоями
  • Количество и важность дефектов в выпущенном продукте
  • Использование критических ресурсов
  • Число и важность обращений заказчиков, относительно предоставляемых услуг

Примеры поддающихся измерению атрибутов выполнения процесса включают следующее:

  • Время цикла
  • Процент времени переработки
  • Процент дефектов удаленных путем мероприятий верификации продукта (возможно по типу верификации, таких как коллегиальные оценки и тестирование)
  • Уровень исправления дефектов
  • Количество и важность дефектов (или инцидентов) найденных в первый год после поставки продукта (или запуска сервиса)

Примеры проектных целей качества и выполнения процесса включают в себя:

  • Поддержка размера журнала запросов на изменение ниже планируемого значения.
  • Улучшение производительности в гибкой среде относительно планируемого значения к планируемому сроку.
  • Сокращение время простоя на x % к установленному сроку.
  • Поддержка изменения расписания ниже указанного процента.
  • Снижение стоимости всего жизненного цикла на указанный % к установленному сроку.
  • Сокращения количества дефектов в продукте, поставляемого заказчику, на 10% без влияния на стоимость.

4. Определяйте промежуточные цели для мониторинга прогресса в достижении целей проекта.

Промежуточные цели могут создаваться для атрибутов выбранного этапа жизненного цикла, вех, рабочих продуктов и подпроцессов.

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

5. Определяйте риски, которые влияют на достижение проектных целей качества и выполнения процесса.

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

6. Разрешайте конфликты между проектными целями качества и выполнения процесса (например, если одна из целей не может быть достигнута без ущерба для другой).

Модели выполнения процесса могут помочь выявить конфликты и способствовать тому, что решение конфликтов не вводит новые конфликты или риски.

Разрешение конфликтов предполагает следующие виды мероприятий:

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

7. Устанавливайте трассировку проектных целей качества и выполнения процесса к их источникам.

Примеры источников цели включают следующее:

  • Требования
  • Цели качества и выполнения процесса организации
  • Цели качество и выполнения процесса заказчика
  • Бизнес-цели
  • Обсуждение с заказчиками и потенциальными заказчиками
  • Обследование рынка
  • Архитектура продукта

Пример метода, позволяющего выявлять и отслеживать эти потребности и приоритеты, — развертывание функций качества (QFD).

8. Определяйте и согласовывайте цели качества и выполнения процесса для поставщиков.

9. Пересматривайте проектные цели качества и выполнения процесса по мере необходимости.

СП 1.2 Составляйте Определенный Процесс

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

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании базовых показателей выполнения и модели.

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

Пример рабочих продуктов

1. Критерии, используемые для оценки альтернатив для проекта

2. Альтернативные подпроцессы

3. Подпроцессы, которые должны быть включены в определенный процесс проекта

4. Оценка риска, влияющего на достижение целей проекта

Подпрактики

1. Устанавливайте критерии для использования при оценке альтернатив процесса для проекта.

Критерии могут быть основаны на следующем:

  • Цели качества и выполнения процесса
  • Доступность данных о выполнении процесса и важность данных для оценки альтернатив
  • Знакомство с альтернативой или альтернативными вариантами, аналогичными составляемым
  • Наличие моделей выполнения процессов, которые могут быть использованы в оценке альтернатив
  • Стандарты линейки продукта
  • Модели жизненного цикла проекта
  • Требования заинтересованных сторон
  • Законы и правила

2. Определяйте альтернативные процессы и подпроцессы для проекта.

Выявление альтернатив может включать одно или несколько из следующих действий:

  • Анализ базовых показателей выполнения организационных процессов для определения кандидата в подпроцессы, которые помогли бы достичь проектные цели качества и выполнения процесса
  • Выявление подпроцессов из набора стандартных процессов, а также с учетом процессов в библиотеке активов процессов, которые могут помочь в достижении целей организации в
  • Выявление процессов из внешних источников (например, других организаций, профессиональных конференций, научных исследований)
  • Регулировка уровня или глубины интенсивности, с которой применяется подпроцесс (описано более подробно в подпрактике ниже)

Регулировка уровня или глубины интенсивности, с которой применяются подпроцессы, может включать следующие варианты:

  • Количество и тип коллегиальных оценок, которые состоятся и когда
  • Количество усилий или календарного времени, затрачиваемого на конкретные задачи
  • Число и выбор вовлекаемых людей
  • Требования к уровню квалификации для выполнения конкретных задач
  • Избирательное применение специализированных методов сборки или верификации
  • Повторное использование решений и связанных с ними стратегий для смягчения последствий рисков
  • Атрибуты продуктов и процессов для измерения
  • Частота дискретизации для управления данными

См. процессную область Комплексное Управление Проектом для получения дополнительной информации об использовании активов организационных процессов для планирования проектной активности.

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

Анализ взаимодействия даст понимание относительных преимуществ и недостатков конкретных альтернатив. Этот анализ может поддерживаться калибровкой моделей выполнения процесса организации с данными выполнения процесса (например, как охарактеризовано в базовых показателях выполнения процесса).

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

4. Оценивайте альтернативные вспомогательные критерии.

Используйте исторические данные, базовые показатели выполнения процесса и модели выполнения процесса по мере необходимости в оценке альтернатив на основе критериев. Эти оценки могут включать использование анализа чувствительности, особенно в ситуациях высокого риска.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об оценке альтернатив.

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

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

6. Оценивайте риски не достижения целей качества и выполнения процесса для проекта.

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

См. процессную область Управление Рисками для получения дополнительной информации об идентификации и анализе рисков.

СП 1.3 Выбирайте Подпроцессы и Атрибуты

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

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

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

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

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

Пример рабочих продуктов

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

2. Выбранные подпроцессы

3. Атрибуты выбранных подпроцессов, которые помогают прогнозировать будущее выполнение проекта

Подпрактики

1. Анализируйте как подпроцессы, их атрибуты, другие факторы и результаты выполнения проекта связанные друг с другом.

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

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации об определении причин выбранных результатов.

2. Определяйте критерии, используемые при выборе вспомогательных процессов, которые являются ключевыми для обеспечения проектных целей качества и выполнения процесса.

Примеры критериев, используемых для выбора подпроцессов:

  • Существует сильная корреляция с результатами выполнения, которые рассматриваются в целях проекта.
  • Стабильное выполнение подпроцесса имеет важное значение.
  • Слабое выполнение подпроцессов ассоциируется с основными рисками проекта.
  • Один или несколько атрибутов подпроцесса служат основными входными артефактами для моделей выполнения процесса, используемых в проекте.
  • Подпроцесс будет выполняться достаточно часто для предоставления достаточных данных для анализа.

3. Выбирайте подпроцессы с помощью определенных критериев.

Исторические данные, модели выполнения процесса и базовые показатели выполнения процесса могут помочь в оценке кандидата подпроцесса на основе критериев отбора.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об оценке альтернатив.

4. Определяйте атрибуты продукта и процесса, которые должны контролироваться.

Эти атрибуты были определены в рамках выполнения предыдущих подпрактик.

Атрибуты, которые дают представление о текущем или будущем выполнении подпроцессов, являются кандидатами для мониторинга, находятся или нет связанные подпроцессы под контролем проекта. Кроме того, некоторые из этих же атрибутов могут служить для других ролей (например, помочь в мониторинге прогресса и выполнения проекта, как описано в Мониторинге и Контроле Проекта [МКП]).

Примеры атрибутов продукта и процесса включают в себя следующее:

  • Усилия, применяемые для выполнения подпроцесса
  • Скорость, на которой выполняется подпроцесс
  • Время цикла для элементов процесса, которые составляют подпроцесс
  • Ресурсы или материалы, использованных в качестве входных для подпроцесса
  • Уровень квалификации сотрудника, выполняющего подпроцесс
  • Качество рабочей среды, используемой для выполнения подпроцесса
  • Объем артефактов подпроцесса на выходе (например, промежуточные рабочие продукты)
  • Качество атрибутов подпроцесса на выходе (например, надежность, тестируемость)

СП 1.4 Выбирайте Меры и Техники Аналитики

Выбирайте меры и аналитические методы для использования в количественном управлении.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

Пример рабочих продуктов

1. Определения мер и аналитических техник для использования в количественном управлении

2. Трассировка мер с проектными целями качества и выполнения процесса

3. Цели качества и выполнения процесса для выбранных подпроцессов и их атрибутов

4. Базовые показатели выполнения процесса и модели для использования в рамках проекта

Подпрактики

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

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании базовых показателей и моделей выполнения.

Общие меры могут классифицироваться линейкой продукта или другими критериями стратификации.

2. Определяйте дополнительные меры, которые могут быть необходимы для покрытия важнейших атрибутов продукта и процесса выбранных подпроцессов.

В некоторых случаях меры может быть получены на основе исследований. Такие меры должны быть четко определены.

3. Определяйте меры, которые будут использоваться в управлении подпроцессов.

При выборе мер, имейте в виду следующие соображения:

  • Меры, которые агрегируют данные из нескольких источников (например, различных процессов, источников входных артефактов, сред) или со временем (например, на уровне фаз) могут маскировать основополагающие проблемы, что затрудняет выявление проблем и принятие решений.
  • Для краткосрочных проектов может быть необходимо агрегировать данные для аналогичных экземпляров процесса для анализа его выполнения, продолжая при этом использовать неагрегированные данные для поддержки отдельных проектов.
  • Выбор не должен быть ограничен только мерами прогресса или выполнения. «Анализ мер» (например, выполнение подготовки инспекции, уровень квалификации членов персонала, покрытие пути в тестировании) может обеспечить лучшее понимание выполнение процесса.

4. Указывайте операционные определения мер, их точки сбора в подпроцессах и каким образом будет определяться целостность мер.

5. Анализируйте взаимосвязь выявленных мер и проектных целей качества и выполнения процесса, и производные цели качества и выполнения процесса для подпроцессов, которые задают целевые значения (например, пороговые значения, диапазоны) для каждого измеряемого атрибута каждого выбранного подпроцесса.

Примеры производных целей качества и выполнения процесса для подпроцессов включают в себя следующее:

  • Поддержка уровня рецензирования кода от 75 до 100 строк кода в час
  • Выдерживать длительность сессий сбора требования до трех часов
  • Выдерживать скорость тестирования на указанное количество тестовых случаев в день
  • Поддержка уровень переделки ниже указанного процента
  • Поддержка производительности в генерировании вариантов использования на один день
  • Выдерживать сложность проектирования (уровень разветвления) ниже заданного порогового значения

6. Определяйте статистические и другие количественные методы для использования в количественном управлении.

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

Проект может извлечь выгоду из анализа выполнения подпроцессов, которые не были выбраны, для оценки их влияния на эффективность проекта. Для идентификации этих подпроцессов также могут быть определены статистические и другие количественные методы.

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

Примеры графических отображений:

  • Диаграммы рассеивания
  • Гистограммы
  • Ящик с усами
  • Графики выполнения
  • Диаграммы Исикавы

Примеры из других методов, используемых для анализа выполнения процесса, включают в себя следующее:

  • Учетные листы
  • Схемы классификации (например, Ортогональная Классификация Дефектов)

7. Определяйте, какие базовые показатели выполнения процесса и модели могут быть необходимы для поддержки определенных анализов.

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

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

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

8. Инструментируйте для организационных сред или среды поддержки проекта для поддержки сбора, деривации и анализа мер.

Этот инструментарий основан на следующем:

  • Описании набора стандартных процессов организации
  • Описании определенного процесса проекта
  • Возможностях организационной или среды поддержки проекта

9. Пересматривайте меры и методы статистического анализа по мере необходимости.

СЦ 2 Количественно Управлять Проектом

Проект управляется количественно.

Количественное управление проектом включает в себя использование статистических и других количественных методов для выполнения следующих задач:

  • Мониторинг выбранных подпроцессов с использованием статистических и других количественных методов
  • Определение удовлетворены ли проектные цели качества и выполнения процесса
  • Выполнение анализа корневых причин выбранных проблем для устранения недостатков

СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов

Отслеживайте выполнение выбранных подпроцессов с использованием статистических и других количественных методов.

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

Пример рабочих продуктов

1. Естественные границы выполнение процесса для каждого выбранного атрибута подпроцессов

2. Действия, необходимые для устранения недостатков в стабильности процесса или возможностей каждого выбранного подпроцесса

Подпрактики

1. Собирайте данные, как это определено выбранными мерами, подпроцессов по мере их выполнения.

2. Контролируйте колебания и стабильность выбранных подпроцессов и устраняйте недостатки.

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

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

Аналитические методы для определения скачков или сигналов включают статистические диаграммы контроля процесса, прогнозирование интервалов и дисперсионный анализ. Некоторые из этих методов вовлекают графические отображения.

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

3. Отслеживайте возможности и выполнение выбранных подпроцессов и устраняйте недостатки.

Назначение этой подпрактики заключается в выявлении действий, которые следует предпринять, чтобы помочь подпроцессу достичь его цели качества и выполнения процесса. Будьте уверены, что выполнение подпроцессов является стабильным по отношению к выбранной мере (предыдущая подпрактика) перед сравнением его возможностей для целей качества и выполнения процесса.

Примеры действий, которые могут быть приняты, когда выполнение отдельных подпроцессов не удовлетворяет его целям, включают следующее:

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

Некоторые действия могут включать использование анализа корневых причин, который описан далее в СП 2.3.

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

СП 2.2 Управляйте Выполнением Проекта

Управляйте проектом с использованием статистических и других количественных методов для определения будут ли удовлетворены цели проекта для качества и выполнения процесса.

См. процессную область Измерение и Анализа для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

См. процессную область Управление Организационными Показателями для получения дополнительной информации об управлении показателями бизнеса.

Эта специфическая практика является проектно-ориентированной и использует несколько входных данных для прогнозирования будут ли удовлетворены проектные цели качества и выполнения процесса. Основываясь на этом прогнозе, риски, связанные с не достижением проектных целей качества и выполнения процесса, выявляются и управляются, а также действия для устранения недостатков определяются по необходимости.

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

Пример рабочих продуктов

1. Результаты прогнозов достижения относительно целей качества и выполнения процесса проекта

2. Графическое отображение и табулирование данных для других подпроцессов, поддерживающих количественное управление

3. Оценка рисков не достижения целей качества и выполнения процесса проекта

4. Действия, необходимые для устранения недостатков в достижении целей проекта

Подпрактики

1. Периодически оценивайте выполнение подпроцессов.

Стабильность и потенциал данных из мониторинга выбранных подпроцессов, как описано в СП2.1, являются ключевыми входными данными для понимания общей способности проекта удовлетворить цели качество и выполнения процесса.

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

2. Отслеживайте и анализируйте прогресс поставщиков в достижении их целей качества и выполнения процесса.

3. Периодически рассматривайте и анализируйте фактические результаты, достигнутые в отношении установленных временных целей.

4. Используйте модели выполнения процесса калиброванные с данными проекта для оценки прогресса в достижении проектных целей качества и выполнения процесса.

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

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

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

5. Определяйте и управляйте рисками не достижения проектных целей качества и выполнения процесса.

См. процессную область Управления Рисками для получения дополнительной информации о выявлении и анализе рисков, и снижении рисков.

Примеры источников рисков включают следующее:

  • Подпроцессы, которые имеют неадекватное выполнение или возможности
  • Поставщики, которые не обеспечивают их цели качества и выполнения
  • Отсутствие прозрачности в возможностях поставщиков
  • Неточности в модели выполнения процесса, используемой для прогнозирования выполнения
  • Недостатки в выполнении прогнозируемого процесса (по оценкам прогресса)
  • Другие выявленные риски, связанные с выявленными недостатками

6. Определяйте и реализуйте действия, необходимые для устранения недостатков в достижении проектных целей качества и выполнения процесса.

Назначение этой подпрактики — определить и реализовать правильный набор действий, ресурсов и график, чтобы вернуть проект на путь достижения его целей.

Примеры действий, которые могут быть предприняты для устранения недостатков в достижении целей проекта, включают следующее:

  • Изменение целей качества и выполнения процесса так, чтобы они находились в ожидаемых пределах определенного процесса проекта
  • Улучшение реализации определенного процесса проекта
  • Принятие новых подпроцессов и технологий, которые имеют потенциал для удовлетворения целей и управления связанными рисками
  • Выявление рисков и стратегии смягчения последствий риска для устранения недостатков
  • Завершение проекта

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

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

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

СП 2.3 Выполняйте Анализ Корневых Причин

Выполняйте анализ корневых причин выбранных проблем для устранения недостатков в достижении проектных целей качества и выполнения процесса.

Адресуемые проблемы включают в себя недостатки стабильности и возможностей подпроцессов и недостатки в выполнении проекта относительно его целей.

Анализ корневых причин выбранных проблем лучше всего проводить вскоре после того, как проблема впервые выявлена, т.к. события произошли недавно, они могут быть тщательно исследованы.

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

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

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

Часто бывает трудно понять, сколько времени потребуется, если не провести первоначальный анализ недостатков.

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятие мер для улучшения выполнения процесса.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерения и анализа и предоставлении результатов измерений.

Пример рабочих продуктов

1. Измерения и анализ (включая статистический анализ) выполнения подпроцесса и проекта записанные в организационном репозитории мер

2. Графическое отображение данных, используемое для понимания результатов и тенденции выполнения подпроцесса и проекта

3. Выявленные корневые причины и потенциальные мероприятия

Подпрактики

1. Выполняйте по необходимости анализ корневых причин для диагностики недостатков выполнения процесса.

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

Использование моделей выполнения процесса в прогнозировании будущего выполнения проекта и процесса описана в подпрактике предыдущей специфической практике.

2. Выявляйте и анализируйте потенциальные мероприятия.

3. Реализуйте выбранные мероприятия.

4. Оценивайте воздействие принимаемых мер на выполнение подпроцессов.

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

CMMI DEV v1.3 – Анализ Причин и Принятие Решений

Posted by Шамрай Александр на Ноябрь 25, 2013

Перевод Шамрай А.В.

Процессная область Поддержки уровня зрелости 5

Назначение

Назначением Анализа Причин и Принятия Решений (АППР) является выявление причин выбранных результатов и принятие мер по улучшению выполнения процесса.

Вступительный комментарий

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

Процессная область процесса Анализа Причин и Принятие Решений включает в себя следующие мероприятия:

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

Обнаружение проблем и дефектов после того, как они были введены, экономически не эффективно. Более эффективно предотвратить дефекты и проблемы путем интеграции мероприятий Анализа Причин и Принятия Решений в каждый этап проекта.

Поскольку аналогичные результаты могли ранее возникать в других проектах или в более ранних этапах или задачах текущего проекта, мероприятия Анализа Причин и Принятия Решений являются механизмами для обмена полученным опытом между проектами.

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

Т.к. выполнять причинно-следственный анализ всех результатов нецелесообразно, то для анализа выбираются результаты на основе компромиссов оценки инвестиции и оценки возврата качества, производительности и времени цикла.

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

См. процессную область Измерение и Анализ для получения дополнительной информации об обеспечении мероприятий измерения и анализа и предоставлении результатов измерений.

Мероприятия Анализа Причин и Принятия Решений предоставляют для проектов механизм для оценки их процессов на локальном уровне и поиска улучшений, которые могут быть реализованы.

Когда улучшения признаны эффективными, информация представляется на организационном уровне для возможного развертывания в организационные процессы.

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

Связанные процессные области

См. процессную область Измерение и Анализ для получения дополнительной информации об обеспечении мероприятий измерения и анализа и предоставлении результатов измерений.

См. процессную область Управление Организационными Показателями для получения дополнительных информации о выборе и реализации улучшений для внедрения.

См. процессную область Количественное Управление Проектами для получения дополнительных информации о количественном управлении проектом для достижения целей качества проекта и выполнения процесса.

Перечень специфических целей и практик

  • СЦ 1 Определить Причины Выбранных Результатов
    • СП 1.1 Выбирайте Результаты для Анализа
    • СП 1.2 Анализируйте Причины
  • СЦ 2 Устранить Причины Выбранных Результатов
    • СП 2.1 Реализовывайте Предложения Мероприятий
    • СП 2.2 Оценивайте Эффект Реализованных Мероприятий
    • СП 2.3 Записывайте Информацию об Анализе Причин

Специфические практики по целям

СЦ 1 Определить Причины Выбранных Результатов

Корневые причины выбранных результатов систематически определяются.

Корневой причиной является инициирующий элемент в причинно-следственной цепочке, который приводит к представляющему интерес результату.

СП 1.1 Выбирайте Результаты для Анализа

Выбирайте результаты для анализа.

Эта деятельность может быть вызвана событием (реактивная) или может быть периодически запланированной, например, в начале нового этапа или задачи (активная).

Пример рабочих продуктов

1. Данные для использования в первичном анализе

2. Данные результатов первичного анализа

3. Результаты, отобранные для дальнейшего анализа

Подпрактики

1. Собирайте соответствующие данные.

Примеры соответствующих данных:

  • Дефекты, найденные заказчиками или конечными пользователями
  • Дефекты, найденные в коллегиальной оценке или на тестировании
  • Показатели производительности, которые выше, чем ожидалось
  • Отчеты по проблемам управления проектом, которые требуют корректирующих действий
  • Проблемы возможностей процесса
  • Полученное значение измерения процесса (например, индекс стоимости выполнения)
  • Измерения пропускной способности ресурсов, использования или время отклика
  • Проблемы предоставления или удовлетворенности сервисами

2. Определяйте какие результаты будут в дальнейшем анализироваться.

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

Примеры методов отбора результаты включают следующее:

  • Анализ Парето
  • Гистограммы
  • Ящик с усами для атрибутов
  • Анализ видов и последствий отказов (FMEA)
  • Анализ возможностей процесса

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

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

СП 1.2 Анализируйте причины

Выполняйте анализ причин выбранных результатов и предложите мероприятия для их решения.

Цель этого анализа – определить действия, которые будут затрагивать выбранные результаты, анализируя данные соответствующих результатов, и выработать рекомендуемые мероприятия для реализации.

Пример рабочих продуктов

1. Результаты анализа корневых причин

2. Предложение мероприятий

Подпрактики

1. Проводите анализ причин с теми, кто отвечает за выполнение задачи.

Причинно-следственной анализ проводится, как правило, на встречах с теми, кто понимает изучаемые результаты. Те, кто лучше понимают выбранные результаты, как правило, это те, кто несет ответственность за выполнение задачи. Анализ наиболее эффективен, когда применяется для данных в реальном времени, так как можно быть ближе к событию, которое вызвало результат.

Примеры, когда может быть выполнен анализ причин:

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

См. процессную область Количественное Управление Проектами для получения дополнительных информации о выполнении анализа корневых причин.

2. Анализируйте выбранные результаты для определения их корневой причины.

Анализ базовых показателей выполнения процесса и модели могут помочь в выявлении потенциальных причин.

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

Примеры методов для определения коренных причин следующие:

  • Причинно-следственные диаграммы
  • Контрольные списки

3. Объединяйте выбранные результаты в группы на основании их корневых причин.

В некоторых случаях результаты могут зависеть от нескольких причин.

Примеры групп причин или категорий включают следующие:

  • Неадекватная подготовка и навыки
  • Проблемы коммуникации
  • Нет учета всех подробностей задач
  • Допуск ошибок в ручных процедурах (например, ввод с клавиатуры)
  • Недостатки процесса

Там, где это уместно, рассматривайте тенденции через симптомы или через группировки.

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

Модели выполнения процесса могут помочь в анализе выгод предложений мероприятий через прогнозирование последствий и возврат инвестиций.

Примеры предлагаемых предупредительных действий включают изменения к следующему:

  • Изучаемый процесс
  • Обучение
  • Инструменты
  • Методы
  • Рабочие продукты

Примеры включения наилучших практик включают в себя следующее:

  • Создание контрольных списков действий, которые улучшают подготовку или взаимодействие в отношении общих проблем и методов их предотвращения
  • Изменение процесса, чтобы не возникали ошибки, находящихся в шагах
  • Автоматизация всего или части процесса
  • Изменение порядка действий процесса
  • Добавление шагов процесса, например задачи стартового совещания для рассмотрения общих проблем, а также действий по их предотвращению

Предложение мероприятий обычно документируют следующее:

  • Автор предложения мероприятий
  • Описание адресуемого результата
  • Описание причины
  • Категория причины
  • Этап выявления
  • Описание действий
  • Время, стоимость и другие ресурсы, необходимые для реализации предложения мероприятий
  • Ожидаемые выгоды от осуществления предлагаемых мероприятий
  • Оценочная стоимость, если проблема не устраняется
  • Категория предложения мероприятий

СЦ 2 Устранить Причины Выбранных Результатов

Корневые причины выбранных результатов систематически устраняются.

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

СП 2.1 Реализовывайте Предложения Мероприятий

Реализуйте выбранные предложения мероприятий, разработанных при анализе причин.

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

Пример рабочих продуктов

1. Предложения мероприятий, выбранных для реализаций

2. Планы мероприятий

Подпрактики

1. Анализируйте предложения мероприятий и определяйте их приоритеты.

Критерии для определения приоритетности предложений мероприятий включают следующее:

  • Значение не устраненных результатов
  • Стоимость реализации улучшений процесса адресуемых результатов
  • Ожидаемое влияние на качество

Модели выполнения процесса могут использоваться для определения взаимодействия между несколькими предложениями мероприятий.

2. Выбирайте предложения мероприятий для применения.

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

3. Создавайте планы мероприятий для реализации выбранных предложений мероприятий.

Примеры информации, представленной в плане мероприятий:

  • Лицо, ответственное за реализацию
  • Подробное описание улучшения
  • Описание затрагиваемых областей
  • Люди, которые должны быть информированы о статусе
  • График
  • Стоимость расходов
  • Следующая дата оценки статуса
  • Обоснование ключевых решений
  • Описание мероприятий по внедрению

4. Реализуйте планы мероприятий.

Для реализации планов мероприятий, должны выполняться следующие задачи:

  • Назначение ответственных.
  • Координация людей, которые выполняют работу.
  • Оценка результатов.
  • Отслеживание мероприятий до их закрытия.

Для особенно сложных изменений могут проводиться эксперименты.

Примеры экспериментов:

  • Использование временно измененного процесса
  • Использование нового инструмента

Мероприятия могут назначаться на членов группы анализа причин, членов команды проекта или других членов организации.

5. Рассматривайте похожие причины, которые могут существовать в других процессах и рабочих продуктах, и принимайте соответствующие меры.

СП 2.2 Оценивайте Эффект Реализованных Мероприятий

Оцените влияние реализованных мероприятий на выполнение процесса.

См. процессную область Количественное Управление Проектами для получения дополнительных информации о выборе мер и техник аналитики.

После того, как изменения процесса применены к проекту, оценивается эффект от изменений, чтобы убедиться, что изменения процесса улучшили выполнение процесса.

Пример рабочих продуктов

1. Анализ выполнения процесса и изменения в выполнении процесса

Подпрактики

1. Измеряйте и анализируйте изменения в выполнении затронутых процессов или подпроцессов проекта.

Эта подпрактика определяет, повлияли ли выбранные изменения положительно на выполнение процесса и на сколько.

Примером изменений выполнения процесса в определенном процессе проекта могут быть предсказуемые изменения для достижения целей качества и выполнения процесса.

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

Статистические и другие количественные методы (например, проверка гипотез) могут использоваться для сравнения базовых показателей до и после для оценки статистической значимости изменения.

2. Определяйте влияние изменения на достижение целей качества и выполнения процесса проекта.

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

3. Определяйте и документируйте соответствующие мероприятия, если улучшения процесса или подпроцесса не привели к ожидаемым выгодам проекта.

СП 2.3 Записывайте Информацию об Анализе Причин

Записывайте данные анализа причин и принятия решений для использования в разных проектах и организации.

Пример рабочих продуктов

1. Записи анализа причина и принятия решений

2. Предложения по организационным улучшениям

Подпрактики

1. Записывайте данные анализа причин и сделайте эти данные доступными, чтобы другие проекты могли сделать соответствующие изменения процесса и достичь аналогичных результатов.

Записывайте следующее:

  • Данные о результатах, которые были проанализированы
  • Обоснование решений
  • Предложения мероприятий, вытекающих из совещаний анализа причин
  • Планы мероприятий, вытекающих из предложенных мероприятий
  • Стоимость анализа и мероприятий решений
  • Измерения изменений в выполнении процесса для определенного процесса, вытекающие из принятых решений

2. Представляйте предложения по улучшению процесса для организации, когда реализованные действия были эффективны для проекта в соответствии с ожиданиями.

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

См. процессную область Количественное Управление Проектами для получения дополнительных информации о выборе улучшений.

Posted in CMMI, Стандарты и методологии | Отмечено: | Leave a Comment »

Лучшие секреты рецензирования кода. Социальные эффекты коллегиальной оценки

Posted by Шамрай Александр на Июль 12, 2013

Неожиданные позитивные социальные аспекты; Управление негативным влиянием и «Эффект большого брата».

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

Любая критика – это и возможность для роста, и причина сдерживания. На основе нашего опыта работы с заказчиками и рецензирования внутреннего кода мы обнаружили несколько социальных проблем, о которых менеджеры и лидеры групп должны знать. Некоторые являются положительными и их следует поощрять в группе; другие являются негативными и они должны решаться тонкими и эффективными методами.

«Эффект Эго»

Первый эффект имеет место даже до того, как произойдет первое рецензирование кода. Оно привнесет и положительные, и негативные эмоции в рецензирование кода; рассмотрим хорошие.

«Джерри всегда забывает проверить на исключение NULL-указателя». Никто не хочет быть известным парнем, который всегда поступает глупо, делает ошибки на уровне молодого разработчика. Так что представьте себя перед компилятором, с поставленной задачей исправить небольшую ошибку, но понимая, что как только вы говорите «Я закончил», ваши коллеги – или еще хуже ваш босс – будут критически рассматривать ваши результаты.

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

Другими словами, вы немедленно станете разработчиком лучше. Вы будете делать работу отлично, потому что вы хотите получить идеальную оценку на рецензировании. «Ого», ваш босс напишет в заметках о встрече, «я никогда не рецензировал код, который был бы настолько продуманным! Я могу только одно сказать! Отлично!»

Хорошо, может быть и нет. Но скорее всего вы хотите, чтобы вам в спину говорили «Ах, да, он жесткий чувак. Он является хорошим разработчиком» и не говорили «он довольно хороший, но делает много глупых ошибок. Когда он говорит, что он сделал, то на самом деле нет.»

Хорошей характеристикой эффекта эго является то, что он работает одинаково хорошо в случаях, когда рецензии обязательны для всех изменений кода или просто используются как «точечные проверки». Если у вас есть шанс 1 из 3 быть вызванным на рецензирование, это уже достаточный стимул, чтобы убедиться, что вы делаете работу хорошо. Однако, существует переломный момент. Например, если шансы рецензирования только 1 из 10, вы может быть неаккуратным, потому что теперь у вас есть повод. «Да, я обычно помню, что это нужно делать. А то что вы только что поймали меня, ну это просто день не сложился.»

Это пример эго, которое работает на нас. Позже мы увидим, как эго можно привести к социальным проблемам, но сейчас давайте чувствовать себя положительно и продолжать исследовать с веселым настроением, продуктивный аспект рецензирования кода редко указывается.

Старые привычки легко умирают

Это был наш второй обзор кода в SmartBear Software с использованием альфа-версии нашего нового инструмента рецензирования кода. Я просматривал небольшое изменение, которое сделал Брэндон в Java-код. Он добавил следующую строку кода:

if («integrate».equals (str)) {…}

Я остановился здесь на мгновение. Он сравнивал равна ли строка str константной строке integrate. Но я написал бы это по-другому – перевернув integrate и str. Я понял, что оба метода работают, но возможно была причина, по которой он выбрал именно этот?

Я написал ему быстро сообщение. Он объяснил, что если str имеет значение null, его выражение вернет false в то время как мой вариант получил бы исключение указателя на null. Поэтому он взял в привычку использование константных строк в левой части выражения equals(), как в этом примере.

Хороший трюк! Я могу получить новую привычку, которая позволит устранить целый класс ошибок из моего кода. Я просто стал разработчиком немного лучше. И мне было приятно это!

Позже мы поговорили о проверке, и мы поняли, что здесь произошло две совершенно неожиданные вещи.

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

Во-вторых, я был оппонентом, но я был единственным, кто научился чему-то. Обычно вы думаете, что процесс рецензирования однонаправленный – проверяющий указывает проблемы автора, и автор может узнать что-то в этом процессе. Но здесь я был оппонентом и все же я был тем, кто учится!

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

И лучший момент: было очень весело! Просто весело изучать что-то новое и расти как разработчик. И также весело, когда все остальные в офисе тоже обучаются – весело как научить, так и учиться, и вы получите ощущение, что вся разработка в организации ускоряется.

Систематический личный рост

Он получается даже лучше.

Как-нибудь попробуйте такой эксперимент: на одну неделю запишите каждую ошибку, которую вы делаете. Каждую опечатку в электронной почте; каждый раз, когда вы случайно закрываете приложение, с которым вы работаете; каждый раз, когда у вас есть ошибка в вашем коде, даже каждая синтаксическая ошибка, которую вы делаете. Не делайте слишком детальным описание; оставляйте каждый элемент в списке на высоком уровне и используйте хэш метки, чтобы сосчитать, сколько раз вы делаете ошибки по определенным типам.

Теперь только представьте себе, что вы сделали это. Как вы могли бы догадаться, что возникнут определенные шаблоны. Некоторые элементы имеют огромное количество хэш-символов рядом с ними. На самом деле к концу второго дня вы устанете от подсчета некоторых из них!

И этот раздражитель может остаться у вас в уме. Вы можете даже начать думать об этом сознательно. Довольно скоро вы будете предвидеть ошибку и предостерегать себя от нее. Некоторые из них будут простыми, другие займут какое-то время для ликвидации.

Но в конце концов вы разовьёте привычки, которые полностью уберут этот тип ошибки. Если вы часто забываете закрыть скобку в вашем коде, возможно вы включите функцию в редакторе кода, который закрывает скобки за вас. Если вы закроете приложение случайно, возможно вы будете приостанавливаться всего за несколько секунд до этого каждый раз, когда вы собираетесь нажать кнопку Закрыть. Может вы найдете как проверять общие слова или научитесь вводить ваши общие ошибки в автоматическую коррекцию в редакторе электронной почты.

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

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

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

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

Но конечно не все социальные аспекты проверки кода являются веселыми и полезными лично. Менеджеры должны быть в курсе этих проблем и знать, как их смягчить.

Задетое самолюбие & Эффект «Большого брата»

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

Во-первых: Задетое самолюбие.

Никто не воспринимает критику хорошо. Некоторые люди взрываются быстрее, чем другие, но каждый чувствует угрызение, когда им указывают на дефекты. Особенно, когда пытаются указать на сложные недостатки – это может быть воспринято как личный выпад.

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

Второе: Эффект «Большого брата».

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

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

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

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

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

Эти пункты являются методами, которые объясняют, что (a) дефекты являются позитивом, а не негативом и (b) плотность дефектов не коррелирует с способностями разработчиков и что поэтому (c) дефектов не стоит избегать и они никогда не будут использоваться для оценки работы.

1. Сложный код имеет больше дефектов

Наличие множества дефектов не обязательно означает, что разработчик небрежен. Может быть, что сам код был более трудным –сложный сам по себе или расположен в модуле с высоким риском, который требует высокого качества кода. На самом деле, чем более сложным получается код, тем больше мы ожидаем найти в нем дефектов, при этом неважно кто написал код.

Можно посмотреть на это с другой стороны: если бы вы знали, что фрагмент кода был сложным, и рецензент сказал, он не нашел недостатков в нем, вы не заподозрили бы, что рецензент не был прилежным? Если я представил это эссе редактору, даже после нескольких самостоятельных проверок, и редактор не представил замечаний, я должен подозревать, что редактор не прочитал текст?

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

2. Больше времени вызывает больше дефектов

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

Группа в различных вариантах пыталась определить необходимое количество времени на страницу кода, тестируя разницу в длительности 5, 15, 30 или даже 60 минут на страницу. Большинство результатов показали увеличение плотности дефектов вплоть до 30 минут на страницу, некоторые даже видели увеличение при 60 минутах на страницу. После определенного момента количество дефектов будет останавливаться в некоторой точке, в которой вы действительно учли все о чем вы могли подумать и дальнейшее время, затраченное на код, не обеспечит дополнительных дефектов. Но 60 или даже 30 минут на страницу гораздо больше времени, чем могло бы предположить большинство людей.

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

3. Это все о коде

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

В 1986 году космический шаттл Челленджер взорвался на 110,3 секунде после взлета, погибли все семь членов экипажа. Последующее президентское расследование пыталось ответить на два вопроса: что вызвало взрыв и почему мы этому не помешали?

Первый вопрос был дан в знаменитой демонстрации обладателя Нобелевской премии физика Ричарда Фейнмана. Ответ не был невероятным; резиновые кольца уплотнителя, используемые для соединения топливных секций, были неупругими при низких температурах и поэтому допустили утечку топлива из бака, где оно впоследствии и загорелось. Тревожный момент заключается в том, что это не было новостью. Это было документально оформлено, эти физические свойства все хорошо понимали. Так почему они не отменили запуск?

И вдруг второй вопрос стал гораздо более интересным. Не только выяснить, кого винить за фиаско, но исправить системные проблемы, которые оказывают влияние на безопасность всех миссий.

И тут еще хуже. Оказывается, инженера по ракете описывали данные, которые говорили, что запуск при температуре 29 градусов по Фаренгейту был небезопасным. Данные содержались в отчете, который был передан инженерами для должностных лиц, ответственных за пуск, в ночь перед запуском.

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

Поэтому инженеры были виноваты в искажении данных? Нет, потому что данные были составлены правильно. Никто не думал упорядочивать их так, чтобы они показали тенденцию. Ни один из них не был обучен методам визуализации и презентации данных.

Основной вывод такой: даже с большим количеством очень умных и опытных людей, будут допускаться ошибки. НАСА решили эту проблему девятью шагами, большинство из которых различные формы рецензирования. Идея рецензирования программного кода является той же – устранить как можно больше дефектов, независимо от того, кто «является причиной» ошибки, независимо от того, кто нашел ее. Это не личное отношение.

Действительно как менеджер, вы знаете, что если «количество дефектов» было использовано для оценки качества работы, у разработчиков будет стимул не находить дефекты, даже когда они знают, что они там. Что является противоположностью цели процесса рецензирования, так что вы знаете, что дефекты должны быть обязательно не фактором для любой персоны – или персонала –, а отчетом.

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

4. Чем больше дефектов тем лучше

Приведенное выше высказывание указывает на казалось бы нелогичный вывод: чем больше дефектов мы находим, тем лучше. В конце концов если нахождение дефекта означает, что катастрофу Челленджера можно предотвратить, то найти дефект – это хорошо. Если мы ожидаем дефекты в важном или сложном коде, обнаруженные дефекты говорят, что код является хорошим. Если рецензенты находят больше дефектов, когда они прилежны, большое количество дефектов – это хорошо.

Этот вывод является по сути правильным! Подумайте об этом так: каждый дефект найденный и исправленный в коллегиальной оценке – это ошибка, которую клиент никогда не увидит. Еще одна проблема, QA не тратит времени на поиск и отслеживание. Еще один кусок кода, который не добавляет постепенно сложности в поддержки программного обеспечения. Разработчики и менеджеры могут спать немного спокойнее по ночам каждый раз, когда будет обнаружен новый дефект.

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

Чем больше дефектов будет найдено, тем лучше команда работает вместе. Это не означает, что автор имеет проблемы; это означает, что они оба успешно изучают все возможности и избавляются от многих ошибок. Авторы и рецензенты должны гордиться любым участком кода, в котором многие дефекты были обнаружены и исправлены.

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

Posted in Рецензирование, Стандарты и методологии | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Новые исследования

Posted by Шамрай Александр на Июнь 24, 2013

Какая современная литература может рассказать о Рецензировании кода; c какими исследованиями мы согласны, а с какими нет.

Поиск в Amazon книг по фразе «рецензирование кода» покажет только один книгу: 29-страничная статья Майкла Фаган из IBM 1974 года. В том году IBM продал модель диска 3330-11 за $111,600. Мегабайт ОЗУ мог обойтись вам в $75000. До сих пор наиболее продаваемым миникомпьютером является PDP-11.

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

Но не произошло никаких особых изменений в признанных устоявшихся методах о том, как проводить правильно рецензирование кода. Некоторые из идей Фагана применимы, как никогда, но наверняка должно появиться что-то новое.

Инспекции кода для сборок в OS/360 не имеет ничего общего с тем, как сказываются последствия изменений кода в объектно-ориентированных интерпретируемых языках 3-го уровня. Сбор встречи по инспекции с 5 участниками не работает при распределенной разработке и гибких методологиях.

Это эссе является исследованием относительно недавних исследований по методам коллегиальной оценки и инспекции. Мы отметили результаты общие для всех исследований и результаты, которые отличаются у некоторых исследований.

Стоит поставить акцент на своевременности исследования. Вы не увидите оригинальные работы Фагана, Глиба и Вигерса. Некоторые из оригинальных идей, по-прежнему применяются, как никогда, но конечно некоторые вещи изменились. Мы не хотим повторять принятые методы великих людей, которые стояли у истоков теории проверки кода, вместо этого исследуем то, что, как представляется, работает в современном мире разработки программного обеспечения.

Вотта 1993, Конради 2003, Келли 2003: Встречи по рецензированию необходимы?

Один из наиболее спорных вопросов в рецензировании кода: Должно ли каждое рецензирование быть встречей? Майкл Фаган, отец инспекции кода, настаивал с 1976 года, что совещания по инспекции это основное место, где обнаруживаются дефекты, но исследования в этой области за прошлые тридцать лет не были настолько убедительны.

Во-первых, самый известный выпад на такое мнение, традиционно связанное с совещаниями, сделал Лоуренс Вотта из AT&T Bell Labs в 1993 году. Он выделил пять причин наиболее цитируемых менеджерами и разработчиками программного обеспечения в поддержку встреч по инспекциям:

  1. Синергия. Команда найдет недостатки, которые отдельных рецензент может не найти.
  2. Образование. Менее опытные разработчики и рецензенты учатся у своих более опытных коллег.
  3. Срок. Встречи создают график, в котором люди должны работать.
  4. Конкуренция. Эго приводит к личному стимулированию содействия и улучшения.
  5. Процесс. Инспекции просто требуют встреч. Это формальный процесс.

Однако в его оригинальных документах в 1993 на основе его собственных исследований, а также исследованиях других Вотта утверждал, что:

  1. Синергия. Встречи, как правило, выявляют ложные дефекты вместо новых дефектов. (Подробнее ниже).
  2. Образование. Образование путем наблюдения обычно недостаточно; Некоторые исследователи его сильно осуждают.
  3. Сроки. Процесс установки сроков является важным, но может быть обеспечен без встреч сам собой или, по крайней мере, без тяжеловесных встреч.
  4. Конкуренция. Конкуренция по-прежнему достигается при любой коллегиальной оценке. Некоторая конкуренция разрушительно влияет на совместную работу, например, между проектировщиками и тестировщиками.
  5. Процесс. Процесс имеет важное значение, но факты, а не «традиция», должны использоваться для определения процесса.

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

Напомним, что «синергия собрания» была наиболее часто упомянута разработчиками и менеджерами, а также в литературе как основное преимущество встреч для инспекции. Здесь «Синергия» относится к команде в том смысле, что группа людей вместе работает намного лучше, чем любой из ее членов по отдельности; в частности, что группа инспекции обязательно будет выявлять больше дефектов чем рецензенты индивидуально.

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

Результаты Вотты, демонстрирующие, что встречи инспекции добавляют только 4% дефектов, которые были обнаружены уже индивидуальным чтением.

Как выяснилось совещания способствовали лишь 4% от всех дефектов, найденных в ходе инспекций в целом. Статистически больше нуля, но Вотта задался вопросом «стоит ли цена времени потраченного на собрание по сбору Tсбора [напрасно потраченное время] и дополнительное время рецензента этому 4% увеличению проблем, найденных на этой встрече (по любой причине)? Ответ на этот вопрос Нет».

Сильные слова! Но существуют ли другие преимущества для совещаний инспекции помимо просто выявления дефектов?

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

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

В общей сложности 147 дефектов было обнаружено во время фазы чтения. Из них 39 (26%) были удалены во время встречи. Хотя некоторые из них были как ложные (т.е. рецензент неправильно определил дефектом), в большинстве случаев плохая документация или стиль кода привели оппонента к мнению, что существует проблема. Келли выразил мнение о том, что эти «дефекты» следует вероятно рассматривать после всех остальных.

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

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

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

Келли установил, что на чтение было потрачено около две трети от общего объема человеко-часов и одну треть на совещание. Это приводит к скорость обнаружения дефекта 1,7 дефектов в час для чтения и 1,2 для совещания. Чтение на 50% более эффективно в поиске дефектов, чем встречи.

Еще один прямой тест исследований Вотта совместных усилий под другим углом прошел в 2003 году и был проведен Рейдаром Конради между Ericsson в Норвегии и двумя норвежскими колледжами, NTNU и Университетом Агдер. Целью экспериментов было измерение воздействия некоторых методов чтения для проверки модели UML. Вотта экспериментировал с рецензированием проектирования, Келли с исходным кодом, и теперь Конради изучит рецензирование архитектуры.

Заявленной целью исследования было определить эффективность UML рецензирования «с учетом объектно-ориентированного чтения». Они собрали отдельные данные для обнаружения дефектов во время этапа чтения и этапа совещания. Их целью не было поддержать или аннулировать результаты Вотта, но их данные могут быть применены для этой цели. Действительно в их собственных записях они каузально упоминают, что их данные просто совершенно случайно соответствовали результатам Вотта.

В частности, в 38 контролируемых инспекциями сценариях они обнаружили, что 25% времени было потрачено на чтение, 75% времени на совещания, и тем не менее 80% дефектов были обнаружены во время чтения! Они были в 12 раз более эффективным в поиске дефектов с использованием чтения чем на совещании. Кроме того, в их случае они приглашали 5-7 человек на каждое совещание, что немного больше, чем Келли или Вотта, или даже Фаган рекомендует, поэтому количество обнаруженных дефектов в соответствии с трудозатратами было очень малым.

И другие исследования подтверждают эти результаты. Поскольку сокращение ложных ошибок, как казалось бы, это основная цель совещания инспекции, многие исследователи решили, что короткой встречи между двумя участниками, возможно даже по электронной почте, а не лично, должно быть достаточно для того, чтобы получить выгоды от этой встречи без каких-либо дополнительных недостатков. Значение выявления ложных ошибок в первую очередь становится под сомнение, потому что часто они являются результатом плохо написанного кода и не должны игнорироваться в любом случае. Учитывая все это, некоторые даже предполагают, что дополнительное время инженеров для реализации исправления ложных дефектов по-прежнему меньше, чем время, необходимое для выявления дефектов как ложных, и поэтому мы должны отказаться от встреч всех вместе!

Блакели 1991: Hewlett Packard

Hewlett Packard имеет долгую историю инспекций кода. В 1988 был издан общекорпоративный приказ, который требовал 10-кратное повышение качества кода, высокий уровень для любой организации разработки, но по крайней мере это была измеримая цель. Они переключились на рецензирование проектирования и кода как часть мероприятий для достижения цели, и управление санкционировало пилотную программу, реализованную группой разработки в Подразделении Поддержки Приложений.

Они сделали следующее заключение: «На основе данных, собранных об использовании инспекций кода и данных относительно стоимости нахождения и исправления дефектов после того, как, продукт был выпущен клиенту, реализация инспекции кода как регулярной части цикла разработки выгоднее по сравнению с затратами, связанными с исправлением дефектов, найденных клиентами».

Это предварительное исследование включало один проект с 30 часами разработки и 20 часами рецензирования – 13 часов на предварительной встрече контроля и 7 часов на совещании. Они ограничили свои инспекционные размеры 200 строками кода в час согласно инструкциям. Был найден 21 дефект, обеспечивая проекту скорость дефектообразования 0.7 в час и плотность дефектов 100 на тысячу строк кода.

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

Поскольку они знали, что эта проблема была важна с самого начала, они собирали достаточно информации относительно каждого дефекта, чтобы определить возможно ли, чтоб каждый из них был обнаружен, улучшив процесс тестирования/QA. В частности, для каждого дефекта они отвечали на вопрос: «Есть ли какой-либо тест, который бы выполнил тестировщик и нашел бы этот дефект?» Возможно, было бы более эффективно выстроить процесс тестирования вместо того, чтобы смотреть код.

Результат был следующий: Только 4 из 21 дефекта могли быть однозначно обнаружены во время фазы тестирования/QA. Они также увидели, что потребовалось бы больше общих рабочих часов, чтобы найти и исправить те 4 дефекта в QA чем потрачено на инспекцию.

Дансморе 2000: Объектно-ориентированные инспекции

Какие методы инспектирования должны использоваться при рассмотрении объектно-ориентированного кода? Объектно-ориентированный код (ОО) имеет различные структурные и исполнительные шаблоны в отличии от процедурного кода; подразумевает ли также это изменение методов рецензирования кода и как, если да?

Алистер Дансморе, Марк Ропер и Мюррей Вуд попробовали ответить на этот вопрос в серии экспериментов.

Первый эксперимент с 47 участниками открыл первую проблему традиционных инспекций кода: понимание фрагмента OO кода часто требует от читателя посетить другие классы в системе или пакете. Действительно, большое количество дефектов редко находилось рецензентами, потому что обнаружение дефектов требует знаний вне непосредственно инспектируемого кода. С традиционными инспекциями на месте с кодом-на-руках читатели не имеют средства для исследования других классов и поэтому им трудно найти дефекты.

Они попробовали найти способ для решение этой проблемы во втором эксперименте. Рецензентам были даны планы чтения, которые обращали их внимание к коду в определенном порядке и предоставляли дополнительную информацию согласно систематического набора правил. Правила были грубой попыткой подтянуть соответствующий код, связанный с кодом, который находится под рецензией. Теория была в следующем, если этот метод лучше, теоретически можно сделать инструмент для автоматического сбора информации. Это «систематическое рецензирование» было выполнено 64 рецензентами и результаты сравнили с первым исследованием.

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

В третьем эксперименте исследователи сравнили три различных подхода для оценки этой проблемы, чтобы в дальнейшем определить, какие методы работают лучше всего в контексте OO:

  1. «Рецензирование по контрольному списку» дает рецензентам конкретный перечень вещей для проверки на уровне класса, метода и иерархии классов. Контрольный список был построен с использованием опыта первых двух экспериментов как руководство какие типы проблем рецензентам следует искать.
  2. «Систематическое рецензирование» — доработанная техника второго эксперимента.
  3. «Рецензирование варианта использования» дает рецензентам множество путей, в которых можно было бы ожидать код, который используется другим кодом в системе. Это своего рода контрольный список, в котором код ведет себя относительно документа, «играет хорошо» в условиях стресса, и работает в нескольких конкретных путях, которые как мы знаем будут изучаться в текущем приложении.

Результат этого эксперимента показан на рисунке ниже. Явно метод с контрольными списками был наиболее успешным, нашел больше дефектов за меньшее время, чем другие два метода, на 30% лучше, чем скорость обнаружения дефектов самого медленного метода. Однако следует отметить, что в каждом из трех методов найденные дефекты не совпадали полностью. Поэтому авторы поэтому предложили, что стоит использовать более чем один подход, хотя количество времени подготовки, которое потребуется для подготовки всех этих методов, возможно будет очень высоко.

Сравнение результатов трех типов рецензирования. Уровень дефектов в час.

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

Результаты показаны на рисунке ниже.

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

Уровень дефектов является постоянным до 60 минуты инспекции, далее он выравнивается на уровень без дефектов, которые не обнаруживались уже вообще после 90 минут.

Во всех трех типах рецензирования шаблон оставался одинаковым. Дефекты находились на относительно постоянной скорости первые 60 минут инспекции. В этот момент метод контрольного списка резко сбрасывал уровень; другие методы рецензирования выравнивались чуть позже. Ни и в одном случае дефекты не обнаруживались после 90 минут.

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

Увано 2006: Анализ движения глаз в процессе рецензирования

Четыре исследователя Института Науки и Технологии Нара выполнили уникальное исследование движений глаз рецензента во время проверки кода. Всегда увлекательно и жутко получить возможность заглянуть в наше подсознание и физиологическое поведение.

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

Исследователи использовали систему по плану, отображаемому в короткой программе на языке C на экране, пока сканер глаз записывал все «фиксации» – время, когда глаз оставался в радиусе 30 пикселей более чем на 1/20 секунды. Кроме того, т.к. они контролировали отображение исходного кода, фиксации были сопоставлены с номерами строк. Результатом является участки, в которых строка кода просматривались с течением времени.

Были использованы шесть различных фрагментов кода C, каждый от 12 до 23 линий, каждый как целая функция или небольшой набор функций для просмотра без прокрутки. Пять предположений были применены для каждого фрагмента, выполняя 27 испытаний (от трех из 30 пришлось отказаться, потому что субъект отвлекался во время опыта).

Общий шаблон – это рецензент, который читает линии сверху вниз в «ухабистом склоне». Это, как правило сквозное, но с короткими, краткими «обратными дорожками» по пути. Они назвали это «первичным сканированием». Обычно 80% из линий только «касаемы» в ходе этого первого сканирования. Затем рецензент концентрируется на определенной части кода – 4 или 5 линий – предположительно где рецензент считает, что может быть проблема.

Другие шаблоны были замечены в зависимости от природы кода. Например, с примерами кода, содержащими две функции вместо одной, часто было очень быстрое «заголовочное сканирование», где глаз лежит на линиях объявлений функции до начала обычного «первичного сканирования». Было также общим случаем увидеть второе сканирование похожее на первое, прежде чем начинается концентрация.

Дальнейшая инспекция движения глаз показывает интересные идеи о том, как кто-то читает исходный код для понимания. К примеру, глаза отдыхают на объявлениях инициализации переменных на протяжении сессии. Мозг требует постоянного обновления о том, что означают эти переменные. Даже тогда, когда есть только две или три локальные переменные, все целые числа, которые не представляет ничего специального или трудно для запоминания, шаблон остается таким же. Исследователи назвали это движение глаз «проследить объявление». Это для кода означает, что объявления локальных переменных также должны быть видимы на том же экране что и код, который использует их. В противном случае читатель вынужден будет прокручивать туда и обратно. Распространенным способом обеспечения этого является ограничение количества строк кода в функции. Мы все слышали аргументы для ограничения длины функции для общего чтения; Вот доказательства, которые являются фундаментом этих аргументов.

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

Но вернемся к рецензированию. Исследователи первоначально искали ответ на вопрос: есть ли что-нибудь в движениях глаз, что может быть отнесено к эффективности рецензирования? Ответ оказался Да.

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

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

Этот результат имеет несколько последствий. Во-первых, замедлить! Как мы говорили в разделе как вывод – чем дольше вы уделяете обзору, тем больше дефектов вы найдете. Поспешность добавляет затраты.

Во-вторых, первичное сканирование является полезным методом при проверке кода. Этот эксперимент показывает, что достаточно тщательное «первичное сканирование» фактически увеличивает уровень обнаружения дефекта.

Лайтенбергер 1999: Факторы, влияющие на количество дефектов

При каких обстоятельствах мы ожидали бы найти больше или меньше дефектов в ходе рецензирования? Размер кода является вопросом инспекции? Как насчет количества времени рецензирования потраченного, глядя на код? Что насчет языка исходного кода или типа программы? Все эти вещи являются «факторами», но мы можем установить что-то более влиятельное, чем эти? Возможно некоторые вещи значат больше, чем другие. В 1999 году трое исследователей провели анализ 300 рецензий от Lucent в Центре Реализации Продуктов для Оптических Сетей (PRC-ON) в Нюрнберге, Германия. Эта группа тратит 15% от их общей разработки на рецензии, но используют ли они свое время мудро? Они обнаруживают настолько много дефектов в час насколько возможно? Если нет, что конкретно они должны делать, чтобы максимизировать уровень обнаружения дефекта? Это были вопросы Лайтенбергера.

Рассмотрение других исследований предложило два наиболее вероятных фактора в количестве дефектов, обнаруженных во время рецензирования: (a) время, затраченное на подготовку и (b) размер кода для инспекции. Так они пришли к причинно-следственной модели – то есть, теоретическая модель, в которой, как они ожидали, эти два фактора могут повлиять на количество дефектов.

Эта модель показана на рисунке ниже. Но создание схемы не доказывает ничего!

Как мы можем проверить является ли эта модель точной и как можно измерить насколько важны каждые из этих причинных связей?

Рисунок 8: Причинно-следственная модель для двух крупнейших факторов, которые определяют количество дефектов, обнаруженных во время рецензирования.

Стрелки указывают причинно-следственные связи. «Е» значения представляют собой внешние факторы, которые не учитываются в модели.

Как вы могли ожидать, существует статистическая система, которая может сделать именно это. Она называется Путь Анализа. Учитывая модели выше и первичные данные из отдельных рецензирований, мы можем определить, насколько каждая из этих стрелок действительно имеет значение.

Результаты Пути Анализа Лайтенбергера для рецензирования кода. Цифры представляют процент от общего влияния.

Результаты одинаковы для проведения рецензирования проектирования и спецификаций.

Результаты показаны на рисунке выше. Следует отметить две важные вещи.

Во-первых, время чтения в два раза влиятельнее, нежели размер кода. Это неожиданно – с большим количеством кода под лупой, вы бы ожидали найти больше дефектов. Но в действительности именно количество времени, которое вы проводите, глядя на код, – независимо от того, насколько велика или мала подпрограмма – определяет сколько дефектов вы найдете.

Во-вторых, «внешние факторы» гораздо более важны, чем любой из названных. Размер кода только показывает лишь 8% колебаний в количестве найденных дефектов; время чтения показывает 35%, но большая часть вариации поступает из других источников. Рецензирование нового кода, отличается от поддерживаемого кода. Сложные алгоритмы отличаются от связей сложных объектов, которые отличаются от простого процедурного кода. Языки отличаются. Уровень опыта автора и рецензента имеет значение. Эти внешние эффекты составляют наиболее важные факторы того сколько дефектов вы можете ожидать при проведении рецензии.

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

Во-вторых, вы не можете усреднить все ваши показатели и сказать «мы должны найти X дефектов на 1000 строк кода». Каждый проект, язык, модуль, даже классы могут быть разными. Это может нарушить ваши метрики на этих уровнях при попытке найти некоторые реальные модели.

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

Заключение

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

Рецензирование максимум один час.

Хотя не каждое исследование рассматривало этот вопрос, общий результат говорит, что эффективность рецензентов по поиску дефектов падает резко после 1 часа. Это справедливо независимо от того, сколько материалов пересматривается одновременно. Некоторые исследования тестировали специально для того, чтобы увидеть насколько много дефектов обнаруживается после 15, 30, 45, 60, 75, 90 и 120 минут на задаче. Во всех случаях существует примерно линейное увеличение количества дефектов, найденных до одного часа, затем значительное выравнивания после этого. Этот результат был отражен и в других исследованиях, которые мы рассматривали.

Точка останова, в которой дальнейшее рецензирование не приносит пользы

Существует по крайней мере два объяснения этого эффекта. Во-первых, каждый рецензент способен найти определенный набор дефектов. Независимо от того, как долго вы таращитесь на код, есть некоторые проблемы, которые вы просто не знаете как найти. Что особенно справедливо, если рецензирование управляется контрольным списком – рецензент часто фокусируется на контрольном списке и все значительное вне этого списка не находится в области его действий.

Второе объяснение заключается в том, что после часа человеческий мозг становится насыщенным. Рецензент не может обрабатывать больше информации, потому что его мозг отказывается сосредоточиваться. «Я искал это слишком долго. Меня уже тошнит от этого» – общая жалоба во время длительного рецензирования. Этот второй пункт может быть проверен просто вернувшись к рецензированию кода на следующий день, и вы увидите, что тот же человек может найти больше дефектов после «перезагрузки». Однако, мы не изучали это и возможно это неважно, потому что мы принимаем, что много времени тратить нецелесообразно.

Чтобы обнаружить больше дефектов, нужно замедлить чтение кода.

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

Что также справедливо, будет или не будет ваш приватный код читаться впоследствии на совещании инспекции.

Встречи для инспекций не обязательно должны быть очными.

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

За последние пятнадцать лет этот эффект был проверен во многих исследованиях и со многих углов зрения. Несколько выводов по этому вопросу показаны во всех исследованиях данного обзора и во многих других.

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

Во-вторых, основным результатом совещания состоит в просеивании и возможно удалении ложных ошибок – то есть, «дефекты» найдены во время частного чтения кода, которые фактически не являются дефектами. Даже тогда ложные ошибки являются часто результатом плохой документации или организации кода; Если читатель путается, возможно код должен быть изменен в любом случае, чтобы избежать путаницы в дальнейшем, даже если это просто означает, что необходимо вставить комментарии в коде.

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

Показатели количества дефектов на строку кода ненадежны.

Это мечта предсказателя. Сколько дефектов скрываются в этих 5000 строк кода? Нет проблем, просто взять наше стандартное количество дефектов на количество строк во время обзора и умножить. 12 дефектов на количество строк кода? Ожидаете, что найдете 60 дефектов. Если вы пока нашли только 30, смотрите дальше.

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

Упущения усложняют поиск дефектов.

Легко найти проблемы в коде, на который вы смотрите; гораздо более трудно понять, что чего-то там нет вообще.

Хотя большинство исследований упоминали это, но никто не измерял эту проблему конкретно. Неофициальным консенсусом является использование контрольного списка как лучшего способа борьбы с этой проблемой; Контрольный список напоминает рецензенту уделить время, чтобы искать что-то, что может быть пропущено.

Например, в нашем собственном опыте утилита контрольного списка имеет пункт «убедитесь, что все ошибки обрабатываются», что имеет ограниченную пользу – это очевидная вещь для проверки всего кода. Но мы забыли передать номер сборки, прежде чем сеанс QA прошел уже на 30%. После установки контрольного списка выпуска мы больше не забывали об этом.

Исследования слишком малы.

Несчастным общим элементом этих исследований является то, что они почти все слишком малыми, чтобы иметь статистическую значимость. Сложно найти более чем 100 рецензий или 100 дефектов в любом из них. Большинство из них говорят «В наших 21 рецензиях, мы обнаружили, что…» двадцать одна рецензия не является статистически значимой, независимо от того, какие данные вы собираете!

Это не недействительные исследования; Это просто означает, что нам нужно рассмотреть все исследования в совокупности, а не какое-либо одно само по себе. Кроме того, в каждом авторы делают замечания, которые интересны и соответствуют независимо от собранных метрик.

Различия между каждыми исследованиями.

Небольшие цифры показывают, что почти ни одно из этих исследований не является достаточно большими, чтобы быть статистически значимым.

Так что теперь перейдем от небольших экспериментов к крупным когда-либо опубликованной отраслевым исследованиям легкой коллегиальной оценки.

Posted in Рецензирование, Стандарты и методологии | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Пять типов рецензирования

Posted by Шамрай Александр на Июнь 13, 2013

За и против формальных проверок, через-плечо, через-почту, парного программирования и инструментального рецензирования.

Есть много способов ободрать кошку. Я могу придумать сразу четыре. Есть также много способов выполнить коллегиальную оценку и каждый имеет свои за и против.

Формальные инспекции

Исторически «формальные» рецензии обычно вызывают «инспекциями». Это пережиток исследования Майкла Фагана 1976 года в IBM относительно эффективности коллегиальных оценок. Он попробовал много комбинаций переменных и придумал процедуру для рецензирования до 250 строк прозы или исходного кода. После 800 итераций он придумал формализованную инспекционную стратегию, и по сей день Вы можете заплатить ему, чтобы он Вам рассказал об этом (название компании: Fagan Associates). Его методы были позже другими изучены и подробно расширены, прежде всего Томом Джилбом и Карлом Виджерсом.

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

Каждому участнику будет присвоена определенная «роль». Для «рецензента» можно определить задачу критического анализа, в то время как «наблюдатель» может бы быть призван как консультант проблемной области или изучить, как правильно делать рецензирование. На инспекции Фагана «читатель» просматривает исходный код только для понимания – не для критического анализа – и представляет его группе. Это разделяет то, что автор предполагал, от того, что фактически представлено; часто сам автор в состоянии выбрать дефекты, получив такое описание со стороны.

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

Формальные инспекции также обычно используют и другие метрики, такие как отдельное время, потраченное на предварительную встречу ознакомления, и время самой встречи, уровни строк кода инспекции и проблемы, с которыми встречаются в самом процессе. Эти числа и комментарии периодически исследуются на встречах усовершенствования процесса; Инспекции Фагана имеют еще следующий шаг, который требует прохождения анкеты-опросника по процессу после каждой встречи для дальнейшего его улучшения.

Типичный поток операций для «формальной» инспекции. Не показаны артефакты, создаваемые анализом: журнал дефектов, заметки по встрече и журнал метрик. Некоторые в инспекции также используют закрывающую анкету-опросник на заключительной встрече.

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

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

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

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

Поэтому давайте посмотрим другие методы.

Рецензирование через-плечо

Это наиболее распространенное и неофициальное из рецензирований кода. Рецензирование «через-плечо» простое – разработчик стоит над рабочим местом автора, в то время как автор проводит рецензента по изменениям кода.

Обычно автор «ведет» рецензирование, находясь за клавиатурой и мышью, открывая различные файлы, указывая на изменения и объясняя, почему был выбран такой путь. Автор может представить изменения, используя различные инструменты, и даже переходя назад и вперед между изменениями и другими файлами в проекте. Если рецензент видит что-то неправильное, они могут поучаствовать в небольшом «парном программировании на месте», когда автор пишет исправление, а рецензент наблюдает. Большие изменения, где рецензент не обязателен, выполняются отдельно.

С современным программным обеспечением использующим общий рабочий стол так называемый анализ «через-плечо» может иметь место и для удаленных ситуаций. Это усложняет процесс, потому что вы должны запланировать эти встречи совместного использования и связаться по телефону. Положение через-плечо позволяет людям указывать, писать примеры или даже переходить к электронной доске для обсуждения, что сложнее сделать по Интернету.

Самое очевидное преимущество рецензирования через-плечо — простота выполнения. Любой может это делать, в любое время и без обучения. Это может применяться каждый раз, когда вам рецензирование необходимо – особенно при сложном изменении или изменении в «стабильной» ветви кода.

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

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

Во-вторых, для автора просто неумышленно пропустить изменение. Бесчисленное количество раз мы наблюдали анализ, который завершался, автор регистрировал свои изменения, и когда он видит, что список файлов уже загружен, он говорит, «О, я изменял этот? «. Слишком поздно!

Процесс рецензирования через-плечо

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

Есть другой эффект рецензирования через-плечо, которые некоторые люди рассматривают как преимущество, а другие как недостаток. Поскольку автор управляет темпом анализа, часто рецензент идет слишком быстро по коду. Рецензент не может продумать сложную часть кода. Рецензент не имеет шансов пройтись по другим исходным файлам, чтобы удостовериться, что изменение не будут ломать что-то еще. Автор мог бы рассказать что-то, что разъяснит код рецензенту, но следующий разработчик, который прочитает этот код, не будет иметь этого объяснения, если этого не будет как комментарий в коде. Для рецензента трудно быть объективным и понимающим эти проблемы, будучи ведомым по коду с взаимодействующим c ним разработчиком.

Например, скажем, что для автора определили задачу с исправлением ошибки, где часть диалогового окна прорисовывалась неправильно. После борьбы с документацией GUI Windows он наконец обнаруживает недокументированную «функцию» в вызове API прорисовки текста, которая вызывала проблемы. Он обработает ошибку с некоторым новым кодом и решит проблему. Когда рецензент доберется до этого обходного решения, это будет выглядеть сначала забавно.

«Почему Вы делаете так,» спросит рецензент, «ведь API GUI Windows сделает это за Вас?»

«Да, я думал так также,» ответит автор, «но оказывается, что в этом случае обрабатывается не правильно. Поэтому я должен был вызвать его по-другому здесь.»

Для рецензента будет просто принять изменения. Но следующий разработчик, который прочтет этот код, будет иметь такой же вопрос и может даже удалит обходное решение в процессе чистки кода. «В конце концов», скажет следующий разработчик, «API Windows делает это для нас, поэтому никакой потребности в этом дополнительном коде нет!»

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

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

Рецензирование через-почту

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

Самая сложная часть почтовой рецензии состоит в поиске и сборе рецензентов для файлов. На конец автор должен выяснить, как собрать файлы. Например, если это рецензирование изменений, предлагаемых для регистрации в управлении версиями, пользователь должен идентифицировать все файлы, добавленные, удаленные и измененные и скопировать их куда-нибудь, затем загрузить предыдущие версии этих файлов (так чтобы рецензенты видели, что было изменено), и организовать файлы так, чтоб рецензенты знали, какие с какими файлами сравнивать. Далее рецензенты должны извлечь эти файлы из электронной почты и сгенерировать различия для них.

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

Система управления версиями может также помочь автоматической отсылкой электронных писем. Например, серверный триггер «регистрации» в системе управления версиями может послать электронное письмо в зависимости от того, кто загрузил код (например, ведущий разработчик каждой группы рецензирует код от участников своей группы) и какие файлы были изменены (например, некоторые файлы «принадлежат» пользователю, который лучше всего квалифицирован для рецензирования изменений). Автоматизация полезна, но для многих процессов рецензирования кода вы захотите провести рецензию перед регистрацией, а не после.

Рисунок 3: Типичный процесс для почтового рецензирования кода уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

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

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

Еще одно преимущество рецензирования через-почту – они не выбивают рецензентов из «зоны». Хорошо известно, что разработчику требуется 15 минут, чтобы войти «в зону», где они погружены в свою работу и очень производительны. Даже простая просьба рецензирования у разработчика выбивает его из зоны – даже если будет ответ «я слишком занят». С электронными письмами рецензенты могут работать во время самостоятельно выбранного перерыва, поэтому они могут оставаться в своей зоне в течение многих часов.

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

Рисунок 4: Типовой процесс для рецензирования кода через-почту уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

Есть еще сложный момент с удаленным рецензированием. Иронично, но это одно из явных преимуществ рецензирования через-почту то, что они могут быть проводиться с удаленными разработчиками. Удаленное рецензирование может занять много дней, т.к. каждый переход «назад и вперед» может занять день, поэтому для завершения рецензирования может потребоваться пять дней вместо тридцати минут. Это тянет за собой много одновременных рецензий, а это в свою очередь означает еще больше трудностей для сохранения переговоров и связанных с ними изменений кода.

Предположим, что разработчик в Хайдарабаде, открывая Outlook, обнаруживает 25 электронных писем от различных людей, обсуждающих аспекты трех различных изменений кода, которые он сделал за последние несколько дней. Потребуется много времени только для того, чтобы разобраться, перед тем как может начаться реальная работа.

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

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

Инструментальное рецензирование

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

Существует несколько основных элементов, которые должны присутствовать в инструменте рецензирования, если он должен решить большие проблемы с другими типами рецензий:

Автоматизированный сбор файлов

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

В идеале инструмент может сделать это и с локальными изменениями, которые не зарегистрированы в управлении версиями, и с уже зарегистрированными изменениями (например, по дате, метке, ветви или уникальному номеру изменения). Даже если Вы не делаете оба этих типа рецензирования сегодня, то вы скорее всего захотите эту опцию в будущем.

Объединенное отображение: Различия, комментарии, дефекты

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

Автоматизированный набор метрик

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

Инструмент, который автоматизирует набор ключевых метрик, является единственным методом сделать разработчиков счастливыми (т.е. без дополнительной работы для них) и получить значимые метрики для вашего процесса. Полное обсуждение метрик рецензирования и что они означают это уже другая задача, но ваш инструмент должен, по крайней мере, собирать эти три уровня: количество строк/час (скорость инспекции), дефектов/час (скорость дефектообразования) и дефектов/количество строк (плотность дефектов).

Выполнение рецензирования

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

Клиенты и интеграция

Некоторым разработчикам нравятся инструменты с командной строкой. Другие предпочитают интеграцию с редакторами и клиентами управления версиями. Администраторам нравятся веб-клиенты, которые нет необходимости устанавливать. Важно, чтобы инструмент поддерживал много способов чтения и записи данных в системе.

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

Если Ваш инструмент удовлетворит этот список требований, то Вы будете обладать преимуществами перед рецензированием через-почту (работа с несколькими, возможно удаленными разработчиками, минимизация прерываний), но без каких-либо проблем выполнения потока операций, сбора метрик, и напрасной траты времени для упаковки файлов/различий, поставки и контроля.

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

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

Парное программирование

Большинство людей связывает парное программирование с XP и гибкой разработкой в целом, но это также процесс разработки, который включает непрерывное рецензирование кода. Парное программирование – два разработчика, пишущие код на одном рабочем месте только одним разработчиком в один момент времени и непрерывным обсуждением в свободной форме и рецензированием.

Исследования парного программирования показали, что оно очень эффективно и в поиске ошибок, и в стимулировании передачи знаний. И некоторые разработчики действительно любят его.

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

Единственная самая большая жалоба на парное программирование это то, что оно занимает слишком много времени. Вместо того, чтобы привести рецензента на 15-30 минут посмотреть изменение, мы берем одного разработчика на несколько дней в парное программирование и вас теперь два разработчика на одной задаче на все время.

Некоторым разработчикам просто не нравится парное программирование, это зависит от расположения разработчика к его партнеру. Парное программирование также не решает проблему удаленных разработчиков.

Полное обсуждение за и против парного программирования в целом вне нашей темы.

Заключение

Каждый из пяти типов рецензирования полезен по-своему. Формальные инспекции и парное программирование — доказанные методы, но требуют большого количества времени разработчика и не работают с удаленными разработчиками. Рецензирование через-плечо является самым простым для реализации, но не может быть реализован как управляемый процесс. Рецензирование через-почту и инструментальное рецензирование давят на баланс между временем, которое инвестируют, и простотой реализации.

И любой вид рецензирования кода лучше, чем ничего.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Сопротивление рецензированию кода

Posted by Шамрай Александр на Июнь 5, 2013

Почему некоторые разработчики сопротивляются Рецензированию кода и как новые инструменты изменят правила игры.

Автор Эрик Браун.

«Рецензирование кода». Скажите это в комнате программистов и вы почувствуете резкое охлаждение, как будто немного жизненной силы было внезапно высосано из каждого. Как программист вы нетерпимы ко всему, что тормозит вашу производительность. Настоящие программисты имеют чувство потокового творчества, когда они пишут код для решения проблем или создания инновации. Этот поток имеет преемственность, которая отступает как только вам нужно сделать паузу, чтобы ответить на телефон или поговорить с коллегой, который просто пришел к вам в офис, и восстанавливается после того, как вы решили особенно трудное препятствие или почувствовали прилив от кофеина из кофе, который вы только что выпили. Но соберите совещание отдела или запланируйте рецензирование кода и поток останавливается. Перспектива сидеть и слушать разговоры других о требованиях клиентах, или новых мерах по обеспечению качества, или обсуждения достаточности комментариев в коде для парня, озадаченного кодом, который хочет понять то, что он должен сделать, заставит любого программиста скорчиться.

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

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

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

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

  • Улучшение качества кода
  • Меньше дефектов в коде
  • Улучшение коммуникации о содержании кода
  • Обучение молодых программистов

А это косвенные выгоды, которые являются побочными продуктами Рецензирования кода:

  • Более короткие циклы разработки/тестирования
  • Уменьшение влияния на техническую поддержку
  • Больше удовлетворенность клиентов
  • Более простой в сопровождении код

И тем не менее, некоторые группы разработки до сих пор не используют рецензирование кода как регулярную часть их процесса. Почему так? Существует две основных простых причины:

  1. Эго программиста
  2. Проблемы передачи исходного кода для рецензирования и планирование встреч для рецензирования

Давайте поговорим сначала об эго. Когда кто-то еще смотрит на твою работу, любой программист естественно будет оценивать то, что человек думает о нем. Это может быть истолковано как конструктивный или критически настроенный процесс, и это толкование может создать 2 разных класса программистов. Первым классом являются коллективные программисты, когда они сталкиваются с проблемой, будут делать все что необходимо для ее понимания (или по крайней мере прийти к временному решению), что часто включает в себя спросить коллегу, который уже знает ответ или готов поделиться разными идеями. Они видят и используют коллегиальную оценку как полезный процесс. Вторым классом являются изоляционисты – те программисты, которые когда сталкиваются с проблемой, которую они не в состоянии решить, будут продолжать непродуктивно грузиться на ней, вместо того, чтобы выявить их коллег, которые им помогут. Стоит отметить, эта дихотомия подходов безусловно не является уникальной для программистов и существует в более широких масштабах личности в целом.

Почему эти классы имеют тенденцию быть настолько различными среди программистов? Основная причина последнего класса программиста, как правило, короткая карьера в разработке программного обеспечения. Их багаж знаний становится ограниченным в том, что они могут сами понять, что даже ярких личностей (в поле ярких личностей) ограничивает.

В 2002 году было озвучено, что средняя карьера в высоких технологиях длится около 8 лет. Это слишком много времени потраченного впустую на свое совершенствование. Положение может быть также важно, как способность. Программист должен иметь способность работать в команде, слушать внимательно, идти на риск и учиться на своих ошибках, для того чтобы выжить в обычно быстро меняющейся среде высоких технологий. Постоянный интерес к обучению последовательно усиливает и обостряет навыки и позволяет программистам продолжать быть продуктивными (и рыночными!) в постоянно меняющейся области.

Многие разработчики уже понимают значение совместной работы. Почему поэтому еще редки рецензии кода для многих разработчиков? Если вы программист, вы вероятно интуитивно знаете ответ. И если нет, чтобы понять ответ вы должны понять сначала как программисты работают.

Программирование — это искусство и дисциплина. Программисты, как правило, должны создавать решения, в отличие от инженерных областей, где большинство проблем имеют категории и известные применяемые решения. Программист создает/придумывает решение, которое является достаточным и необходимым. Программист работает в череде изменяемого и повышенного состояния сознания для производства. Если вы попросите кого-то, кто работает в таком режиме, предоставлять еженедельный отчет или присутствовать на корпоративных сессиях повышения боевого духа или сидеть на еженедельных совещаниях отдела, вы будете обычно встречаться с интонацией презрения или оправдания о наличии задерживаемой функции Sev-3, до которой они начали добираться.

Когда я работал в качестве разработчика драйверов устройства для большой корпорации разработки программного обеспечения и оборудования, наш менеджер первой линии был очень нетехническим. У него всегда было одно и тоже понимание ошибок, которые мы пытались изолировать: «Вы просто должны установить флаг». Большинство программистов имеют первичный страх необходимости объяснять что-то или страдать от бессмысленных вопросов таких как этот. Так что, когда вы спросите программиста извлечь последние несколько изменений чужого кода из системы управления версиями, распечатать их и выделить изменения, и затем принести их на встречу для обсуждения с другими людьми, включая моего старого менеджера, вы ощутите, как уходит из вас жизненная сила.

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

Однако рецензирование кода не должно быть больше болезненным. Процесс рецензирования кода, как и индустрия программного обеспечения, резко изменился за последние 10 или 20 лет. Так же, как современные IDE устраняют трудозатраты и риски рефакторинга, есть в настоящее время программные средства для рецензирования кода, которые решают вопросы сотрудничества и интеграцию с системой управления версиями.

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

Больше нет оправданий не использовать рецензирование кода.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Примеры для коллегиальной оценки

Posted by Шамрай Александр на Июнь 4, 2013

Ошибка на 1 млрд $ и почему никто не говорит о коллегиальной оценке кода.

Это должно было занять только час.

Плохая новость была в том, что мы имели стек жалоб от клиентов. Последний релиз имел неприятную ошибку, которая проскользнула через контроль качества (QA). Хорошая новость в том, что некоторые из этих жалоб включали описание проблемы – диалоговое окно с непредвиденной ошибкой – и к одной жалобе был прикреплен файл с журналом. Нам только нужно было воспроизвести проблему с помощью журнала и добавить этот случай в модульные тесты. Быстро выпустить сборку из стабильной ветви и мы в ажуре.

Конечно это не так, как выяснилось потом. Мы следовали по шагам из журнала и все работало нормально. QA не могли воспроизвести проблему. Потом оказалось, что диалоговое окно с ошибкой было отвлекающим – реальная ошибка происходила задолго до диалогового окна, где-то глубоко в коде.

Спустя неделю с двумя разработчиками мы наконец обнаружили причину проблемы. Как только мы увидели код, это стало болезненно очевидным – определенная подпрограмма не проверяла недопустимость входных данных. Пока мы вышли на исправление, мы уже имели более двадцати жалоб. Об одном потенциальном клиенте, который испытывал продукт, мы уже никогда не слышали.

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

Хуже всего, что это не единичный инцидент. Это происходит во всех командах разработки. Хорошие новости? Политики рецензирования кода могут остановить эти проблемы на самых ранних этапах, прежде чем они достигнут клиента, прежде чем они будут дорогими.

Пример для рецензирования: Поиск ошибок в начале и часто

Один из наших клиентов решил протестировать сколько точно денег компания сэкономила бы, если бы они использовали коллегиальную оценку в рамках трех месяцев, проекта на 10000 строк и с 10 разработчиками. Они отслеживали сколько ошибок были найдены QA и клиентами в течение последующих шести месяцев. Затем они пошли обратно и сформировали еще одну группу разработчиков рецензирования кода. Используя метрики из предыдущих версий этого проекта они знали среднюю стоимость исправления дефекта на каждом этапе разработки, так что они смогли измерить непосредственно сколько денег они могли бы сохранить.

Результат: Рецензирование кода сохранило бы половину стоимости исправления ошибок. Кроме того, они нашли бы 162 дополнительных ошибок.

Почему столь драматичен эффект рецензирования кода? Виновником может быть отсутствие сотрудничества на этапе разработки.

С требованиями и проектированием вы всегда встречаетесь. Вы привлекаете клиентов, менеджеров, разработчиков и QA для синтеза результатов. Вы делаете это, потому что ошибки в требованиях или архитектуре дорогие, что может привести к падению объема продаж. Вы обсуждаете относительные приоритеты, сложность и долгосрочные преимущества вашего выбора.

Сохранить 150 000$: Урок из реального мира

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

Рецензирование кода добавляет обратный элемент сотрудничества к этой фазе процесса разработки программного обеспечения.

Рассмотрим это: ничего коммерческого не публикуется без корректировок от нескольких профессиональных редакторов. Посмотрите подтверждение этого в любой книге и вы сможете найти отзывы, кто помог «удалить дефекты». Независимо от того, насколько умен или прилежен автор, процесс рецензирования необходим для производства высококачественной работы. (И даже тогда, когда автор не нашел еще пять ошибок после просмотра первой версии?)

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

Мы не должны. Если рецензирование работает с романами, то и в проектировании программного обеспечения это может также работать при написании кода. Рецензирование кода добавляет элемент столь необходимого сотрудничества к этапу разработки процесса разработки программного обеспечения.

Ошибка на 1 миллиард $

В 2005 году Adobe приписали $1 млрд доходов к формату PDF. Почему PDF стоит 1 млрд $? Потому что это один формат, который каждый может просматривать и печатать. Он работает просто. Если он потеряет этот статус, Adobe потеряет состояние построенное на этом формате, которому 2005 финансовом году присвоили прибыль в 1 млрд $.

Теперь представьте, что вы менеджер по разработке Acrobat Reader версии для Windows. Следующая основная версия должна быть сделана за 9 месяцев, и вы несете ответственность за добавление пяти новых функций. Вы знаете, как много читают с Reader-ом и сколько дохода – и рабочих мест – зависит от его дальнейшего успеха.

Так что теперь вопрос: какая из тех пяти функции настолько убедительна, что было бы возможно введение критической ошибки в Reader только, чтобы иметь эту функцию?

Ответ: Ни одна!

Ничто не стоит потери вашего положения в отрасли. Но по-прежнему необходимо реализовывать новые функции, чтобы быть технологически свежими и конкурентоспособным. Так какие методы будете вы использовать в процессе разработки, чтобы получить представление об отсутствии ошибок?

Ответ: Все. Включая рецензирование кода.

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

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

Это не означает, что они реализуют Рецензирование кода независимо от расходов; время разработчика по-прежнему дорогой товар. Это означает, что они будут уделять время, чтобы понять этот процесс, который, если выполнять должным образом, испытанный метод, который значительно сокращает количество поставляемых ошибок, сохраняет код поддерживаемым и дает возможность новичкам быть продуктивными быстро и безопасно.

Но вам не нужно иметь 1 млрд $ на кону, чтобы быть заинтересованными в качестве кода и возможности поддержки. Поставка ошибок QA стоит денег; поставка ошибок клиентам стоит много денег и потерю доброго отношения.

Но если рецензирование кода работает и это хорошо, почему мало людей говорят об этом? Кто-то действительно делает это?

Почему рецензирование кода является секретом

В 1991 году ООП было Следующей Большой Вещью. Но странно, на OOPSLA было несколько важных документов легкого содержания и тем не менее участники признались друг к другу в коридоре, говорили, что их компании горячо используют новые методы, что дает значительные улучшения для повторного использования кода и декомпозиции сложных систем.

Так почему они не говорят публично? Потому что группы разработки, которые действительно понимают техники ООП, имеют конкурентное преимущество. ООП является новым и каждый изучал эмпирически, что работает, а что нет; зачем выдавать ваши заработанные знания для ваших конкурентов?

Успешно внедренный процесс рецензирования кода – это конкурентное преимущество. Никто не хочет отдавать секрет того, как эффективно выпускать меньше дефектов.

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

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

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

Мне интересно. Что дальше?

Итак, рецензирование кода работает, но что делать, если разработчики тратят слишком много времени на это? Что делать, если социальные последствия личностных критик нарушают моральные принципы? Как можно выполнять рецензирование измеряемо, так чтобы вы могли определить проблемы процесса?

Мы покроем исследования рецензирования в реальном мире и покажем, какие выводы можно извлечь из них (и какие нет). Мы дадим результаты наших собственных исследований по 2500 отзывам. Мы дадим профессиональные советы и руководства для пяти наиболее распространенных типов рецензирования. Мы объясним, как воспользоваться преимуществами позитивных социальных и личных аспектов рецензирования, также какими путями менеджеры могут смягчить негативные эмоции, которые могут возникнуть. Мы объясним, как осуществить обзор в контексте CMMI/PSP/TSP. Мы дадим конкретные советы по как построить процесс коллегиальной оценки, которая удовлетворит конкретные цели. Наконец мы опишем инструмент, который наши клиенты использовали для различных видов рецензирования как возможно безболезненно и как возможно более эффективно.

Рецензирование кода может быть практичным, эффективным и даже веселым.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения?

Posted by Шамрай Александр на Март 24, 2012

Статья, находящаяся перед вами, открывает цикл статей о человеческом факторе, Agile-практиках и других полезных приемах, используемых при управлении командами в ИТ. Объединяет рассматриваемые практики и приемы одно – они позволяют проявиться положительным эффектам, связанным с человеческим фактором. И мы объясняем, почему с точки зрения психологии, это происходит. Так сказать, подводим теоретическую и экспериментальную базу под то, что себя уже давно зарекомендовало и работает. Или под то, что работает не у всех, и потому является предметом оживленных споров и дискуссий. И начинаем мы наши исследования с рассмотрения эффекта парного программирования через призму экспериментов социальной психологии.

Читать далее >>

Posted in Agile, Стандарты и методологии | Leave a Comment »

CMMI DEV v1.3 – Показатели Организационных Процессов

Posted by Шамрай Александр на Февраль 3, 2012

Перевод Шамрай А.В.

Процессная область Управления Процессами уровня зрелости 4

Назначение

Назначением Показателей Организационных Процессов (ПОП) является создание и поддержка количественного представления о выполнении отдельных процессов в наборе стандартных организационных процессов для поддержки достижения целей качества и выполнения процесса, а также предоставление данных о выполнении процесса, базовых показателей и моделей количественного управления проектами организации.

Вступительный комментарий

Процессная область Показатели Организационных Процессов включает в себя следующие мероприятия:

  • Установка организационных количественных целей показателей качества и выполнения процесса на основе бизнес-целей (см. определение «цели показателей качества и выполнения процесса» в глоссарии.)
  • Выбор процессов или подпроцессов для анализа показателей выполнения процесса.
  • Создание определения мер, которые будут использоваться для анализа показателей выполнения процесса (см. определение «показатели выполнения процесса» в глоссарии).
  • Установление базовых показателей выполнения процесса и моделей выполнения процесса (см. определения «базовые показатели выполнения процесса» и «модели показателей выполнения процесса» в глоссарии).

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

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

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

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

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

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

  • Определить ведут ли себя процессы последовательно или имеют стабильные тенденции (то есть являются предсказуемыми)
  • Определить процессы, в которых их выполнение находится в нормальных границах, которые согласованы по проектам и могут быть агрегированы
  • Определить процессы, которые показывают необычное (например, случайное, непредсказуемое) поведение
  • Определить аспекты процессов, которые могут быть улучшены в организационном наборе стандартных процессов
  • Идентифицировать реализацию процесса, который выполняется лучше всего

Этот процесс взаимодействует и поддерживает реализацию других процессных областей высокого уровня зрелости. Активы, создаваемые и поддерживаемые в рамках реализации этой процессной области (например, меры, которые будут использоваться для характеристик поведения подпроцессов, базовых показателей выполнения процесса, моделей показателей выполнения процесса), являются входными для количественного управления проектами, причинно-следственного анализа и принятия решений и процессов управления показателями выполнения организации в рамках анализа, описанного ниже. Процессы количественного управления проектами обеспечивают данные по качеству и выполнению процесса, необходимые для поддержки активов, описанных в этой процессной области.

Связанные процессные области

См. процессную область Измерение и Анализ для получения дополнительных сведений об определении мер, получения данных измерений и анализа данных измерений.

См. процессную область Управление Организационными Показателями для получения дополнительных сведений о проактивном управлении организационными показателями для удовлетворения своих бизнес-целей.

См. процессную область Количественное Управление Проектами для получения дополнительных сведений о количественном управлении проектом для достижения установленного качества проекта и обработки задач.

Перечень специфических целей и практик

  • СЦ 1 Установить Базовые Показатели и Модели Выполнения
    • СП 1.1 Устанавливайте Цели для Показателей Качества и Выполнения Процесса
    • СП 1.2 Выберите Процессы
    • СП 1.3 Установите Меры для Показателей Выполнения Процесса
    • СП 1.4 Анализируйте Показатели Выполнения Процесса и Устанавливайте Базовые Показатели Выполнения Процесса
    • СП 1.5 Устанавливайте Модели Показателей Выполнения Процесса

Специфические практики по целям

СЦ 1 Установить Базовые Показатели и Модели Выполнения

Базовые показатели и модели, которые характеризуют ожидаемое выполнение процесса организационного набора стандартных процессов, установлены и поддерживаются.

До установления базовых показателей и моделей выполнения процесса, необходимо определить цели показателей качества и выполнения процесса для этих процессов (специфическая практика Устанавливайте Цели Показателей Качества и Выполнения Процесса), какие процессы могут быть измерены (специфическая практика Выберите Процессы) и какие меры являются полезными для определения показателей выполнения процесса (специфическая практика Установите Меры для Показателей Выполнения Процесса).

Первые три практики этой цели взаимосвязаны и часто выполняются одновременно и итерационно для выбора качественных и целей выполнения процесса, выбора процессов и мер. Часто выбор одной из практик целей качества и выполнения процесса, или процесса, или меры ограничивает выбор других. Например, выбор целей показателей качества и выполнения процесса объективно связано с дефектами, передаваемых заказчику, почти наверняка потребует выбор процессов верификации и меры, связанные с дефектами.

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

СП 1.1 Устанавливайте Цели для Показателей Качества и Выполнения Процесса

Устанавливайте и поддерживайте количественные цели организации для показателей качества и выполнения процесса, которые трассируемы с бизнес-целями.

Цели для показателей качества и выполнения процесса организации могут быть установлены для различных уровней организационной структуры (например, бизнес область, линейка продуктов, функция, проект), а также для различных уровней иерархии процессов. При создании целей для качества и выполнения процесса учтите следующее:

  • Трассировка к бизнес-целям организации
  • Прошлые показатели отдельных процессов или подпроцессы в контексте (например, в контексте проектов)
  • Множественность атрибутов выполнения процесса (например, качество продукта, продуктивность, время цикла, время отклика)
  • Присущая изменчивость или естественные границы отдельных процессов или подпроцессов

Цели для показателей качества и выполнения процесса организации обеспечивают фокус и направление для мероприятий по анализу показателей выполнения процесса и количественному управлению проектом. Однако следует отметить, что обеспечение целей показателей качества и выполнения процесса, которые значительно отличаются от возможностей текущего процесса, требуют использования методов, представленных в разделах Причинно-Следственный Анализа и Принятие Решений и Управление Показателями Выполнения Организации.

Пример рабочих продуктов

1. Цели показателей качества и показателей выполнения процесса

Подпрактики

1. Рассматривайте бизнес цели организации, связанные с показателями качества и выполнения процессов.

Примеры бизнес-целей включают следующее:

  • Поставить продукт в рамках бюджета и в срок
  • Улучшить качество продукта на указанный процент в установленные сроки
  • Повысить продуктивность на указанный процент в установленные сроки
  • Поддерживать уровень удовлетворенности заказчика
  • Улучшить время выхода на рынок для новых версий продукта или услуги на заданный процент в установленные сроки
  • Снизить запаздывание функциональности продукта на указанный процент в установленные сроки
  • Снизить уровень отзыва продукта обратно на указанный процент в установленные сроки
  • Снизить общие затраты владения на указанный процент в установленные сроки
  • Уменьшить расходы поддержки предыдущих продуктов на указанный процент в установленные сроки

2. Определите количественные цели для показателей качества и выполнения процесса организации.

Цели показателей качества и выполнения процесса могут быть установлены для измерений процесса или подпроцесса (например, трудозатраты, время цикла, эффективность удаления дефектов), а также измерений продукта (например, надежность, плотность дефектов) и измерений сервиса (например, производственная мощность, время отклика) в случае необходимости.

Примеры целей показателей качества и выполнения процесса включают в себя следующее:

  • Достичь указанной скорости удаления дефектов, продуктивности, продолжительности, производительности или стоимостных целей
  • Улучшить показатели скорости удаления дефектов, продуктивности, продолжительности, производительности или стоимости на указанный процент от базового уровня показателей выполнения процесса в установленные сроки
  • Повысить показатели соглашений об уровне обслуживания на указанный процент от базового уровня показателей выполнения процесса в установленные сроки

3. Определите приоритеты целей показателей качества и выполнения процесса организации.

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

5. Пересматривайте количественные цели для показателей качества и выполнения процесса организаций по мере необходимости.

Примеры, когда количественные цели для показателей качества и выполнения процесса организации, возможно, потребуется пересмотреть, включают следующее:

  • Когда изменяются бизнес-цели организации
  • Когда изменяется организационный набор стандартных процессов
  • Когда фактическое качество и выполнение процесса значительно отличаются от целей

СП 1.2 Выберите Процессы

Выберите процессы или подпроцессы в организационном наборе стандартных процессов для включения в анализ показателей выполнения организационных процессов и поддержки трассировки с бизнес-целями.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании организационных активов процессов.

Организационный набор стандартных процессов состоит из набора стандартных процессов, которые, в свою очередь, состоят из подпроцессов.

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

Пример рабочих продуктов

1 Список процессов или подпроцессов, предназначенных для анализа показателей выполнения процесса, с обоснованием их выбора, включая трассировку с бизнес-целями.

Подпрактики

1. Устанавливайте критерии для выбора подпроцессов.

Примеры критериев, которые могут использоваться при выборе процесса или подпроцесса для анализа показателей выполнения процесса организации, включают в себя следующее:

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

2. Выберите подпроцессы и задокументируйте обоснование их выбора.

Примеры подходов к выявлению и оценки альтернатив подпроцессов в рамках отбора включают следующее:

  • Причинно-следственный анализ
  • Анализ чувствительности

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

3. Устанавливайте и поддерживайте трассировку между выбранными подпроцессами, целями качества и показателей выполнения процесса и бизнес-целями.

Примеры способов, в которых могут быть выражены трассировки, включают следующее:

  • Связи подпроцессов с целями качества и показателями выполнения процесса
  • Связи подпроцессов с бизнес-целями
  • Последовательность целей (например, отношение Больших Y к Важным X, стратегическое Хосин планирование)
  • Система сбалансированных показателей
  • Развертывание Качественных Функций (Quality function deployment (QFD))
  • Цель Вопрос Метрика
  • Документация для модели показателей выполнения процесса

4. Пересматривайте выбор по мере необходимости.

Пересмотр выбора может быть необходим в следующих ситуациях:

  • Прогнозы, сделанные по модели показателей выполнения процесса, приводят к слишком большому количеству вариантов, что делает их бесполезными.
  • Изменились цели для качества и показателей выполнения процесса.
  • Изменился организационный набор стандартных процессов.
  • Изменение основ качества и показателей выполнения процесса.

СП 1.3 Установите Меры для Показателей Выполнения Процесса

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

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации мер.

Пример рабочих продуктов

1. Определения для отдельных мер по показателям выполнения процесса с обоснованием их выбора, включая трассировку отдельных процессов или подпроцессов.

Подпрактики

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

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

Парадигма Цель Вопрос Метрика — это подход, который может использоваться для выбора мер, которые обеспечивают видение целей показателей качества и выполнения процесса организации. Часто бывает полезным для анализа то, как эти цели показателей качества и выполнения процесса выполнения могут быть достигнуты, основываясь на понимании выполнения процесса, предоставляемого выбранными мерами.

Примеры критериев, используемых для выбора мер, включают следующее:

  • Связь мер с целями показателей качества и выполнения процесса организации
  • Освещение, что меры обеспечивают в течение жизни продукта или услуги
  • Видимость, что меры обеспечивают для показателей выполнения процесса
  • Доступность мер
  • Частота, с которой могут быть собраны значения мер
  • Степень, в которой меры управляемы изменениями процесса или подпроцесса
  • Степень, в которой меры предоставляют представление конечных пользователей об эффективном выполнении процесса

2. Устанавливайте операционные определения для выбранных мер.

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации мер.

3. Включайте выбранные меры в организационный набор общих мер.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании организационных активов процессов.

4. Пересматривайте набор мер в случае необходимости.

Меры периодически оцениваются для их дальнейшей полезности и возможности показать эффективность процесса.

СП 1.4 Анализируйте Показатели Выполнения Процесса и Устанавливайте Базовые Показатели Выполнения Процесса

Анализируйте показатели выполнения выбранных процессов и устанавливайте и поддерживайте базовые показатели выполнения процесса.

Выбранные меры анализируются для характеристики показателей выполнения отдельных процессов или подпроцессов, достигнутых по проектам. Эта характеристика используется для создания и поддержки базовых показателей выполнения процесса (см. определение «базовые показатели выполнения процесса» в глоссарии.) Эти базовые показатели используются для определения ожидаемых результатов процесса или подпроцесса, которые используется для проекта в рамках определенного набора условий.

Базовые показатели выполнения процесса сравниваются с целями показателей качества и выполнения процесса организации для определения достижения целей показателей качества и выполнения процесса.

Базовые показатели выполнения процесса являются измерениями показателей выполнения для организационного набора стандартных процессов на различных уровнях детализации. Процессы, которые могут затрагивать базовые показатели выполнения процесса, включают следующее:

  • Последовательность связанных процессов
  • Процессы, которые охватывают всю жизнь проекта
  • Процессы разработки отдельных рабочих продуктов

Может существовать несколько базовых показателей выполнения процесса для характеристики показателей выполнения для подгруппы организации.

Примеры критериев, используемых для классификации подгруппы, включают следующее:

  • Линейка продуктов
  • Направление бизнеса
  • Прикладная область
  • Сложность
  • Размер группы
  • Размер рабочего продукта
  • Элементы процесса из организационного набора стандартных процессов

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

См. процессную область Количественное Управление Проектами для получения дополнительной информации о количественном управлении проектом для достижения установленных показателей качества и выполнения процессов проекта.

Пример рабочих продуктов

1. Анализ данных показателей выполнения процесса

2. Данные базовых показателей выполнения организационных процессов

Подпрактики

1. Собирайте выбранные измерения для отдельных процессов и подпроцессов.

Процесс или подпроцесс находятся в использовании, когда измерения записываются для последующего их использования.

См. процессную область Измерения и Анализ для получения дополнительной информации об указании процедур сбора и хранения данных измерений.

2. Анализируйте собранные меры для создания распределения или ранжирования результатов, которые характеризуют ожидаемые показатели выполнения выбранных процессов или подпроцессов, когда они используются в проекте.

Этот анализ должен включать стабильность соответствующих процессов или подпроцессов и сопутствующих факторов и контекста. Связанные с этим факторы включают входные элементы для этого процесса и другие атрибуты, которые могут повлиять на результаты. Контекст включает бизнес-контекст (например, область) и значимую адаптацию организационного набора стандартных процессов.

По возможности измерения следует использовать из стабильных подпроцессов в проектах; другие данные могут быть ненадежными.

3. Устанавливайте и поддерживайте базовые показатели выполнения процесса из собранных измерений и анализов.

См. процессную область Измерения и Анализ для получения дополнительной информации о согласования мероприятий измерения и анализа и предоставления результатов измерений.

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

4. Оценивайте и согласуйте с соответствующими заинтересованными сторонами базовые показатели выполнения процесса.

5. Предоставляйте информацию о показателях выполнения процесса для всей организации в хранилище измерений.

Базовые показатели выполнения организационного процесса используются проектами для оценки естественных границ для показателей выполнения процесса.

6. Сравнивайте базовые показатели выполнения процесса со связанными целями показателей качества и выполнения процесса, чтобы определить будут ли эти цели показателей качества и выполнения процесса достигнуты.

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

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации об определении причины выбранных результатов.

См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации о планировании и реализаций мероприятий по процессу.

См. процессную область Управление Организационными Показателями Выполнения для получения дополнительной информации об анализе данных показателей процесса и выявления потенциальных областей для улучшения.

7. Пересматривайте базовые показатели выполнения процесса по мере необходимости.

Примеры, когда базовые показатели выполнения организационного процесса, возможно, потребуется пересмотреть, включают следующее:

  • Когда изменились процессы
  • Когда организационные результаты изменились
  • Когда организационные потребности изменились
  • Когда процессы поставщиков изменились
  • Когда поставщики изменились

СП 1.5 Устанакливайте Модели Показателей Выполнения Процесса

Создавайте и поддерживайте модели показателей выполнения процесса для организационного набора стандартных процессов.

Организации высокого уровня зрелости обычно устанавливают и поддерживают ряд различных моделей показателей выполнения процесса на различных уровнях детализации, которые охватывают целый ряд мероприятий, которые являются общими для организации и затрагивают организационные цели показателей качества и выполнения процесса. (См. определение «модель показателей выполнения процесса» в глоссарии). В некоторых случаях проекты могут потребовать создания своих собственных моделей показателей выполнения процесса.

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

Модели показателей выполнения процессов используются следующим образом:

  • Организация использует их для оценки, анализа и прогнозирования показателей выполнения процесса, которые связаны с процессами и изменения в организационном наборе стандартных процессов.
  • Организация использует их для оценки (потенциальной) возврата инвестиций для мероприятий по совершенствованию процесса.
  • Проекты используют их для оценки, анализа и прогнозирования показателей выполнения процесса их определенных процессов.
  • Проекты используют их при выборе процессов или подпроцессов для использования.
  • Проекты их используют для оценки прогресса в достижении целей показателей качества и выполнения процесса проекта.

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

Примеры моделей показателей выполнения процесса включают следующее:

  • Модели динамики системы
  • Регрессионные модели
  • Модели сложности
  • Дискретно-событийное моделирование
  • Модели Монте-Карло

См. процессную область Количественное Управление Проектами для получения дополнительной информации об управлении проектом на основе количественных показателей для достижения установленных в проекте целей качества и показателей процесса.

Пример рабочих продуктов

1. Модели показателей выполнения процесса

Подпрактики

1. Устанавливайте модели показателей выполнения процесса, основанных на организационном наборе стандартных процессов и базовых показателях выполнения процесса.

2. Калибруйте модели показателей выполнения процесса на основе прошлых результатов и текущих потребностей.

3. Оценивайте модели показателей выполнения процесса и согласуйте с соответствующими заинтересованными сторонами.

4. Поддерживайте использование моделей показателей выполнения процесса в проектах.

5. Пересматривайте модели показателей выполнения процессов по мере необходимости.

Примеры, когда модели показателей выполнения процесса, возможно, потребуется пересмотреть, включают следующее:

  • Когда изменяются процессы
  • Когда организационные результаты изменились
  • Когда организационные цели показателей качество и выполнения процесса изменились

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | 1 Comment »

 
%d такие блоггеры, как: