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

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

При постановке задачи очень полезно помнить о таком понятии в Agile, как I.N.V.E.S.T. критерии. I.N.V.E.S.T. это аббревиатура объединяющая шесть характеристик, которым должна соответствовать совершенно любая задача в бэклоге.

Выполнение этих критериев I.N.V.E.S.T. уже сделает большинство ваших задач пригодными для самостоятельного выполнения любым членом команды. Однако в каждой команде может быть своя специфика, которая требует для выполнения этих критериев своих уточнений. Поэтому ниже мы поговорим о том, как на практике сделать задачи соответствующими этим критериям.

Если вы описываете бизнес задачу, которая несет ценность для определенной группы пользователей, то используйте для описания формулу для User Story:

Как <роль>, я хочу <что>, чтобы <цель>

Например, “Как пользователь, я хочу получать оповещения о появлении товара в наличии, чтобы знать, что его можно купить”.

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

Критерии приемки - это список критериев, являющийся индивидуальным для каждой задачи и описывающий все условия правильной работы функционала, запрашиваемого в задаче. В классическом Agile критерии приемки должны быть оформлены в формате списка описывающего что для какой роли должно быть сделано в задаче, но не того как это должно быть сделано. Например “пользователь должен иметь возможность авторизоваться на сайте”, “поле ИНН должно соответствовать формату ____” и так далее. Но так как Agile это в первую очередь про гибкость, в вашей команде вы можете выбрать отличающийся формат. Главное условие, что читая критерии приемки любой член команды понимал какой функционал он должен реализовать в итоге и после готовности задачи правильные исполнение условий задачи оценивалось именно по этим критериям приемки.

Различные технические задачи и задачи на исследование могут иметь другой формат. Все зависит от того, как удобно именно вашей команде. Главное чтобы при их описании выполнялись критерии I.N.V.E.S.T. и критерии готовности задачи к разработке, о которых мы поговорим позднее.

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

Помимо ответственного за постановку бизнес задач, так же необходим ответственный со стороны разработки, который будет помогать представителю бизнеса с начальными вопросами по сложности реализации и различных подводных камнях, которые могут встретится в этой задаче на этапе разработки. Если такого ответственного не выделить, то ПО будет вынужден отвлекать от работы команду, работающую в этот момент над текущим спринтом и вырывать их из контекста, что отрицательно скажется на эффективности. Разумеется в работу ответственного должно быть заложено время на эти отвлечения во время планирования спринта. Ответственный для технических вопросов может быть как всегда один и тот же человек, так и сменяемый, например, в формате дежурства. Здесь выбираете то, что удобно для вашей команды и ее компетенций.

Теперь, когда есть ответственные за правильную постановку задачи, нужно определится как эта правильная постановка должна выглядеть. Для начала всегда нужно помнить про критерии I.N.V.E.S.T., однако они дают очень верхнеуровневое понятие готовности задачи к разработке. На практике выполнение каждого критерия будет очень сильно зависеть именно от вашей специфики и вашей команды. Поэтому лучший способ определить правильность описания задачи это определить критерии готовности задачи к разработке именно для вашей команды. Критерии готовности задачи к разработке это список обязательных требований, которые должны быть выполнены при описании задачи, чтобы это задача могла попасть на рассмотрение разработкой и дальнейшую оценку. Чтобы определить эти критерии нужно собрать всю команду и представителей бизнеса и совместно обсудить, что для команды важно знать из задачи для самостоятельной работы над ней. Примеры таких критериев: “В задаче описаны критерии приемки”, “В задаче указаны зависимости задачи от других отделов или их отсутствие”, “Дизайн интерфейса для задачи полностью готов и принят бизнесом” и так далее. Для каждого типа задач, который описывается иначе список критериев готовности задачи в к разработке может отличатся. Например для User Story этот набор критериев будет один, а для технических задач он может быть другой. Это также решается индивидуально для вашей команды.

Почему эти критерии должны определяться каждой командой самостоятельно? Давайте рассмотрим этот вопрос на примере дизайна. Есть проект А, где дизайн крайне важен для качественной поставки функционала клиенту. Команде такого проекта обязательно нужен критерий готовности задачи “Дизайн интерфейса для задачи полностью готов и принят бизнесом”. Однако, на проект Б разрабатывается для внутреннего пользования в компании и дизайн не имеет такого ключевого значения. Бизнес этого проекта ничего не имеет против того, чтобы разработка сама решала как расположить элементы на странице, главное чтобы функционал работал, как задумано. Для такого проекта излишним будет вносить в критерии готовности задачи к разработке пункт о дизайне. Таким образом у каждого проекта, в зависимости от его специфики, будут свои важные детали, которые обязательно вносить в каждую задачу.

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

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

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

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

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

В критерии готовности задачи вносятся все так же все технические вещи, которые должны быть выполнены исполнителем. Примеры критериев готовности задачи: “задача покрыта Unit-тестами на 70%”, “задача протестирована”, “задача соответствует всем критериям приемки”, “задача прошла проверку заказчиком на соответствие требованиям” и так далее.

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

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

Если вы хотите больше узнать о том, как правильно построить процессы в своей компании или команде, всю подробную информацию по внедрению и адаптации Agile именно под ваши нужды мы разбираем в нашей книге "Гибкие методологии на практике". В ней вы найдете множество примеров, как нужно и как не нужно применять гибкие методолгии и станете настоящим специалистом по Agile.