Комментарии 14
Я когда внедрял у себя agile не стал ограничивать верхнюю планку story points. То есть у нас 1sp — самая простая задача, а задача с 50sp означает, что она в 50 раз сложнее первой… ну и так далее.
Кстати то же самое у нас с приоритетами. n-1 менее важно чем n. N — любое число.
И, если позволите, маленький совет — делайте задачи как можно более конкретными. То есть не «подготовить список тренеров», а скорее «создать список тренеров, которые ...., Результат: файл со списком, каждый тренер отдельной строкой, кодировка файла utf8». Утрирую, конечно, но всё же. И я бы не стал боятся разбивать userstory на болшее число задач :)
Кстати то же самое у нас с приоритетами. n-1 менее важно чем n. N — любое число.
И, если позволите, маленький совет — делайте задачи как можно более конкретными. То есть не «подготовить список тренеров», а скорее «создать список тренеров, которые ...., Результат: файл со списком, каждый тренер отдельной строкой, кодировка файла utf8». Утрирую, конечно, но всё же. И я бы не стал боятся разбивать userstory на болшее число задач :)
Мы ограничили число sp для этого проекта, чтоб как бы точка отсчёта была. Никто не мешает её переступить, если появятся более сложные требования.
В нашем случае детализация той истории не нужна — это просто lift and shift со старого сайта. А так — да, будем детализировать. И пока что мне не совсем понятно, как это делать — в частности, если 2 истории оказываются связаными, и как бы одним логическим куском функционала… но, будем учится и разбираться!
В нашем случае детализация той истории не нужна — это просто lift and shift со старого сайта. А так — да, будем детализировать. И пока что мне не совсем понятно, как это делать — в частности, если 2 истории оказываются связаными, и как бы одним логическим куском функционала… но, будем учится и разбираться!
Наталья, я не очень понял проблему со связанным функционалом. Давайте все вместе попробуем разобраться :)
С удовольствием!
Вот у нас есть 2 истории:
Как пользователь, я хочу зарезервировать курс, чтобы улучшить свои знания
Как пользователь, я хочу знать, по каким датам курсы доспупны, чтобы зарезервировать удобный для меня курс
Насколько я понимаю, надо детализировать каждую историю отдельно, чтобы их теоретически делали разные люди.
В первой истории можно описать, какие данные нужно собрать с пользователя, какие там обязательные поля и т.д.
Но второе требование связано с первым, скажем, таким образом, что когда пользователь выберет город, система подгрузит список доступных дат. Как бы второе являются частью первого, и само по себе бесполезно.
Я не знаю, что «правильно» делать в таком случае. Может, объединить истории? Может, сделать ссылку, указав в первой, что после выбора города выполняется история 2? Или какой-то другой вариант — например, написать отдельный документ…
В реальности у меня там ни 2, а 8 историй так связанных. Если их слить в одну, она получится очень громоздкой или потеряет детали.
Вот у нас есть 2 истории:
Как пользователь, я хочу зарезервировать курс, чтобы улучшить свои знания
Как пользователь, я хочу знать, по каким датам курсы доспупны, чтобы зарезервировать удобный для меня курс
Насколько я понимаю, надо детализировать каждую историю отдельно, чтобы их теоретически делали разные люди.
В первой истории можно описать, какие данные нужно собрать с пользователя, какие там обязательные поля и т.д.
Но второе требование связано с первым, скажем, таким образом, что когда пользователь выберет город, система подгрузит список доступных дат. Как бы второе являются частью первого, и само по себе бесполезно.
Я не знаю, что «правильно» делать в таком случае. Может, объединить истории? Может, сделать ссылку, указав в первой, что после выбора города выполняется история 2? Или какой-то другой вариант — например, написать отдельный документ…
В реальности у меня там ни 2, а 8 историй так связанных. Если их слить в одну, она получится очень громоздкой или потеряет детали.
перед сном только одно решение приходит в голову:
ваша вторая us — это составная часть первой (это вы и без меня знаете). Так одна (первая) us является набором более мелких us. На мой взгляд это нормально.
С другой стороны. В очередную итерацию попадают как правило несколько us. Каждая us дробится на задачи. Но приоритезация в рамках итерации идёт на множестве задач. Поэтому: сначала делаем задачу [выбор курса] (это us#1), потом [выбор города](из us#2), затем [выбор доступных дат](us#2) — закрываем этим целиком us#2 и продолжаем работать над задачами us#1.
Да… в теории всё так красиво и легко :) Но что я себе хорошо уяснил: Agile тем и прекрасен, что в нём нет «правильного» подхода. Точнее даже правильных действий. Есть цель — удовлетворение заказчика, поддержка изменений (вобщем всё по манифесту). А как это сделать — каждая команда решает сама. Agile это не библиотечка, это фреймворк или даже best practices :) Делайте так, как вам удобно.
Надеюсь коллеги дадут свои комментарии.
ваша вторая us — это составная часть первой (это вы и без меня знаете). Так одна (первая) us является набором более мелких us. На мой взгляд это нормально.
С другой стороны. В очередную итерацию попадают как правило несколько us. Каждая us дробится на задачи. Но приоритезация в рамках итерации идёт на множестве задач. Поэтому: сначала делаем задачу [выбор курса] (это us#1), потом [выбор города](из us#2), затем [выбор доступных дат](us#2) — закрываем этим целиком us#2 и продолжаем работать над задачами us#1.
Да… в теории всё так красиво и легко :) Но что я себе хорошо уяснил: Agile тем и прекрасен, что в нём нет «правильного» подхода. Точнее даже правильных действий. Есть цель — удовлетворение заказчика, поддержка изменений (вобщем всё по манифесту). А как это сделать — каждая команда решает сама. Agile это не библиотечка, это фреймворк или даже best practices :) Делайте так, как вам удобно.
Надеюсь коллеги дадут свои комментарии.
И да, вы молодец! Не побоялись внедрить новую методологию.
Про фокус-фактор вы, наверное, не слышали… :( Настоятельно рекомендуется пользоваться именно им, а не лезть в пересчет на реальные часы разработки. Ибо смысл скрама отчасти теряется.
Насколько я знаю, в пределах итерации детальное планирование практикуется, например, вот — www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps_11.html
А так — нет, не слышала, надо будет почитать!
А так — нет, не слышала, надо будет почитать!
Почитала про фокус-фактор, и насколько понимаю, одно другому только помогает.
Если задание, скажем, оценено в 4 часа, это не значит, что за рабочий день (8 часов), полностью посвящённый проекту будут выполнены 2 таких заданий. Естественно, будут разговорчики, ответы на мэйлы, кофе, зарядка для глаз, обсуждение нового айфона — и фокус фактор станет, скажем, 0.6 — будет выполнено первое задание и около трети второго.
Фокус-фактор без «идеальных часов» бессмысленен.
Я правильно понимаю?
Если задание, скажем, оценено в 4 часа, это не значит, что за рабочий день (8 часов), полностью посвящённый проекту будут выполнены 2 таких заданий. Естественно, будут разговорчики, ответы на мэйлы, кофе, зарядка для глаз, обсуждение нового айфона — и фокус фактор станет, скажем, 0.6 — будет выполнено первое задание и около трети второго.
Фокус-фактор без «идеальных часов» бессмысленен.
Я правильно понимаю?
Если я в свою очередь вас правильно понял, то да :) Фокус-фактор позволяет не думать в реальных часах, потому что расчет в реальных часах не позволяет учесть ни среднюю производительность команды, ни риски/форс-мажоры. Потому мы от этого и отказались.
Т.е. мы определяем фокус-фактор (ФФ) команды — это планируемое отношение временнОй емкости спринта, измеренное в story points к его емкости в часах реального времени. После чего можно перевести длину спринта в story points, домножив на фокус-фактор, и все расчеты вести в SP — мерять остаток, оценивать скорость и трудоемкость и т.п.
Что еще более важно: фокус-фактор непрерывно переоценивается по результатам каждого спринта. Мы, например, это делаем на планировании спринта, исходя из ФФ, рисков и т.п. Таким образом после 2х-3х спринтов вы точно сможете сказать, какая часть backlog уместится в будущий спринт.
Т.е. мы определяем фокус-фактор (ФФ) команды — это планируемое отношение временнОй емкости спринта, измеренное в story points к его емкости в часах реального времени. После чего можно перевести длину спринта в story points, домножив на фокус-фактор, и все расчеты вести в SP — мерять остаток, оценивать скорость и трудоемкость и т.п.
Что еще более важно: фокус-фактор непрерывно переоценивается по результатам каждого спринта. Мы, например, это делаем на планировании спринта, исходя из ФФ, рисков и т.п. Таким образом после 2х-3х спринтов вы точно сможете сказать, какая часть backlog уместится в будущий спринт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка требований в Scrum