Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов:
1. Оценка для user stories ведется в user point. Выбирается средняя по сложности задача, оценивается в идеальных человеко-днях и это есть user point?
А другие задачи измеряются в этих user point' ах относительно эталонной user story?
2. Допустим оценили user story. Но ведь user story разбивается на задачи. Может статься так, что после разбиения на задачи (не учли какие-то мелкие задачи при оценке user story), суммарная оценка трудоемкости станет выше оценки user story? И надо ли вообще проводить оценку для отдельных задач?
Или user story все-таки вначале разбивается на задачи и суммарная оценка трудоемкости — это и есть трудоемкость всей user story?
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги
_>Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов: _>1. Оценка для user stories ведется в user point. Выбирается средняя по сложности задача, оценивается в идеальных человеко-днях и это есть user point? _>А другие задачи измеряются в этих user point' ах относительно эталонной user story?
Выберите, на ваш взгляд, самую простую задачу — оцените ее, не бойтесь оценивать не в единицах, а в десятках, или в сотнях поинтов.
_>2. Допустим оценили user story. Но ведь user story разбивается на задачи. Может статься так, что после разбиения на задачи (не учли какие-то мелкие задачи при оценке user story), суммарная оценка трудоемкости станет выше оценки user story? И надо ли вообще проводить оценку для отдельных задач? _>Или user story все-таки вначале разбивается на задачи и суммарная оценка трудоемкости — это и есть трудоемкость всей user story?
_>З.Ы. Чувствую что запутался я малость...
Попробую помочь распутаться. Вы описали все (как вам сейчас кажется) истории, и готовы приступить к их исполнению. Понятно, что за один присест (спринт) все не сделать, поэтому следует выбрать самое главное. Как выбираем? Истории желательно приоритизировать, т.е. расставить в порядке убывания их значимости для бизнеса. К этому вопросу подходим так — зная, что завтра все программисты уйдут в отпуск, что им нужно сделать прежде всего? Эти задачи получают наибольший приоритет, и наивысшие оценки (не бойтесь значений — пусть это будут тысячи поинтов — это не суть важно).
Просмотрите список с программистами — пройдитесь по самым важным задачам, дайте теперь им определить, какое количество времени у них займет исполнение работы по каждой из них. Тоже в поинтах. Не стесняйтесь пользоваться большими числами и здесь. Главное — выберите что-то простенькое за эталон. Скажем — 1 час работы одного программиста — 10 поинтов... Оттолкнитесь от такого, например...
Далее попробуйте сопоставить полученные цифры. Вы увидите, что максимально важное для бизнеса можно сделать минимальными усилиями — начните с этого. Спланируйте спринт, завершите его, и посмотрите, на сколько ваши ожидания по срокам подтвердились. Коррекция для следующего спринта должна быть только в объеме планируемой работы. Не беритесь сделать больше, чем вы физически способны.
Не забывайте главное — ваши изначальные постановки (user stories) должны быть максимально независимыми одна от другой. Так, чтобы выполненную работу по каждой из них можно было сдавать в эксплуатацию. Если по какой-то причине они у вас повязаны зависимостями, то никакие вышеизложенные упражнения не применимы...
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги
_>Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов: _>1. Оценка для user stories ведется в user point. Выбирается средняя по сложности задача, оценивается в идеальных человеко-днях и это есть user point?
Одна поправка, не "средняя по сложности", а "наименее сложная" и, крайне желательно чтоб это была не отдельная задача (закодить, протестить и пр.), а законеченная фича, включающая в себя все эти работы. "Лучшие собаководы" советуют именно так, но ИМХО тут возможны эксперименты и упрощения. Если для каждого нового проекта выбирать из него новую работу как эталон, то и оценки других работ относительно него будут скакать при смене эталона, а Вам ещё Velocity считать на основе этих оценок и на основании Velocity планировать следующие проекты — пожалейте своего менеджера Так-что лучше выберите за эталон какую-либо несложную фичу/работу, которую команда выполнила недавно и про которую ВСЯ КОМАНДА знает, что она из себя представляет.
_>А другие задачи измеряются в этих user point' ах относительно эталонной user story?
Ага. Здесь ключевое слово "относительно", т.е. команда на самом деле не оценивает, а сравнивает.
_>2. Допустим оценили user story. Но ведь user story разбивается на задачи. Может статься так, что после разбиения на задачи (не учли какие-то мелкие задачи при оценке user story), суммарная оценка трудоемкости станет выше оценки user story?
Не "может статься", а так и будет Какие-то фичи в бэклоге переоцените, какие-то недоцените — всё компенсируется законом больших чисел. Скажу больше, возможно, что в рамках одного и того-же спринта присутвуют две фичи оцененные в 5 stоry point-ов. При планировании спринта, разбиении этих фич на задачи и оценке их в часах выяснится, что одна фича суммарно оценивается в 30 часов, а вторая, допустим, в 38 — и это то-же нормально, связано с вероятностным распеределением оценок.
_>И надо ли вообще проводить оценку для отдельных задач?
Да, надо. Всё-таки "фичами", в рамках спринта, ворочать тжеловато. Спринт (и его задачи) всё-таки легче планировать и контролировать в идеальных часах.
_>Или user story все-таки вначале разбивается на задачи и суммарная оценка трудоемкости — это и есть трудоемкость всей user story?
Ну, вообще, если уже на этапе планирования релиза user story легко можно разбить на задачи, то это круто! А так — разбивайте на задачи и оценвайте user story, когда вам это удобно и, главное, когда это возможно (т.е. есть уже вся необходимая для реализации информации). Потом вседа можно переоценить. "Планы — ничто, планирование — всё"
А вообще, вот здесь очень толков написано на эту тему.
Да и denis_miller, наверное, забредёт сюда — расскажет, что к чему
Попробуйте вначале оценивать не в стори-поинтах, а в часах, так будет всем спокойнее
На начальном этапе внедрения, чем меньше сложностей, тем будет лучше
Когда освоитесь (месяц, два), переходите к оценке в "попугаях" — если вообще понадобится.
Обязательно используйте Plannig poker — реальное подспорье.
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги
_>Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов:
[...] _>З.Ы. Чувствую что запутался я малость...
_>>Планирую внедрять Scrum в конторе. И у меня есть несколько основных вопросов: _>>1. Оценка для user stories ведется в user point. Выбирается средняя по сложности задача, оценивается в идеальных человеко-днях и это есть user point? _>>А другие задачи измеряются в этих user point' ах относительно эталонной user story?
Д>Выберите, на ваш взгляд, самую простую задачу — оцените ее, не бойтесь оценивать не в единицах, а в десятках, или в сотнях поинтов.
Позвольте не согласится. С таким подходом запросто можно скатится к микроменеджменту или, наоборот, не увидеть детали (чего собственно и боится топикстартер). Предлагаю выделить пять градаций (в днях). Если при оценке фичи получается больше — декомпозируйте, меньше — укрупняйте.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Декарт, Вы писали:
_>>>Планирую внедрять 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 в конторе".
А что. Вполне себе нормальный метод. Для случаев, когда система скорее "широкая", чем "глубокая" (много относительно независимых фич, мало слоев, слои тонкие) — отлично сработает. С поправкой starina_bz насчет пойнтов — еще лучше.
"Относительные оценки", не привязанные напрямую с срокам — это в принципе прикольная штука и не в контексте скрама. Экспертов заставляют применять "метод структурной аналогии" при оценке, так, что у них нет возможности этого избежать. Можно будет при случае попробовать.
Можно и без универсальных "пойнтов", конечно. Можно (и так будет правильнее) иметь "базис" из нескольких типичных задач, по которым известны характеристики. Тут большой простор, надо будет подумать.
Здравствуйте, Декарт, Вы писали:
Д>Во-первых, что вы имеете в виду под микроменеджменетом? Неумение руководства управлять коллективом? Так скатиться к нему можно и без оценок трудозатрат вообще... По поводу предложенных градаций — читайте классиков. Единичная задача, которую мы включаем в Sprint Backlog не должна требовани на исполнение более чем нескольких часов. Таким образом за один день человек получает возможность что-либо закончить, и желательно не одну задачу.
Это наиболее парадоксальная часть скрама. Выделенное не всегда возможно. Кроме того, такая стратегия практически исключает возможность применения предварительного проектирования, и требует очень хорошего понимания того, как будет решаться задачи на этапе планирования.
Д>С вашим же подходом на скрам митинге вы будете слышать на протяжении недели одно и то же — работаю над такой-то задачей... И только в конце недели узнаете, что программист в тупике.
Д>Product Manager приготовит User Stories (Product Backlog) и позаботится об оценке их важности в бизнес поинтах, сортировке по степени важности, и предоставит самое главное на данный момент, самое необходимое и самое четко сформулированное в девелопмент. Программисты рассмотрят, выяснят детали, оценят объем работ. Как правило, сессия планирования такая занимает несколько часов.
Пример. Пишем медиаплеер. Элементарная и неделимая бизнес-задача — реализовать поддержку декодирования Dolby Digital с аппаратным ускорением на DSP-процессоре. Медиаконвейер, допустим, GStreamer.
На одно чтение документации по Dolby Digital, и понимание того, что именно надо переложить на DSP-ядро, уйдет от нескольких дней до недель. Потом, будет еще трахотня с отладкой и оптимизацией, которая в несколько часов не уложится, и которую планировать детально довольно глупо.
Это элементарный пример более "глубокой" системы, чем "широкой". Для одной видимой пользователю и простой в тестировании функции — несколько слоев, и куча архитектурных проблем, которые надо решить. Для справки — один анализ алгоритма Dolby Digital и разработка ТЗ для написания DSP кода (а также инструменты для тестирования результатов DSP-кода) заняла в реальности две недели.
Почему так много? Видите-ли, вскрытие показало, что алгоритм DD полагается на плавающую запятую. Заранее это известно не было, кстати. А в DSP-шнике, который надо было применять, нет плавающей запятой. Нюанс, однако. Что же делать, что же делать? Побьете эту задачу по классике скрама — в серию наколбасов кода за пару-тройку часов? Пойнты там, то, се.
Блин, да даже юнит-тест для DSP-кода в данной задаче не пишется за пару часов. Для того, чтобы его написать, надо сначала придумать, как погрешность результатов измерять, а это само по себе небольшое исследование.
Д>Что за совет такой? Сколько получится — столько получится. Не выдумывайте, и не занимайтесь махинациями.
Это — правильно. Не надо выдумывать, и заниматься махинациями.
Д> Если команда "загорится" внедрением SCRUM — все пойдет как по маслу.
От того, что команда "загорится", скрам не начнет мочь того, что он не может. Зато — начнутся махинации с выдумками. Скарм слишком сильно ограничивает подход к разработке, чтобы во всех случаях можно было обойтись без выдумок.
Здравствуйте, Gaperton, Вы писали:
G>Это элементарный пример более "глубокой" системы, чем "широкой". Для одной видимой пользователю и простой в тестировании функции — несколько слоев, и куча архитектурных проблем, которые надо решить. Для справки — один анализ алгоритма Dolby Digital и разработка ТЗ для написания DSP кода (а также инструменты для тестирования результатов DSP-кода) заняла в реальности две недели.
Здравствуйте, alexei_s, Вы писали:
_>Попробуйте вначале оценивать не в стори-поинтах, а в часах, так будет всем спокойнее
Спокойнее будет не всем, если вообще будет.
Измерение часами отпугивает, думаешь "2 часа! это ж четверть дня, а на самом деле считай пол-дня уйдет!", а речь всего-то идет об относительной оценке трудозатрат. Часы меняют впечатление и мышление в неконструктивную сторону, как мне кажется.
Здравствуйте, alexei_s, Вы писали:
R>>Измерение часами отпугивает, думаешь "2 часа! это ж четверть дня, а на самом деле считай пол-дня уйдет!",
_>Значит смело и ставим пол-дня
Так уйдет-то на самом деле только 2, остальное из-за того что или "у страха глаза велики" или непрестижное задание.
Я замечал, как коллеги (никакого скрама) начинают отлынивать от неприятной работы, раздувая ее сложность тем самым приведенным мною приемом.
В общем, мне все же кажется, что вот эта прямая связь оценки трудоёмкости с рабочим временем искажает реальную картину, в результате все забывают свои оценки как только сообщили их начальству и работают как уже пойдет, всегда можно будет если что найти какую-нибудь неожиданно возникшую трудность, чтобы оправдать задержку.
Еще такая ситуация.
Один мой коллега например открыто рассказывает, что сообщает начальнику нереально оптимистические сроки, потому что начальник имеет привычку вообще выбрасывать из плана задачу, чуть заслышав о ее большом времени. При чем новой не дает, т.е. задача выкидывается (это ж как много человеко-часов на нее уйдет!), а эти человеки в результате по-простому пинают, проедая баблос впустую. Уж лучше бы хоть что-нибудь делали.
Заслышав же оптимистическую оценку, начальник довольно успокаивается и забывает об этой задаче на срок значительно превышающий даже пессимистическую оценку.
Здравствуйте, Rothmans, Вы писали:
R>Еще такая ситуация. R>Один мой коллега например открыто рассказывает, что сообщает начальнику нереально оптимистические сроки, потому что начальник имеет привычку вообще выбрасывать из плана задачу, чуть заслышав о ее большом времени. При чем новой не дает, т.е. задача выкидывается (это ж как много человеко-часов на нее уйдет!), а эти человеки в результате по-простому пинают, проедая баблос впустую. Уж лучше бы хоть что-нибудь делали. R>Заслышав же оптимистическую оценку, начальник довольно успокаивается и забывает об этой задаче на срок значительно превышающий даже пессимистическую оценку.
Да да. примерно так и бывает. Причем еще до Agila было)
Я на одной работе так делал, когда был бывшим студентом.
Говорили за сколько ты напишешь. Я грил за 8 часов, это и то была очень оптимистическая оценка.
Мне начальник: нет не пойдет слишком долго.
Срок 4 часа. Ну я говорил смотри сам.Давай поставим 4 часа, но не успею. Делай.
В итоге уходило 2 недели. Кто нить заболеет, кто-нить что-нить забудет, по 50 раз переделывается задание.
В итоге просто спрашивали сделали или не сделали.
Так-что лучше выберите за эталон какую-либо несложную фичу/работу, которую команда выполнила недавно и про которую ВСЯ КОМАНДА знает, что она из себя представляет. 
А так — разбивайте на задачи и оценвайте user story, когда вам это удобно и, главное, когда это возможно (т.е. есть уже вся необходимая для реализации информации). Потом вседа можно переоценить. "Планы — ничто, планирование — всё" 
