Carlton Nettleton — President at Look Forward Consulting, experienced Agile consultant

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

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

Моим первым ответом было: «Нет, эта работа уже распланирована, поэтому команда может взять новые задачи, которые следует обязательно завершить к концу спринта». Ей по-прежнему было сложно разобраться в тонкостях концепции, пока я не набросал на доске все то, что имел в виду. Так как это был интересный разговор, мне хотелось бы поделиться озвученными в нем мыслями также и с другими.

Почему в скрам-планировании так делать нельзя?

Предположим, у вас есть скрам-команда, создавшая следующий план релиза пользовательских историй. У каждой пользовательской истории есть ценность (обозначенная знаком $) и относительный размер по отношению к другим историям. Общая ценность, создаваемая этой командой в релизе 3-го спринта, составляет $20.

Это работа, связанная с обязательствами, которую владелец продукта может передать заинтересованным сторонам с достаточной степенью уверенности, что она будет исполнена к дате релиза спустя 6 недель. Когда я говорю о разумной уверенности, я имею в виду уверенность на 85%. Мы уверены, что все задачи будут выполнены в 1-м спринте, но уверены уже в меньшей степени, когда дело касается задач с более низкой ценностью в 3-м спринте.

Не забывайте о том, что когда вы создаете план релиза по Agile, то вы работаете с неполной информацией. Мы проводим достаточно времени над пользовательскими историями, чтобы понять высокоуровневый объем задач, высокоуровневые подробности внедрения и провести высокоуровневое оценивание.

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

Планирование в скраме

Часто нам кажется, что на практике это не составит труда, ведь существуют три силы, используемые при работе со скрам-командами, позволяющие предоставить заинтересованным сторонам ожидаемый (и превосходящий ожидания) результат.

  1. В Agile-командах стейкхолдеры имеют возможность получать максимальную ценность от каждой недели программирования. Если команда располагает дополнительными возможностями, она берет на себя дополнительную работу.
  2. В начале каждого спринта мы просим команду повторно оценить пользовательские истории опираясь на свои знания приложения, индивидуальные навыки, умение работать в команде и недавний опыт работы с приложением. Как правило, это позволяет с легкостью реализовать стори или же расширить объем задач. В любом случае, под рукой всегда есть владелец продукта для внесения корректив.
  3. Мы сосредоточены на предоставлении законченных фрагментов ценности, а не на написании кода для наибольшего количества функциональных возможностей продукта. В скраме нельзя переносить незаконченную работу из одного спринта в другой, также скрам-командам не разрешается брать задачи, которые нереально завершить к концу спринта. Ни одна незаконченная задача не может выходить за рамки спринта.

Ценности в скраме

Возвращаясь к первоначальному вопросу — если скрам-команда закончила выполнение задач раньше срока, может ли она взяться за стори, запланированные на более поздние спринты? Если пользовательскую историю можно завершить в пределах таймбокса, то категорически можно, флаг в руки!

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

Что если вы были бы владельцем продукта и должны были бы выполнить этот план релиза?

Как владелец продукта, вы привнесли бы в него $24 ценности вместо первоначальных $20, ожидаемых стейкхолдерами.

Как это получилось у владельца продукта?

Некоторые пользовательские истории (синие поля) изначально оценивались как большие, но когда они были завершены, оказалось, что это произошло быстрее, чем ожидалось. Может быть множество причин, почему это так (что можно рассмотреть на ретроспективе), но в результате у команды появился дополнительный ресурс. А владелец продукта заполнил образовавшееся время новой пользовательской историей (зеленые поля), которая поместилась в спринт.

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

О ценностях, планировании и сложных ситуациях во время спринта поговорим на тренинге PSPO

Но почему бы не взять истории раньше? Разве нельзя добавить все эти бонусные истории в последний спринт? Можно, но заимствование в спринт 2 работы, запланированной на спринт 3, не добавит ему ценности. В данный момент у нас образовался пробел в спринте 2, который надо бы заполнить чем-то ценностнообразующим.

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

Carlton Nettleton Focus on Adding Value, Not Features