Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Почему это кажущееся противоречие? Ранее я писал о причинах. Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.
Но мне часто задают связанный с этим вопрос, который я хочу задать здесь:
Мне любопытно, почему вы не используете story points для планирования спринта. Я думал, что смысл измерения скорости в story points был, частично, в том, чтобы определять, сколько мы можем взять (или зафиксировать) в спринт. Используете ли вы только story point для долгосрочного планирования (например, планирования релизов)?
Я не использую story points для планирования спринта, потому что story points это полезная долгосрочная мера. Но points не полезны в краткосрочной перспективе.
Было бы уместно, чтобы команда сказала: «У нас средняя скорость 20 story points, и у нас осталось 6 спринтов, поэтому мы закончим около 120 story points в этих шести спринтах».
Было бы неуместным, чтобы команда сказала: «У нас средняя скорость 20 story points, поэтому мы закончим в следующем спринте». Это не работает.
Предположим, что баскетбольная команда находится в середине своего сезона. На текущий момент они сыграли 41 игру и забили в среднем 98 очков за игру. Было бы уместно сказать: «Вероятно, мы будем забивать в среднем по 98 очков за игру в оставшейся части сезона». Но они не должны говорить перед какой-либо конкретной игрой: «У нас в среднем 98, поэтому мы заберем 98 сегодня». Вот почему я говорю, что скорость является полезным долгосрочным предсказателем, но не является полезным краткосрочным предсказателем.
Скорость будет изменяться от спринта к спринту.
Вот почему я хочу, чтобы команды планировали свои спринты, глядя на бэклог продукта, выбирая одну из наиболее важных вещей, которую они могли бы сделать, разбивая этот элемент/user story бэклога продукта на задачи и оценивая задачи, спрашивая себя, могут ли они взять на себя обязательства по выпуску этого элемента бэклога продукта и затем повторяли пока они не будут заполнены. Нет обсуждения story points. Нет обсуждения скорости. Речь идет только об обязательствах, и мы решаем, сколько мы можем выполнить, разбивая пункты бэклога продукта на задачи и оценивая их.
Когда команда заканчивает планировать спринт таким образом, то вполне вероятно, что количество story points, которые они неосознанно преследуют, должно быть близко к их среднему значению, но оно будет меняться.
Также будет верно, что команда будет выполнять примерно одинаковое количество часов от одного спринта до следующего. Я использую термин «capacity», чтобы ссылаться на это количество часов, потому что скорость зарезервирована для того, чтобы ссылаться на измерение объема запланированных или выполненных работ, как указано в единицах, используемых для оценки бэклога продукта (что я рекомендую делать с использованием story points).
Об авторе: Mike Cohn является одним из авторов Scrum-методологии разработки программного обеспечения. Он один из основателей Agile Alliance и Scrum Alliance. Специализируется на помощи компаниям во внедрении и улучшении использования agile процессов и методов создания высокопроизводительных команд.
Список литературы: Agile Estimating and Planning, Mike Cohn, 2005 год.
P.S. А вы оцениваете бэклог спринта в часах или story points?
Комментарии (35)
codecity
27.10.2018 21:26+2Скорость будет изменяться от спринта к спринту.
Хм. Так и скорость, выраженная в часах — тоже будет изменяться? Ведь люди не роботы — устали, начали работать медленнее. То что раньше делалось за пол часа — будут делать за час-полтора. Получается хрен редьки не слаще.
gt814 Автор
28.10.2018 17:40Все верно, не важно в каких единицах — скорость разная в каждом спринте.
И Cohn говорит о том, что при планировании спринта не нужно обсуждать скорость.
Story Points и скорость он использует только для долгосрочного планирования, для оценки бэклога продукта. Но скорость там усредненная.
AlexTheLost
27.10.2018 23:47Один раз работал в конторке где были эти сторипоиты, да и вообще нужно было наперёд сказать сколько у меня времени займет та или иная задача.
Имхо бред, я что лопатой копаю? Даже с лопатой можно неверно оценить может под землёй будет куча камней или какая нибудь коммуникация и все оценки сбились.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них, дал слишком много — а почему так много можно же быстрее...)
Ну или очередной тупой манагер который не занимался разработкой никогда, возомнил себя гуру планирования и без понимания сути вещей заставляет всех вокруг страдать точными оценками и отчетами по ним.
Поэтому сейчас когда я слышу о стори поинтах или аналогичной херни, сразу же ставлю крест на предложении.gdt
28.10.2018 05:49Зря вы так, в этом деле надо без фанатизма — и тогда у всех всё будет хорошо. Насколько я помню, сторипоинты нужны в том числе для оценки фокус-фактора команды, да и никто же не требует от вас точной оценки — покер планнинг вроде бы должен повышать её точность, отчасти поэтому оценка в сторипоинтах, а не в часах.
AlexTheLost
28.10.2018 13:01-1В том и дело что требую где то явно, где то ничего не говорят но на разработчике висит уже груз ответственности в виде поставленой оценки.
ApeCoder
28.10.2018 13:09А как он висит, если ничего не говорят. Вообще, насколько я помню, сначала в XP предлагали использовать «идеальные часы» и velocity оценивалась как отношение идеальных часов к календарным. Потом решили что это подбивает начальников давить на девелоперов, чтобы они работали согласно идельным часам, потом ввели сторипоинты, чтобы сделать единицу измерения абтрактной и отвязанной от времени.
Нон как видно ни начальники ни девелоперы не хотят разбираться в этой истории — первые предпочитают давить, вторые — страдать и винить сторипоинты :).
VolCh
29.10.2018 12:54+1Когда у меня просят оценку задачи то ответственность на мне в момент когда оценку даю. Когда приступаю к задаче, то никакой дополнительной ответственности из-за того, что я же и давал на неё оценку у меня не возникает. Оценка — это не обязательство. И даже если я многократно превысил свою же оценку, то что-то схожее с чувством вины у меня возникает по отношению к ошибочной оценке, а не низкой производительности. Когда заканчиваю задачу и вижу что оценка была не точной, то анализирую почему оценка была не точной, а не почему я не уложился в срок, чтобы в следующий раз подобную задачу оценить в три дня, например, а не в один. Или в один, но указать дополнительно риски, которые потребуют переоценки задачи в случае их «срабатывания».
В любом случае главное, что надо помнить, чтоб не чувствовать лишний груз ответственности: оценка — это не обязательство. Когда вы уже работаете над задачей ваше обязанность сделать задачу как можно быстрее, а не уложиться в оценку.
zviryatko
28.10.2018 10:45+3Ага, классно получится если при планировании работы на спринт кто-то за вас скажет часы за которые выполнит работу, а делать её придется вам, вот тогда вы и поймёте почему удобно использовать какие-то-там поинты.
P.s. лично мне нравится система футболок: разделение задач на s, m, l, по договоренности можно добавлять xs, xl, xxl, но обычно это лишнее.
AlexTheLost
28.10.2018 13:11Логичная альтернатива это не использование оценок по времени. Точнее той формы что описана в статье и относится к этим бредовым методологиям.
По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальнику. И корректируются в процессе работы. Смысла в чем то другом не вижу.
Когда вы управляете конвеером где налаженный тех процесс, такие оценки вполне возможны, но даже тут нет страховки от случайных событий — кто-то заболел или отключили электричество.
В IT уже начиная с самого среднего проекта эти оценки бред.
Может когда вся работа это постоянно клепание CRUD или типового УГ на Joomla и аналогах, оценки ещё возможны, при условии что команда слажена. В более менее сложном проекте это уже бред.boblenin
28.10.2018 15:22Странно. Редко приходится слышать такое аргументирование против стори поинтов.
> По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальник
На глазок — не работает. Оценка по времени для фичи, которая требует взаимодействия множества людей длительное время требует слишком большого количества информации, которой один человек практически никогда не обладает. Иногда надеятся на «опыт» оценивающего, но происходит либо суровая переоценка (а значит перерасход), либо просто низкая точность.
Оценки времени получаются с таким суровым разбросом, что на всех уровнях их все потом добивают многократными временными буферами и все равно сроки срываются (ну либо опять же закладываются такие суровые буферы, что некоторые компании можно сразу закрывать). Потому и используюся строи поинты. Их можно откалибровать с помощью исторических наблюдений. Правильно отработаный процесс оценки бэклога в стори поинтах дает не оценку, а вилку которая нужна для того, чтобы другие подразделения компании могли координировать свою работу с програмистами (маркетинг, продажи, hr,… да кто угодно).
В рамках спринта использование часов для задач — более-менее оправдано. Хотя бы потому, что строи поинты привязываются к комманде, а задачи к отдельным людям, а значит для отдельного разработчика становятся не преминимыми. Ну и при достаточном уровне декомпозиции временнЫе оценки по задачам так сильно не плывут.
Eldhenn
28.10.2018 11:06> Имхо бред, я что лопатой копаю?
Не, если задача декомпозирована на элементарные операции, то конечно да. Только я не разу не видел такой декомпозиции. Да и ответственность просто переносится на сторону аналитиков — а они смогут заренее сказать, сколько времени у них займёт декомпозиция задачи?AlexTheLost
28.10.2018 13:05Сама идея о том что какие то аналитики, дают оценки времени выполнения задач программистам и делают их декомпозицию, вам это уже само по себе не кажется бредом. Вы программистом работаете? Очень интересно узнать.)
VolCh
29.10.2018 13:07Почему бред? В целом это как работа аналитиков искать закономерности типа «оценки этого программиста в половине случае в два раза больше факта, а в половине в три раза меньше», а задача менеджера составить план работ так, чтобы был запас процентов в 80 и при этом иметь в виду риски что может потребоваться 200
boblenin
28.10.2018 15:39фичу придумывают аналитики, историю или юзкейс придумывает product owner в соавторстве с коммандой, а вот таски придумывают сами разработчики.
фича — это зачем мы хотим что-то сделать, история/юзкейс — что мы хотим сделать, а таски — это как мы это будем делать.
enjoykaz
28.10.2018 11:25Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них
Ох, мы тут все стали забывать, что разработчиков берут потому, что они самые умные в команде и всем важно их мнение, а не потому что они должны пахать.AlexTheLost
28.10.2018 13:28Никто вам манагерам ничего не должен.)
Вы забываете что разработчик это, в основном, квалифицированный специалист. Который обменивает свои знания на деньги компании. А типичный манагер, какой нибудь бывший тестировщик или БА, который 0 в разработке, и трясется за своё место потому что в другой компании он никому не нужен, а в этой получил место просто потому что работает там уже много времени и глубо знаком с проектом, но ни как не потому что он какой то одаренный и с глубоким понимание специалист.
Вот и получается что манагер судит по себе, он жутко зависим от компании и часто ограниченный, в его понимании все такие же как он, а разработчик ресурс. Только вот все не так. Уже не эра заводов и значение квалифицированного специалиста на проекте который может его поддерживать в живом состоянии, решая все проблемы это огромная ценность для бизнеса но не для этого специалиста. С учетом текущей высококонкурентной среды, когда неплохую работу можно найти за неделю.
Разработчик не пахарь, а ценность.
Кол-во манагеров я бы везде тотально сократил, потому что они обычно только мешают. Сколько я проектов уже перевидал, почти все если уже быть честным, где все держится на одном двух, главных разработчиках, и они решают все реальные проблемы, а манагер который только мешает, думает что это результат его 'гениальной' работы и избавится от этого ненужного баласта, постоянно отвлекающего, напрягающего и генерирующего поток бессмысленных идей и предложений по проекту, трудно. Почему то в головах многих людей старой формации, которые сейчас в силу своих возрастных преимуществ владеют большинством бизнесов, прочно заселе восприятие о необходимости манагера.
Но это не беда, сейчас уже много компаний которые стремятся к плоской структуре и они постепенно выигрывают позиции, за счет своей эффективности.
G1yyK
28.10.2018 11:53sp про сложность и не разу про скорость. с задачей в 1 sp можно 3 дня делать монтонную просту работу, и с задачей в 5 sp -3 дня разбиратся и за полчаса доделать ее.
И оценить мы примерно можем сколько мы sp делаем, считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Ну а если не уложились и сильно всохатились, есть ретро на котором можно обсудить как улучшить ситауцию.
scrum — это процесс в котором надо научится жить. и менеджеры которые привыкли все возводить в абсолют(скорость разработки) для них трудно переключится на sp.mkshma
28.10.2018 14:30scrum — это процесс в котором надо научится жить
Его надо закопать и никогда не откапывать. Надеюсь когда-нибудь люди придут к этому.AlexTheLost
28.10.2018 23:03Любой адекватный разработчик это понимает. Манагерам удобно так выжимать соки.
Когда я слышу это слово scrum или понимаю что эта бездарная идея где то рядом. Сразу делаю выводы кто передо мной и что нужно валить.
boblenin
28.10.2018 15:28> sp про сложность и не разу про скорость.
Когда вы их используете для планирования (имеется ввиду planning собрание в scrum) — так думать можно и так проще. Но вообще, после того, как она прокорректирована несколькими спринтами — это комплексная оценка. В ней закладываются накладные рассходы на отпуска, собрания, автоматизированное тестирование, коммункации внутри комманды и с заказчиком.
> считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под over-commitment.G1yyK
28.10.2018 17:45+1> Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под over-commitment.
На самом деле нет, это средний показатель наоборот позволят лишнего ничего не втянуть, что мы точно не успеем(бизнес старается под завязку спринт нафаршировать), но как правила в спринте нужно место оставить для различных форсмажоров, плюс задачи по улучшению процесса. Бывает даже так что, бизнесу точно нужна небольшая фича которая делаться достаточно просто, она ставится целью спринта, а остальное по возможности.
Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут главное донести их необходимость/суметь продать. И если что то идет не так, лучше завалится с задачами которые не влияют на цель спринта.boblenin
29.10.2018 03:28> На самом деле нет, это средний показатель наоборот позволят лишнего ничего не втянуть, что мы
> точно не успеем(бизнес старается под завязку спринт нафаршировать)
Если вы берете среднее, значит у вас уже были спринты с меньшей производительностью.
> Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут
> главное донести их необходимость/суметь продать.
От кого?
ApeCoder
28.10.2018 11:59"Речь идет только об обязательствах"
https://www.scrum.org/resources/commitment-vs-forecast
"One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications. "
otchgol
28.10.2018 19:30Мне, как человеку страдающему от скрамма, безумно интересно узнать смысл оценок в сторипоинтах. Что дает количество сторипоинтов менеджменту я не могу понять. Слова не пусные. Я вижу пару моментов определяющих бестолковость сторипоинтов:
По моему опыту бэклог бэклог глубже одного спринта редкость. Не знаю кто готов оценивать бэклог на три спринта вперед, если к следующему спринту он может и должен быть реорганизован.
Оценка задачи базруется на опыте оценивающих. Равномерность команды недостижимый миф, поэтому отпуск любого члена команды меняет вес сторипоинта довольно значительно. Ценность метрики такой точности весьма сомнителен.
Планирование на срок дальше одного релиза сомнительно, поскольку релиз способен поменять ситуацию довольно радикально. Индустрия тоже может и будет меняться. При этому перенос релиза на один-два спринт, как правило, допустимо. Какой тогда смысл?
Все это я говорю после перехода команды с оценок в часах на сторипоинты. У нас довольно странный менеджмент. Он относится к Сазерлэнду как к иконе и не пытается ничего адаптировать, потому и перестраиваем едущую машину без оглядок. Спустя четыре месяца использования сторипоинтов могу лишь констатировать несходящиеся спринты.ApeCoder
28.10.2018 22:10Вот статья самого Сазерленда www.scruminc.com/story-points-why-are-they-better-than
Я так понимаю, что это нужно для того, чтобы примерно представлять сколько фич можно сделать за данное время и как-то приблизительно планировать вперед учитывая все эти отпуски и болезни усредненно.
Есть разный софт и он разрабатывался по разному. Для кого-то нужно планировать вперед, чтобы координироваться с переводчиками, маркетингом и прочим.
Вопрос. А что такое «несходящиеся спринты» и какой реальный негативный эффект от этого?otchgol
29.10.2018 00:17Дисклаймеры: Я не фанат Сазерленда ни отца ни сына ни духа, который у них, вероятно, есть. Я не был ни на одном скрам тренинге. Я ненавижу скрам и любые концепции обесценивания девелопера.
Несмотря на мою необученность я в курсе идей скрама. В реальности все может быть не так, как у них. В нашей команде никто не пробует восполнить отсутствие человека и доделать его работу, кроме случаев крайней необходимости. Это нормальная экономия времени — тому, кто делал сделать это быстрее, а очередность задач не имеет значения при скраме.
Люди команды очень-очень разные. Это не однородное месево, воспеваемое сазерлендом. Он требует увольнения любых людей выше или ниже среднего уровня команды. Это тупик. Команда не будет развиваться, потмоу как добиться равномерного развития невозможно. В общем утопия.
По моему опыту развитие продуктом никак не связано с маркетингом. Все маркетинговые мероприятия сеюминутны и концептуальны и с перспективой не связаны. Это мой личный опыт наблюдения за несколькими продуктами одной конторы. Но очень долгий. Маркетинг абстрактен.
Сходимость спринта для нас это приближение burn down chart к идеальной форме или ходя бы падение до 0 в конце спринта. Для нашего менеджмента это единственная ментрика, потому краеугольная.ApeCoder
29.10.2018 09:14Он требует увольнения любых людей выше или ниже среднего уровня команды.
Можно цитату?
Для нашего менеджмента это единственная ментрика, потому краеугольная.
Тогда надо увеличить оценки раза в четыре — по большей части итерации начнут сходиться. Оценка это вероятностный процесс, если хотите 100% уверенность в том, что выйдете в ноль до конца спринта, надо планировать бесконечное время
vyatsek
29.10.2018 13:56Я не знаю кто такой Майкл Кох и какой продукт он написал. Изначально оценка в sp выглядит очень слабой попыткой характеризовать динамику. На этот "Гербалайф" купилась целая куча деланных менеджеров, которые мало того что в софте не понимают, так и в принципе в управлении.
Пусть возьмём модель scrum, sp и так далее. Может изучал не так детально, но никто не приводил граничных условий когда эта модель работает, а когда нет. В энтерпрайзе, когда пара строчек в минуту может обернуться тем, что тебе надо поговорить 3 другими командами, у тех свои зависимости, в итоге строчка становится очень дорогой, и часто это выясняется только в процессе работы. Оценка в sp уже уехала. Второе легаси говнокод, в нем очень сложно давать оценки, т.к. не всегда понятно, какое изменение что за собой тянет. Более того перед изменением часто надо сделать рефакторинг, чтобы не усугублять ситуацию. А там бывает и дизайн надо обсудить и какие-то варианты попробовать, оценка мало предсказуема.
Разный уровень знания кода и технологий, кто то уже работал, кому то немного изучить. Оценки разные.
По опыту для точных краткосрочных оценок нужен хороший и понимаемый код и слаженная работа команды, тогда все можно оценивать в часах, днях. Но чтобы построить слаженную команду и контролируемый процесс, необходимо применять совсем другие методики и инструменты.
Всегда поражало что как можно оценивать сложный процесс разработки по одному графику попугаев? Куча факторов, в том числе противодействующих аккумулируются в одном графике. Вот график пошел не туда куда надо, какие факторы на это повлияли, хрен знает.
Очень напоминает форекс разводил, вот тут будет фигура "голова-плечи", курс идёт по волнам Эллиота, создаваемыми давлением Бойля Мариотта, значит тут продаем и тут покупаем, с вас 100$ за торговлю на истории))
Прежде чем вообще что-то изучать, всегда оцениваю результат этих людей: что они уже сделали, а всякие продаваемых "Гербалайфа" с канбаном, скрамом, скейлд аджайл фреймворком идут лесом — слишком много продаванов. Посмотрите как организован процесс написания ядра линукс, вот процесс Торвальдса стоит изучить, потому что результат как говорится "на лицо", а что эти продаваны сделали я не знаю.vyatsek
29.10.2018 14:07Не ответил на главный вопрос автора. Все что можно оценить, оцениваем, все что нет, не оцениваем.
mkshma
Потому что, очевидно, story point берутся от балды и метрикой являться не могут.
G1yyK
ну почему же от балды, sp это сложность задачи как ее видит вся команда и есть очень четкие правила как считать их(нужен эталон в 1 sp и уже с ним сравнивать).
От балды берется только там где scrum для галочки
mkshma
Я пропустил какую-то революцию и мы теперь можем измерять сложность задачи не от балды? Вот это новость. Это напоминает ситуацию со спортсимами, где игроки часто спорят по поводу рейтингов персонажей, мол «вот у этого футболиста должен быть рейтинг 94, а не 92, разработчики накосячили!» И вроде как у разработчиков тоже как бы есть свой эталон «1 очка умений» для игрока, вот только все ли с такой оценкой согласны? Да и правильно ли разработчики оценили степень умений игрока? А черт его знает. Так же и в разработке. Простейший фикс на 3 строчки может откопать такой пласт технического долга, что вы еще 3 недели будете перебирать всю систему по кусочкам и выскребать оттуда все лишнее, а при планировании эта задача у вас пойдет с оценкой 1 sp и вы отстанете от графика аж на 3 недели. Даже постфактум мы не можем с достаточной точностью оценить сложность задачи, просто потому что не особо ясно что считать «сложностью». Поэтому и не могут sp считаться серьезной метрикой ну вот вообще никак, как и затраченные на работу часы.
G1yyK
Конечно никто вам не скажет что есть четкие критерии которых вы должны придерживаться для оценки сложности задач, НО каждая команда выбирает для себя эталон который берет за 1SP и уже этой задачей меряют все остальные.
И данный процесс итеративный и со временем эталонная задача изменится.
А про ту проблему про которую вы говорите — что фикс на 3 строчки кода, превращается в 3х недельную правку кода — Это должно разбиратся на ретро и понимать почему так вышло(потому что вы начали рефракторить все вокруг — большой технический долг, или задачу не разобрали — потому что задачи оцениваются не в строчках и оценка делается всей командой(тестирование, аналитика, разработка) — если так вышло, то тут либо все под забили на разбор задачи(да там 3 строчки поправить, ерунда).
Всякое бывает и каждый случай надо разбирать, именно разбирать, а не искать крайнего. Если технический долг большой, то наверное надо в бизнесовые задачи, как минимум вводить написание тестов, автотестов и тп.
gt814 Автор
Не понятно, как эталон сложности прикладывать к другим задачам.
Не происходит ли подмена понятия?
Что, на самом деле, мы вспоминаем трудоемкость аналогичных задач (потраченное время) и на основании этого называем количество story points?