День 1366. #TypesAndLanguages
Пару Слов об Оценках и Стори-Пойнтах. Начало
Стори-Пойнты (Story Points - SP) представляют собой сложность, риск, трудоёмкость и объём пользовательской истории. Истории оцениваются в баллах, чтобы получить относительный размер каждой из них, чтобы затем планировать будущее. Однако при планировании спринта нужно разбить историю на задачи.
Допустим, вы делите истории на задачи, которые длятся не более одного дня. Однако в этом случае вы фактически уберёте трудоёмкость из SP, поскольку каждая задача основана на ровно одном трудодне.
У вас может быть простая история, но она займёт много времени, например, написание документации. В этом случае история должна иметь немного стори-пойнтов, но всё же может занять больше времени, чем история на разработку трудного функционала. Аналогично, написание 3х документов не должно иметь в 3 раза больше SP, чем написание одного. Трудоёмкость выше, а остальные измерения остались прежними, поэтому SP не должны возрастать линейно.
Как разделить истории на задачи? Если вы можете распараллелить какую-то работу, то её следует разделить на несколько задач. Если нет, и в задаче нет логического «чекпойнта», то это должна быть одиночная задача. Технически задача (и история) должна быть выполнена за спринт, это единственное требование. Однако, если ожидается, что задача займёт больше половины спринта, то стоит попытаться её поделить.
Мы разбили истории на задачи. Какие истории включить в предстоящий спринт? Можно рассчитать производительность команды, особенно если команда стабильна. Это может дать представление о том, сколько времени займёт работа, исходя из предыдущих спринтов. Однако, использовать производительность команды в стори-пойнтах для планирования спринта значит не понимать их смысл.
Допустим, в команде 5 человек, команда стабильна, и в последнем спринте закончили 25 историй в 1 стори-пойнт каждая. В следующем спринте задачи в 3 SP каждая. Сколько задач взять? Если вы думаете, что 8, это означает, что вы используете SP как ещё одну единицу времени и что ваши оценки растут линейно. Это неверно. 3 задачи по 1 SP не равны 1 задаче в 3 SP (поскольку есть и другие факторы, учитываемые при оценке). Но есть ещё проблема: в предыдущем спринте каждый член команды работал над 5 задачами в 1 SP, т.е. производительность каждого 5 SP за спринт. Поэтому, если взять больше 5 задач в 3 SP, кому-то придётся взять на себя 2 задачи, а это уже 6 SP.
Можно решить только приступить к задаче и перенести её на следующий спринт, но это противоречит идее планирования и обязательности. Agile-подход направлен на устранение неопределённости и рисков, а не на избавление от планирования и обязательств. Программисты утверждают, что плохо предсказывают будущее, поэтому хотят планировать небольшие шаги. Тем не менее, всё равно необходимо завершать работу, за которую вы взялись в спринте. Если вы берёте задачу с мыслью «я не закончу её, но хотя бы начну», то делаете неправильно. Вы должны разделить задачу на части и взять одну часть, которую сможете выполнить в спринте. Agile-подход и стори-пойнты нужны для того, чтобы полностью избежать оценок по времени, а для того, чтобы сделать их более реалистичными и надёжными. Вам всё ещё нужно закончить работу за спринт, т.е временные рамки фиксированы размером спринта.
Вместо 8-ми задач по 3 SP стоит взять 5. Это большая разница: 15 SP против 25. И по этой причине команда может выполнять разное количество SP в каждом спринте. Если вы заранее знаете, сколько SP вы выделите при планировании спринта, то это полностью противоречит идее стори-пойнтов.
Можно рассчитывать производительность и скорость. Но не нужно использовать эти значения для планирования работы внутри спринта. SP — не единицы измерения времени.
Как же перейти от SP ко времени? Никак. Мы можем зафиксировать только работу, выполненную в текущем спринте. SP могут быть соотнесены с оценками времени, но не могут диктовать их, а оценки времени не могут быть выведены из SP.
Продолжение следует…
Источник https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/
Пару Слов об Оценках и Стори-Пойнтах. Начало
Стори-Пойнты (Story Points - SP) представляют собой сложность, риск, трудоёмкость и объём пользовательской истории. Истории оцениваются в баллах, чтобы получить относительный размер каждой из них, чтобы затем планировать будущее. Однако при планировании спринта нужно разбить историю на задачи.
Допустим, вы делите истории на задачи, которые длятся не более одного дня. Однако в этом случае вы фактически уберёте трудоёмкость из SP, поскольку каждая задача основана на ровно одном трудодне.
У вас может быть простая история, но она займёт много времени, например, написание документации. В этом случае история должна иметь немного стори-пойнтов, но всё же может занять больше времени, чем история на разработку трудного функционала. Аналогично, написание 3х документов не должно иметь в 3 раза больше SP, чем написание одного. Трудоёмкость выше, а остальные измерения остались прежними, поэтому SP не должны возрастать линейно.
Как разделить истории на задачи? Если вы можете распараллелить какую-то работу, то её следует разделить на несколько задач. Если нет, и в задаче нет логического «чекпойнта», то это должна быть одиночная задача. Технически задача (и история) должна быть выполнена за спринт, это единственное требование. Однако, если ожидается, что задача займёт больше половины спринта, то стоит попытаться её поделить.
Мы разбили истории на задачи. Какие истории включить в предстоящий спринт? Можно рассчитать производительность команды, особенно если команда стабильна. Это может дать представление о том, сколько времени займёт работа, исходя из предыдущих спринтов. Однако, использовать производительность команды в стори-пойнтах для планирования спринта значит не понимать их смысл.
Допустим, в команде 5 человек, команда стабильна, и в последнем спринте закончили 25 историй в 1 стори-пойнт каждая. В следующем спринте задачи в 3 SP каждая. Сколько задач взять? Если вы думаете, что 8, это означает, что вы используете SP как ещё одну единицу времени и что ваши оценки растут линейно. Это неверно. 3 задачи по 1 SP не равны 1 задаче в 3 SP (поскольку есть и другие факторы, учитываемые при оценке). Но есть ещё проблема: в предыдущем спринте каждый член команды работал над 5 задачами в 1 SP, т.е. производительность каждого 5 SP за спринт. Поэтому, если взять больше 5 задач в 3 SP, кому-то придётся взять на себя 2 задачи, а это уже 6 SP.
Можно решить только приступить к задаче и перенести её на следующий спринт, но это противоречит идее планирования и обязательности. Agile-подход направлен на устранение неопределённости и рисков, а не на избавление от планирования и обязательств. Программисты утверждают, что плохо предсказывают будущее, поэтому хотят планировать небольшие шаги. Тем не менее, всё равно необходимо завершать работу, за которую вы взялись в спринте. Если вы берёте задачу с мыслью «я не закончу её, но хотя бы начну», то делаете неправильно. Вы должны разделить задачу на части и взять одну часть, которую сможете выполнить в спринте. Agile-подход и стори-пойнты нужны для того, чтобы полностью избежать оценок по времени, а для того, чтобы сделать их более реалистичными и надёжными. Вам всё ещё нужно закончить работу за спринт, т.е временные рамки фиксированы размером спринта.
Вместо 8-ми задач по 3 SP стоит взять 5. Это большая разница: 15 SP против 25. И по этой причине команда может выполнять разное количество SP в каждом спринте. Если вы заранее знаете, сколько SP вы выделите при планировании спринта, то это полностью противоречит идее стори-пойнтов.
Можно рассчитывать производительность и скорость. Но не нужно использовать эти значения для планирования работы внутри спринта. SP — не единицы измерения времени.
Как же перейти от SP ко времени? Никак. Мы можем зафиксировать только работу, выполненную в текущем спринте. SP могут быть соотнесены с оценками времени, но не могут диктовать их, а оценки времени не могут быть выведены из SP.
Продолжение следует…
Источник https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/
👍6
День 1367. #TypesAndLanguages
Пару Слов об Оценках и Стори-Пойнтах. Продолжение
Начало
Нам нужны оценки по времени
Нужно ведь планировать работу наперёд.
Да. Поэтому оценивать задачи в стори-пойнтах — плохо. Программисты разные: у них разный опыт, разные навыки, им нравятся разные части разработки ПО. Нельзя просто придумать коэффициент для перевода SP в часы, так как каждый спринт индивидуален и каждый программист индивидуален, поэтому придётся знать эти коэффициенты для каждого человека и уметь предсказывать будущее (поскольку они меняются с каждым спринтом). Из-за этого программисту очень просто объяснить, почему он работал над задачей «слишком долго»: потому, что SP не передают никакой оценки времени (кроме того, что должны укладываться в один спринт).
Но заинтересованные стороны должны знать, сколько времени это займёт. Во-первых, потому что они хотят планировать бюджет. Во-вторых, потому что необходимо координировать множество других вещей (маркетинг, реклама, продажи и т. д.). В-третьих, потому что если какие-то проекты будут длиться слишком долго, то их проще отменить.
Поскольку программистов редко заботят нетехнические вещи, они хотят избавиться от ответственности. И именно поэтому им нравится оценивать задачи в стори-пойнтах. Не нужно думать о часах, и у них есть очень хорошее объяснение, что дела будут сделаны «когда они будут сделаны». Очевидно, что это мало полезно всем остальным, и хорошие инженеры это понимают. Если вы считаете, что нормально оценивать задачи в SP, то представьте, что сантехник говорит вам, что починка вашей раковины «займет 8 SP». Очевидно, вас это не устроит, вместо этого вы ожидаете оценки по времени. Как ни странно, программисты часто утверждают, что разработка ПО отличается от «реальной жизни», и поэтому они не могут оценивать по времени надолго. Это неправда.
Как это должно выглядеть?
Как только вы разбиваете истории на задачи, вы оцениваете каждую задачу в часах (или днях, или любой другой единице времени). Затем просто выполняете расчёты, чтобы проверить, какие задачи вы можете включить в спринт. И на основе этого определяете, какие пользовательские истории вы обработаете.
Производительность и инкременты
Прежде чем перейти к фактическим единицам времени, мы рассмотрим производительность. Вы не можете использовать производительность для планирования спринта: если вы заранее знаете, сколько SP вам нужно сделать за спринт, то вы делаете это неправильно. Спринты предназначены для фиксации того, какие пользовательские истории будут выполнены полностью, и фактическое количество SP будет отличаться от спринта к спринту.
Однако, когда команда стабильна, вы можете рассчитать производительность и использовать её, чтобы оценить, достаточно ли у вас запланировано работы на какой-то период времени (до следующего релиза). Стратегический анализ бизнеса стоит дорого, да и планы со временем меняются. Нет смысла планировать что-то на 3 года вперед, потому что, скорее всего, планы устареют. В то же время хорошо бы иметь некоторое представление о том, сколько работы вам предстоит и над чем вы будете работать в течение следующих 6 месяцев.
Если вы подсчитаете, что в среднем команда набирает X стори-пойнтов за спринт, то вы можете посмотреть сколько работы вам предстоит сделать, сколько из неё оценено в SP, и достаточно ли вам работы до следующего релиза. Просто умножаете производительность на количество спринтов до релиза. Дело не в том, чтобы быть суперточным, а в том, чтобы понимать, сколько времени это займёт. Если вы видите, что у вас достаточно стори-поинтов, чтобы заполнить работой следующий год, то нет необходимости делать бизнес-анализ с вашим клиентом сейчас, это может подождать до следующего месяца. Может быть и наоборот. Вы думаете, что вам хватит работы на ближайшие 6 месяцев, а по оценке получается только на 5. Делайте выводы.
Окончание следует…
Источники:
- https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/
- https://blog.adamfurmanek.pl/2022/06/18/types-and-programming-languages-part-13/
Пару Слов об Оценках и Стори-Пойнтах. Продолжение
Начало
Нам нужны оценки по времени
Нужно ведь планировать работу наперёд.
Да. Поэтому оценивать задачи в стори-пойнтах — плохо. Программисты разные: у них разный опыт, разные навыки, им нравятся разные части разработки ПО. Нельзя просто придумать коэффициент для перевода SP в часы, так как каждый спринт индивидуален и каждый программист индивидуален, поэтому придётся знать эти коэффициенты для каждого человека и уметь предсказывать будущее (поскольку они меняются с каждым спринтом). Из-за этого программисту очень просто объяснить, почему он работал над задачей «слишком долго»: потому, что SP не передают никакой оценки времени (кроме того, что должны укладываться в один спринт).
Но заинтересованные стороны должны знать, сколько времени это займёт. Во-первых, потому что они хотят планировать бюджет. Во-вторых, потому что необходимо координировать множество других вещей (маркетинг, реклама, продажи и т. д.). В-третьих, потому что если какие-то проекты будут длиться слишком долго, то их проще отменить.
Поскольку программистов редко заботят нетехнические вещи, они хотят избавиться от ответственности. И именно поэтому им нравится оценивать задачи в стори-пойнтах. Не нужно думать о часах, и у них есть очень хорошее объяснение, что дела будут сделаны «когда они будут сделаны». Очевидно, что это мало полезно всем остальным, и хорошие инженеры это понимают. Если вы считаете, что нормально оценивать задачи в SP, то представьте, что сантехник говорит вам, что починка вашей раковины «займет 8 SP». Очевидно, вас это не устроит, вместо этого вы ожидаете оценки по времени. Как ни странно, программисты часто утверждают, что разработка ПО отличается от «реальной жизни», и поэтому они не могут оценивать по времени надолго. Это неправда.
Как это должно выглядеть?
Как только вы разбиваете истории на задачи, вы оцениваете каждую задачу в часах (или днях, или любой другой единице времени). Затем просто выполняете расчёты, чтобы проверить, какие задачи вы можете включить в спринт. И на основе этого определяете, какие пользовательские истории вы обработаете.
Производительность и инкременты
Прежде чем перейти к фактическим единицам времени, мы рассмотрим производительность. Вы не можете использовать производительность для планирования спринта: если вы заранее знаете, сколько SP вам нужно сделать за спринт, то вы делаете это неправильно. Спринты предназначены для фиксации того, какие пользовательские истории будут выполнены полностью, и фактическое количество SP будет отличаться от спринта к спринту.
Однако, когда команда стабильна, вы можете рассчитать производительность и использовать её, чтобы оценить, достаточно ли у вас запланировано работы на какой-то период времени (до следующего релиза). Стратегический анализ бизнеса стоит дорого, да и планы со временем меняются. Нет смысла планировать что-то на 3 года вперед, потому что, скорее всего, планы устареют. В то же время хорошо бы иметь некоторое представление о том, сколько работы вам предстоит и над чем вы будете работать в течение следующих 6 месяцев.
Если вы подсчитаете, что в среднем команда набирает X стори-пойнтов за спринт, то вы можете посмотреть сколько работы вам предстоит сделать, сколько из неё оценено в SP, и достаточно ли вам работы до следующего релиза. Просто умножаете производительность на количество спринтов до релиза. Дело не в том, чтобы быть суперточным, а в том, чтобы понимать, сколько времени это займёт. Если вы видите, что у вас достаточно стори-поинтов, чтобы заполнить работой следующий год, то нет необходимости делать бизнес-анализ с вашим клиентом сейчас, это может подождать до следующего месяца. Может быть и наоборот. Вы думаете, что вам хватит работы на ближайшие 6 месяцев, а по оценке получается только на 5. Делайте выводы.
Окончание следует…
Источники:
- https://blog.adamfurmanek.pl/2022/06/11/types-and-programming-languages-part-12/
- https://blog.adamfurmanek.pl/2022/06/18/types-and-programming-languages-part-13/
👍6
День 1368. #TypesAndLanguages
Пару Слов об Оценках и Стори-Пойнтах. Окончание
Начало
Продолжение
Цикл обратной связи
Стори-пойнты используются не только для планирования релизов, но и для относительной оценки вашей работы. Вам нужно сравнивать вещи друг с другом и уметь сказать, какие вещи «большие», а какие «маленькие». Это должны знать все стороны.
Сначала клиент указывает, что нужно сделать. Затем нам нужно провести бизнес-анализ с клиентом, чтобы получить некоторые детали, разбить работу на пользовательские истории. Далее инженеры-программисты должны собраться вместе и оценить работу в стори-пойнтах. Они не должны оценивать точную продолжительность в часах/днях/месяцах. Им нужно только показать, какие задачи «большие», а какие «маленькие».
Затем вы снова передаёте эти оценки клиенту, чтобы он мог определить приоритеты. Клиент может не знать, что функция «большая» с точки зрения технической сложности, когда она кажется небольшой с точки зрения результата для клиента: парочка изменений в UI, улучшение производительности или что-то подобное. Вот зачем нужны стори-поинты: чтобы клиент мог скорректировать приоритеты и указать, какие дела нужно сделать в первую очередь, а какие можно отложить или отменить.
Наконец, клиент составляет список. Затем команды инженеров собираются вместе и планируют спринт. На этом этапе отбрасывается понятие стори-пойнтов. Пользовательские истории разбиваются на задачи и фиксируются конкретные пользовательские истории, которые должны быть реализованы в спринте.
Планирование в единицах времени
Если вы используете производительность, чтобы рассчитать, достаточно ли у вас работы на следующие 6 месяцев, то вы эффективно используете стори-пойнты как единицу времени. И в данном случае это нормально, потому что это всего лишь прогноз, а не обязательство, какие пользовательские истории следует выполнить. Может показаться, что мы из Agile вернулись к модели Waterfall. Нет, потому что мы корректируем процесс по ходу дела. В Waterfall мы сначала анализируем работу, потом делаем реализацию, потом тестируем, а потом уже разворачиваем. И всё. При спиральном (инкрементном, agile) подходе мы работаем в терминах релизов: планируем гораздо меньшую часть работы, и поставляем её. Вот в чём разработка ПО немного отличается от строительства домов. Вы переезжаете в новый дом только после завершения строительства. Однако при разработке ПО мы начинаем использовать продукт, даже если он ещё не готов, и делаем это гораздо раньше. В этом суть поэтапной работы: мы не ждём, пока дом будет «готов», мы въезжаем, как только у нас есть одна комната, без окон, без потолка и без входных дверей.
Однако мы не можем быть точны. Годовую работу мы не оценим идеально, мы всегда пропустим дедлайн. Но мы рискуем, потому что можем исправить траекторию на ходу. Все меняется: мы можем потерять техническое преимущество, потерять инвестора, люди могут уйти из компании или попасть под автобус. Есть много вещей, которые могут пойти не так, поэтому просто нужно признать, что мы не будем точны. Но дело не в том, чтобы через год понять, что мы пропустили дедлайн, а в том, чтобы выяснить это заранее и быть «достаточно точными».
Как быть достаточно точным?
История показывает, что оценки экспертов не бывают точны. Мы можем ограничить незавершённую работу, уменьшить скрытую работу, автоматизировать рутинную работу, чтобы улучшить процесс и получить более надёжные оценки. Можем использовать метод Монте-Карло, находить критические пути и моделировать различные сценарии. Но мы также можем просто переоценить наши планы и предположить, что 30% из них не будут реализованы в течение года. Всё это приемлемо, если вы знаете, насколько вы неточны.
Источник: https://blog.adamfurmanek.pl/2022/06/18/types-and-programming-languages-part-13/
Пару Слов об Оценках и Стори-Пойнтах. Окончание
Начало
Продолжение
Цикл обратной связи
Стори-пойнты используются не только для планирования релизов, но и для относительной оценки вашей работы. Вам нужно сравнивать вещи друг с другом и уметь сказать, какие вещи «большие», а какие «маленькие». Это должны знать все стороны.
Сначала клиент указывает, что нужно сделать. Затем нам нужно провести бизнес-анализ с клиентом, чтобы получить некоторые детали, разбить работу на пользовательские истории. Далее инженеры-программисты должны собраться вместе и оценить работу в стори-пойнтах. Они не должны оценивать точную продолжительность в часах/днях/месяцах. Им нужно только показать, какие задачи «большие», а какие «маленькие».
Затем вы снова передаёте эти оценки клиенту, чтобы он мог определить приоритеты. Клиент может не знать, что функция «большая» с точки зрения технической сложности, когда она кажется небольшой с точки зрения результата для клиента: парочка изменений в UI, улучшение производительности или что-то подобное. Вот зачем нужны стори-поинты: чтобы клиент мог скорректировать приоритеты и указать, какие дела нужно сделать в первую очередь, а какие можно отложить или отменить.
Наконец, клиент составляет список. Затем команды инженеров собираются вместе и планируют спринт. На этом этапе отбрасывается понятие стори-пойнтов. Пользовательские истории разбиваются на задачи и фиксируются конкретные пользовательские истории, которые должны быть реализованы в спринте.
Планирование в единицах времени
Если вы используете производительность, чтобы рассчитать, достаточно ли у вас работы на следующие 6 месяцев, то вы эффективно используете стори-пойнты как единицу времени. И в данном случае это нормально, потому что это всего лишь прогноз, а не обязательство, какие пользовательские истории следует выполнить. Может показаться, что мы из Agile вернулись к модели Waterfall. Нет, потому что мы корректируем процесс по ходу дела. В Waterfall мы сначала анализируем работу, потом делаем реализацию, потом тестируем, а потом уже разворачиваем. И всё. При спиральном (инкрементном, agile) подходе мы работаем в терминах релизов: планируем гораздо меньшую часть работы, и поставляем её. Вот в чём разработка ПО немного отличается от строительства домов. Вы переезжаете в новый дом только после завершения строительства. Однако при разработке ПО мы начинаем использовать продукт, даже если он ещё не готов, и делаем это гораздо раньше. В этом суть поэтапной работы: мы не ждём, пока дом будет «готов», мы въезжаем, как только у нас есть одна комната, без окон, без потолка и без входных дверей.
Однако мы не можем быть точны. Годовую работу мы не оценим идеально, мы всегда пропустим дедлайн. Но мы рискуем, потому что можем исправить траекторию на ходу. Все меняется: мы можем потерять техническое преимущество, потерять инвестора, люди могут уйти из компании или попасть под автобус. Есть много вещей, которые могут пойти не так, поэтому просто нужно признать, что мы не будем точны. Но дело не в том, чтобы через год понять, что мы пропустили дедлайн, а в том, чтобы выяснить это заранее и быть «достаточно точными».
Как быть достаточно точным?
История показывает, что оценки экспертов не бывают точны. Мы можем ограничить незавершённую работу, уменьшить скрытую работу, автоматизировать рутинную работу, чтобы улучшить процесс и получить более надёжные оценки. Можем использовать метод Монте-Карло, находить критические пути и моделировать различные сценарии. Но мы также можем просто переоценить наши планы и предположить, что 30% из них не будут реализованы в течение года. Всё это приемлемо, если вы знаете, насколько вы неточны.
Источник: https://blog.adamfurmanek.pl/2022/06/18/types-and-programming-languages-part-13/