Владелец продукта (PO) не является членом команды в прямом смысле этого слова, но ставит команде цели с помощью требований в журнале пожеланий (BL).
Состав Scrum-команды
Координация деятельности происходит ежедневно на скрам-митинге, который проводит скрам-мастер и в котором участвует вся команда. Основная цель скрам-митинга – координация работы команды на уровне отдельных историй пользователя.
Масштабирование Scrum
Небольшие команды чаще показывают хорошие результаты, чем большие, поэтому необходимо по возможности вести разработку компактными командами. К сожалению, часто бывает, что объем проекта и сроки его реализации просто не позволяют вести разработку 5–9 людьми и приходится задействовать несколько команд.
Привлечение нескольких команд
Для организации разработки больших проектов или портфеля проектов необходимо масштабировать Scrum на следующий уровень. Со стороны команд разработки это выливается в проведение Scrum of Scrum.
На этот митинг собираются скрам-мастера (SM) в качестве представителей конкретных команд. Организует собрание руководитель программы (Program Manager, PM). При использовании дивизионной организационной структуры на данном уровне он также может являться руководителем соответствующего дивизиона (подразделения).
В качестве базовой структуры митинга можно предложить каждому скрам-мастеру ответить на следующие вопросы.
1. Что было сделано с прошлого Scrum of Scrum?
2. Какие были проблемы?
3. Что будет сделано к следующему Scrum of Scrum?
При этом акцент нужно сделать на проблемах, которые команда не может решить сама и вынуждена передавать выше.
Scrum of Scrum of Scrum
Следующим уровнем масштабирования является Scrum of Scrum of Scrum. Для осуществления этого проводится соответствующее мероприятие, на которое собираются менеджеры программ и топ-менеджер (обычно технический директор подразделения).
Обсуждение на данном уровне ведется в масштабе спринтов и релизов. Из проблем обсуждаются только самые крупные.
Scrum of Scrum of Scrum
Очень удобно использовать данное мероприятие для финального обсуждения и принятия производственных стандартов.
Управление продуктами
Для масштабирования деятельности продуктовых команд владельцы продуктов (Product Owner, PO) проводят Meta Scrum под руководством главного владельца продукта (Chief Product Owner).
Meta Scrum
Обсуждение требований происходит на уровне журналов пожеланий (BL) спринтов, а не отдельных историй пользователей. Соответственно определяются и высокоуровневые приоритеты.
На данном уровне можно рассмотреть также журнал пожеланий программы (Program Backlog, PBL). Он может быть как реальным, так и виртуальным (также возможны сочетания обоих подходов). Реальный журнал пожеланий программы получается при реализации большого проекта несколькими командами, а виртуальный – при выполнении множества независимых проектов.
Meta Scrum, рассмотрение журнала пожеланий программы
Scrum на уровне предприятия
Если объединить продуктовую и производственную схему масштабирования, то получится полноценная схема масштабирования Scrum на уровне предприятия.
Актуализация журналов пожеланий
Распределенный Scrum
Следует отметить, что вышеописанные схемы подходят для организации распределенной разработки. Для этого необходимо ввести региональные дивизионы и закрепить за ними руководителя программы и главного владельца продукта.
Распределенный Scrum
Глава 10. Контроль и обеспечение качества
Интеграция контроля и обеспечения качества в Scrum
В гибких методологиях за обеспечение качества отвечает вся команда, но большая часть работы, безусловно, ложится на тестировщиков, хотя их роль изменяется по сравнению с классическим подходом. У тестировщиков в Scrum есть две основные функции:
• регрессионное тестирование функционала с предыдущих спринтов;
• приемочное тестирование спринтов и релизов.
Обычно функционал растет очень быстро, и проекты испытывают острый недостаток в тестировщиках, поэтому для регрессионного тестирования необходимо применять автоматические тесты. Даже при достаточном количестве тестировщиков они не смогут вручную тестировать регрессию по все возрастающему количеству функционала продукта.
Это же касается тестирования функционала очередного спринта, иначе вы рискуете попасть в «регрессионную спираль смерти», но его можно разбавить и ручным тестированием.
Структура спринта для тестировщиков
В рамках спринта у тестировщиков есть пять основных активностей:
• планирование итерации;
• автоматизация приемочного тестирования;
• тестирование историй пользователей;
• регрессионное тестирование;
• демонстрация.
Активности тестировщиков
Тестировщики должны участвовать вместе с командой в планировании спринта и оценке задач. Необходимо, чтобы к старту спринта тестировщики четко понимали суть и рамки каждой задачи. При наличии времени можно составить краткие сценарии тестирования историй пользователей, которые затем превратятся в автоматические тесты.
На этапе приемочного тестирования прорабатываются автоматические тесты для документирования нового функционала. Такой подход используется прежде всего в разработке через тестирование, где тесты пишутся до кода, который они проверяют. Затем на этапе тестирования историй пользователя пишется большее количество автоматических тестов.
К концу спринта выполняется регрессионное тестирование, чтобы убедиться, что добавленный новый функционал не внес ошибки в старый. В завершение спринта происходит демонстрация и ретроспектива. На ретроспективе тестировщик должен озвучить параметры качества, которых достигла команда в текущем спринте, и обсудить наиболее неприятные и критические дефекты.
Сколько необходимо тестировщиков
Многие профессионалы в нашей отрасли считают, что делать программы без дефектов невозможно. С этим сложно спорить, ведь зачастую в командах тестировщиков больше, чем разработчиков.
23 августа 2010 года на сайте habrahabr.ru среди 1835 человек, из которых 551 воздержался, был проведен опрос по соотношению количества разработчиков и тестировщиков. Следует отметить, что на сайте достаточно много представителей небольших компаний/веб-студий и фрилансеров, но общая картина все равно ясна.
Количество тестировщиков определяется многими факторами:
• количеством разработчиков;
• наличием автоматических приемочных тестов;
• наличием практики написания модульных тестов разработчиками;
• общим качеством продукта.
Результаты опроса
На диаграмме видно, что в большинстве случаев тестировщиков в той или иной мере не хватает, поэтому их работу необходимо максимально автоматизировать, чтобы на выполнение тестов уходило минимум ручного труда.
Глава 11. Бережливое производство
Бережливое производство пришло к нам из США. Фактически бережливое производство – это осмысление производственной системы Toyota американскими учеными. Бережливой такую систему организации труда называют, потому что она нацелена на сокращение издержек в виде потерь производства (вообще это достаточно узкий взгляд на данную систему).
Основателем производственной системы Toyota был Тайити Оно, который еще в послевоенное время сделал первые попытки оптимизации производства. Его компания была вынуждена конкурировать с такими гигантами, как Ford, которые за счет эффекта масштаба производства имели достаточно низкую себестоимость произведенных автомобилей.
Ценность – основа бережливого производства
Чтобы понять концепцию бережливого производства, нужно представлять, что такое ценность для потребителя. Ценность – это преимущества, которые потребитель получит от использования вашего продукта или услуги. Бережливое производство расценивает все, что не добавляет ценности продукту, потерями, которые на японском языке называются муда. Основой бережливого производства как раз и является устранение муды.
Виды потерь
Классически выделяются семь видов потерь:
• перепроизводство;
• ожидание;
• ненужная транспортировка;
• лишние этапы обработки;
• лишние запасы;
• ненужные перемещения;
• дефекты.
В самой популярной книге о производственной системе Toyota «Дао Toyota» авторы обозначили восьмой вид потерь: нереализованный творческий потенциал сотрудников.
