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

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

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

Use-Case 2.0. Сценарий использований 2.0 – содержимое

Posted by Shamrai Alexander на Май 23, 2018

Сценарий использования 2.0 состоит из набора элементов, с которыми нужно работать, и набора мероприятий.

С чем работать

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

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

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

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

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

Сценарии использования

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

Сценарий использования – это:

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

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

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

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

  1. Цель установлена: когда цель сценария использования была выяснена.
  2. Структура истории понятна: когда понимание структуры повествования сценария использования достаточно для команды, чтобы начать работу по выявлению и реализации первого слайса сценария использования.
  3. Простейшая история выполнена: когда система выполняет простейшую историю, которая позволяет пользователю достичь цель.
  4. Достаточно историй выполнено: когда система выполняет достаточно историй для обеспечения полезного решения.
  5. Все истории выполнены: когда система выполняет все истории, рассказываемые сценарием использования.

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

Слайс сценария использования

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

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

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

Слайс сценария использования:

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

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

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

1) Границы определены: когда границы слайса определены и выявлено количество покрываемых историй.

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

3) Проанализирован: когда слайс проанализирован и понятно его воздействие на компоненты системы, и затрагиваемые части готовы для написания кода и тестирования разработчиком.

4) Реализован: когда программная система была усовершенствована реализацией слайса, и слайс готов к тестированию.

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

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

Истории

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

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

Рисунок 4. Взаимосвязь между потоками и историями

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

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

  • Сверху вниз: Некоторым людям нравится использовать подход сверху вниз где они 1) определяют сценарий использования 2) набрасывают основной поток, и 3) применяют мозговой штурм для определения альтернативных потоков на основе базового потока. Такое структурирование повествования и позволяет им определить свои истории.
  • Снизу вверх: Используя подход снизу вверх мы начинаем с мозгового штурма для некоторого набора историй, и затем группируем их по темам для определения наших сценариев использования. Набор историй изучается, чтобы помочь нам определить основные и некоторые из альтернативных потоков. Структура сценария использования в дальнейшем приводит нас к выявлению любых отсутствующих историй и дает возможность убедиться, что все истории были сформированы и дополняют друг друга.

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

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

Дефекты и изменения

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

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

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

Рабочие продукты

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

Рисунок 5. Рабочие продукты Сценария использования 2.0

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

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

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

Работа со сценариями использования и слайсами

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

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

Рисунок 6. Фиксация свойств сценария использования и его слайсов с помощью бумажных заметок

Отображенный сценарий использования является сценарием использования «7 Просмотр и покупка» для онлайн-покупок приложений. Слайсы 1 и 2 сценария использования основаны на индивидуальных историях, производных от основного потока: «Выбрать и купить 1 продукт» и «Выбрать и купить 100 продуктов». Слайс 3 основан на нескольких историях, покрывающих наличие различных систем поддержки, участвующих в сценарии использования. Эти истории охватывают целый ряд альтернативных потоков.

Основными свойствами сценария использования являются его имя, состояние и приоритет. В этом случае используется популярная схема приоритетов MoSCoW (Must, Should, Could, Would) — (Должен Быть, Стоит Иметь, Может Быть, Может не Быть). Сценарии использования должны также быть оценены. В этом случае используется простая схема оценки их относительного размера и сложности.

Основными свойствами слайса сценария использования являются 1) перечень его историй, 2) ссылки на сценарий использования и потоки, которые определяют истории, 3) ссылки на тесты и тестовые сценарии, которые будут использоваться для проверки его выполнения и 4) оценку работы, необходимой для имплементации и тестирования слайса. В этом примере истории используются для наименования слайса и ссылки на сценарий использования, скрытой в номере слайса, и на список потоков. Оценки были добавлены позднее после консультаций с командой. Это большие цифры в нижней правой части каждой бумажной заметки. В этом случае команда играет в покер планирования для создания относительных оценок с помощью баллов историй; 5 баллов историй для слайсов 7.1 и 7.2 и 13 баллов описаний для слайса 7.3, который, как команда считает, будет занимать более чем вдвое большее усилий в сравнении с другими слайсами. В качестве альтернативы могут использоваться идеальные дни, размеры футболки (XS, S, M, L, XL, XXL, XXXL) или любой другой популярный метод оценки.

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

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

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

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

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

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

Завершая рабочие продукты

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

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

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

Рисунок 10. Уровни детализации рабочих продуктов

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

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

Что делать

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

Рисунок 11. Активности Сценария Использования 2.0

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

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

Найти субъекты и сценарии использования

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

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

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

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

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

СОВЕТ: МОЗГОВОЙ ШТУРМ МОДЕЛИРОВАНИЯ ЗАПУСТИТ ВАШУ МОДЕЛЬ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

Разделить сценарии использования

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

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

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

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

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

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

СОВЕТ: ВАМ НУЖЕН ТОЛЬКО ОСНОВНОЙ ПОТОК САМОГО ВАЖНОГО СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ ДЛЯ СОЗДАНИЯ ВАШЕГО ПЕРВОГО СЛАЙСА

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

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

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

Подготовить слайс сценария использования

