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

Обсуждение требований происходит на уровне журналов пожеланий (BL) спринтов, а не отдельных историй пользователей. Соответственно определяются и высокоуровневые приоритеты.

На данном уровне можно рассмотреть также журнал пожеланий программы (Program Backlog, PBL). Он может быть как реальным, так и виртуальным (также возможны сочетания обоих подходов). Реальный журнал пожеланий программы получается при реализации большого проекта несколькими командами, а виртуальный – при выполнении множества независимых проектов.

Meta Scrum, рассмотрение журнала пожеланий программы

Если объединить продуктовую и производственную схему масштабирования, то получится полноценная схема масштабирования Scrum на уровне предприятия.

Актуализация журналов пожеланий

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

Распределенный Scrum

В гибких методологиях за обеспечение качества отвечает вся команда, но большая часть работы, безусловно, ложится на тестировщиков, хотя их роль изменяется по сравнению с классическим подходом. У тестировщиков в Scrum есть две основные функции:

• регрессионное тестирование функционала с предыдущих спринтов;

• приемочное тестирование спринтов и релизов.

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

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

В рамках спринта у тестировщиков есть пять основных активностей:

• планирование итерации;

• автоматизация приемочного тестирования;

• тестирование историй пользователей;

• регрессионное тестирование;

• демонстрация.

Активности тестировщиков

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

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

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

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

23 августа 2010 года на сайте habrahabr.ru среди 1835 человек, из которых 551 воздержался, был проведен опрос по соотношению количества разработчиков и тестировщиков. Следует отметить, что на сайте достаточно много представителей небольших компаний/веб-студий и фрилансеров, но общая картина все равно ясна.

Количество тестировщиков определяется многими факторами:

• количеством разработчиков;

• наличием автоматических приемочных тестов;

• наличием практики написания модульных тестов разработчиками;

• общим качеством продукта.

Результаты опроса

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

Бережливое производство пришло к нам из США. Фактически бережливое производство – это осмысление производственной системы Toyota американскими учеными. Бережливой такую систему организации труда называют, потому что она нацелена на сокращение издержек в виде потерь производства (вообще это достаточно узкий взгляд на данную систему).

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

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

Классически выделяются семь видов потерь:

• перепроизводство;

• ожидание;

• ненужная транспортировка;

• лишние этапы обработки;

• лишние запасы;

• ненужные перемещения;

• дефекты.

В самой популярной книге о производственной системе Toyota «Дао Toyota» авторы обозначили восьмой вид потерь: нереализованный творческий потенциал сотрудников.