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

— А вы уверены, что вы сможете сделать эти задачки? - спросил менеджер перед началом нового спринта у своей команды, в которой было 4 разработчика (включая меня) и 2 тестировщика. 

Ненавижу такие вопросы, обращенные к группе людей. Менеджер как бы перекладывает с себя ответственность на команду, мол если не сделаете - то сами виноваты, я же вас спрашивал… Да и как он ожидает получить ответ? Нам по порядку выстроившись в очередь отвечать? И дальше если большинство (типа у нас тут демократия, ага) скажет “Уверен”, то стартанем спринт, а если нет - то … то что? Уберем пару задачек, как делали в прошлый раз? Зато потом в середине спринта разработчики освободились и мы вкинули еще несколько тикетов в активный спринт. Джира в такие моменты даже показывает предупреждение: “Будьте аккуратны! Вы собираетесь вмешаться в скоуп спринта!” (да не такое, да, я в курсе, но похожее: “Sprint scope will be affected by this action.”)

— Скорость нашей команды - 100sp, а мы уже набрали задач на 150sp. Вы точно все успеете?

Повторил. Явно перекладывает с себя ответственность. 

… Прошло две недели …

— Итак, скорость нашей команды - 100sp по результатам статистики нескольких прошедших спринтов. Все время мы берем в спринт задач по сумме больше нашей скорости. И все время в конце спринта у нас остаются задачи, которые мы пообещали выдать, но не закончили работу над ними. Давайте подумаем, как мы можем сделать так, чтобы мы успевали выполнять все, что заявляем в начале спринта? - задал вопрос менеджер команде на ретро.

Казалось бы. Проанализируй задачи, что остались не выполненными, сделай самостоятельный вывод, подумай сам своей головой над возможным решением этой проблемы… В конце то концов, ты же ходишь на всей наши дейли! Ты же в курсе кто чем занят был! Ты же сам видел, как прошел наш 2-ух недельный спринт… Но нет. Все менеджеры не любят ничего делать своими руками? Все менеджеры любят делегировать?

Я уже думал над этой проблемой не один раз. Мы никогда не сможем закончить наш спринт так, чтобы brundown график оказался в нуле. И я не могу понять, почему менеджер не может это понять. Я попал в этот проект давно, еще задолго до того, как этот менеджер присоединился к нам. Я помню, как и раньше нам задавали эти вопросы другие руководители… Но знаете, чего я не могу вспомнить? Вы не поймите неправильно, я пытаюсь, отчаянно ищу воспоминания, но не нахожу их… Воспоминания о том, как менеджер хотя бы один раз предложил самостоятельно решение этой проблемы.

— Окей. У меня есть доказательство того, что мы всегда будем видеть Committed > Completed в конце спринта. - сказал я. О, я уверен в том, что говорю. Такое бывает редко, обычно я сомневаюсь. Но сейчас, без всякого сомнения, я готов предоставить свои изъяснения на суд… на суд кого? Менеджера, который не заслужил уважения? Нет, на суд коллег. С ними мы на равных, а поэтому их мнение стоит очень дорого.

— Всегда? - с усмешкой переспросил менеджер.

Его здесь не было год назад, и два, и три. “Всегда?” - да что он хочет этим сказать?! Эта проблема не решается уже 4 года. И это только в этом проекте. У меня были и другие проекты с Agile, и этими графиками в джире. И было все то же самое. Может быть раньше я не придавал этому значения, потому что был слишком мал. А может быть потому, что не боялся менять проекты. “Всегда?” - как будто он знает, как будто он видел другие команды без этих проблем, но не хочет нам о них рассказывать. Как добрый папочка, который хочет, чтобы его ребенок самостоятельно на своих ошибках нашел правильный путь.

— Всегда. Я докажу.

Представим, что у нас есть команда из 1 разработчика и 1 тестировщика. Разработчик может выполнить 6 sp за спринт, а тестировщик — 4 sp. У нас будут двухнедельные спринты. Каждая задача должны быть сначала сделана разработчиком, а затем протестирована. Только после этого результат можно отдавать клиенту. Предположим, что это первый спринт в проекте. Давайте посмотрим, как он пройдет.

1-й спринт

Разработчик получил две задачи по 5 sp (Dev 3 sp (это значит, что на разработку в этой задаче отведено 3 стори поинта) + QA 2 sp (а на тестирование 2 стори поинта)). Committed = 10 sp. 

Первый понедельник: разработчик начинает работать над задачей 1. 

Конец первой пятницы: разработчик передал задачу 1 на тестирование. 

Второй понедельник: разработчик начинает работать над задачей 2, тестировщик начинает проверять задачу 1. 

Конец второй пятницы: разработчик передал задачу 2 на тестирование, тестировщик закрыл задачу 1. 

В конце первого спринта у нас есть 1 незакрытая задача: задача 2. Она готова полностью разработана, но еще не протестирована. Скорость команды по диаграмме в Jira: 5 sp (Committed SP = 10 sp, Completed SP = 5 sp).

2-й спринт 

Разработчик получил две задачи по 5 sp (Dev 3 sp + QA 2 sp), а также у нас есть задача 2, которую надо протестировать. Итак, Committed = 15 sp (Задача 2 (старая) + Задача 3 (новая) + Задача 4 (новая)). 