После выбора слайса для разработки потребуются дополнительные действия для:

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

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

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

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

СОВЕТ: ЕСЛИ СЛАЙС НЕ ИМЕЕТ ТЕСТОВЫЕ СЦЕНАРИЕВ, ТО ОН НЕ ПОДГОТОВЛЕН ДОЛЖНЫМ ОБРАЗОМ

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

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

Анализировать слайс сценария использования

Перед началом создания кода следует проанализировать слайс для:

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

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

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

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

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

СОВЕТ: ХРАНИТЕ АНАЛИЗ ДОСТУПНЫМ И ЛЕГКИМ

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

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

Реализация программного обеспечения (по слайсам)

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

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

Тестирование системы (по слайсам)

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

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

Тестирование системы целиком

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

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

Изучать и адаптировать сценарии использования

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

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

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

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

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

СОВЕТ: НЕ ЗАБУДЬТЕ ПОДДЕРЖИВАТЬ ВАШ ЖУРНАЛ СЛАЙСОВ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

Реклама

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

USE-CASE 2.0. Базовые принципы

Posted by Shamrai Alexander на Май 18, 2018

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

  1. Сохранять их простыми, рассказывая истории
  2. Понимать общую картину
  3. Сосредотачивать внимание на значении
  4. Строить систему слайсами
  5. Поставлять систему инкрементами
  6. Адаптировать под потребности команды

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

Принцип 1: Сохранять их простыми, рассказывая истории

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

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

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

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

Принцип 2: Понимать общую картину

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

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

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

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

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

Принцип 3: Сосредотачивать внимание на значении

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

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

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

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

ОСНОВНОЙ ПОТОК АЛЬТЕРНАТИВНЫЕ ПОТОКИ
1. Вставить карту А1. Неправильная карта
2. Выполнить валидацию карты А2. Нестандартный сумма
3. Выбор получения наличных денег А3. Требуется квитанция
4. Выбор счета А4. Недостаточно средств в банкомате
5. Подтверждение доступности средств А5. Недостаточно средств на счету
6. Возврат карты А6. Возможен перерасход
7. Выдача наличных А7. Карта застряла
А8. Карта забыта
И т.д.

Рисунок 2. Структура рассказов сценариев использования

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

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

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

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

Принцип 4: Строить систему слайсами

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

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

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

Нарезка сценариев использования

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

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

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

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

Слайсы – это больше, чем просто требования и тестовые сценарии

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

Рисунок 3. Слайс сценария использования больше, чем просто нарезка требований

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

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

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

Слайсы сценария использования: Наиболее важная часть Сценария использования 2.0

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

Принцип 5: Поставлять систему инкрементами

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

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

Рисунок 4 показывает инкрементальную разработка версии системы. Первый инкремент содержит только один слайс: первый слайс от сценария использования 1. Второй инкремент добавляет еще один слайс из сценария использования 1 и первый слайс от сценария использования 2. Для создания третьей и четвертой частей добавляются дополнительные слайсы. Четвертый инкремент считается завершенным и достаточно полезным для реализации.

Рисунок 4. Сценарии использования, слайсы сценариев использования, инкременты и релизы

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

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

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

Принцип 6: Адаптировать под потребности команды

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

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

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

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

USE-CASE 2.0. Что такое сценарий использования 2.0?

Posted by Shamrai Alexander на Май 17, 2018

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

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

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

  • Легковесный
  • Масштабируемый
  • Универсальный
  • Простой в использовании

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

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

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

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

USE-CASE 2.0. Об этом руководстве

Posted by Shamrai Alexander на Май 16, 2018

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

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

Как читать это руководство

Руководство состоит из четырех основных глав:

  • Что такое сценарий использования 2.0? – одна страница введения в практику.
  • Базовые принципы – введение в сценарии использования, основанное вокруг 6-ти принципов, которые выступают в качестве основы для практики.
  • Сценарий использования 2.0 – содержимое – практика, представленная как набор ключевых концепций, деятельностей, рабочих продуктов и правил, которые связывают их вместе.
  • Использование сценариев использования 2.0 – резюме, когда и как применять практику.

Также есть краткое вступление, которое описывается этой главой, и короткое заключение.

Если вы новичок в теме сценариев использования, то вы можете прочитать главы «Что такое сценарий использования 2.0?», «Базовые принципы» и «Использование сценариев использования 2.0», чтобы понять основные концепции. Затем вы можете погрузиться в «Сценарий использования 2. 0 – содержимое» для понимания, как и когда вы начинаете применять практику.

Если вы знакомы с основами сценариев использования, то вы можете нырять прямо в главы «Сценарий использования 2. 0 – содержимое» и «Использование сценариев использования 2.0» после прочтения главы «Что такое сценарий использования 2.0?». Это поможет вам сравнить сценарий использования 2.0 с вашим собственным опытом и понять, что изменилось.

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

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

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

Posted by Shamrai Alexander на Декабрь 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 Shamrai Alexander на Ноябрь 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 Shamrai Alexander на Ноябрь 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 Shamrai Alexander на Июль 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 Shamrai Alexander на Июнь 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 Shamrai Alexander на Июнь 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 »

 
%d такие блоггеры, как: