Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

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

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

Сокращение объема незаконченного проектирования существенно повышает качество программ.

В 2004 году я работал с двумя командами в Motorola. Обе они разрабатывали сетевую часть бэкэнд-приложения для мобильных телефонов. Одна команда работала над сервером для «скачивания по воздуху» (over-the-air, OTA) рингтонов, игр и других приложений и данных. Вторая разрабатывала сервер для управления устройствами «по воздуху» (OTA DM). Обе команды руководствовались методологией Feature Driven Development (FDD). Обе были примерно одного размера – человек восемь разработчиков, один архитектор, до пяти тестировщиков и менеджер проекта. Работая совместно с маркетологами, команды сами проводили анализ и проектирование. Обеим командам помогали отдельные команды проектирования пользовательского взаимодействия (UX) и разработки пользовательской документации (технические писатели).

На рис. 3.1 демонстрируется кумулятивная диаграмма потока для команды, занимавшейся закачкой ОТА. Кумулятивная диаграмма потока – это зонированный график, который отражает объем работы в определенном состоянии. Состояния, показанные на диаграмме, – это бэклог, то есть объем работы, который заведен в учетную систему, но очередь до него еще не дошла. «Начатое» – это когда требования к функционалу обсуждались с разработчиками; «спроектированное» – то есть для функции разработана ML-диаграмма последовательности; «разработанное» – то есть функционал разработан в соответствии с диаграммой последовательности; «завершенное» – то есть все модульные тестирования пройдены, код прошел рецензирование и был принят ведущими разработчиками и передан на тестирование.

.

Рис. 3.1. Кумулятивная диаграмма потока (КДП) команды закачек OTA (осень 2003 – зима 2004 гг.)

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

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

Команде сервера закачек ОТА не хватало либо дисциплины, либо мотивации для использования метода FDD. Они не работали совместно, как требует FDD, а выдавали большие порции функций на откуп индивидуальным разработчикам. Обычно на одного разработчика у них в любое время приходилось до десяти функций. А команда по разработке OTA DM следовала методам, изложенным в учебнике. Они хорошо работали в сотрудничестве и разрабатывали модульные тесты для 100 % своих функций. И самое важное – они трудились над небольшим количеством функций одновременно, обычно это было 5–10 функций в работе для всей команды в любой момент.

Целевым ориентиром для функции в FDD является 1,6–2,0 функционального очка кода.

У команды по разработке сервера закачек OTA, находившейся в Сиэтле, среднее время выполнения составляло примерно три месяца на функцию от начала работы до сдачи ее для интеграционного теста команде из Шампейна ( рис. 3.1).

У команды по разработке OTA DM среднее время выполнения колебалось от 5 до 10 дней, что показано на рис. 3.2. Разница в исходном качестве, измеряемом в количестве ошибок в системном или интеграционном тесте, превысила 30 раз. Команда по разработке OTA DM продемонстрировала изначальное качество на уровне лидеров индустрии – две или три ошибки на 100 функций, а команда по разработке сервера закачек OTA продемонстрировала средний по индустрии результат – около двух ошибок на функцию.

Рис. 3.2. Кумулятивная диаграмма потока (КДП) команды управления устройствами OTA (зима 2004 года)

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