Первый понедельник: разработчик начинает работать над задачей 3, тестировщик начинает проверять задачу 2.

Конец первой пятницы: разработчик передал задачу 3 на тестирование, тестировщик закрыл задачу 2. 

Второй понедельник: разработчик начинает работать над задачей 4, тестировщик начинает проверять задачу 3. 

Конец второй пятницы: разработчик передал задачу 4 на тестирование, тестировщик закрыл задачу 3. 

В конце второго спринта у нас есть 1 незакрытая задача: задача 4. Скорость команды по диаграмме Jira: 10 sp (Заданные SP = 15 sp, Завершенные SP = 10 sp).

n-й спринт

То же самое, что и 2-й спринт. 

Таким образом, у нас всегда будет Committed > Completed. То есть тестировщик всегда будет не успевать протестировать то, что разработчик закончил разрабатывать в конце недели.

Единственное, о чем мы можем здесь поговорить, это насколько велика разница между Committed и Completed. Если мы попробуем разбить задачу 5 sp на две разные задачи по 2.5 sp и возьмем в спринт 4 задачи вместо двух, мы можем получить другой результат. Давайте посмотрим:

4 задачи по 2.5 sp (Dev 1.5 sp + QA 1 sp). Если вы выполните расчеты, как в примере выше, то в конце n-го спринта получите: Committed = 12.5 sp, Completed = 10 sp. Мы уменьшили разницу между Committed и Completed просто используя декомпозицию.

Затем мы можем попробовать декомпозировать еще сильнее: 8 задач по 1.25 sp (Dev 0.75 sp + QA 0.5 sp). В n-м спринте: Committed = 11.25 sp, Completed = 10 sp. Думаю, вы поняли суть. 

Committed никогда не может быть равен Completed, но он может приблизиться к нему, если мы будем очень сильно декомпозировать наши задачи.

— Так получается потому, что ваши процессы - это Waterfall обернутый в спринты. - резко отрезал менеджер. — Все, что нам нужно сделать, это попросить разработчиков тестировать свои задачи.

Попросить разработчиков тестировать свои задачи… Я это уже слышал. Это не просто маленький штрих в наших процессах. Это полностью новый процесс. Зачем нам тогда вообще в таком случае тестировщики? Надо чтобы все были “универсальными” в команде. И это то, о чем мы сами должны были додуматься и предложить на ретро? Можно ли вообще такие вопросы на ретро обсуждать? … Предположим, что он имел ввиду что-то другое… Скажем, он имел ввиду, что надо просто разработчикам писать больше интеграционных и автоматических тестов, performance тестов. Ух, как же в таком случае увеличится стоимость поддержки этого добра. У нас уже автотесты запускаются по 4-5 часов. И это немного тестов там еще написано. А чего только стоит разбирать в ручную flaky падения в этом ворохе логов? Исходному коду уже почти 10 лет… Технического долга я надекомпозировал на 3 человеко года, и это только поверхностный взгляд и очень приблизительная оценка. Автотесты нужно оптимизировать, потому что они были написаны не девелоперами, и там просто гектары возможностей для улучшений. И мы все это знаем, просто нам не дают ресурсов этим заниматься. Надо фичи пилить. И если вдруг мы решим вкладываться в расширение автотестов и интеграционных тестов, то скорость разработки упадет очень сильно. Неужели он этого не понимает?

— Что, если разработчики не захотят заниматься тестированием? - спросил я, ведь я знаю, что коллеги меня поддержат в этом вопросе. Никто из разработчиков не захотел бы заниматься ручным тестированием. Не потому, что “не барское это дело”, вовсе нет. Потому что у тестировщиков есть свои процессы, свои инструменты, свои метрики и подходы. Этому нужно учиться, на это нужно тратить время. Да и плюс никуда не делось то, что давно стоит во главе этого разделения: тестировщики должны разрушать, а разработчики строить. На этом конфликте рождается софт. Если поместить этот конфликт в одну голову, то в лучшем случае мы получим некачественный продукт, а в худшем - уничтоженную мотивацию.

— Конечно, разработчики не хотят тестировать. Нам нужно попросить их делать то, что они так хорошо умеют - писать код. Писать автотесты! Да, не все может быть автоматизировано, но то, что можно - надо автоматизировать. Тогда в конце спринта разработчик будет заканчивать писать автотесты, и тестировщик дотестирует ручные задачи. Committed будет равен Completed.

Да, я предполагал этот ответ. Я хотел продолжить дискуссию, но вдруг подумал: почему это вообще проблема, что Committed больше Completed? Мы делаем фичи в продукте спринт за спринтом. Улучшаем его, добавляем что-то новое. Команда не стоит на месте. 100 sp в две недели это вобще-то показатель. Его можно использовать при планировании. Но почему мы обязаны в конце спринта сдавать все, с чем спринт начали?

— Хорошо, давайте делать так, вы правы, - я не стал дальше спорить. Потому что понял, что следующие 4 года в проекте менеджеры продолжат задавать все тот же вопрос: «Почему Committed > Completed в ваших спринтах?»