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

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

СКАЧАТЬ «спроектированное» – то есть для функции разработана 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 года)

СКАЧАТЬ