Как оценивать большие задачи

    Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

    image

    Немного о 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, — это также означает, что у разработчиков нет полного понимания, как ее делать. Пытаться всей командой подробно описать решение задачи во время оценки — неэффективная трата времени. Этим может заняться и один человек. Для решения этой проблемы, мы за каждой задачей назначали ответственного, который расписывал решение до командной оценки. Однако, не было четких критериев, насколько подробно расписывать решение. Иногда достаточно и пары предложений, а иногда нужно несколько абзацев, чтобы решение задачи было понятным.

    Делим на части


    Пытаясь разобраться с этими проблемами мы пришли к следующей идее: истории надо делить на подзадачи до тех пор, пока ни у кого не останется вопросов, сколько времени уйдет на решение каждой. Подзадачи должны быть равного размера, чтобы мы могли получить оценку, просто сложив их количество.

    В итоге наш процесс проектирования-оценки выглядит так:

    1. На входе пользовательская история — минимальная функциональность, которая принесет пользу клиенту. У пользовательской истории обязательно должны быть критерии приемки понятные менеджеру или клиенту, чтобы ее можно было принять.
    2. Если история выглядит слишком большой, то выделяется MVP: выбрасывается все, без чего клиент может на первых порах обойтись. По завершении этой истории делается следующая, в которой уже добавленная функциональность будет расширяться.
    3. За этой историей назначается ответственный, который в случае необходимости разбивает историю на отдельные задачи так, чтобы каждую задачу можно было делать параллельно с другими. Часто встречаются пользовательские истории, которые не имеет смысла разбивать на задачи: либо они не параллелятся, либо история слишком маленькая. По возможности задачи нужно делать такими, чтобы их можно было протестировать независимо. Тогда тестирование можно будет начать после завершения первой задачи, а не ждать, пока доделают всю историю.
    4. Затем ответственный разбивает каждую задачу на подзадачи. Каждая подзадача — пункт, с описанием от одного предложения до абзаца. Он может не иметь никакого смысла для непрограммистов. Отдельные подзадачи вроде “написать класс” и “написать тесты на этот класс” — это нормально. Разбивая на подзадачи ответственный руководствуется следующими правилами:

      • все подзадачи должны быть примерно одинакового минимального размера (1 story point)
      • для каждой подзадачи должно быть понятно, что в ней надо сделать
      • у подзадачи есть понятные программисту критерии приемки (класс написан, тесты проходят)

    5. Команда оценивает задачу. При командной оценке происходит ревью того, насколько хорошо ответственный проработал решение и разбил задачу на подзадачи, нет ли среди подзадач слишком больших или слишком маленьких. При этом:

      • если конкретная подзадача кому-то непонятна, ее расписывают подробнее;
      • если команда решает, что подзадача слишком большая, ее разбивают на части;
      • если при чтении описания подзадач возникает много вопросов, на которые ответственный не может ответить, задачу отправляют на более подробную проработку;
      • если команде не нравится решение задачи, его меняют на ходу или отправляют на перепроектирование.

    После оценки всех задач мы получаем оценку пользовательской истории. Количество подзадач в истории — это и есть ее оценка в 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 фичи можно разбить на следующие задачи, каждую из которых можно делать независимо:

    1. js-библиотека отвечающая за подписку и отображение уведомлений.
    2. Микро-сервис, отправляющий пуш уведомления.
    3. UI для массовой отправки уведомлений.

    Немного поизучаем гугловскую документацию web push уведомлений, после чего разобьем первую задачу на подзадачи:

    1. Реализовать в js-библиотеке следующие методы:
      • проверка, что браузер поддерживает пуш уведомления;
      • проверка, подписан ли пользователь сайта на уведомления;
      • подписка на уведомления.
    2. Написать тесты, проверяющие, что эти методы корректно работают в браузерах, которые поддерживают и не поддерживают пуш уведомления.
      Мы используем для этого BrowserStack. В качестве альтернативы в этом пункте может стоять задача протестить js-методы вручную в разных браузерах.
    3. Научиться работать с serviceWorker’ами.
      Обработкой push-уведомлений занимается serviceWorker. Мы раньше их не использовали, поэтому выделим 1S на изучение новой технологии.
    4. Написать serviceWorker, обрабатывающий уведомления. Добавить регистрацию этого serviceWorker’а в метод подписки.
    5. Написать тесты на serviceWorker.

    В результате мы оценили первую задачу в 5S (если, конечно, команда согласится с таким разбиением). Таким же образом разбиваются и остальные задачи.

    Немного про статистику


    Оценка команды подсказывает, когда история будет готова. Для этого учитывается количество story points, выполненных за предыдущие недели.

    История, считается выполненной, только если она прошла приемку или ей даже пользуются. Реальный интерес представляет именно то, с какой скоростью мы поставляем ценность для клиентов, а не как быстро задачи попадают в приемку.

    Чтобы такая оценка работала, необходимо договориться о максимальных сроках на ревью и приемку. Например, у нас ответственный за ревью задачи обязан сделать первое ревью в течение 2 дней с момента отправки задачи на ревью, а доработки по результатам ревью должен принимать в течение дня.

    Если не получается выделить небольшое MVP и некоторые фичи растягиваются на два спринта, то статистика по спринтам будет прыгать. Но даже в этом случае можно вычислить скорость команды, если взять средний результат за последние несколько спринтов.
    image

    Дооценка задач


    Как бы вы хорошо не прорабатывали задачу, всегда остается вероятность что-то не учесть. Если в процессе работы над фичой появляются новые неучтенные подзадачи, надо их дооценить. Тогда вы всегда будете знать примерное время до завершения задачи. Также можете собирать статистику, насколько story point’ов вы дооценили за спринт. Это поможет понять погрешность оценки.

    Недоцененные story point’ы нельзя использовать при подсчете скорости команды. Если команда в прошлом спринте сделала историй на 50 story point’ов и во время спринта дооценила их на 10 story point’ов — это не значит, что в следующий спринт можно взять 60 story point’ов. Берите 50, так как и в этот раз вы могли что-то недооценить.

    Заключение


    Когда мы начали заранее делить истории на подзадачи, проблем с недооценкой больших задач стало меньше. Больше не возникает ситуаций, когда задачу приходится переделывать с нуля из-за неправильного проектирования.

    Рекомендую вам попробовать этот подход, если вы тратите слишком много времени команды на Planning Poker, есть проблемы с оценкой больших задач или проектированием.
    Mindbox 42,80
    Компания
    Поделиться публикацией
    Комментарии 19
    • –1
      Разделение одной задачи на подзадачи обычно занимает в районе 5-30 минут, но на некоторые истории, состоящие из нескольких задач, в сложных случаях может уходить пара дней.

      Вы за 30 минут должны весь объём спринта оценить, добрый вечер.


      Посередине выполнения задачи размера 20, менеджер спрашивает у разработчика, когда тот закончит.

      Интересный у вас agile и тамада весёлый :)

      • +2
        Вы за 30 минут должны весь объём спринта оценить, добрый вечер.

        Когда мы оценивали с помощью Planning Poker на оценку 2-ух недельного спринта уходило не меньше полутора часа. Слишком много возникает вопросов к реализации и требованиям клиента. Пара дней уходит на большие истории, чтобы разобраться в том, что нужно делать и спроектировать решение. Так что это выходит за рамки оценки.
        А сколько тикетов вы успеваете за пол часа оценить? Какого размера? Как часто во время работы над тикетом оказывается, что тикет сильно недооценен?
        • –3
          Хе-хе, если задаться целью, то и за пять минут можно весь спринт оценить. Если в постановке задачи > 10 букв, то два часа, если > 20, то четыре и так далее. Чем не метод оценки? Правда, грубоват, зато рррраз — и в работу сразу, команда не тратит время зря, лол.
          • 0
            «Нужно что бы работало!»
            • 0

              Нет, не так, "точные оценки не нужны".

          • 0
            Слишком много возникает вопросов к реализации и требованиям клиента.

            Вы это у клиента выясняете прямо на PP?

            • 0
              Раньше на Planing Poker звали менеджера, который общался с клиентом. Иногда оказывалось, что менеджер тоже до конца не знает, чего хочет клиент. Тогда оценку задачи откладывали.

              Потом стали выделять разработчика на проработку истории. Это сильно помогло, к моменту оценки командой все нюансы успевали выяснить с менеджером и клиентом.

              Сейчас за любой историей закрепляются продукт оунер и архитектор, которые выясняют все требования и продумывают решение в общих чертах. Так что команде приходит задача, по которой уже нет вопросов к клиентам. Но все равно остаются нюансы, которые полезно продумать до оценки, и разбиение истории на части помогает их выявить.
        • 0
          разбивать большие задачи на мелкие, и потом оценить их… выглядит как аджайл и планинг покер.
          чем этот метод не планиг покер?
          • 0
            В Planning Poker историям дают относительные оценки. Например, от 0,5 до 40.

            Можно разбивать истории до задач поменьше и оценивать их с помощью Planning Poker.

            Мы же разбиваем истории до подзадач размером 1. Каждую подзадачу мы не оцениваем по какой-то шкале. Просто отвечаем на вопрос — она занимает ровно 1 story point или нет.
          • 0
            Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

            Это же не агильно
            Это не так. Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.

            И исправьте везде по тексту статьи Definition of Done (критерии готовности) на Acceptance criteria (критерии приемки). Критерии готовности (http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done) описывают общие условия готовности любых элементов бэклога, а частные критерии готовности конкретной работы — это критерии приемки.
            • 0
              Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.
              Не совсем. Наш способ оценки слишком дорогой, чтобы использовать его для оценки бэклога. Хотя и Planning Poker для этого мне кажется слишком затратным. Для оценки задач в бэклоге мы используем экспертную оценку одного-двух человек. Этого достаточно для приоритезации и при этом мы не тратим много времени на поддержку бэклога.

              Делим историю на подзадачи и оцениваем мы непосредственно перед тем как брать их в спринт.
              • 0
                Прочитайте все-таки, что такое Product Backlog refinement:
                Желательно, чтобы элементы Бэклога Продукта, расположенные сверху, были более  детализированными и понятными по сравнению с расположенными ниже элементами.  Чем детальнее описание элементов Бэклога Продукта, тем точнее может быть их оценка. В  свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они  детализированы.

                Детализация же элементов Бэклога Продукта, над которыми Команда Разработки будет  работать во время следующего Спринта, предполагает, что каждый из элементов может  быть потенциального готов в течение Спринта так, что не остается никакой другой работы,  чтобы подготовить продукт к выпуску.
                Обычно максимально детально прорабатываются истории на следующий спринт, достаточно детально на 2-3 спринта вперед, остальной хвост бэклога детально не прорабатывается.
                • 0
                  Ну я так понял детально проработанные истории на следующий спринт — это уже Sprint Backlog (http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog). Но это уже нюансы, конечно.
            • 0

              Ни слова не увидел о том как учитываются риски в этом подходе.

              • 0
                Вместо экспертной оценки рисков, мы разбиваем истории на подзадачи настолько мелко, чтобы нивелировать риски. Они, конечно, все равно остаются, но в среднем мы не учитываем только 20% подзадач.
              • 0
                1 пойнт — прокрустово ложе. Можно вполне использовать 1/3/5 пойнтов. Допустим, 5 пойнтов — это условно 1 день, 3 пойнта — полдня, 1 пойнт — 1-2 часа или хотфикс. В неделю 25 и график будет не такой скачущий.
                • 0
                  Да, такой подход тоже можно использовать. Так проще разбивать истории на подзадачи и точно не будет возникать эффекта привязки. Но тогда надо будет оценивать каждую подзадачу с помощью Planning Poker и это достаточно долго.

                  Важный момент: 1 день, пол дня и 2 часа стоит использовать только для того, чтобы программистам было проще прийти к одинаковому пониманию размер story point'а. Здесь 5 story point'ов — это 1 идеальный день. Чаще всего люди не укладываются в оценку, которую они дали в абсолютных величинах. С относительной оценкой получается лучше. Реальный размер story point'а нужно определять исходя из статистики.

                  На скачки графика такой подход не повлияет. График скачет в основном из-за того, что по окончании месяца остаются наполовину сделанные большие истории. Их в скорости мы не учитываем. Учитываем только принятые. Можно по другому учитывать, чтобы график меньше скакал, но это спорный вопрос.
                  • 0
                    Зачем оценивать покером? Такие задачи каждый разработчик обычно вполне в состоянии сам оценить, обычно достаточно точно. Разбил, оценил сам (неопытным может помогать тимлид). Все же понимание, что займет 1-2 часа, что 4 часа, а что день — довольно похожее у разных людей с более-менее неплохим бэкграундом. Проблемы возникают только если задача больше 5 пойнтов.

                    В целом, одна из рабочих практик — 1 пойнт это 1 час, в день человек работает 5 часов, 3 теряются на коммуникации, чтение форумов, статей и прочие отвлечения. 5 пойнтов могут в итоге получиться за 3 часа, в другой раз 3 пойнта в день работы (если сработали риски). В течение итерации флуктуации всегда бывают, но в итоге они компенсируются и получаются неплохие и достаточно точные графики прогресса.
                    • 0
                      Один разработчик может слишком много упустить, разбивая историю на подзадачи. Даже тимлид от этого не застрахован. Команда на оценке может увидеть, что что-то не учтено или планируется сделать неправильно. Командная оценка — это в первую очередь ревью того, как спроектировано решение. Можно сократить этап совместной оценки оценки так: вместо Planning Poker'а команда просто указывает, какие задачи точно нельзя сделать за день и нужно разбить. Оценку каждой задачи уже дает один человек. Но такая оценка будет не качественной. Более самоуверенный программист будет недооценивать, а осторожные — переоценивать. Полноценная оценка всей командой помогает решить эту проблему.

                      Для удобства при оценке можно считать, что 1 story point — это 1 час. Важно помнить, что это не реальный час и не путать этим клиентов или менеджеров. Реальный размер story point'а надо вычислять исходя из статистики. У кого-то это будет 2 рабочих часа, а у кого-то и все 4. Мы разбиваем до подзадач, которые по нашей оценке занимают 3-4 часа. Но с учетом рисков, приемки, ревью и отвлечений на общение с менеджерами, один программист делает только 3 story point'а в неделю.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое