Швабера вообще стоит читать, если есть интерес к применению Scrum, потому что, во-первых, он один из основателей Agile Alliance, а во-вторых один из двух авторов теоретики по процессу Scrum. То есть, он знает о чём говорит и то, что он говорит это не секонд хенд, а сведения из первоисточника.

Возвращаясь к книге. Она оказалась и интересной и полезной, но первичных ожиданий не оправдала. По названию я ожидал, что основное содержание будет составлено из описания практик того, как нужно управлять проектами по Scrum. Оказалось же, что Кен Швабер написал не о теоретических подходах, а чисто о случаях практического применения(упрощая – дал кейсы на разные ситуации). Но важнее оказалось то, что описывал он эти случаи с подходом людей на разных ролях, иногда в одной и той же ситуации, а иногда на протяжении длительного времени. Вот так и получилось, что ожидания не оправдались, но при этом материал оказался крайне полезным. Хотя больше она понравится менеджерам, чем рядовым программистам, тестировщикам и прочим участникам разработки.

Книга разбита на девять слабо связанных частей, а каждой рассматривается по несколько случаев, которые, по идее, должны дать общее представление об основных проблемах, методах их решения и о том, как вообще не допускать описанных ситуаций. Сами случаи показаны так, как видел их сам Кен и обычно разбиты на три части: исходная ситуация до введения Scrum, либо в самом начале его применения; описание появившейся проблемы; описание вынесенных уроков из ситуации и необходимые решения для устранения проблем (Lessons Learned). Очень хорошо и подробно описана работа в условиях одной команды, причем как в случае, когда начинался новый проект, так и при переводе существующего проекта на Scrum. Применение Scrum в случае, когда задействовано много команда (Scaling Scrum) описано явно недостаточно. При этом Кем в явном виде указывает на то, что расширение Scrum на несколько групп вполне осуществимо, но при это придётся сделать финт ушами.

В конце книги Кен поместил список правил, которым стоит следовать при работе в условиях Scrum. Если же не следовать этому компактному списку правил, то на правильно работающий процесс рассчитывать не стоит.

Я уверен, что не я один участвовал в подобном процессе, мы материли “Scrum мастера” за то, что он ничего не знает, а время митинга растягивается минимум на час. Большую часть которого две трети участников спят, ковыряют столы, стулья и носы, звонят по телефону, обсуждают вчерашний футбол, сидят с хмурыми мордами лицами. После митинга никто не помнил о чем договорились, да и вообще, договорились ли?! Но ведь что то обсуждали, но что же решили? Никто не помнил. “Scrum мастер” писал письмо руководству о прогрессе в разработке, выражая его в процентах

Мы готовы к завоеванию мира на 90%!

Эта версия лучше на 45%!

Ваши ресницы будут длиннее на 63.3% если вы попали в 34 и 5 десятых процента белокожих женщин с карими глазами и родинкой на животе!

Да брехня это всё, виртуально. А мы реальны. Мы понимали, что это чушь, что нам это чуждо и не нужно. Естественно всё умерло и с каждым релизом выяснялось, что забыли что-нибудь положить в CVS, сделали изменения в зависимых модулях и забыли известить зависимых. В тестировании тоже всё было не слишком гладко, даже налаженные горизонтально-вертикально-поперечные связи давали сбои и какие то очевидные ошибки оставались незамеченными.

Так что необходимость митингов как была так и осталась. Я решил следовать довольно простой схеме. В моей команде люди разбиты по своим проектам и…

Тогда, еще два года назад, “Scrum мастер” сделал главную ошибку, которой сейчас пытаюсь избежать я – он взял всех лидов и разработчиков по всем направлениям и посадил в одну комнату с целью у каждого узнать “как дела”. Направления, хоть и представляли собой единую платформу, но всё-таки были довольно самостоятельными и по большому счёту были связаны вместе только базой. Это примерно как, если бы вы ходили каждый день в один и тот же бар и слушали бы как бармен рассказывал как сложно достать сейчас бренди, хотя вам всё равно есть бренди или нет.

…я решил митинговать с каждой командой отдельно (привет, велосипед). На каждую встречу не более 15 минут, во время митинга поднимаются только три темы: что не получилось сделать из запланированного вчера, какие проблемы мешают, что делаем сегодня. И так изо дня в день, пока эти маленькие сообщества не научатся четко говорить о проблемах и понимать свою работу, а я вместе с ними не пойму в деталях что происходит. После этого можно будет перейти к тому, чтобы митинговать со связанными командами. Делать это каждый день уже нет смысла, потому что группы нужно связывать только, когда релиз одного из компонент сильно затрагивает другие.

За разными командами тестировщиков стоят не только разные продукты или компоненты, но и разные команды разработчиков. А это люди! Каждый со своими тараканами и подходами к работе, которые могут упростить жизнь релизу или усложнить.

Был у нас очень интересный разработчик. Он разрабатывал один компонент системы…  в течение двух лет! И когда проект был на этапе завершения оказалось, что он не совместим с платформой немного (ну это ладно). В добавок после его добавления в систему дороги назад уже не было – обратной совместимости продумано не было. С одной стороны очень плохо, разработчик чудовище. С другой мы избавились от многоярусной поддержки целого семейства старого кода.

На третьем шаге собираем всех тестировщиков вместе. Это не может быть частое явление, на мой взгляд. Но почему бы не сделать так раз в месяц, для того чтобы не было вопросов кто и чем занимается. Это сыграет свою роль, обязательно. Когда это произойдёт нельзя будет сказать – “Вот он! Это потому что два месяца назад они были на митинге”, но при проблемах всегда найдется падла зараза, которая скажет “Это потому что митингов не было” и будет права.

С каждым шагом мы приближаемся к тому, чтобы повысить обмен информацией между тестировщиками. Это отлично, но не достаточно. После того как это свершилось надо двигаться в девелопмент и в добавок к личным горизонтальным связям добавлять еще качественно зрелый обмен информацией между разработчиками и разработчиками и тестировщиками. Так очень много глупостей и сложностей можно устранить.

Заинтересованные в релизе группы людей

Список вопросов неполный, но QA должны знать ответы хотя бы на них. Для этого, в первую очередь, потребуется отслеживать выполнение задач по разработке и тестированию. Существование трекера первый шаг к построению нормальной информационной системы.
Подойдет любая система трекинга, в которой можно реализовать такую структуру (я предпочитаю Atlassian Jira, для небольших проектов Eventum):

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

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

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

Принципиальная схема процесса при такой структуре проектов выглядит так:

Потоки информации между проектами

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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