Гибкое управление проектами и продуктами

Управление продуктами

Для масштабирования деятельности продуктовых команд владельцы продуктов (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» авторы обозначили восьмой вид потерь: нереализованный творческий потенциал сотрудников.

Традиционно выделяют также еще два вида потерь:

• му́ри (перегрузка);

• му́ра (неравномерность).

Инструменты бережливого производства. Бережливое производство ПО

Принципы бережливого производства можно применить и в разработке программного обеспечения.

Уменьшение потерь. Видов потерь в разработке программного обеспечения достаточно много: от переключения между задачами до реализации лишнего функционала. Помните правило 20/80: 20 % функционала продукта приносят 80 % ценности заказчику, и именно гибкие методологии позволяют эти 20 % функционала выявить и назначить им максимальную важность.

Фокусировка на обучении. Весь процесс создания программного обеспечения фактически состоит из обучения: с каждой новой функцией мы узнаем что-то новое, поэтому, как и для любой другой инженерной деятельности, следует сосредотачиваться на обучении.

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

 Позднее принятие решений. Очень важно принимать решения как можно позже. Самым ярким примером здесь является создание архитектуры приложения. В противоположность подходу Big Up Front Design мы создаем архитектуру только для текущего функционала, следуя принципам KISS и YAGNI.

 Быстрая поставка. Бережливое производство ПО предполагает максимально быстрые и частые поставки для получения обратной связи.

 Уважение к людям. Люди – это основа любой мыслительной деятельности, к которой, несомненно, относится разработка ПО. Мы должны уважительно относиться к командам, предоставляя им максимум полномочий и ответственности.

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

Производственная система «Тойоты» (Toyota Production System, TPS)

Ниже приведены 14 принципов TPS.

1. Философия долгосрочной перспективы: можно пойти на убытки для достижения отдаленной цели.

2. Производственный поток должен быть непрерывным.

3. Канбан: производство по системе «точно вовремя» без промежуточных запасов.

4. Хейдзунка: равномерное распределение нагрузки на всех этапах технологического процесса.

5. Андон и дзидока: автоматическая остановка производства с целью решения проблем.

6. Формализация накопленных знаний: достигнутое нужно делать новым стандартом.

7. Визуальный контроль: иногда простая лампочка эффективнее компьютерного монитора.

8. Внедрять только проверенные технологии.

9. Воспитывать собственных лидеров, искренне исповедующих философию компании.

10. Формировать и воспитывать рабочие команды, в которых каждый искренне исповедует философию компании.

11. Уважать и развивать партнеров-поставщиков.

12. Генти гаубицу: перед тем как начать разбираться в ситуации, увидеть все своими глазами.

13. Немаваси: принимать коллективные решения только после согласия большинства, но внедрять немедленно.