Agile: оценка и планирование проектов - [62]
Если в ходе итерации появятся новые задачи (а они почти наверняка появятся), то команда, которая приняла обязательство поставить функциональность, описанную пользовательской историей, будет стараться выполнить также и новые задачи. Команда, которая обязалась выполнить только набор идентифицированных задач, может отказаться от выполнения новых. Не исключено, однако, что новые задачи окажутся слишком объемными для выполнения в данной итерации. В этом случае команде необходимо обсудить ситуацию с владельцем продукта и определить, есть ли возможность реализовать цель итерации. Команде для этого, возможно, придется сократить функциональность истории, а то и полностью исключить ее.
Я спрашиваю команду, сможет ли она принять обязательство по реализации после разбивки каждой пользовательской истории на задачи и оценки этих задач. Применительно к первой пользовательской истории такой вопрос может показаться глупым. В команде, планирующей двухнедельную итерацию, может быть семь человек. Может так случиться, что они идентифицировали работу пока всего лишь на 34 часа, а я спрашиваю, смогут ли они принять обязательство по ее выполнению. Их ответ (либо в словесной форме, либо в виде смущения на лицах), без сомнения, будет следующим: «Конечно, мы можем принять обязательство выполнить это. Нас семь, и у нас целых две недели, а здесь работы всего на 34 часа». Вместе с тем чем дальше продвигается обсуждение и чем больше пользовательских историй включаются в итерацию, тем более тщательного обдумывания требует мой вопрос о возможности принятия обязательства. В конечном итоге наступает предел, за которым команда уже не может увеличивать объем обязательств. В таком случае она может исключить историю или заменить ее на более мелкую перед завершением обсуждения.
Суммирование оценок
По моему опыту, для определения, сможет ли команда справиться с набором пользовательских историй, лучше всего просуммировать оценки, данные задачам, и посмотреть, представляет ли полученная сумма разумный объем работы. Надо учитывать, конечно, что некоторым задачам присуща высокая неопределенность, поскольку работа не продумывалась детально, а требования туманны. Так или иначе, суммирование оценок дает определенное представление об общем объеме работы.
Допустим, команда работает с использованием двухнедельных итераций. В каждой итерации ей доступно 560 часов (7 человек × 10 дней × 8 часов в день). Мы знаем, что определенное время тратится на деятельность, не отраженную в карточках с задачами, — ответы на электронные письма, участие в совещаниях и т. д. Также нам известно, что оценки неточны; в конце концов, это оценки, а не гарантированные величины. По этим причинам нельзя ожидать, что эта команда возьмется за выполнение задач объемом 560 часов. На практике большинство команд успешно справляются с работой, когда ее плановый объем (сумма оценок на карточках с задачами) составляет от четырех до шести часов в день. Для нашей команды из семи человек, работающей двухнедельными итерациями, это означает плановый объем работы от 280 до 420 часов. В какой точке этого диапазона команда остановится, зависит от того, насколько хорошо она идентифицирует задачи для данной истории, насколько точно оценивает эти задачи, а также от объема сторонних обязательств членов команды и размера общекорпоративных непроизводительных издержек. После пары итераций большинство команд начинают примерно чувствовать, какой объем работы в часах они должны планировать на итерацию.
Прежде чем принимать обязательство выполнить работу во время итерации, необходимо посмотреть на задачи и понять, обеспечивают ли они подходящее распределение работы в соответствии с квалификацией и опытом членов команды. Не получится ли так, что Java-программист окажется перегруженным, а HTML-программисту будет нечего делать? Не окажутся ли выбранные пользовательские истории легко поддающимися программированию, но требующими много времени или трудно тестируемыми, что приведет к перегрузке тестировщика? Не требуют ли выбранные истории предварительного анализа и дизайна пользовательского интерфейса?
Команда в ситуации вроде этой должна сначала попытаться найти подходы к более рациональному распределению работы. Может ли HTML-программист в этом примере помочь тестировщику? Может ли кто-нибудь другой, кроме дизайнера пользовательского интерфейса, выполнить эту работу? Если нет, то можно ли удалить из этой итерации истории, которые требуют дизайна пользовательского интерфейса, и можно ли вместо них взять истории, в которых это не требуется? Главное, чтобы все в команде отвечали за что-нибудь в пределах своих умений независимо от специализации.
При оценке возможности принять обязательство по реализации набора новых функций некоторые команды предпочитают сначала распределять задачи между конкретными исполнителями, а потом уже оценивать, сможет ли каждый исполнитель справиться с порученной работой. Этот подход работает хорошо, и я, бывало, рекомендовал его использовать (Cohn, 2004). Однако, как оказалось, отказ от распределения задач во время планирования итерации и от индивидуальных оценок, необходимых для принятия обязательств, облегчает команде переход на мышление «мы все работаем над этим вместе».
Стив Мэдден был одержим обувью и не просто ее производил, а создавал тренды. Несмотря на синдром дефицита внимания, наркотическую зависимость, тюремное заключение и потерю уважения окружающих, он смог взобраться на олимп обувной индустрии! Книга Стива Мэддена – это исповедь предпринимателя, которая вдохновляет и помогает понять, как достичь успеха вопреки всему.В формате PDF A4 сохранен издательский макет.
«Руководство…» написано по итогам десяти лет работы автора в закупках электронных товаров в Китае, чем он занимается с 2010-го года по настоящее время. Книга разъясняет, как устроено производство продукции в Китае, как организована торговля, рассказывает о специфике и особенностях поставщиков, образе жизни, менталитете и мышлении китайцев, которые влияют на конечный продукт.
Как часто тебе приходится сталкиваться с непрошеной критикой? Как часто ты переживаешь о том, что недостаточно красива, талантлива, успешна, счастлива, просматривая по вечерам ленты в соцсетях? Ты устала быть несчастливой в своем теле? Меня зовут Цыпулина Яна, и я 23 года жила с ненавистью к себе и своей внешности, потому что болею алопецией. На большей части головы у меня не растут волосы, и из-за этого десять лет в школе я была знаменитостью – «лысым уродом», на которого каждый день показывали пальцем и над которым всячески издевались. Долгое время мне хотелось просто исчезнуть, я просыпалась и засыпала с ощущением беспомощности и отвращением к себе.
Книга для того, кто хочет запустить первый бизнес: кофейный островок, кофе-бар или небольшую уютную кофейню со столиками.Автор на собственном опыте показывает, как пройти путь от намерения до создания сети кофеен, не покупая франшизу. За 5 лет существования Coffee Molly было запущено 9 кофе-баров площадью от 6 до 60 кв. м.От главы к главе раскрываются важные закономерности, которые помогают создавать не просто точки продаж, а притягательные места для клиентов.
Рассматриваются такие инструменты статистического анализа взаимосвязи, как корреляционный и регрессионный анализ. Техника работы в пакете Excel изучается на примере смоделированных данных. Затем полученные навыки применяются к анализу реальных данных по ценам в интернет-магазине и биржевым котировкам на Московской бирже.
Изучать маркетинговые инструменты на личном опыте — занятие дорогостоящее и рискованное. Не одна компания утонула, копируя действия конкурентов и используя потрёпанные годами шаблоны. Почему же старые методы ведения бизнеса уже не работают? Что такое маркетинг и существует ли он вообще? Как создать продукт, который будет пользоваться спросом у клиентов и приносить владельцу бизнеса деньги, радость и удовлетворение?