Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Декарт, Вы писали:
_>>>Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов: _>>>1. Оценка для user stories ведется в user point. Выбирается средняя по сложности задача, оценивается в идеальных человеко-днях и это есть user point? _>>>А другие задачи измеряются в этих user point' ах относительно эталонной user story?
Д>>Выберите, на ваш взгляд, самую простую задачу — оцените ее, не бойтесь оценивать не в единицах, а в десятках, или в сотнях поинтов.
А>Позвольте не согласится. С таким подходом запросто можно скатится к микроменеджменту или, наоборот, не увидеть детали (чего собственно и боится топикстартер). Предлагаю выделить пять градаций (в днях).
Во-первых, что вы имеете в виду под микроменеджменетом? Неумение руководства управлять коллективом? Так скатиться к нему можно и без оценок трудозатрат вообще... По поводу предложенных градаций — читайте классиков. Единичная задача, которую мы включаем в Sprint Backlog не должна требовани на исполнение более чем нескольких часов. Таким образом за один день человек получает возможность что-либо закончить, и желательно не одну задачу. С вашим же подходом на скрам митинге вы будете слышать на протяжении недели одно и то же — работаю над такой-то задачей... И только в конце недели узнаете, что программист в тупике.
По поводу же управления. Речь идет о SCRUM-команде. Значит, дело имеем с САМОУПРАВЛЕНИЕМ. Планируем сообща, делаем самое главное, и все добровольно.
Product Manager приготовит User Stories (Product Backlog) и позаботится об оценке их важности в бизнес поинтах, сортировке по степени важности, и предоставит самое главное на данный момент, самое необходимое и самое четко сформулированное в девелопмент. Программисты рассмотрят, выяснят детали, оценят объем работ. Как правило, сессия планирования такая занимает несколько часов. Часто это первое знакомство команды с представленными проблемами, и Product Owner обязан сделать хорошую презентацию требований. При этом сам Product Owner не принимает участия в оценке трудозатрат. Он их только принимает. Если ожидалось, что какую-то задачу программисты должны суметь сделать за неделю, а они говорят, что будут копаться с ней месяц — речь чаще всего идет о не до конца понятной постановке, или технологических трудностях, или чем-то еще, о чем, возможно, стоит подумать дополнительно, прежде чем начинать инвестировать время.
А>Если при оценке фичи получается больше — декомпозируйте, меньше — укрупняйте.
Что за совет такой? Сколько получится — столько получится. Не выдумывайте, и не занимайтесь махинациями. Рассмотрев задачи, и приняв к исполнению самые необходимые, команда снова приступает к обсуждению. Задачи из Product Backlog как правило объемные, и потребуют декомпозиции. До начала каких либо работ над теми задачами из Product Backlog, которые включены в Sptint, команда потратит время и изготовит Sprint backlog, детально расписав, что должно быть сделано, чтобы требуемая, как Вы говорите, "фича", была готова к "употреблению". При подготовке списка задач Sprint Backlog, команда должна помнить, что каждая задача должна быть сделана за несколько часов. Укрупнять ничего не требуется. Если что-то можно сделать за пять минут — сделайте! Но если что-то не делается за сутки, то подумайте, что же там такое серьезное внутри, что требует столько много времени, обсудите это сообща с командой, и проведите детализацию. В будущем это позволит работать над задачей не одному человеку, а нескольким людям сразу, что увеличит производительность команды.
И главное — если чувствуете, что запутались — не пытайтесь разбираться в одиночку — разбирайтесь с командой, сообща. Внедрять SCRUM советую не с того, что кто-то один составит Product Backlog, и предложит остальным дать оценки... А с того, что вся команда почитает литературу, послушает консультанта, онлайн презентации, сделает свое исследование о том, что же такое SCRUM, и затем обсудит полученную информацию. Чем больше точек зрения, тем лучше. Если команда "загорится" внедрением SCRUM — все пойдет как по маслу. Если же нет — я не завидую тому, кто "планирует внедрять Scrum в конторе".
