работы осталось выполнить для завершения итерации. На таком графике оставшийся объем работы отражается либо в баллах, либо в часах, в зависимости от выбранной единицы измерения. На Рисунке 12.3 показан пример дневного графика выполнения скрипта, где по горизонтальной оси указаны дни спринта, а по вертикальной – количество оставшихся до завершения баллов истории. График берет свое начало в «нулевой день» спринта с количеством не отработанных баллов, равным, в данном случае, 45. На горизонтальной оси отложены 10 дней, что соответствует двухнедельному спринту (учитываются только рабочие дни). В идеале, в конце спринта количество не отработанных баллов должно равняться нулю.
Тестирование качества проводится во время спринта. Чтобы добиться более высокой скорости разработки, члены команды должны тестировать истории сразу после их реализации. Если отработанная история соответствует критериям приемлемости, она считается завершенной; в противном случае она отклоняется и возвращается в разработку. Необходимо также предусмотреть в конце спринта время на тестирование результатов разработки и исправление возможных ошибок. Далее в этой главе мы рассмотрим тему тестирования более подробно.
Рисунок 12.3. График выполнения спринта
Цель, которая должна достигаться в конце каждого спринта, состоит в «приращении» функциональности продукта. Руководство по Scrum предписывает командам определять, что именно в их случае будет подразумеваться под статусом «Готово». Многие команды понимают под готовностью так называемый «выпущенный продукт» или «потенциально выпущенный продукт». Во многих случаях количество выпусков продукта соответствует количеству итераций, когда результаты спринта представляются клиентам вскоре после завершения спринта. Другие разработчики организуют более длительные циклы, когда выпуск продукта происходит по результатам нескольких спринтов. В любом случае цель состоит в том, чтобы к окончанию спринта обеспечить готовность продукта к выпуску. По завершении каждого спринта члены команда проводят обзорное совещание по спринту (также называемое демонстрационным совещанием), на котором они показывают результаты своей работы. Это позволяет гарантировать, что продукт работает должным образом, и делает прогресс команды более заметным. В идеале для участия в таких совещаниях приглашаются клиенты или иные заинтересованные лица, чтобы они могли оставить свои отзывы, которые будут учтены при проведении последующих спринтов.
Как и другие Agile-методологии, Scrum фокусируется на последовательном улучшении рабочих процессов. Для достижения этой цели команды проводят ретроспективы, в ходе которых обсуждают, как прошел их последний спринт, что сработало хорошо, что пошло не так, и какие улучшения стоит внедрить при проведении следующего спринта. Некоторые команды проводят такие обсуждения после каждого спринта; другие делают это по итогам двух или трех спринтов.
Это был лишь краткий обзор методологии Scrum – если вы хотите узнать о ней больше, ознакомьтесь с последней версией руководства по Scrum по ссылке: http://scrumguides.org.
Канбан
Другой популярной разновидностью Agile-разработки является Канбан – процесс, созданный на основе системы, разработанной автоконцерном Toyota для улучшения сборки автомобилей. Система Toyota ориентирована на производство по принципу «точно в срок» и ликвидацию отходов (издержек). Я изучал оригинальную систему Канбан и принципы бережливого производства во время обучения в аспирантуре Технологического института Вирджинии.
На производстве работники используют бумажные карточки – «канбан» – в качестве сигналов, передаваемых на предыдущий этап процесса, о необходимости пополнения запасов (заготовок). Канбан был адаптирован для целей разработки программного обеспечения с применением виртуальных карточек, каждая из которых представляет находящееся в работе задание, но при этом уже не выполняет сигнальной функции. Основным принципом Канбана является визуализация рабочего процесса. Каждая карточка представляет собой историю пользователя или относящееся к ней задание для разработки. Карточки помещают на специальную канбан-доску, состоящую из набора столбцов, каждый из которых соответствует определенной стадии рабочего процесса. Столбцы расположены слева направо в том порядке, в котором выполняется работа. Пример канбан-доски приведен на Рисунке 12.4. Здесь вы можете видеть следующий набор столбцов (стадий рабочего процесса) слева направо: «Бэклог», «Подготовлено», «В процессе разработки», «Разработка завершена», «В процессе тестирования», «Тестирование завершено» и «Выпуск», которые определяются следующим образом:
• Бэклог: рабочие задания, которые членам команды предстоит взять в работу, отсортированные по приоритетности.
• Подготовлено: задания, которые были взяты из бэклога, и готовы к передаче в разработку.
• В процессе разработки: задания, разработка которых происходит в данный момент.
• Разработка завершена: задания, прошедшие этап разработки, но еще не переданные на тестирование.
• В процессе тестирования: задания, находящиеся в процессе тестирования.
• Тестирование завершено: задания, которые успешно прошли тестирование, но еще не были выпущены.
• Выпуск: задания, которые были выпущены после их разработки и тестирования.
Некоторые столбцы канбан-доски представляют выполняемую работу (например, «В процессе разработки», «В процессе тестирования»), в то время как другие обозначают стадии ожидания обработки (например, «Подготовлено», «Завершено»). Столбцы последнего типа дают представление о состоянии очереди на выполнение работ. Когда член команды завершает работу над одним заданием, он берет верхнюю карточку следующего задания из тех, что находятся в соответствующей очереди, и начинает работать над ним.
Рисунок 12.4. Пример канбан-доски
По мере прохождения рабочего процесса карточка задания перемещается из одного столбца в следующий – слева направо. Благодаря такой визуализации, чтобы понять, над чем работает команда в любой момент времени, достаточно просто взглянуть на доску. По количеству карточек, скопившихся в том или ином столбце, легко определить узкие места рабочего процесса.
Возможно, вы заметили, что каждый из столбцов «Разработка» и «Тестирование» на Рисунке 12.4 разделен на два подраздела: один из которых обозначает нахождение задания в процессе работы, а другой соответствует завершенному состоянию. Это позволяет составить более четкое представление о текущем рабочем процессе и его узких местах.
В Канбане количество заданий, находящихся в активном состоянии, регулируется путем ограничения объема «незавершенных процессов» или сокращенно – НЗП. Команда определяет максимальное количество карточек, которое может накапливаться в каждом столбце, что представляет собой лимит НЗП. Члены команды последовательно перемещают карточки заданий между этапами работы. Однако они могут перенести карточку в следующий столбец только в том случае, если там имеется свободное место (то есть лимит карточек, находящихся в следующем столбце, еще не исчерпан). Это правило помогает выровнять процессы обработки и добиться стабильного рабочего потока. Командам предписано периодически корректировать установленные лимиты НЗП в целях оптимизации рабочего процесса. На канбан-доске размер лимита НЗП указывается над каждым столбцом. Как показано на Рисунке 12.4, команды часто используют единый лимит НЗП для связанных стадий одного этапа – «В процессе» и «Завершено». Например, общее количество карточек в столбце «Разработка» (включая обе его стадии: «В процессе» и «Завершено») не может быть больше трех. Это помогает стимулировать более быстрое продвижение карточек, находящихся в ожидания
