Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.
Три года мы использовали Planning Poker. При этом подходе каждый программист в закрытую оценивает историю в 0.5, 1, 2, 3, 5, 8, 13, 20, 40 условных единиц (story points). Затем люди, которые дали наиболее высокие и низкие оценки, объясняют, почему эта задача кажется им такой сложной, или наоборот — простой. Обсуждение продолжается, пока все не придут к единой оценке.
После завершения спринта скрам мастер подсчитывает сколько story point в завершенных историях. Исходя из собранной статистики он определяет, сколько задач поместится в следующий спринт.
Чтобы дать оценку пользовательской истории, разработчики должны понимать как ее реализовывать, хотя бы в общих чертах. Чтобы понимать как реализовывать, нужно понимать, чего хочет клиент. Все это выясняют и обсуждают во время оценки. На одну историю команда тратит по 5-30 минут. При этом в обсуждении активно участвуют 2-3 человека, которые лучше разбираются в теме. Остальные тратят время зря.
Так как время на оценку все-таки сильно ограничено, разработчики часто упускают важные моменты. Это может привести к тому, что историю сильно недооценят, или ее придется переделывать с нуля.
Иногда оказывается, что менеджер не узнал у клиента важных нюансов, и оценку истории приходится откладывать.
Одну историю мы оцениваем в 20. Еще десять историй оцениваем по 2 каждую. Оценка десяти маленьких историй в сумме равняется одной большой. Однако, большую историю почти всегда делают дольше, чем несколько маленьких с той же оценкой.
При таком способе оценки 20 > 2*10.
Почему так происходит? Чем больше размер истории, тем больше возможностей забыть что-то учесть при ее оценке. Даже если все учесть, вероятность недооценить на 50% одну историю больше, чем вероятность настолько же недооценить десять историй.
Посередине выполнения задачи размера 20, менеджер спрашивает у разработчика, когда тот закончит. Разработчик либо ответит что-то невнятное, либо выдаст слишком оптимистичную оценку, либо возьмет свою оптимистичную оценку и умножит ее на 2. Точной оценки менеджер вряд ли добьется.
Это связано с тем, что для ответа разработчик делит задачу на ту часть, которую сделал, и ту, которая осталась, после чего быстро оценивает оставшуюся часть. Он может ошибиться и при попытке учесть все, что ему еще осталось делать, и в оценке размера этой части. Тем более, что эту оценку он дает в одиночку и очень быстро, чтобы не заставлять менеджера ждать.
Команда дает истории оценку 40, — это значит, что программисты на самом деле не знают, сколько займет задача. Они до конца не понимают, как будут ее делать.
Та же проблема, хоть и в меньшей степени, касается оценок 20, 13, 8. Если историю, описанную парой предложений, оценивают в 13 или 20, — это также означает, что у разработчиков нет полного понимания, как ее делать. Пытаться всей командой подробно описать решение задачи во время оценки — неэффективная трата времени. Этим может заняться и один человек. Для решения этой проблемы, мы за каждой задачей назначали ответственного, который расписывал решение до командной оценки. Однако, не было четких критериев, насколько подробно расписывать решение. Иногда достаточно и пары предложений, а иногда нужно несколько абзацев, чтобы решение задачи было понятным.
Пытаясь разобраться с этими проблемами мы пришли к следующей идее: истории надо делить на подзадачи до тех пор, пока ни у кого не останется вопросов, сколько времени уйдет на решение каждой. Подзадачи должны быть равного размера, чтобы мы могли получить оценку, просто сложив их количество.
В итоге наш процесс проектирования-оценки выглядит так:
После оценки всех задач мы получаем оценку пользовательской истории. Количество подзадач в истории — это и есть ее оценка в story point’ах.
Так как количество вариантов оценки сильно ограничено, оценка командой происходит быстрее. Можно еще больше ускорить командную оценку, если не проводить голосование по каждой подзадаче, а задавать открытые вопросы:
Четкие критерии разделения задач на подзадачи и оценка результата проектирования всей командой уменьшает вероятность забыть про какие-либо важные моменты и не позволяют схалтурить при проектировании. Когда человек, ответственный за проработку задачи, разбивает ее на достаточно маленькие части, у него автоматически возникают вопросы как к заказчику фичи, так и к существующему коду, который возможно придется отрефакторить. Это лучше, чем когда те же вопросы возникают посреди работы над задачей.
Более того, если какие то вопросы не пришли в голову проектировщику, их зададут ему во время командной оценки. Когда же проработка задачи происходит только во время работы над тикетом, то за это отвечает только один человек и какие-то важные вопросы он может и не задать, в результате чего задачу возможно придется переделывать.
У нас достаточно часто историю прорабатывает один человек, а выполняет ее другой. Но даже если вы захотите закреплять задачу за разработчиком до оценки, все равно полезно выделять отдельно этап проектирования и оценки задачи командой. На этапе оценки кто-то из команды может сказать, как сделать задачу проще, или может выясниться, что ее вообще не надо делать — где-то уже есть нужный функционал. Хотя, конечно, закрепление задач за разработчиками не добавляет процессу гибкости. Я рекомендую построить процесс так, чтобы спроектированную задачу мог выполнять любой разработчик в команде.
Так как у каждой подзадачи есть понятные программисту критерии приемки, то он всегда понимает, сколько подзадач он сделал и сколько осталось. Поэтому он легко может ответить на вопрос, когда задача отправится в приемку.
Разделение одной задачи на подзадачи обычно занимает в районе 5-30 минут, но на некоторые истории, состоящие из нескольких задач, в сложных случаях может уходить пара дней.
Стоит ли тратить столько времени только ради более точной оценки? Конечно нет. Но по факту почти все время уходит не на разбиение задачи, а на проработку и проектирование ее решения. Чтобы подробно описать решение некоторых историй может понадобится обсудить ее с несколькими людьми и просмотреть существующий код. На это и уходит много времени. Сам процесс разбиения на подзадачи при этом занимает полчаса в худшем случае.
Заранее спроектированное решение, которое может оценить команда перед началом работы, стоит того, чтобы тратить на него столько времени.
Обычно при Agile подходах проектирование проводят одновременно с разработкой. С этой точки зрения наш подход менее агильный. Однако, главное в Agile — это доставлять ценность клиенту как можно быстрее. Если вы выделяете MVP, то не так уж важно в каком порядке вы его разрабатываете. Обратную связь от клиента вы все равно получите только после окончания разработки MVP.
Так как команда в открытую оценивает то разбиение, которое им предоставил ответственный за проектирование, может возникнуть эффект привязки — члены команды будут соглашаться с уже заданным разбиением, особенно если его сделал более авторитетный разработчик. В нашей практике это проблема не сильно проявляется, обычно люди не стесняются говорить, что подзадача слишком большая, слишком маленькая или непонятна. Но, если в вашей команде возникают проблемы с этим, можно выносить каждую подзадачу на закрытое голосование с вариантами:
При этом, перед голосованием все, кому непонятна подзадача, могут задать вопросы.
При выполнении подробно расписанной задачи у программиста остается гораздо меньше свободы для творчества. Если разработчик будет только писать код для спроектированных за него историй, то он не будет расти и может быть сильно демотивирован. Поэтому важно, чтобы каждый разработчик в команде имел шанс заниматься проектированием — разбивать истории на задачи и подзадачи должны все. Не страшно, если более опытные разработчики чаще занимаются проработкой пользовательских историй. Важно, чтобы даже джуниорам перепадало немного проектирования.
Процесс оценки задач через разбиение достаточно трудоемок, поэтому его не получится использовать для быстрой оценки. Для предварительной примерной оценки историй можно использовать экспертную оценку двух-трех человек. Такая оценка, будет неточной, но для приоритезации ее достаточно. Давать предварительную оценку в story point’ах не стоит, чтобы не возникало иллюзии точности этой оценки.
Я рекомендую использовать для предварительной оценки старые добрые человеко-недели: пол недели, одна, две, месяц. После оценки истории командой, люди, давшие экспертную оценку, могут быстро узнать насколько они ошиблись — достаточно перевести их человеко-недели в story point’ы (среднюю скорость одного разработчика мы знаем из статистики).
По возможности старайтесь не оценивать задачи до приоритезации. Если после оценки истории ее надолго отложат, то вы потеряете время:
Поэтому на оценку должны приходить задачи, которые уже точно нужно делать. Если для выставления приоритетов нужно знать, сколько времени займёт история, следует обходиться предварительной оценкой.
Если же вас устраивает оценка с помощью Planning Poker, но есть проблемы с качеством проектирования, вы можете разбивать историю на подзадачи после оценки и приоритезации. Тогда процесс разработки будет выглядеть следующим образом:
При таком подходе вы все-равно получаете ревью результата проектирования до того, как разработчик начнет писать код. Хотя суммарно такой процесс скорее всего займет больше времени.
Для примера возьмем следующую фичу: хотим реализовать push-уведомления в браузере со своим js-плагином для подписки, с блекджеком и поэтессами. В идеале хотим:
Выделим из этой фичи MVP — выкинем все что можно, чтобы при этом получилась полезная хотя бы для одного из клиентов фича:
MVP фичи можно разбить на следующие задачи, каждую из которых можно делать независимо:
Немного поизучаем гугловскую документацию web push уведомлений, после чего разобьем первую задачу на подзадачи:
В результате мы оценили первую задачу в 5S (если, конечно, команда согласится с таким разбиением). Таким же образом разбиваются и остальные задачи.
Оценка команды подсказывает, когда история будет готова. Для этого учитывается количество story points, выполненных за предыдущие недели.
История, считается выполненной, только если она прошла приемку или ей даже пользуются. Реальный интерес представляет именно то, с какой скоростью мы поставляем ценность для клиентов, а не как быстро задачи попадают в приемку.
Чтобы такая оценка работала, необходимо договориться о максимальных сроках на ревью и приемку. Например, у нас ответственный за ревью задачи обязан сделать первое ревью в течение 2 дней с момента отправки задачи на ревью, а доработки по результатам ревью должен принимать в течение дня.
Если не получается выделить небольшое MVP и некоторые фичи растягиваются на два спринта, то статистика по спринтам будет прыгать. Но даже в этом случае можно вычислить скорость команды, если взять средний результат за последние несколько спринтов.
Как бы вы хорошо не прорабатывали задачу, всегда остается вероятность что-то не учесть. Если в процессе работы над фичой появляются новые неучтенные подзадачи, надо их дооценить. Тогда вы всегда будете знать примерное время до завершения задачи. Также можете собирать статистику, насколько story point’ов вы дооценили за спринт. Это поможет понять погрешность оценки.
Недоцененные story point’ы нельзя использовать при подсчете скорости команды. Если команда в прошлом спринте сделала историй на 50 story point’ов и во время спринта дооценила их на 10 story point’ов — это не значит, что в следующий спринт можно взять 60 story point’ов. Берите 50, так как и в этот раз вы могли что-то недооценить.
Когда мы начали заранее делить истории на подзадачи, проблем с недооценкой больших задач стало меньше. Больше не возникает ситуаций, когда задачу приходится переделывать с нуля из-за неправильного проектирования.
Рекомендую вам попробовать этот подход, если вы тратите слишком много времени команды на Planning Poker, есть проблемы с оценкой больших задач или проектированием.
Немного о Planning Poker
Три года мы использовали Planning Poker. При этом подходе каждый программист в закрытую оценивает историю в 0.5, 1, 2, 3, 5, 8, 13, 20, 40 условных единиц (story points). Затем люди, которые дали наиболее высокие и низкие оценки, объясняют, почему эта задача кажется им такой сложной, или наоборот — простой. Обсуждение продолжается, пока все не придут к единой оценке.
После завершения спринта скрам мастер подсчитывает сколько story point в завершенных историях. Исходя из собранной статистики он определяет, сколько задач поместится в следующий спринт.
В чем собственно проблема
Разбираемся в истории на ходу
Чтобы дать оценку пользовательской истории, разработчики должны понимать как ее реализовывать, хотя бы в общих чертах. Чтобы понимать как реализовывать, нужно понимать, чего хочет клиент. Все это выясняют и обсуждают во время оценки. На одну историю команда тратит по 5-30 минут. При этом в обсуждении активно участвуют 2-3 человека, которые лучше разбираются в теме. Остальные тратят время зря.
Так как время на оценку все-таки сильно ограничено, разработчики часто упускают важные моменты. Это может привести к тому, что историю сильно недооценят, или ее придется переделывать с нуля.
Иногда оказывается, что менеджер не узнал у клиента важных нюансов, и оценку истории приходится откладывать.
Иллюзия точности оценки больших историй
Одну историю мы оцениваем в 20. Еще десять историй оцениваем по 2 каждую. Оценка десяти маленьких историй в сумме равняется одной большой. Однако, большую историю почти всегда делают дольше, чем несколько маленьких с той же оценкой.
При таком способе оценки 20 > 2*10.
Почему так происходит? Чем больше размер истории, тем больше возможностей забыть что-то учесть при ее оценке. Даже если все учесть, вероятность недооценить на 50% одну историю больше, чем вероятность настолько же недооценить десять историй.
Насколько процентов ты закончил свою работу?
Посередине выполнения задачи размера 20, менеджер спрашивает у разработчика, когда тот закончит. Разработчик либо ответит что-то невнятное, либо выдаст слишком оптимистичную оценку, либо возьмет свою оптимистичную оценку и умножит ее на 2. Точной оценки менеджер вряд ли добьется.
Это связано с тем, что для ответа разработчик делит задачу на ту часть, которую сделал, и ту, которая осталась, после чего быстро оценивает оставшуюся часть. Он может ошибиться и при попытке учесть все, что ему еще осталось делать, и в оценке размера этой части. Тем более, что эту оценку он дает в одиночку и очень быстро, чтобы не заставлять менеджера ждать.
40 = неизвестность
Команда дает истории оценку 40, — это значит, что программисты на самом деле не знают, сколько займет задача. Они до конца не понимают, как будут ее делать.
Та же проблема, хоть и в меньшей степени, касается оценок 20, 13, 8. Если историю, описанную парой предложений, оценивают в 13 или 20, — это также означает, что у разработчиков нет полного понимания, как ее делать. Пытаться всей командой подробно описать решение задачи во время оценки — неэффективная трата времени. Этим может заняться и один человек. Для решения этой проблемы, мы за каждой задачей назначали ответственного, который расписывал решение до командной оценки. Однако, не было четких критериев, насколько подробно расписывать решение. Иногда достаточно и пары предложений, а иногда нужно несколько абзацев, чтобы решение задачи было понятным.
Делим на части
Пытаясь разобраться с этими проблемами мы пришли к следующей идее: истории надо делить на подзадачи до тех пор, пока ни у кого не останется вопросов, сколько времени уйдет на решение каждой. Подзадачи должны быть равного размера, чтобы мы могли получить оценку, просто сложив их количество.
В итоге наш процесс проектирования-оценки выглядит так:
- На входе пользовательская история — минимальная функциональность, которая принесет пользу клиенту. У пользовательской истории обязательно должны быть критерии приемки понятные менеджеру или клиенту, чтобы ее можно было принять.
- Если история выглядит слишком большой, то выделяется MVP: выбрасывается все, без чего клиент может на первых порах обойтись. По завершении этой истории делается следующая, в которой уже добавленная функциональность будет расширяться.
- За этой историей назначается ответственный, который в случае необходимости разбивает историю на отдельные задачи так, чтобы каждую задачу можно было делать параллельно с другими. Часто встречаются пользовательские истории, которые не имеет смысла разбивать на задачи: либо они не параллелятся, либо история слишком маленькая. По возможности задачи нужно делать такими, чтобы их можно было протестировать независимо. Тогда тестирование можно будет начать после завершения первой задачи, а не ждать, пока доделают всю историю.
- Затем ответственный разбивает каждую задачу на подзадачи. Каждая подзадача — пункт, с описанием от одного предложения до абзаца. Он может не иметь никакого смысла для непрограммистов. Отдельные подзадачи вроде “написать класс” и “написать тесты на этот класс” — это нормально. Разбивая на подзадачи ответственный руководствуется следующими правилами:
- все подзадачи должны быть примерно одинакового минимального размера (1 story point)
- для каждой подзадачи должно быть понятно, что в ней надо сделать
- у подзадачи есть понятные программисту критерии приемки (класс написан, тесты проходят)
- Команда оценивает задачу. При командной оценке происходит ревью того, насколько хорошо ответственный проработал решение и разбил задачу на подзадачи, нет ли среди подзадач слишком больших или слишком маленьких. При этом:
- если конкретная подзадача кому-то непонятна, ее расписывают подробнее;
- если команда решает, что подзадача слишком большая, ее разбивают на части;
- если при чтении описания подзадач возникает много вопросов, на которые ответственный не может ответить, задачу отправляют на более подробную проработку;
- если команде не нравится решение задачи, его меняют на ходу или отправляют на перепроектирование.
После оценки всех задач мы получаем оценку пользовательской истории. Количество подзадач в истории — это и есть ее оценка в story point’ах.
Аргументы за
Быстрый этап командной оценки
Так как количество вариантов оценки сильно ограничено, оценка командой происходит быстрее. Можно еще больше ускорить командную оценку, если не проводить голосование по каждой подзадаче, а задавать открытые вопросы:
- Какие подзадачи непонятны?
- Какие подзадачи стоит разделить?
- Какие подзадачи стоит объединить?
Формализация качества проектирования
Четкие критерии разделения задач на подзадачи и оценка результата проектирования всей командой уменьшает вероятность забыть про какие-либо важные моменты и не позволяют схалтурить при проектировании. Когда человек, ответственный за проработку задачи, разбивает ее на достаточно маленькие части, у него автоматически возникают вопросы как к заказчику фичи, так и к существующему коду, который возможно придется отрефакторить. Это лучше, чем когда те же вопросы возникают посреди работы над задачей.
Более того, если какие то вопросы не пришли в голову проектировщику, их зададут ему во время командной оценки. Когда же проработка задачи происходит только во время работы над тикетом, то за это отвечает только один человек и какие-то важные вопросы он может и не задать, в результате чего задачу возможно придется переделывать.
У нас достаточно часто историю прорабатывает один человек, а выполняет ее другой. Но даже если вы захотите закреплять задачу за разработчиком до оценки, все равно полезно выделять отдельно этап проектирования и оценки задачи командой. На этапе оценки кто-то из команды может сказать, как сделать задачу проще, или может выясниться, что ее вообще не надо делать — где-то уже есть нужный функционал. Хотя, конечно, закрепление задач за разработчиками не добавляет процессу гибкости. Я рекомендую построить процесс так, чтобы спроектированную задачу мог выполнять любой разработчик в команде.
Четкое понимание насколько задача завершена
Так как у каждой подзадачи есть понятные программисту критерии приемки, то он всегда понимает, сколько подзадач он сделал и сколько осталось. Поэтому он легко может ответить на вопрос, когда задача отправится в приемку.
Аргументы против
Требуется время на подготовку задачи к командной оценке
Разделение одной задачи на подзадачи обычно занимает в районе 5-30 минут, но на некоторые истории, состоящие из нескольких задач, в сложных случаях может уходить пара дней.
Стоит ли тратить столько времени только ради более точной оценки? Конечно нет. Но по факту почти все время уходит не на разбиение задачи, а на проработку и проектирование ее решения. Чтобы подробно описать решение некоторых историй может понадобится обсудить ее с несколькими людьми и просмотреть существующий код. На это и уходит много времени. Сам процесс разбиения на подзадачи при этом занимает полчаса в худшем случае.
Заранее спроектированное решение, которое может оценить команда перед началом работы, стоит того, чтобы тратить на него столько времени.
Это ж не агильно
Обычно при Agile подходах проектирование проводят одновременно с разработкой. С этой точки зрения наш подход менее агильный. Однако, главное в Agile — это доставлять ценность клиенту как можно быстрее. Если вы выделяете MVP, то не так уж важно в каком порядке вы его разрабатываете. Обратную связь от клиента вы все равно получите только после окончания разработки MVP.
Возможен эффект привязки
Так как команда в открытую оценивает то разбиение, которое им предоставил ответственный за проектирование, может возникнуть эффект привязки — члены команды будут соглашаться с уже заданным разбиением, особенно если его сделал более авторитетный разработчик. В нашей практике это проблема не сильно проявляется, обычно люди не стесняются говорить, что подзадача слишком большая, слишком маленькая или непонятна. Но, если в вашей команде возникают проблемы с этим, можно выносить каждую подзадачу на закрытое голосование с вариантами:
- слишком большая — разделить;
- слишком маленькая — объединить с другой;
- в самый раз.
При этом, перед голосованием все, кому непонятна подзадача, могут задать вопросы.
Разработчик не может расти выполняя задачи, в которых уже все продумано до него
При выполнении подробно расписанной задачи у программиста остается гораздо меньше свободы для творчества. Если разработчик будет только писать код для спроектированных за него историй, то он не будет расти и может быть сильно демотивирован. Поэтому важно, чтобы каждый разработчик в команде имел шанс заниматься проектированием — разбивать истории на задачи и подзадачи должны все. Не страшно, если более опытные разработчики чаще занимаются проработкой пользовательских историй. Важно, чтобы даже джуниорам перепадало немного проектирования.
Нельзя быстро дать оценку большой истории
Процесс оценки задач через разбиение достаточно трудоемок, поэтому его не получится использовать для быстрой оценки. Для предварительной примерной оценки историй можно использовать экспертную оценку двух-трех человек. Такая оценка, будет неточной, но для приоритезации ее достаточно. Давать предварительную оценку в story point’ах не стоит, чтобы не возникало иллюзии точности этой оценки.
Я рекомендую использовать для предварительной оценки старые добрые человеко-недели: пол недели, одна, две, месяц. После оценки истории командой, люди, давшие экспертную оценку, могут быстро узнать насколько они ошиблись — достаточно перевести их человеко-недели в story point’ы (среднюю скорость одного разработчика мы знаем из статистики).
По возможности старайтесь не оценивать задачи до приоритезации. Если после оценки истории ее надолго отложат, то вы потеряете время:
- это время вы могли потратить на что-то полезное клиенту уже сейчас;
- к тому моменту, когда вы все-таки возьметесь за эту историю, ее оценка может стать неактуальной из-за рефакторингов или новых фичей.
Поэтому на оценку должны приходить задачи, которые уже точно нужно делать. Если для выставления приоритетов нужно знать, сколько времени займёт история, следует обходиться предварительной оценкой.
Если же вас устраивает оценка с помощью Planning Poker, но есть проблемы с качеством проектирования, вы можете разбивать историю на подзадачи после оценки и приоритезации. Тогда процесс разработки будет выглядеть следующим образом:
- оцениваем истории с помощью Planning Poker,
- приоритезируем,
- разработчик расписывает решение до подзадач,
- команда оценивает это решение,
- разработчик пишет код.
При таком подходе вы все-равно получаете ревью результата проектирования до того, как разработчик начнет писать код. Хотя суммарно такой процесс скорее всего займет больше времени.
Пример
Для примера возьмем следующую фичу: хотим реализовать push-уведомления в браузере со своим js-плагином для подписки, с блекджеком и поэтессами. В идеале хотим:
- js-плагин работает во всех браузерах, поддерживающих push-уведомления;
- js-плагин работает как на https так и на http сайтах;
- отправлять уведомления можно как массово вручную, так и по событию для отдельных потребителей;
- отслеживать доставки и клики в уведомлениях.
Выделим из этой фичи MVP — выкинем все что можно, чтобы при этом получилась полезная хотя бы для одного из клиентов фича:
- уберем поддержку Safari, так как у него своя реализация push-уведомлений;
- уберем поддержку http сайтов, так как для их поддержки нужно писать сложный хак;
- оставим только массовую отправку уведомлений, так как большинству клиентов с https сайтами нужна в первую очередь именно массовая отправка;
- в начале обойдемся без статистики, так что отслеживание доставки и кликов отложим на потом.
MVP фичи можно разбить на следующие задачи, каждую из которых можно делать независимо:
- js-библиотека отвечающая за подписку и отображение уведомлений.
- Микро-сервис, отправляющий пуш уведомления.
- UI для массовой отправки уведомлений.
Немного поизучаем гугловскую документацию web push уведомлений, после чего разобьем первую задачу на подзадачи:
- Реализовать в js-библиотеке следующие методы:
- проверка, что браузер поддерживает пуш уведомления;
- проверка, подписан ли пользователь сайта на уведомления;
- подписка на уведомления.
- Написать тесты, проверяющие, что эти методы корректно работают в браузерах, которые поддерживают и не поддерживают пуш уведомления.
Мы используем для этого BrowserStack. В качестве альтернативы в этом пункте может стоять задача протестить js-методы вручную в разных браузерах. - Научиться работать с serviceWorker’ами.
Обработкой push-уведомлений занимается serviceWorker. Мы раньше их не использовали, поэтому выделим 1S на изучение новой технологии. - Написать serviceWorker, обрабатывающий уведомления. Добавить регистрацию этого serviceWorker’а в метод подписки.
- Написать тесты на serviceWorker.
В результате мы оценили первую задачу в 5S (если, конечно, команда согласится с таким разбиением). Таким же образом разбиваются и остальные задачи.
Немного про статистику
Оценка команды подсказывает, когда история будет готова. Для этого учитывается количество story points, выполненных за предыдущие недели.
История, считается выполненной, только если она прошла приемку или ей даже пользуются. Реальный интерес представляет именно то, с какой скоростью мы поставляем ценность для клиентов, а не как быстро задачи попадают в приемку.
Чтобы такая оценка работала, необходимо договориться о максимальных сроках на ревью и приемку. Например, у нас ответственный за ревью задачи обязан сделать первое ревью в течение 2 дней с момента отправки задачи на ревью, а доработки по результатам ревью должен принимать в течение дня.
Если не получается выделить небольшое MVP и некоторые фичи растягиваются на два спринта, то статистика по спринтам будет прыгать. Но даже в этом случае можно вычислить скорость команды, если взять средний результат за последние несколько спринтов.
Дооценка задач
Как бы вы хорошо не прорабатывали задачу, всегда остается вероятность что-то не учесть. Если в процессе работы над фичой появляются новые неучтенные подзадачи, надо их дооценить. Тогда вы всегда будете знать примерное время до завершения задачи. Также можете собирать статистику, насколько story point’ов вы дооценили за спринт. Это поможет понять погрешность оценки.
Недоцененные story point’ы нельзя использовать при подсчете скорости команды. Если команда в прошлом спринте сделала историй на 50 story point’ов и во время спринта дооценила их на 10 story point’ов — это не значит, что в следующий спринт можно взять 60 story point’ов. Берите 50, так как и в этот раз вы могли что-то недооценить.
Заключение
Когда мы начали заранее делить истории на подзадачи, проблем с недооценкой больших задач стало меньше. Больше не возникает ситуаций, когда задачу приходится переделывать с нуля из-за неправильного проектирования.
Рекомендую вам попробовать этот подход, если вы тратите слишком много времени команды на Planning Poker, есть проблемы с оценкой больших задач или проектированием.
