Запрос на принятие обязательств

We use cookies. Read the Privacy and Cookie Policy

В своем исследовании факторов успеха команд Ларсон и Лафасто (Larson and LaFasto, 1989) установили, что единое обязательство, принятое всеми членами команды, является одним из ключевых факторов успеха. Во время совещания по планированию итерации я спрашиваю команду: «Можете ли вы принять обязательство реализовать функции, которые мы обсудили?» Обратите внимание на то, что я не спрашиваю, смогут ли они принять обязательство реализовать задачи, которые мы идентифицировали. Это совершенно другой вопрос и значительно более слабое обязательство, поскольку оно относится к выполнению набора задач, а не к постановке новой функциональности.

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

Я спрашиваю команду, сможет ли она принять обязательство по реализации после разбивки каждой пользовательской истории на задачи и оценки этих задач. Применительно к первой пользовательской истории такой вопрос может показаться глупым. В команде, планирующей двухнедельную итерацию, может быть семь человек. Может так случиться, что они идентифицировали работу пока всего лишь на 34 часа, а я спрашиваю, смогут ли они принять обязательство по ее выполнению. Их ответ (либо в словесной форме, либо в виде смущения на лицах), без сомнения, будет следующим: «Конечно, мы можем принять обязательство выполнить это. Нас семь, и у нас целых две недели, а здесь работы всего на 34 часа». Вместе с тем чем дальше продвигается обсуждение и чем больше пользовательских историй включаются в итерацию, тем более тщательного обдумывания требует мой вопрос о возможности принятия обязательства. В конечном итоге наступает предел, за которым команда уже не может увеличивать объем обязательств. В таком случае она может исключить историю или заменить ее на более мелкую перед завершением обсуждения.