1. Что такое Effort у Backlog item? Да я понял, что это какие-то попугаи (стори поинтс) и и что велосити зависит от их выполнения и влияет на реальную оценку запланированных требований. Но как все же ее оценивать и использовать? Пока получилось только создать внутри Task'и и там уже есть возможность указать понятную мне оценку remaining work в часах. Пока только этим и пользуемся.
2. Не могу разобраться с правами. Хочется простого.
Есть команда: Product Owner + Scrum master + developers + testers + сочувствующие.
Владелец и Scrum master имеют полный доступ ко всему проекту — это я сделал без проблем.
Сочувствующие — это вышестоящее руководство, смежные проекты, которые могут видеть все, но только в режиме чтения. Тут как то не все выходит. Главное чтобы они еще и не стали членами комманды, чтобы не пришлось их на каждый спринт занулять на вкладке capacity. Почему-то баклог проекта оказался невиден
Програмисты — не могут редактировать баклог, но по-возможности могут создавать внутри backlog item'ом задачи.
Тестировщики — могут писать Test Cases, Заводить баги, видеть баклог на чтение.
Здравствуйте, BluntBlind, Вы писали:
BB>Установил, смотрю, есть вопросы.
BB>1. Что такое Effort у Backlog item? Да я понял, что это какие-то попугаи (стори поинтс) и и что велосити зависит от их выполнения и влияет на реальную оценку запланированных требований. Но как все же ее оценивать и использовать? Пока получилось только создать внутри Task'и и там уже есть возможность указать понятную мне оценку remaining work в часах. Пока только этим и поднальзуемся.
Да, стори поинтс — это какие-то попугаи.
Нужны для грубой оценки PBIs (product backlog item).
Оценки далает команда с помощью planning poker.
Если очень грубо, то сначала, до того, как вообще начинаете работать над проектом,
выбирается одна задача (reference story),
которую все члены команды более менее понимают (что имеется ввиду и что примерно надо делать).
Этой самой reference story произвольным образом назначается цена.
Ну скажем в 10 story points.
Далее исходя из этой эталонной оценки всем известной задачи,
оцениваются все другие задачи.
В ходе planning poker каждый называет свою оценку сравнивая ее с reference story.
Если расхождений больших нету, то берется среднее число.
Если расходения существенные (один говорит 5, а другой дает 100),
то надо обсуждать. Налицо разное понимание сути задачи и надо прийти к общему знаменателю.
Я лично скрам очень не жалую, но в ихней методике оценок есть смысл.
А вот оценки в часах — это на мой взляд штука весьма бесполезная и даже вредная.
P.S. Прежде чем применять темплейты, советую все же хоть немного ознакомиться с теорией.
Здравствуйте, bkat, Вы писали:
B>А вот оценки в часах — это на мой взляд штука весьма бесполезная и даже вредная. B>P.S. Прежде чем применять темплейты, советую все же хоть немного ознакомиться с теорией.
Спасибо, понял.
Мы как делаем. Мы с аналитиком формируем backlog разбивая и выдирая userstories из вариантов испольpования по приоритету.
Затем мы с командой обсуждаем каждую userstory разбивая ее при этом на технические задачи (task).
Вот эти задачи мы и оцениваем используя planning poker. Оценку мы получаем в днях: 1/2, 1, 3, 5, 10 и т.д. Если нужно, дробим задачи. Редко у нас бывает оценка больше 5 дней.
Просто в tfs11 задачи оцениваются в часах, вот и переводим оценку в часы. Теперь я понял как используется Effort. Будем туда складывать суммарную оценку задач из которых состоит userstory, полученные при планировании. Т.е. в итоге у нас будет Effort полученный на этапе планирования методом planning pocker и в тоже время есть задачи, remaining work которых можно использовать для отслеживания уже при выполнении работ. Т.е. если задача затягивается, увеличим remaining work, но Effort уже пересчитывать не будем.
Только вот теперь вопрос возник. Запланировали спринт. И скажем в итоге пара задачи из какой-то userstory не успели сделать. Как с ними правильно поступить? Чтобы tfs правильно учел. Перенести эту userstory в следующий спринт? Или скопировать?
Здравствуйте, BluntBlind, Вы писали:
BB>Здравствуйте, bkat, Вы писали:
B>>А вот оценки в часах — это на мой взляд штука весьма бесполезная и даже вредная. B>>P.S. Прежде чем применять темплейты, советую все же хоть немного ознакомиться с теорией.
BB>Спасибо, понял. BB>Мы как делаем. Мы с аналитиком формируем backlog разбивая и выдирая userstories из вариантов испольpования по приоритету. BB>Затем мы с командой обсуждаем каждую userstory разбивая ее при этом на технические задачи (task). BB>Вот эти задачи мы и оцениваем используя planning poker. Оценку мы получаем в днях: 1/2, 1, 3, 5, 10 и т.д. Если нужно, дробим задачи. Редко у нас бывает оценка больше 5 дней. BB>Просто в tfs11 задачи оцениваются в часах, вот и переводим оценку в часы. Теперь я понял как используется Effort. Будем туда складывать суммарную оценку задач из которых состоит userstory, полученные при планировании. Т.е. в итоге у нас будет Effort полученный на этапе планирования методом planning pocker и в тоже время есть задачи, remaining work которых можно использовать для отслеживания уже при выполнении работ. Т.е. если задача затягивается, увеличим remaining work, но Effort уже пересчитывать не будем.
Дело конечно ваше и если такая система оценок у вас работает,
то продолжайте в том же духе. Но вообще-то это точно не скрам
и на мой взгляд имеет много проблем.
Оценки в story points надо проводить до того как PBI разбивается на задачи и задачи
оцениваются с часах.
Увязывать story points со временем — это в корне неверно.
Ну если грубо, то оценка в story points — это расстояние в км. которое надо преодолеть.
Ну а какое время для этого потребуется — это сильно зависит от команды, и конкретных людей.
У вас же получается и нету оценок PBI до того как они попадут в спринт.
Все же очень рекомендую вам ознокомиться с базовой теорией по скраму,
если уж вы решили его применять.
Мое личное мнение, что если следить за тем, что PBI, попадающие в спринт,
имеют не слишком большую сложность (скажем не больше половины средней velocity члена команды),
то оценки в часах отдельных задач можно и не делать. Экономит кучу времени.
BB>Только вот теперь вопрос возник. Запланировали спринт. И скажем в итоге пара задачи из какой-то userstory не успели сделать. Как с ними правильно поступить? Чтобы tfs правильно учел. Перенести эту userstory в следующий спринт? Или скопировать?
Ну это мелочи.
Если какой-то PBI не успели сделать, то убираете его из спринта,
переоцениваете с учетом того, что уже сделано и решаете
что с ним делать дальше (например, переносите в следующий спринт).
