Я расскажу о оценке работ(estimation) в скрам. Её рекомендуется проводить дважды — сначала в story points, на уровне user stories, а потом — в часах, на уровне заданий в текущей итерации. Так же я попытаюсь объяснить, почему это делается дважды.
У нас в компании решили более серьёзно отнестись к введению Agile принципов, а конкрентей — Scrum. Мне поручили внедрить это дело в небольшой проект, который должен быть готов к сентябрю, с 4 программистами и веб-дизайнером. Задача проекта — миграция html-сайта в Sharepoint 2010, и добавление многих новых функций.
Раньше мы как-то считали, что утренний Scrum митинг — это уже вполне такой нормальный скрам. Но, немного почитав и поковырявшись, оказалось, что в общем-то не совсем.
Итак, первоначальная оценка — guesstimate
Первоначальная оценка проекта производиться на уровне user stories которые находятся в Product Backlog. User stories рекомендуется писать в слегка незграбной, с первого взгляда, манере:
«Как [тип пользователя] я хочу [выполнить действие] чтобы [причина]» (As a [type of user] I want [some goal] so that [some reason]).
Например, вместо привычного «Студент должен иметь возможность выбрать желаемый курс» — «Как студент, я хочу выбрать желаемый курс чтобы получить нужные знания». С одной стороны, звучит очень искусственно, но с другой — и программист, и представитель бизнеса понимают, кто, что и зачем хочет сделать. В коротком предложении есть контекст, роль, действие и цель, всегда в той же самой структуре. Удобно. Хоть и непривычно.
Мой бэклог состоит из 40 историй такого уровня. Это — недостаточно детальные требования, чтоб произвести точные оценки, но кое-что можно сделать — оценить бэк-лог в story points.
Что такое story points? Это относительная оценка каждой истории. Теория предлагает использовать степень двойки для оценки( 2, 4, 8...) или ряд Фибоначчи (1, 2, 3, 5, 8...).
Для того, чтобы оценить, надо сначала выбрать систему, и максимальное значение. Мы решили использовать Фибоначчи, с максимальным значением 21.
Дальше, надо выбрать самую простую историю и оценить её как 1. В нашем случае это история — «Как пользователь, я хочу просмотреть информацию о тренерах, чтобы знать их компетенцию». После этого выбираем самую сложную историю, и оцениваем её как максимум, в нашем случае — 21. Это история «Как подписчик, я хочу заказать курс, чтобы я мог его посетить».
После этого теория предлагает оценить остальные требования, в порядке приоритета. Для этого можно использовать технику типа «Покер планирования» (Planning poker), где каждый программист пишет на листке свою оценку требования, а потом все одновременно показывают, и начинается обсуждение, если оценки сильно разные.
Оценивать весь бэклог не обязательно — достаточно оценить только истории на несколько итераций вперёд. Кроме того, к этой оценке надо будет возвращаться, потому что бэклог постоянно пополняется, меняются приоритеты.
Так почему же story points, а не дни?
Во-первых, на этом этапе не достаточно много известно о требованиях, чтобы провести точное планирование.
Во-вторых, программисты не захотят оценивать такие требования по времени, потому что вы их потом припомните… Им легче ответить вопрос «Настолько это большое?» чем «сколько это займёт?»
В-третьих, в нашем случае команда не знакома с технологией (Sharepoint только вышел), и точных оценок дать просто невозможно.
Какой в этом толк?
Во-первых, product owner может пересмотреть свои приоритеты. Раз история А «стоит» 13 очков, а Б всего лишь 2 — давайте сделаем её скорей.
Во-вторых, это помогает планированию. Если мы знаем, что в первом спринте мы сделали 50 story points, во втором — 55, то в третьем наверно тоже сделаем каких 55.
В-третьих, это проще. «А» сложнее «Б», поэтому 21.
А что дальше? Где нормальные цифры?
Обычные человеко-часы начинаются позже.
Первый спринт самый сложный, особенно у нас — с новой командой, новой технологией и новой методологией. Вместе с product owner мы опредилили 9 историй для первой итерации.
Для точной оценки мы сели с самым опытным программистом, и учитывая отсутствие опыта у остальных, провели оценку. По-нормальному и тут надо было в покер играть, но ситуация не та.
Чтобы получить точные оценки, каждую историю надо разбить на задания. Каждое задание должно быть не более 8 часов, чтобы за день было понятно, сделано оно или нет. Мы разбили наши истории на 2-10 заданий, примерно такого рода «Построить UI для страницы тренеров», «Подготовить список тренеров» и т.д. Оценили каждую в часах, и получилось… Что нам надо раза в 3 больше времени! Пришлось уменьшить бэклог итерации.
В итоге мы получили, что в первой итерации мы можем закончить 67 story points. Это — 105 часов работы. То есть, сейчас скорость нашей команды — 67 story points за итерацию. По мере того, как команда ознакомится с новой технолонией, скорость вырастет, и в следующем спринте мы сможем разработать больше story points. Используя оценку в часах, это было бы невозможно, или надо было бы выдумывать какие-то формулы, типа там, «в каждой последующей итерации мы спланируем на 10% больше чем в прошлой».
У нас в компании решили более серьёзно отнестись к введению Agile принципов, а конкрентей — Scrum. Мне поручили внедрить это дело в небольшой проект, который должен быть готов к сентябрю, с 4 программистами и веб-дизайнером. Задача проекта — миграция html-сайта в Sharepoint 2010, и добавление многих новых функций.
Раньше мы как-то считали, что утренний Scrum митинг — это уже вполне такой нормальный скрам. Но, немного почитав и поковырявшись, оказалось, что в общем-то не совсем.
Итак, первоначальная оценка — guesstimate
Первоначальная оценка проекта производиться на уровне user stories которые находятся в Product Backlog. User stories рекомендуется писать в слегка незграбной, с первого взгляда, манере:
«Как [тип пользователя] я хочу [выполнить действие] чтобы [причина]» (As a [type of user] I want [some goal] so that [some reason]).
Например, вместо привычного «Студент должен иметь возможность выбрать желаемый курс» — «Как студент, я хочу выбрать желаемый курс чтобы получить нужные знания». С одной стороны, звучит очень искусственно, но с другой — и программист, и представитель бизнеса понимают, кто, что и зачем хочет сделать. В коротком предложении есть контекст, роль, действие и цель, всегда в той же самой структуре. Удобно. Хоть и непривычно.
Мой бэклог состоит из 40 историй такого уровня. Это — недостаточно детальные требования, чтоб произвести точные оценки, но кое-что можно сделать — оценить бэк-лог в story points.
Что такое story points? Это относительная оценка каждой истории. Теория предлагает использовать степень двойки для оценки( 2, 4, 8...) или ряд Фибоначчи (1, 2, 3, 5, 8...).
Для того, чтобы оценить, надо сначала выбрать систему, и максимальное значение. Мы решили использовать Фибоначчи, с максимальным значением 21.
Дальше, надо выбрать самую простую историю и оценить её как 1. В нашем случае это история — «Как пользователь, я хочу просмотреть информацию о тренерах, чтобы знать их компетенцию». После этого выбираем самую сложную историю, и оцениваем её как максимум, в нашем случае — 21. Это история «Как подписчик, я хочу заказать курс, чтобы я мог его посетить».
После этого теория предлагает оценить остальные требования, в порядке приоритета. Для этого можно использовать технику типа «Покер планирования» (Planning poker), где каждый программист пишет на листке свою оценку требования, а потом все одновременно показывают, и начинается обсуждение, если оценки сильно разные.
Оценивать весь бэклог не обязательно — достаточно оценить только истории на несколько итераций вперёд. Кроме того, к этой оценке надо будет возвращаться, потому что бэклог постоянно пополняется, меняются приоритеты.
Так почему же story points, а не дни?
Во-первых, на этом этапе не достаточно много известно о требованиях, чтобы провести точное планирование.
Во-вторых, программисты не захотят оценивать такие требования по времени, потому что вы их потом припомните… Им легче ответить вопрос «Настолько это большое?» чем «сколько это займёт?»
В-третьих, в нашем случае команда не знакома с технологией (Sharepoint только вышел), и точных оценок дать просто невозможно.
Какой в этом толк?
Во-первых, product owner может пересмотреть свои приоритеты. Раз история А «стоит» 13 очков, а Б всего лишь 2 — давайте сделаем её скорей.
Во-вторых, это помогает планированию. Если мы знаем, что в первом спринте мы сделали 50 story points, во втором — 55, то в третьем наверно тоже сделаем каких 55.
В-третьих, это проще. «А» сложнее «Б», поэтому 21.
А что дальше? Где нормальные цифры?
Обычные человеко-часы начинаются позже.
Первый спринт самый сложный, особенно у нас — с новой командой, новой технологией и новой методологией. Вместе с product owner мы опредилили 9 историй для первой итерации.
Для точной оценки мы сели с самым опытным программистом, и учитывая отсутствие опыта у остальных, провели оценку. По-нормальному и тут надо было в покер играть, но ситуация не та.
Чтобы получить точные оценки, каждую историю надо разбить на задания. Каждое задание должно быть не более 8 часов, чтобы за день было понятно, сделано оно или нет. Мы разбили наши истории на 2-10 заданий, примерно такого рода «Построить UI для страницы тренеров», «Подготовить список тренеров» и т.д. Оценили каждую в часах, и получилось… Что нам надо раза в 3 больше времени! Пришлось уменьшить бэклог итерации.
В итоге мы получили, что в первой итерации мы можем закончить 67 story points. Это — 105 часов работы. То есть, сейчас скорость нашей команды — 67 story points за итерацию. По мере того, как команда ознакомится с новой технолонией, скорость вырастет, и в следующем спринте мы сможем разработать больше story points. Используя оценку в часах, это было бы невозможно, или надо было бы выдумывать какие-то формулы, типа там, «в каждой последующей итерации мы спланируем на 10% больше чем в прошлой».
