Гибкое управление проектами и продуктами - Борис Вольфсон

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

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

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

Таблица 6.1.

Оценка вероятности и рисков

Безусловно, максимум внимания необходимо уделить «красным» рискам: мало того, что они наиболее вероятны, ущерб от них обещает быть максимальным.

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

Что касается Lessons Learned, для этого идеально подходит ретроспектива. Только замечу, что эти уроки и лучшие практики также необходимо распространять между командами, например на Scrum of Scrum.

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

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

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

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

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

Цикл разработки в рамках TDD

Такой подход называется разработкой через тестирование или разработкой через тесты (Test Driven Development). Процесс работы разбивается на три этапа:

• красный – пишем неработающий тест;

• зеленый – минимальными усилиями заставляем тест работать;

• рефакторинг – устраняем дублирования и приводим код в порядок.

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

Схема для выбора кода

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

Лия Шабакаева, разработчик

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

• Алгоритмы – это код, реализующий разного рода алгоритмы и бизнес-логику. Он достаточно независим от других частей, и тестировать его необходимо максимально тщательно.

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

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

В рамках TDD используется следующая практика из экстремального программирования – рефакторинг.

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

Структура процесса рефакторинга

При парном программировании код пишется двумя разработчиками за одним компьютером, причем один из разработчиков играет роль «пилота», а второй – «штурмана».

Роли разработчиков при работе в паре

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

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

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