Читать онлайн «Гибкое управление проектами и продуктами». Страница 11

Глава 7. Инженерные практики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы и минусы гибкого анализа требований

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

Функции владельца продукта

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

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

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

• UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность;

• UML-диаграммы быстро теряют актуальность при начале разработки;

• UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга;

• UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста;

• UML неявно подразумевает водопадную модель разработки.

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

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

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

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

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