5 ошибок начинающего лида

    У каждого тимлида есть своё кладбище сотрудников управленческих ошибок. Каждый день публикуются новые статьи «5 ошибок начинающего разработчика», «7 примеров того, как не надо управлять процессами», «100 и 1 способ укладываться в сроки». И это круто!


    Чужие грабли экономят ваше время, делают вас смелыми, похлопывают по плечу и наглядно дают понять, что не один вы такой «я сделяль», и все это проходили.



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


    Предыстория


    Последние 6 лет я посвятила тестированию, сменив несколько компаний, команд с целью получить актуальные и уверенные знания о том, как создавать качественный продукт, и какую роль в этом процессе могут играть тестировщики-инженеры. Иногда причиной ухода становилось отсутствие возможности обучаться у сильных коллег тестировщиков (а это необходимо в самом начале пути), ведь их просто не было. Опробовала свои силы как в ручном, так и в автоматизированном тестировании. И именно после того, как я прокачалась в автоматизации, мне представилась возможность попробовать себя в роли лида тестировщиков с опытным Agile-коучем.


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


    Ошибки


    №1 Менеджер «Здесь и сейчас»


    У меня лучше получалось решать точечные вопросы «здесь и сейчас», но это не всегда приближает команду к заявленной цели.


    Рассмотрим пример. В самом начале становления нового формата QA в Dodo, познакомившись с тем как устроено тестирование и желанием всех начать автоматизацию еще вчера, я решила, что ее нужно начать в ближайшее время. (О том как мы меняли процессы можно узнать из доклада «Алиса в стране QA») Нам всем очень хотелось избавить ребят от ежедневной рутины ручного регрессионного тестирования на 9 странах.


    Следуя принципу «решаю проблемы здесь и сейчас», мы организовали встречу с тестировщиками, составили карту действий, расставили приоритеты, выделили каждому тестировщику время на автоматизацию и приступили к реализации задач с карты. Первым делом определились с инструментом и представили свой план ускорения регресса на общем собрании ИТ. Тестировщики радовались появившимся тестам и верили в скорое избавление от ручной рутины.


    Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.


    Что делать? Советы Кэпа


    Глубже разбираться в проблеме, искать причины, а не следствия. Велика вероятность, что ваши ожидания того, что именно тестировщики – это основной кладезь знаний о системе с точки зрения пользователя, сильно завышены. Стоит позвать на первые собрания разных представителей ИТ компании, попросить помощи с фасилитацией встречи у scrum-мастера, предварительно обговорив с ним, какой результат ты хотел бы получить.

    №2 Менеджер «Опытный инженер»


    Второй мой фейл – это «шапка» опытного инженера. Все самые сложные задачи попадали ко мне.


    Формирование PageObject, реализация базового набора методов для работы с нашей системой, скрипты запуска в CI/CD – всё это я по привычке решила взвалить на себя. Не стала я делегировать и коммуникацию с продуктовыми командами, инженерами инфраструктуры, и собеседования, и тексты вакансий. По словам наставника, наша QA команда была «зеленой» (новички) во всех смыслах. Разумеется, я решила сначала обучить ребят тому, что знаю сама, наблюдая за их работой, чтобы со временем делиться своими задачами.


    Проблема в том, что с тем количеством встреч (общие встречи, командные встречи, внутреннее обучение, 1&1, собеседования, тестовые дни), что свалились на мои плечи, я перестала укладываться в рабочее время со своими задачами. Восьми часов в день не хватало, и я начала это компенсировать свободным временем, которое тратила на кодинг, тексты, подготовку к собеседованиям с кандидатами. Остатки драгоценных часиков я проводила с ребятами в паре с целью обучения и постепенного развития проекта с автотестами. Мое переключение контекста каждый час-два замедляло нас по всем фронтам: автоматизация, коммуникации QA c командами и прочее. Низкие темпы становления крутых QA-инженеров и автоматизации процессов приводили к тому, что и на выходных я работала, чтобы сделать пятилетку за пару месяцев.


    Что делать? Советы Кэпа


    Не бойтесь делегировать задачи. У всех есть право на ошибку и не стоит его отбирать, как бы тебя ни гипнотизировали лиды других команд или наставник, не ведись. Твои ребята должны сами захотеть доверять тебе и следовать за тобой, всегда экспериментируй. Соберитесь вместе, определите то, какие из процессов можно улучшить, кто из ребят готов их продвигать, а возможно некоторые из них можно передать за пределы вашей команды. Опытный фасилитатор поможет сделать так, чтобы выбранные совместно решения не остались только на бумаге. Самостоятельная эффективная команда – это то, к чему должен стремиться каждый руководитель.

    №3 Менеджер «Обратная сторона микроменеджмента»


    Еще одной из ошибок часто является микроменеджмент. Мне пришлось столкнуться с ее обратной стороной – неявный жесткий контроль.


    Стараясь избегать слежки за каждым шагом ребят и ограничения фронта работ, я начала «навязывать» ребятам их «безграничные» возможности: планы развития, исследовательские задачи, выступления, курсы, организация митапов, походы в гости к другим компаниям и прочие активности. Намерения благие – обучение, прокачка и оттачивание навыков, расширение кругозора, новые знакомства в профессиональной сфере. Это же все то, чего мне так не хватало, когда я начинала работу тестировщиком. Проблема в том, что команда хочет право выбора: выступать или нет, смотреть или нет, а я же загнала их в жесткие рамки.


    – Ребята, мы делаем митап. Нам нужны следующие роли, подарки, будут вот такие докладчики. Без вашей помощи мы не сможем сделать запоминающееся мероприятие.
    – Ребята, в декабре будет Heisenbug. Я уже заказала онлайн-трансляцию для нас, забронировала переговорку, а в субботу транслирую с домашнего компьютера. Все за?
    – Ребята, мы на этой неделе идем в гости в компанию «Одноклассники» знакомиться с тем, как у них построена автоматизация.


    Данные возможности воспринимались как рамки-ограничения, которые все так не любят. Моя инициатива выглядела безальтернативной, а главное она была не настолько эффективной, как ожидалось.


    Что делать? Советы Кэпа


    Излишняя забота о ребенке приводит к тому, что он вырастает инфантильным или начинает делать все наоборот назло родителям. Похоже, так можно сказать и о заботе руководителя о своей команде. Мотивируй, а не заставляй, собери встречку на тему «Как нам расширять свой кругозор в IT?» и внимательно слушай коллег, не начинай с порога называть все способы, что тебе известны. А главное не бегай за своими коллегами с предложением выступить на конференции и попасть на интереснейший мастер-класс. Объяви о возможности – этого будет достаточно.

    №4 Менеджер «Везде так делали»


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


    Что делать? Советы Кэпа


    Главное не начать себя угнетать тем, что твои профессиональные навыки и знания ставятся под сомнение и никак не учитываются при принятии решений. Либо ищи достойные аргументы, которые найдут поддержку у команды, либо согласись с командой.

    №5 Менеджер «Истеричка»


    Важную роль в процессе становления тебя как профессионала/мастера своего дела играет наставник. Но есть один нюанс, твое восприятие помощи наставника. Если между вами недоверие друг другу, то эффект от совместной деятельности вряд ли порадует и команду, и всех вокруг.


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


    Что делать? Советы Кэпа


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

    Подведем итоги


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


    Тестировщики сейчас являются частью Dev-команд, ребята весьма самостоятельны и способны сами принимать решения по технической реализации, сотрудничеству с другими командами. Они самостоятельно пишут скрипты, отбирают новых ребят-тестировщиков, проводят митапы и многое-многое другое. Да, мы шли к этому больше года, но никто не обещал, что управление людьми – это легко.

    Dodo Pizza Engineering
    348,66
    О том как IT доставляет пиццу
    Поделиться публикацией

    Комментарии 355

      +15
      попросить помощи с фасилитацией встречи

      Можно перевести это на русский или английский язык?
        0

        "Фасилитировать встречу" означает помогать участникам встречи концентрироваться на её цели, а также мотивировать на активное обсуждение и принятие решений. У нас в Dodo создана школа scrum-мастеров, выпускники которой помогут договориться даже самым молчаливым.

          +7
          Разве этим не модератор занимается? А вообще на описание тамады похоже))
            +1
            В принципе да, я думаю что было выбрано слово «фасилитатор» потому что на публичных дискуссиях (с участием модератора) айтишники бывают не так часто, поэтому в сознании большинства модератор это такой человек с бан-хаммером, задача которого пресекать всякие непотребства. А фасилитатор наоборот занимается тем, что способствует диалогу разных участников
            0
            facilitate [fə'sɪlɪteɪt] гл.
            общ. способствовать; содействовать; оказать содействие; поспособствовать

            образ. вести, проводить семинар и т.д.

          +13
          Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.

          И где тут ошибка?
          Тестировщиков освободили от рутины — профит (больше времени на полезные задачи, выше мотивация). Регрессионные тесты они как раз про то, чтобы не сломать случайно в будущем что-то давно и хорошо работающее и не терять деньги от простоя — профит для бизнеса.
            0
            Вот да, когда нам разработчики (сторонние) присылали на тест новую версию программы моделирования мебели вторым делом (после проверки заявленных изменений и исправлений) я начинал строить обычную модель стремясь найти моменты, которые они могли поломать там, и от проверки этого было никуда не деться, так как это программисты могут считать, что ничего не затронули из старого, а мой опыт говорит обратное)
            И да, я не был тестировщиком в полном смысле этого слова.
              0
              Выгодней покрывать тестами смежные задачи, они чаще ломаются при добавлении нового функционала. Это не исключает того что не надо покрывать все остальное, но выбор время/функционал надо четко прогнозировать. Шанс поламать смежный функционал выше, значит его чаще будут проверять, шанс поламать какой-то отдельный функционал ниже, значит его будут реже проверять.
              +5
              Тестировщики у вас тоже работают день бесплатно, а в случае трудоустройства две недели должны мыть туалеты в Сывтывкаре? Или этот опыт только для разработчиков?
                +2

                Откуда у вас такая странная информация? У нас действительно есть стажировка на базе пиццерии или учебного центра. Однакээ

                  0

                  Однако стажировка состоит из разных этапов реальной работы сотрудников пиццерий. Про гембу и её пользу мы уже ни один раз писали.

                    0
                    Это шутка такая или действительно жизненный опыт?
                      0
                      реальная история
                        +2
                        Это обязательное требование для всех разработчиков, придуманная неадекватным создателем додопиццы. Дескать вы не сможете писать правильный код, если вначаре не поработали в сывтывкаре мойщиком туалетов, кассиром и тестомесом.

                        додо-пицца в свое время преподносила это как большой бонус, рнассказывали про гембу, ее пользу, кайдзен, дао и прочую ахинею. Сейчас это уже перестали афишировать, но пока все еще рассказывают почему вначале надо работать бесплатно на них, а потом ехать в сывтывкар месить тесто и убирать мусор со столов, и какая от этого большая польза.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        +21
                        Но… вы же… буквально используете слово «транслит»…
                        +15

                        Господи, как я вас всех ненавижу :) Тимлиды с аджайл-коучами и фасилитаторами. Да пропади вы все пропадом!


                        Я пришел в программирование, чтобы решать технические задачи и радовать пользователя новыми фичами, а сейчас трачу 30% времени рабочего на то, чтобы играть в передвижение гребанных квадратиков по доске, митинги, и прочую дичь. А самое главное — все самые важные проблемы решались просто разговором с нужным человеком, живым ли или перепиской — не важно. Без необходимости отвлекать остальную команду от их дел.


                        Как достала уже вся эта эффективность вокруг. Все кругом эффективные. Все вокруг полезные. Только софт всё хуже и хуже, а мир все бесчеловечнее.

                          –7
                          +1
                            +1
                            дело в том что это твоё представление и, возможно, «нужного» человека, а создание продукта это коллективный труд
                            понятно что каждый специалист хочет делать то что сочтёт нужным за деньги работодателя, но, слава богу, аджайл-коучи нашли решение против этого хаоса
                              +3

                              Подобное "решение технических задач" и "радование пользователя новыми фичами" может быть действительно успешным, только если вы работаете в одиночку. Когда в процессе участвует больше одного человека — людям нужно уметь организовываться (или уметь помогать их организовывать), иначе есть большой риск зафейлить выпуск продукта — как по качеству, так и по срокам.
                              Как бы вам ни хотелось жить в своём розовом мире, в котором "тимлиды с айджайл-коучами и фасилитаторами" не нужны, факты остаются фактами — люди в большинстве своём самоорганизовываться не умеют, и им нужно помогать.

                                +2

                                Я и не отрицал необходимость руководства. Просто конкретно двиганье квадратиков по канбан-доске и ежедневные митинги — это полнейшая херня, а ее руководство. А именно этим занимаются 90% менеджеров, что я видел, а сотрудники уж вынуждены коммуникации выстраивать как-то сами. А те, что не страдали херней — не страдали бы ею и без аджайла. Классический waterfall, к слову, не так уж и плох для подавляющего большинства проектов с конечным сроком жизни. Тем не менее, аджайл модно, поэтому каждый божий день приходится сидеть и страдать какой-то и считать сторипоинты в попугаях...

                                  +2

                                  "Двиганье квадратиков" и "сторипойнты в попугаях" (кстати, в попугаях, то есть неких абстрактных единицах — это гораздо правильнее, чем в часах, например) позволяют планировать и прогнозировать, то есть делать то, с чем, скажем так, "традиционные" методы разработки, типа того же waterfall, не справляются от слова никак.

                                    +3

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


                                    По поводу сторипоинтов в попугаях — полная чушь. Просто невероятный идиотизм. Никогда не видел, чтобы хоть кто-то оценил этих попугаев правильно. Реально, обычно каждый разработчик вырабатывает для себя некий способ конвертации часов в попугаи и просто им пользуется. Например, считает, что 16 рабочих часов == 1 попугай. Так и живем :)

                                      –1
                                      не означает, что эти процессы и оценки невозможны

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


                                      Просто невероятный идиотизм

                                      Трудно спорить с подобным attitude, поэтому даже пытаться не буду. Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты (хороший старт даст это видео — https://www.youtube.com/watch?v=Gxf76eGyG5c&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK&index=5), а главное — зачем они нужны.

                                        +5
                                        корректно, достоверно и надежно

                                        Будто бы аджайл может сделать это. Дай бог там прогнозы на месяц сбываются.


                                        Трудно спорить с подобным attitude

                                        Вы правда считаете, что если употребить английское слово, вместо прямого и однозначного перевода вы будете выглядеть умнее?


                                        Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты

                                        Я в курсе, что это такое. А еще в курсе, что абсолютно все известные мне программисты ложили болт на это и используют конвертацию в часы работы.

                                          –1
                                          Будто бы аджайл может сделать это.

                                          Я разве это утверждал?


                                          вы будете выглядеть умнее?

                                          Зачем вы додумываете за меня?


                                          Я в курсе, что это такое.

                                          Что?


                                          абсолютно все известные мне программисты

                                          Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.


                                          Говнокод, приложения, жрущие ОЗУ гигабайтами

                                          Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.


                                          Эффективность — это не просто слово. Эффективность — это доставка фичи до клиента в сроки, за которые эта фича не теряет актуальности и позволяет бизнесу заработать персонально Вам на зарплату. Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.

                                            +3
                                            Я разве это утверждал?

                                            Если нет, тогда я не понял, к чему вообще была фраза про наличие инструментов для предсказания сроков.


                                            Зачем вы додумываете за меня?

                                            Затем, что никаких предпосылок не сделать этого я не нашел? Если есть объяснение получше, я бы выслушал.


                                            Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.

                                            Абсурдны сами сторипоинты :) Даже если взять ваше же видео. В нём п.2 говорит "используйте объективные оценки". Дело в том, что время объективно. Если задача не сформирована по принцицу "оцените время, когда всё будет хорошо?", а по принципу "сколько времени вам понадобится для добавление кнопки в меню выбора языка", то все сторипоинты нафиг не нужны.


                                            Забавно также, насколько абсурден ключ №3 предлагаемый авторов видео, который приводит в пример тот факт, что расстояние между двумя городами можно оценить как "2 раза проехать до города посередине". Это порождает логичную проблему "а сколько ехать до города посередине?" и в итоге всё снова сводится к часам. Так зачем заниматься этой попугайщиной, если можно просто правильно формулировать вопросы?


                                            Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.

                                            А почему мы его так пишем? Не потому ли. что такой код дешевле и тупо нет времени подумать над более оптимальным решением?


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


                                            Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.

                                            К большому несчастью, выбора-то нет. Или быть эффективным, или просить милостыню. Поэтому я эффективен до усрачки, не помню, чтобы хоть раз кто-то выражал недовольство моей работой. Просто не обязан любить всё это дерьмо.

                                              0

                                              Я прошу прощения, что приходится разжевывать азы, но нет, ничего не сводится к часам, потому что сторипойнты нужны не для того, чтобы понять, сколько будет делаться одна конкретная задача. Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.


                                              Если Вы будете измерять задачи часами, то Вы, во-первых, будете делать это некорректно, потому что временные затраты — это только часть оценки. Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт. Следовательно, Вы не можете прогнозировать.


                                              Что касается Вашей персональной эффективности, кто я такой, чтобы в ней сомневаться. Но позволю себе спросить — в чем именно Вы её измеряете? Как Вы понимаете, что Вы эффективны? Почему Вы думаете, что не можете быть еще эффективнее?

                                                +5
                                                Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды

                                                А как понимать скорость работы команды в сторипоинтах? Какая разница между "ну, мы можем сделать эту задачу за 3 дня" и "это займет 3 сторипоинта"?


                                                что Вы этого НЕ понимаете.

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


                                                временные затраты — это только часть оценки.

                                                Что-то я не очень понимаю, что является другими частями оценки в вопросе "когда будет готова фича?"


                                                Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт.

                                                Сторипоинты не проясняют ситуацию ни на йоту. Я не помню ни одного случая, чтобы это работало. Понятные задачи, которые легко оценить в часах, делаются в срок. Задачи, которые невозможно оценить в часах — никогда не делаются в срок. Вот и вся история. Дайте мне какой-нибудь живой пример, который убедит меня в обратном.


                                                Как Вы понимаете, что Вы эффективны?

                                                Достаточно просто — меня не увольняют и не собираются, насколько мне известно. Мне платят выше рынка, в конце концов. Не помню ни одного плохого отзыва о своей работе в анонимной оценке, проходящей в компании раз в год.


                                                Почему Вы думаете, что не можете быть еще эффективнее?

                                                Почему не могу? Могу :) Но я уже несколько раз упомянул, что мне вся эта эффективность поперёк горла, т.к. она измеряется в вещах, которые интересны бизнесу. Персонально мне нет никакого резона быть эффективнее))) Забавно то, что "эффективность" и заработок вещи хоть и коррелирующие между собой, однако зависимость у них далеко не линейная, а скорее логарифмическая)

                                                  –2

                                                  Сторипоинты выглядят логичнее на уровне члена команда. Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
                                                  Считать что синиор делает 2 часа в одном звучит странно.

                                                    0
                                                    Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
                                                    Считать что синиор делает 2 часа в одном звучит странно.

                                                    На уровне членов команды каждый член команды дает свою собственную оценку в часах и тогда все ок.
                                                    Стори поинты проблему никак не решают, т.к. то, что Вася делает задачу Х вдвое быстрее Пети, не значит совсем, что он вдвое быстрее делает все задачи. Просто (в подавляющем большинстве случаев) у него выше экспертиза как раз в этой области Х. А в области Y будет другая ситуация.


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

                                                      0

                                                      Лол, у нас в приступе самого аджайло-ада решили играть в кросскомпетентную команду, и типа оценки более не привязаны к людям (равно как и задачи). После того, как я оценил что-то на плюсовых темплейтах в один SP, а задача досталась человеку, который хорошо строит модели, но не умеет в плюсы, получилось, ну… короче, решили больше так не делать.


                                                      Но я не понимаю, что вообще должно быть в голове, чтобы такая идея даже в голову пришла.

                                                        0
                                                        После того, как я оценил что-то на плюсовых темплейтах в один SP, а задача досталась человеку, который хорошо строит модели, но не умеет в плюсы, получилось,

                                                        Ну это вообще откровенная наркомания, когда задача с оценкой Х достается человеку, несогласному с этой оценкой.

                                                      +1

                                                      Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна? Как это поможет в планировании?


                                                      Возьмем ситуацию: в команде есть сеньор (2 СП/спринт), миддл (1 СП/спринт) и 2 джуна (0,5 + 0.5 = 1 СП/спринт).


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


                                                      Её сложность нужно оценить в стопипоинтах. Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.

                                                        –2
                                                        Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна?

                                                        Что значит молоток, кроме как инструмент для забивания гвоздей?


                                                        Как это поможет в планировании?

                                                        Это поможет примерно оценить сколько времени займет выполнение задачи конкретным сотрудником. Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта. Хотя обычно 1 СП ~ 1 час мидла.


                                                        Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.

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

                                                          +1
                                                          Хотя обычно 1 СП ~ 1 час мидла

                                                          Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.


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

                                                          Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.


                                                          Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта

                                                          У нас новую арифметику завезли? Иначе где логика?)


                                                          Чтобы так оценивать, нужна эталонная известная задача.

                                                          Что такое "эталонная известная задача". Неужели такое существует? Эталонная известная задача — это задача которую каждый из сотрудников решал в одинаковых условиях независимо от своих коллег, а вы в это время сидели с таймером рядом и измеряли (лол) за сколько часов её сделал каждый из них. В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?

                                                            0
                                                            Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.

                                                            Я был не прав. В часах действительно неправильно считать. Но 1 СП/спринт тоже нереально. 1 СП это какая-то типичная простейшая эталонная задача. Где вы видели, чтобы простейшие задачи по 2 недели только разрабатывали?


                                                            Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.

                                                            Потому и не помогало, что оценивал один а делал другой. Оценку сложности делают совместно. При этом договариваются до какой-то одной оценки путем обоснования минимального и максимального. Что то вроде:


                                                            • Почему ты 5 СП, когда все сказали 3?
                                                            • Потому что тут вылезет вот такая проблема, про которую все забыли.
                                                            • Коллеги, ваша оценка изменится от этого факта?
                                                            • Да, если это учитывать, то 5 СП.

                                                            У нас новую арифметику завезли? Иначе где логика?)

                                                            Действительно опечатался. Имел в виду скорость джуна 0,5 СП/спринт.


                                                            Что такое "эталонная известная задача". Неужели такое существует?

                                                            Когда вы на поддержке какого-то определенного набора похожих продуктов, то существует. Допустим заказчики захотели фичу в продукте 1, вы ее сделали. Потом они ее просят в продукте 2-5 и вы знаете сколько времени ее делать. Причем знаете индивидуальное время каждого специалиста.


                                                            В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?

                                                            В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?

                                                              0
                                                              В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?

                                                              Так у каждого сотрудника в любом случае своя оценка (хоть в часах хоть в SP). Просто не надо среднюю оценку брать, а так и оставлять, списком оценок.

                                                                0

                                                                Нет, потому что оценивающий не оценивает задачу саму по себе, а сравнивает её с уже выполненными и оцененными. Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.

                                                                  0
                                                                  Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.

                                                                  Но вес — это вполне понятная числовая характеристика. Штука в том, что вы не можете сравнивать сложность, не переведя ее в какую-то числовую характеристику, мозг так не работает.
                                                                  Так что, на самом деле, абсолютно все при оценке сторипоинтов делают такой перевод. Это не обязательно часы — могут быть строки кода или другие единицы, но главное, что они те, которые поддаются измерению. А сложность неизмерима, по-этому сложность задач саму по себе нельзя сравнить численно. Можно сказать что "задача Х сложнее, чем Y", но нельзя сказать, что она сложнее в 2.5 раза.

                                                                    +1
                                                                    абсолютно все при оценке сторипоинтов делают такой перевод

                                                                    Это абсолютная неправда. Если лично Вы не понимаете, как обходиться без этого, это не значит, что остальные, да еще и все, тоже не понимают.

                                                                      0
                                                                      Это абсолютная неправда.

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


                                                                      Скажите пожалуйста, когда вы говорите, что одна задача 2 сторипоинта, а дургая — 6, то чего именно в этой второй задаче втрое больше и почему именно втрое, а не в 2.5 раз? То есть — как и что вы измерили?

                                                                        0

                                                                        Говорите за себя оО


                                                                        Когда я говорю, что одна задача 2 сторипойнта, а вторая 6 (хотя мы, как правило, пользуемся рядом фибоначчи, но это не суть), это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп. Мы не измеряем, мы сравниваем. Как только вы перестанете пытаться измерять задачу, что действительно невозможно, и начнете сравнивать — у вас всё получится.

                                                                          0
                                                                          это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп.

                                                                          А откуда берется множество задач, оцененных в 6? Каким образом в 6сп была оценена первая задача, оцененная в 6сп?
                                                                          То, о чем вы говорите сейчас — это ординалистский подход, то есть вы просто берете пул задач, потом упорядочиваете по сложности (x сложнее y а y сложнее z), выбираете к какой из задач ближе ваша конкретная, и устанавливаете ей сложность. С этим подходом, однако, есть одна проблема — вы не имеете права переводить одни задачи в другие. Иными словами у вас есть задача "малого размера" и есть задача "не очень малого размера" и при этом вы не имеете права переводить n задач малого в k задач не очень малого, т.к. это не количественная оценка. То есть, сложить все задачи и получить какую-то сумму в сп вы в данном случае не можете (т.е. у вас получится в конце спринта не "выполнили задач на 100сп", а "выполнили 5 задач по 10сп, 1 задачу 20сп, 5 задач по 5сп, 5 задач по 1сп", и никаких эти сп теперь не сложить). Чтобы это сделать — вам нужна именно количественная оценка.
                                                                          Ваши сп при таком подходе не могут складываться, это просто названия. То есть 4сп не факт что вдвое (или хотя бы примерно вдвое) больше, чем 2сп. Она может быть больше на 10% или в сто раз.
                                                                          Понятное дело, что при таких оценках никакого планирования невозможно.

                                                                          0

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


                                                                          Мозгу не обязательно знать точные величины сравниваемых метрик, чтобы решить во сколько раз они различаются. Вот стоит у меня на столе сейчас наполовину пустой стакан лимонада. Я не знаю сколько мл стакан, не знаю сколько лимонада, но могу сказать, что это половина.

                                                                            0
                                                                            То есть временем оперируем, но в часах его не меряем.

                                                                            Ну да, так и делаем. Берем известную задачу, время выполнения которой известно из практики, т.к. мы его пронаблюдали и сравниваем данную задачу с этой известной.
                                                                            Только, обратите внимание — в данном случае мы можем измерить время выполнения эталонной задачи. Мы знаем, сколько она у нас заняла (ну, точнее мы говорим не о конкретной задаче, а о пуле задач определенного типа, и о том, статистически, сколько времени, исходя из реальной практики, занимает выполнение задач такого рода). СП эталонной задачи измерить нельзя, СП вообще измерить нельзя — в этом проблема СП.


                                                                            И, повторяю, когда вы оцениваете в СП, вы тоже интуитивно используете некий измеримый показатель для эталонной задачи, пусть и не отдавая себе в этом отчета. Мозг просто не может работать по-другому.
                                                                            Чтобы сравнить что-то с эталоном, необходима измеримость эталона. Вы не можете сравнивать, например, отризок х с отрезком y, если длина отрезка y не может быть измерена. Если вы не можете измерить эталон — то вы можете только ординалистски заявить: "х больше" или "х меньше". Но вы не сможете сказать, что "х больше в 2.5 раза". Для подобной оценки нужно иметь возможность промерять оригинал.

                                                                              0

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


                                                                              А чтобы сравнивать что-то с эталоном не нужно знать метрику эталона. Измерение отрезка X в метрах мы производим путём подсчёта сколько во сколько раз эталонный отрезок больше или меньше измеряемого. Все наши единицы измерения по сути произвольны и измеряя что-то в них мы считаем во сколько раз что-то больше или меньше эталона. Эталон метра мы не можем измерить в метрах, мы создаём аксиому, что этот эталон имеет длину в 1 метр и измеряем остльное сравнивая длины с эталоном.


                                                                              Если нас не интересует сколько времени занимает задача, а интересует какой набор задач мы сделаем за 2 недели и планируем мы путём сравнения с эталонной, зная предполгая, что за 2 недели мы сделаем 100 таких задач, то какой смысл сравнивать длительность эталонной задачи с оценваемой, а потом приводит это к эталону часов (не суть, 1/24 суток или сколько-ко там каких-то периодов в микромире), если часы нас не интересуют? Более того, повторюсь, длительность эталонной задачи не константа в часах.

                                                                                0
                                                                                Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.
                                                                                Если нас не интересует сколько времени занимает задача, а интересует какой набор задач мы сделаем за 2 недели и планируем мы путём сравнения с эталонной, зная предполгая, что за 2 недели мы сделаем 100 таких задач
                                                                                Но при этом вы всё равно сравниваете эталонную с временем, закладываясь на 100 эталонок в 2 недели. И выше сами утверждаете, что решение эталонной — величина не статическая. Так в чем разница — мерить в часах сравнивая с эталоном, или мерить в эталоне, который не статический?
                                                                                  0

                                                                                  Исходим из гипотезы, что время на эталонную задачу изменяется плюс-минус пропорционально со временем на оцениваемые задачи, то есть растёт или падает скорость команды в эталонных задачах/спринт. Нам не нужны оценки в часах ни эталонной. ни оцениваемых, чтобы сказать сколько мы сделаем за спринт. Это просто лишняя информация. Да, можно посчитать сп/час, но зачем?

                                                                                    0
                                                                                    Но когда вы говорите, что сделаете условных 100 за 2 недели вы по сути и считаете 100 эталонок на n часов с учетом чая, т.е. одна эталонка в сколько-то часов. Суть то не меняется.

                                                                                    Вот сегодня решаю задачи, которые в основном делал напарник. Скорость решения в два раза ниже. Но решить надо за сегодня-завтра, а напарник в отпуске до следующей недели. Зато в моих стандартных задачах, например исправление шаблона генерации отчета — у меня какую-нибудь ошибку минут 10-30 поискать время уйдет и ещё 5-10 исправить логику, благо пару флагов включил и в тестовом режиме сразу понятно хотя бы в каком месте искать, а у него — неопределённо долго, так как переписывал не он и вначале ему надо разобраться, пусть там и подробно откомменчено, но портянка на 6к строк неизвестного кода за 5 минут не просматривается и в логику не влезешь, особенно когда оба не программисты, а админы) Ну и что, что в среднем эти задачи наш отдел решает десятками в день?
                                                                                      0
                                                                                      Но когда вы говорите, что сделаете условных 100 за 2 недели вы по сути и считаете 100 эталонок на n часов с учетом чая, т.е. одна эталонка в сколько-то часов. Суть то не меняется.

                                                                                      Нет, это можно посчитать сколько часов эталонка займёт, но мы обещаем сделать 100 за 2 недели, пускай это 600 часов, а не 100 по 6 часов на каждую.

                                                                                  0
                                                                                  Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.

                                                                                  И в чем тут проблема? Какая нам разница, сколько задача будет занимать через год? Мы же в часах меряем, а не в СП, А часы останутся часами :)


                                                                                  А чтобы сравнивать что-то с эталоном не нужно знать метрику эталона. Измерение отрезка X в метрах мы производим путём подсчёта сколько во сколько раз эталонный отрезок больше или меньше измеряемого.

                                                                                  А для этого должна быть определена метрика, все верно.


                                                                                  Эталон метра мы не можем измерить в метрах, мы создаём аксиому, что этот эталон имеет длину в 1 метр

                                                                                  Вы не поняли. Нам не важно знать, сколько именно чего-то там (других эталонов) в метре, нам важна сама измеримость. И тогда мы можем провернуть этот фокус (взять питона и промерять его в попугаях). Но смысл в том, что, и питон и попугай имеют измеримую длину. Только по-этому все работает. Если бы мы не могли измерить питона или попугая, то мы не смогли бы потом измерить и питона в попугаях (обратите внимание — сравнение размеров питона и попугая есть факт измерения сам по себе). Так вот, абстрактная "сложность задачи" — это величина by design неизмерима. Вы можете сказать, что задача Х сложнее, чем Y, но не можете сказать, что она сложнее "в 2.5 раз". Потому что "питон длиннее попугая в Х раз" — это понятно что значит, это в питона влазит Х попугаев, у нас есть конкретный процесс который позволяет определить как оно влазит и мы можем этот процесс виртуально в голове представить, давая оценку и потом проверить, проведя процесс в реальности. А что значит, что задача Х оценена в сторипоинтах в 2.5 раз больше, чем Y? Почему именно в 2.5 раз больше, откуда взялось это число? Что ИМЕННО сравнивалось? Каков процесс сравнения (ака измерения)? Что вы представляли в голове при сравнении, какой процесс? И как теперь процесс повторить ИРЛ, чтобы проверить результат? Вы виртуально представили ход выполнения задачи, сравнили его с ходом выполнения эталонной и получили, что для Х надо сделать в 2.5 раз больше "дел"? Ну поздравляю — вы как раз часы сейчас и оценили :)
                                                                                  И именно так все часы и оценивают :)

                                                                                    0
                                                                                    И в чем тут проблема? Какая нам разница, сколько задача будет занимать через год? Мы же в часах меряем, а не в СП, А часы останутся часами :)

                                                                                    Если мы оцениваем в часах как оценка эталонки умнженную на относительную сложность, то нам нужно каждый спринт оценивать эталонку. Если будем считать "эта задача в 10 раз сложнее эталонной, а значит она на 10 часов", то со временем эта оценка может стать завышенной, потому что год назад мы эталонку сделали за час, а сегодня сделали бы за 45 минут. и новую задачу должны оценить в 7,5 часов, а не в 10.


                                                                                    Вы виртуально представили ход выполнения задачи, сравнили его с ходом выполнения эталонной и получили, что для Х надо сделать в 2.5 раз больше "дел"? Ну поздравляю — вы как раз часы сейчас и оценили :)

                                                                                    Нет, не часы. Мы не знаем сколько часов займёт эталонка :)

                                                                                      0
                                                                                      Если мы оцениваем в часах как оценка эталонки умнженную на относительную сложность, то нам нужно каждый спринт оценивать эталонку.

                                                                                      Зачем? У каждого своя эталонка (и не одна на самом деле — по факту таких эталонок десятки). И каждый у себя в голове с ней сравнивает, чисто интуитивно. И потом говорит часы. Человек сказал: "5 часов", а сколько там у него был эталон — 1 час или 10 или использовалось много эталонов (ага, эта задача как половина задачи Х, треть задачи Y и как две задачи Z, а размер X, Y, Z мне известен, так что будет вот столько) — это не важно вам вообще. У каждого свой опыта и свои эталоны.


                                                                                      Нет, не часы. Мы не знаем сколько часов займёт эталонка :)

                                                                                      Почему не знаем? Знаем, это суть эталонки. Человек эталонки по факту выполнял и, с-но, точно знает, сколько они занимают. Именно те задачи, размер которых заведомо известен, и подбираются, бессознательно, для сравнения. Размер которых известен и те, которые в сумме покрывают процесс решения оцениваемой задачи. Иногда, конечно, точно сложить пазл нельзя — тогда и возникают основные погрешности, ну типа "текущая задача это как задача Х + задача Y + еще кропаль", и вот с оценкой этого кропаля могут возникнуть проблемы, т.к. его не с чем сравнить :)


                                                                                      К слову, единый эталон при определении СП — это тоже очень большой минус, т.к. на практике с этим эталоном можно адекватно сравнивать только очень узкий пул задач. Так что по факту сравнение идет не только с эталоном но и с другими оцененными задачами (иначе никак, т.к. нельзя сравнивать несравниваемое), и тогда погрешность только накапливается. В случае часов накопления погрешности не происходит, т.к. идет постоянная подкрутка — вы всегда ретроспективно обновляете эталонные оценки, подкручивая их под реальные сроки выполнения.

                                                                                        0
                                                                                        Зачем?

                                                                                        Как раз чтобы привести к единому стандарту, чтобы не у каждого своя была, а более-менее общий пул. При оценеке в СП, конечно. В часах я не понимаю как делать общую более-менее достоверную оценку, применимую для каждого. Ну разве что выбирать исполнителя на этапе планирования и общей оценки вообще не делать, только его оценку и принимать. Иначе составление плана будет адом, в моём понимании. Собственно какой календарный план может быть, если не знаем будет задача делаться час или 10 без сработавших рисков, просто смотря по тому кому она достанется.


                                                                                        Почему не знаем? Знаем, это суть эталонки. Человек эталонки по факту выполнял и, с-но, точно знает, сколько они занимают.

                                                                                        При оценке в СП знания сколько времени занимают эталонки не нужны. А в часах я сомневаюсь, что кто-то считает "в прошлый раз, год назад, подобная задача заняла у меня 1 час 25 минут, так и оценю", скорее будет минимум 1,5 часа, а может и 2 просто "по ощущениям" "за час не уложусь, значит два".


                                                                                        В случае часов накопления погрешности не происходит, т.к. идет постоянная подкрутка — вы всегда ретроспективно обновляете эталонные оценки, подкручивая их под реальные сроки выполнения.

                                                                                        Кто этим реально систематически занимается? А при оценке в СП без привязки к часам и личностям, только к спринту эта подстройка идёт реально автоматически.
                                                                                        К слову, при оценке в СП при таком подходе понятие ошибки в оценке задачи сильно сужается, ошибкой становится "слишком много/мало взяли СП на спринт". То, что задачу в 1 СП делал в два раза дольше чем в 2 СП по сути ошибкой оценки не является, если более-менее точно оценили весь бэклог спринта в целом. Как по мне, то отвязываясь от часов мы улучшаем психологическое состояние команды из-за сужения понятия ошибок и отсутствия дедлайна на каждую конкретную задачу.

                                                                                          0
                                                                                          Как раз чтобы привести к единому стандарту, чтобы не у каждого своя была, а более-менее общий пул.

                                                                                          Зачем? Это же мешает точной оценке. Какой смысл тратить время на действия, которые гарантированно приносят исключительно вред? Назло маме уши отморозил — что-то из этого разряда? :)


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

                                                                                          Икзактли! Вообще говоря, никакая оценка кроме оценки исполнителя смысла не имеет. По-этому описанный вами вариант — это вообще единственно возможный вариант работы. Что в случае часов, что в случае СП, т.к. производительность команды в СП зависит от того, кто и какую взял задачу.
                                                                                          Скорость работы команды (с, с-но, планы) всегда зависит от того, кто и какую задачу делает. Распределите задачи так — будет один план, распределите эдак — другой.


                                                                                          При оценке в СП знания сколько времени занимают эталонки не нужны.

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


                                                                                          А в часах я сомневаюсь, что кто-то считает "в прошлый раз, год назад, подобная задача заняла у меня 1 час 25 минут, так и оценю", скорее будет минимум 1,5 часа, а может и 2 просто "по ощущениям" "за час не уложусь, значит два".

                                                                                          Ну да, по ощущениям. А ощущения берутся на основе опыта решения соответствующих задач, ибо больше им взяться неоткуда. Вся эта работа происходит бессознательно — и потому максимально эффективно.


                                                                                          Кто этим реально систематически занимается?

                                                                                          Все занимаются, автоматически. Никаких усилий для этого прилагать не надо, просто когда у вас есть "ощущение", что за полтора часа, может и не успеете, а за два — успеете, то это вот оно и есть. В этом ощущении учтен ваш опыт, и по мере роста этого опыта (сбора статистики вашим мозгом, то есть) происходит постоянная подкрутка ощущений.


                                                                                          То, что задачу в 1 СП делал в два раза дольше чем в 2 СП по сути ошибкой оценки не является,

                                                                                          Ну в этом суть СП — делайте любую оценка и она в любом случае верна. А если не успели — то это не медленно работали и не плохо оценили, а просто: "много взяли на спринт", возьмем меньше. Только если как вы сами заметили — выполнение по времени 1сп дольше чем 2сп не является ошибкой, то ну взяли вы на следующий спринт не 100сп, а 50сп задач, но выполняли их в итоге двое больше. И что? :)


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

                                                                                          А, ну это как не ставить детям плохие оценки, а вместо этого рисовать цветочки в тетрадку? Ну да, да. Только вот такая штука — она и в школе-то не очень, а мы вроде про взрослых дядек говорим, не? Которые работают, не? И несут какую-то ответственность, не? И вы предлагаете, чтобы "психологический климат" был лучше просто не учитывать метрики по которым можно про*баться и вместо этого ввести свои, особенные метрики, по которым все молодцы? :)
                                                                                          Сделали в этом спринте больше СП чем в прошлдом? Мы молодцы! Сделали меньше? Ну просто много сп в спринт напихали :)
                                                                                          Это же несерьезно, извините. И неопнятно, как связано с планированием. То есть, допустим, можно принять этот аргумент. Но тогда так и надо говорить — СП они не для планирования, а для того, чтобы поддерживать "психологический климат", чтобы вместо дедлайнов — котятки и цветочки :)
                                                                                          И с этим тогда будет, действительно, трудно спорить.

                                                                                            0
                                                                                            Зачем? Это же мешает точной оценке. Какой смысл тратить время на действия, которые гарантированно приносят исключительно вред?

                                                                                            Наоборот, это оценку приближает к объективной как к суперпозиции субъективных. Оценку именно сложности, не времени.


                                                                                            Икзактли!

                                                                                            :) Начинаем понимать друг друга


                                                                                            Вообще говоря, никакая оценка кроме оценки исполнителя смысла не имеет. По-этому описанный вами вариант — это вообще единственно возможный вариант работы.

                                                                                            Не единственный. Как с точки зрения авторитарного менеджмента, который дедлайны спускает сверху (часто без особых объективных оснований типа новых законов или каких-то иных внешних событий типа периодов повышенной потребительской или деловой активности), а там как хочешь так крутись и готовься к наказанию. Так и с точки зрения оценки в СП, которая "прячет" разницу в средней производительности членов команды с одной стороны, а, с другой, выявляет пробелы в компетенциях. Когда только исполнитель оценивает, то если он в неё попал (с обоих сторон), то сложно сказать что-то о его компетентности кроме как адекватности оценок. Мнение "я бы эту задачу сделал в 2 раза быстрее" лишь мнение.


                                                                                            Скорость работы команды (с, с-но, планы) всегда зависит от того, кто и какую задачу делает. Распределите задачи так — будет один план, распределите эдак — другой.

                                                                                            А не распределим вообще на этапе планирования (за редким случаем) будет третий, пускай не обеспечивающий максимальную производительность, которую объективно можно было бы запланировать на конкретном спринте, но обеспечивающий такие вещи как: разделение знаний, как следствие снижение бас-фактора и рост "вширь", вплоть до Т и даже Ш специалистов. Снижение количества приоритетных задач которые приходится оставлять в бэклоге, потому что ключевой специалист по какому-то типу задач уже нагружен, а остальные в часах даже оценить не могут. Ну и индивидуальные оценки ставят под вопрос вообще существование команды, может просто группа узкопрофильных специалистов, которые и помочь друг другу толком не могут. То есть в долгосрочной перспективе распределение задач по принципу общей очереди увеличивает производительность команды, выявляя и обычно заполняя пробелы в компетенциях.


                                                                                            Ну, во-первых, какая разница нужны или нет, если они по факту есть? Ну то есть вам не надо никак усилий прилагать, они просто сразу есть.

                                                                                            Нет по факту. Я вот участвовал в оценивании в первый рабочий день на новом месте, ещё ни строчки кода даже не посмотрев. Просто исходя из общего понимания, что изменение текста нескольких сообщений для пользователей должна быть простейшей задачей при более-менее равномерном DX в разных частях системы. Я не мог (да и почти за месяц скоро не могу) оценить её в часах. Но могу сказать, например, что задача добавления новой сущности и создания CRUD ендпоинта будет раз в 10 сложнее на большинстве проектов, если там нет кодогенераторов.


                                                                                            Ну да, по ощущениям. А ощущения берутся на основе опыта решения соответствующих задач, ибо больше им взяться неоткуда.

                                                                                            Ощущения времени могут быть ложными. Просто по факту незнания а сколько задача заняла. Я вот крайне редко анализирую позадачно попал в первоначальную оценку в часах или нет, даже если логирую время. да и вообще сколько времени реально это заняло понимаю только если один раз залогировал, и то посчитав ретроспективно, когда начал и когда закончил, исходя из 8 часов рабочего времени и часа на обед. По крайней мере когда выступаю в роли исключительно разработчика. То есть у меня сознательно получаемой обратной связи о корректности моих прогнозов фактически нет. А вот в сторипоинтах или других попугаях анализирую как разработчик — это интересная мне метрика.


                                                                                            Ну в этом суть СП — делайте любую оценка и она в любом случае верна. А если не успели — то это не медленно работали и не плохо оценили, а просто: "много взяли на спринт", возьмем меньше.

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


                                                                                            Только вот такая штука — она и в школе-то не очень, а мы вроде про взрослых дядек говорим, не? Которые работают, не? И несут какую-то ответственность, не? И вы предлагаете, чтобы "психологический климат" был лучше просто не учитывать метрики по которым можно про*баться и вместо этого ввести свои, особенные метрики, по которым все молодцы? :)

                                                                                            Ответственность-то никуда не девается. Сами говорили, что результат оцениается стейкхолдерами "успели не успели сдать скоуп". Вот за это и ответственность. Анализ причин почему не успели (или много времени свободного осталось) — внутреннее дело команды и общая ответственность перед стейкхолдерами за общий результат. Да, и анализ прежде всего по оценкам. Буквально перед каждым список задач и каждый говорит где в оценках сложности про*бались, а где просто раздолбайничали.


                                                                                            СП они не для планирования, а для того, чтобы поддерживать "психологический климат", чтобы вместо дедлайнов — котятки и цветочки :)

                                                                                            СП для планирования, но для планирования внутри команды, без привлечения менеджмента и стейкхолдеров — они получают только результат планирования по сути. Им неинтересна скорость работы в СП, их либо устраивает скоуп работ которые команда взяла по окончанию планирования или не устраивает. Ну и потом результат, конечно, успели или нет выполнить запланированное.


                                                                                            Если же команда оценивает в часах, то менеджмент очень быстро на практике становится микроменеджментом, те же диаграммы Ганта начинает строить позадачно и персонально и спрашивать каждого лично за несовпадения оценок и фактов. В теории можно без этого, на практике не встречал. Наверное потому что для менеджмента часовые оценки родная стихия, они знают что с ними делать, а вот СП что-то непонятное с одной стороны, а с другой если это даёт устраивающие результаты, то чем бы дитя не тешилось :)

                                                                                              0
                                                                                              То есть в долгосрочной перспективе распределение задач по принципу общей очереди увеличивает производительность команды, выявляя и обычно заполняя пробелы в компетенциях.
                                                                                              Ага, мы так мебель рисовали. Точнее вначале начальник отдела распределял, но когда его поймали на том, что он одному парню все говно сливал, а любимчику дорогие и простые заказы, то… сделали просто систему, что как освободился или заказ повис заходишь и забираешь следующий по списку, но висеть одновременно на тебе должно не более 5 заказов (с указанием «ожидаю ответа дизайнера, главного технолога-конструктора, отдела снабжения, замерщика»), а в работе может быть только парочку. Вот только в связи с тем, что заказы вообще разные по сложности мебели, места установки и стоимости, то посчитать скорость работы команды даже ретроспективно невозможно было. Но, оказывается, есть волшебная серебряная пуля, которая…
                                                                                                0

                                                                                                Да, есть. Для вашего случая, по-моему, лучшее из популярного :) СП как раз для оценки таких задач, по идее. Что не исключает в отдельных случаях отдельные задачи назначать персонально.

                                                                                                0
                                                                                                Наоборот, это оценку приближает к объективной как к суперпозиции субъективных. Оценку именно сложности, не времени.

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


                                                                                                Не единственный.

                                                                                                Окок. Единственный, который может стабильно давать вменяемые результаты :)
                                                                                                Слишком сильно различается производительность между разными исполнителями, даже если уровень исполнителей один и тот же. Это даже не 2-3 раза — бывает разница, натурально, в десятичный порядок.


                                                                                                Когда только исполнитель оценивает, то если он в неё попал (с обоих сторон), то сложно сказать что-то о его компетентности кроме как адекватности оценок.

                                                                                                Оценивают все, вы же во время оценки не знаете, кто исполнитель. И по этим оценкам сразу видно компетенции. Ну точнее это вообще как происходит — еще на стадии оценки, если Вася ставит больше (меньше) остальных, то его спрашивают — а почему. И тогда сразу выясняется про компетенции все.
                                                                                                А вот когда в итоге вы анализируете выполнение плана (ну и сам план строите) вы, конечно, берете оценку исполнителя за базис, т.к. именно он исполняет и особо тут уже не важно, что остальные наоценивали (разве что с точки зрения статистики потом эту инфу можно использовать).


                                                                                                А не распределим вообще на этапе планирования (за редким случаем) будет третий

                                                                                                Да это все прекрасно, но я ж не о том. Я о том, что нету такой вещи как "производительность команды".
                                                                                                Я говорю про то, что в зависимости от распределения задач у вас меняется СП которые команда может за спринт выполнить, и это "меняется" — это легко разница в разы. С-но "сп в спринт" — абсолютно бесполезный и бессмысленный показатель, который ничего не показывает, по факту. Вот я о чем :)


                                                                                                Нет по факту. Я вот участвовал в оценивании в первый рабочий день на новом месте, ещё ни строчки кода даже не посмотрев.

                                                                                                Полное понимание всеми участниками оценки объема работ, необходимых для выполнения задачи, является в скраме необходимым условием выставления оценки. Пока есть кто-то, кто не понимает — оценки просто не ставятся, происходит уточнение задачи, декомпозиция, возможно вообще перенос на куда-то там. Условно говоря, это тогда просто незадача.


                                                                                                Но могу сказать, например, что задача добавления новой сущности и создания CRUD ендпоинта будет раз в 10 сложнее на большинстве проектов, если там нет кодогенераторов.

                                                                                                Ну вот именно что не можете, если не знаете как устроены соответствующие подсистемы. И, скажу вам, я лично сталкивался с кейзом, в котором сделать новый эндпоинт было гораздо проще, чем изменить "несколько сообщений". Вы просто при своей оценке тут делаете некие предположения о том, как все устроено, и что маловероятно, что оно устроено сильно иначе. Но тут не важно СП или часы — это работает одинаково в обоих случаях.
                                                                                                Когда у вас новый человек — это исключительный кейс, он ничего не может нормально оценить, понятное дело, ни в часах ни в СП вообще никак и этот кейс особым образом в любом случае обрабатывается, пока человек не начнет быть "в теме" и не сможет начать нормально использовать свой опыт.


                                                                                                Ощущения времени могут быть ложными.

                                                                                                Ощущения сложности — тоже. Тем более, что они основываются на ощущениях времени.


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

                                                                                                Для этого не надо ничего оценивать, это же сразу видно. Было поставлено 8ч (например) а вы залогировали 10ч. Что тут анализировать? Во время проставления сразу и видите, что потратили на два часа больше.


                                                                                                А вот в сторипоинтах или других попугаях анализирую как разработчик — это интересная мне метрика.

                                                                                                Ну это уже дело вкуса. Мне во часы более интересны.А стори поинты неинтересны, т.к. они не несут никакой информации.


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

                                                                                                Так а толку что каждый говорит, если это все только угадайка? :) С часами же сразу видно где беда, не надо угадывать.


                                                                                                Если же команда оценивает в часах, то менеджмент очень быстро на практике становится микроменеджментом

                                                                                                Можно, конечно. Но зачем?


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

                                                                                                Слушайте, ну если у вас какой-нибудь аджайл во все поля, то у вас нету никакого менеджмента, который будет делать диаграммы ганта. Ну или вы как член команды можете со всей командой послать этого человека на*уй с его гениальными идеями.
                                                                                                А если у вас менеджмент с диаграммами ганта — то у вас менеджмент с диаграммами ганта, забудьте про сп, разговор в этом контексте не имеет смысла :)

                                                                                                  0
                                                                                                  Так что когда вы оцениваете сложность — вы все равно выбираете в итоге какую-то измеримую вещь. Обычно это время.

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


                                                                                                  Это даже не 2-3 раза — бывает разница, натурально, в десятичный порядок.

                                                                                                  Бывает, да. Тут уже на ретроспективе решается почему так получилось и что с этим делать. ОДин из варинтов — не давать задачи такого типа этого исполнителю, но это только один из многих.


                                                                                                  А вот когда в итоге вы анализируете выполнение плана (ну и сам план строите) вы, конечно, берете оценку исполнителя за базис, т.к. именно он исполняет и особо тут уже не важно, что остальные наоценивали (разве что с точки зрения статистики потом эту инфу можно использовать).

                                                                                                  Если план составляется по общей оценке без назначения исполнителя и учёта его потенциального уровня, то скорее всего часы оценки будут близки к СП. Иначе я не представляю как это работает. Сеньор говорит два часа, джун — 8 часов, на вопрос почему так долго говорит надо будет разобраться с тем-то, то в план же пойдёт часов 5?


                                                                                                  С-но "сп в спринт" — абсолютно бесполезный и бессмысленный показатель, который ничего не показывает, по факту. Вот я о чем :)

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


                                                                                                  Полное понимание всеми участниками оценки объема работ, необходимых для выполнения задачи, является в скраме необходимым условием выставления оценки.

                                                                                                  Согласен, самого удивило, что меня позвали. Но полное понимание часто на практике недостижимо из-за разделения труда и разной квалификации.


                                                                                                  Вы просто при своей оценке тут делаете некие предположения о том, как все устроено, и что маловероятно, что оно устроено сильно иначе. Но тут не важно СП или часы — это работает одинаково в обоих случаях.

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


                                                                                                  Для этого не надо ничего оценивать, это же сразу видно. Было поставлено 8ч (например) а вы залогировали 10ч. Что тут анализировать? Во время проставления сразу и видите, что потратили на два часа больше.

                                                                                                  Как минимум это надо посмотреть что было 8, ну или помнить, какую оценку дали. А 10 часов может сложиться из нескольких логов, так что даже считать не будешь, а сколько всего потратил. Я вообще очень радовался, когда логирования времени прямого не было, только статусом задачи манипуляция, которую вообще из IDE делал.


                                                                                                  С часами же сразу видно где беда, не надо угадывать.

                                                                                                  Ну как сразу видно оценка рабочего времени была неверная или не всё время задачи по факту было рабочим?


                                                                                                  А если у вас менеджмент с диаграммами ганта — то у вас менеджмент с диаграммами ганта, забудьте про сп, разговор в этом контексте не имеет смысла :)

                                                                                                  Я про то, что если менеджмент видит часы, то он начинает рисовать даиграммы. А если видит непонятные сп, то довольствуется бёрндаун графиком :)

                                                                                                    –1
                                                                                                    Некоторые выбирают не только время.

                                                                                                    Строки кода еще можно.
                                                                                                    Я серьезно, встречал такое :)


                                                                                                    Сеньор говорит два часа, джун — 8 часов, на вопрос почему так долго говорит надо будет разобраться с тем-то, то в план же пойдёт часов 5?

                                                                                                    В план пойдет столько кому задача будет поставлена. Ну какой смысл если исполнитель говорит что "сомневаюсь что сделаю за 5, скорее это 8" давать ему 5 часов? Ну то есть вы можете так сделать, конечно, но, извините, надеяться потом что все будет в срок — будет большая глупость.


                                                                                                    Как минимум это надо посмотреть что было 8, ну или помнить, какую оценку дали.

                                                                                                    Ну, типа, эта цифра стоит у задачи в вашей джире или что там у вас, как и:


                                                                                                    А 10 часов может сложиться из нескольких логов, так что даже считать не будешь, а сколько всего потратил.

                                                                                                    Суммарные затраты тоже. Серьезно, 2019. А вы тут про "не помню".


                                                                                                    Но полное понимание часто на практике недостижимо из-за разделения труда и разной квалификации.

                                                                                                    Ну тогда "нерелевантных" юнитов можно не опращивать. Если человек не представляет объем работ по задаче, он никакой оценки не даст (ни в СП ни в часах), если он при этом не является потенциальным исполнителем (ну работает на другой частью ситсемы, или там он бек, а задача по фронту, или еще что), то, вообще говоря, нету никакой проблемы в том, что он и оценку ставить не будет. Потому что если он и поставит — это оценка-рандом, что в случае часов, что в случае СП. И нет никакой необходимости нервы человеку трепать.


                                                                                                    Ну как сразу видно оценка рабочего времени была неверная или не всё время задачи по факту было рабочим?

                                                                                                    Если человек говорит что он работал когда не работал, то вам никакое планирование не поможет. Ии в случае СП все еще печальнее, т.к. к этим вариантам добавляются многие другие.

                                                                                                      0
                                                                                                      В план пойдет столько кому задача будет поставлена.

                                                                                                      От того, чтобы в плане ставить исполнителя и стараемся уходить — это исключительный случай должен быть. Это получается жёсткий план, микроменеджмент. С одной стороны. С другой стороны тратятся ресурсы на само планирование, которое редко бывает точным и вообще выдерживается даже приблизительно. И вообще по сути диаграмма Ганта получается, только критические пути выстроить осталось :)


                                                                                                      В план пойдет столько кому задача будет поставлена.

                                                                                                      Не получается идею донести :( Я просто не смотрю на на оценки, уже залогированное время и т. п., я ввожу время по завершению задачи или дня и всё. Мне просто неинтересно по конкретным задачам насколько факт отличается от оценки в часах. Когда джира хорошо настроена, я в неё захожу только чтобы задачу прочитать или комментарий оставить: переключение статусов делаю не выходя из IDE, а время само логируется.


                                                                                                      Если человек говорит что он работал когда не работал

                                                                                                      Логировать каждую минуту это уже не микроменеджмент, а нано менеджмент. Кто-подошёл что-то рассказать, узнать, посоветоваться или попросить показать. Услышал краем уха обсуждение какое-то и влез. Живот прихватило.

                                                                                                        0
                                                                                                        От того, чтобы в плане ставить исполнителя и стараемся уходить — это исключительный случай должен быть.

                                                                                                        Если исполнителя в плане нет значит задача не выполнена. Потому что если она выполнена — ее кто-то сделал, а если ее кто-то сделал — тот этот кто-то исполнитель, а значит — исполнитель есть.


                                                                                                        Логировать каждую минуту это уже не микроменеджмент, а нано менеджмент.

                                                                                                        А кто говорит о логировании каждой минуты? Ну отошел/отвлекся и ладно. У нас же речь о том, что человек весь день котиков смотрит, а потом пишет: "работал 8ч".


                                                                                                        Мне просто неинтересно по конкретным задачам насколько факт отличается от оценки в часах.

                                                                                                        Ну а мне неинтересно сколько в СП. Какая разница, кому что интересно? Это вообще нерелевантный фактор.


                                                                                                        Так постоянная коррекция — неотъемлемая часть скрама и вообще аджайла.

                                                                                                        Ну так с СП коррекции нет, т.к. нет данных, по которым можно корректировать.


                                                                                                        То же, да не совсем. Тратится общее время спринта, а не конкретной задачи и даже не конкретного человека.

                                                                                                        Так а какая разница? И там и там в задачу просто включается "восстановление" и все. Это не надо делать явно. Просто если у вас задача, которая делается 8ч, и после нее надо отдохнуть 4ч, просто записывается как 12ч (хотя вообще конечно это в принципе странная штука, что надо "восстанавливаться", это само по себе уникальная ситуация, которую следует отдельно обрабатывать). С-но именно это и происходит при оценке в СП.

                                                                                              0
                                                                                              Не, ну если у вас в команде одинаковые роботы пишут код, то да. Или вы пишите исключительно одно и то же.

                                                                                              Если у вас разного уровня специалисты с разным опытом решения разных задач, то что даст универсальная единица, когда человек даже может не представлять, как эту задачу решать на начало. Какой коэффициент выполнения СП для данной задачи вы ему подберёте?
                                                                                                0

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

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

                                                                                                    На одну задачу — увеличивай вдвое, на другую — уменьшай вдвое, третью — пл плану делай. Фишка СП в том, что статистически они друг друга нивелируют. Выбросы могут быть и их нужно анализировать.

                                                                                                      0
                                                                                                      На одну задачу — увеличивай вдвое, на другую — уменьшай вдвое, третью — пл плану делай. Фишка СП в том, что статистически они друг друга нивелируют.

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

                                                                                                        0

                                                                                                        Так постоянная коррекция — неотъемлемая часть скрама и вообще аджайла.

                                                                  0

                                                                  Например, оценивают задачу в своих в 1 сп. Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт. А когда джуны до миддл дорастут сможет команда 5 делать. Собственно привязка к сторипоинтам позволяет отслеживать рост проищводительности

                                                                0

                                                                Скорость работы в SP понимается очень просто. Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте. Это и есть скорость работы.


                                                                Когда мы оцениваем задачу в SP, мы не пытаемся ответить на вопрос "за какое время можно её выполнить", потому что на этот вопрос корректно ответить крайне сложно, и чем больше задача — тем сложнее (см. феномен ошибки планирования). SP — это совокупная оценка трех факторов:


                                                                • предполагаемая сложность задачи
                                                                • предполагаемое время выполнения задачи
                                                                • предполагаемые риски, которые могут повлиять на выполнение задачи (например, плохая постановка, или зависимость от внешних систем).

                                                                Оценка в SP является объективной, потому что не ставится от балды, а оценивается в сравнении с другими, уже оцененными задачами.


                                                                Вы говорите, что задачи, которые невозможно оценить в часах, никогда не делаются в срок. А задачи, которые типа возможно — разве делаются? Снова отсылаю к феномену ошибки планирования. Ну и я повторюсь, SP нужны не для оценки конкретной задачи, SP служат оценке скорости работы команды в целом. Вам нужен живой пример? Любая компания, грамотно прошедшая agile-трансформацию. Пообщайтесь с Avito, например. Я слышал, у них всё довольно-таки здорово.


                                                                Есть agile и без сторипойнтов. Например, Канбан. Но и там мы не пытаемся оценивать задачи в часах. Вместо этого мы, условно говоря, причисляем задачи к разным категориям (например, "маленькая", "средняя" и "большая"; в идеале такая категория должна быть одна, но, разумеется, в IT это практически невозможно), опять же сравнивая её с уже выполненными. После этого, зная за какое время у нас обычно выполняются задачи аналогичной категории, мы можем оценить вероятности выполнения этой задачи в определенные сроки.


                                                                Теперь про эффективность. Вы называете критерием эффективности ваше "не увольнение". Тогда как Вы поймете, что стали более эффективны? Вас еще более "не уволят"? Очевидно, это не самая лучшая метрика. 360 тоже сомнительный критерий — оценки субъективны. Выходит, что криитериев эффективности у Вас нет. Как же Вас умудрилось задолбать то, что вы даже не можете измерить?

                                                                  0
                                                                  Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте.

                                                                  А зачем? Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?


                                                                  С точки зрения бизнеса, оценка скорости команды — это вообще один из следующих вариантов: "успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".


                                                                  После того, как вы ко мне пришли и отчитались, что ваша команда за спринт делает 100SP, как мне это перевести в понятные и полезные для бизнеса показатели (те, что выше указаны)?


                                                                  SP — это совокупная оценка трех факторов:

                                                                  Вы не поверите, но при оценке в часах тоже учитываются все эти факторы. Причем гораздо более естественным и очевидным образом, чем в SP. Потому что как учесть все это в часах — достаточно очевидно, а вот логика вывода SP у каждого своя и не формализуется.

                                                                    +1

                                                                    Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.

                                                                      0
                                                                      Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.

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

                                                                        0

                                                                        При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов. Какую оценку ставить, 4, 6, 8?

                                                                          0

                                                                          А со сторипоинтами не то же самое будет?


                                                                          Вообще если немного подумать, то очевидно, что эта проблема будет всегда, потому что в рабочей неделе у вас 40 (или сколько там) часов, а не N сторипоинтов. И вообще вы время в часах измеряете, а не в сторипоинтах. Время первично.


                                                                          И, в частности, даже если задача оценена в 6 сторипоинтов, то время её выполнения зависит от того, кто её будет выполнять.

                                                                            0
                                                                            При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов.

                                                                            Так с СП то же самое будет. Даже если принять, что все понимают сторипоинты одинаково, все равно каждый поставит свою оценку (если мы предполагаем, что команда "неровная"). Только на самом деле под сторипоинтами еще и подразумевают все что-то свое, т.к., я уже упоминал — сторипоинты неформализуемы и неизмеримы. Серьезно, как вы можете топить за метрику с подобными свойствами?


                                                                            Какую оценку ставить, 4, 6, 8?

                                                                            Так и ставите: "Вася — 4ч, Петя — 8ч".


                                                                            И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп.

                                                                            Вы так и не объяснили в чем проблема с часами. Точно так же — оцениваете в часах и знаете, сколько команда может сделать часов за спринт. При этом вот этот второй показатель вам даже измерять не надо, он заранее известен. С-но, неопределенность становится ниже.


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

                                                                          0

                                                                          Ну а какой в этом смысл? Если стратегически оценить для клиента, что вот этот вот набор фич будет стоить вам примерно X спринтов денег — тут можно хотя бы понять.


                                                                          А какой смысл переводить задачи в sp, чтобы по факту вместить их в 10 дней?


                                                                          Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт

                                                                          Совершенно не факт. Если у вас 4 клона сидят, то может. Но ведь может получиться, что чей-то уровень не позволит реализовать задачу даже за удвоенные сторипоинты, а если отдать её более опытному — ему не хватит часов. Может быть на длинном пути какие-то задачи окажутся проще и разница нивелируется. Но в чем тогда смысл двойной конвертации на коротких отрезках?

                                                                            0

                                                                            Ну так и есть. Прежде всего "за эти две недели мы сделаем вот этот набор фич". И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп. Если хотите переводите спринт в часы и получите скорость команды сп/час. Если оценивать задачи в часах, то скорость получится час/час и равной 1 при точной оценке. Ну и анализ будет типа работы за 300 часов мы сделали работы на 250 часов, а обещали на 300. Что с этим анализом делать? Давайте в следующий раз на 300 часов пообешаем сделать работы на 250 часов, чтоб не краснеть, что не выполняем обещания?

                                                                          0
                                                                          Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?

                                                                          У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.


                                                                          "успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".

                                                                          понятные и полезные для бизнеса показатели (те, что выше указаны)?

                                                                          Почему вдруг эти показатели понятны и полезны для бизнеса?
                                                                          Бизнесу как раз важно знать сколько денег он потратит и что за это получит. "что-то не успели" это сколько тугриков?

                                                                            –1
                                                                            У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.

                                                                            А почему бизнес так же не может выбирать в часах, а не в СП? Смотрите, вы сейчас называете преимущества оценки в СП над отсутствием оценки в принципе. Ну да, лучше в СП, чем никак. Но мы же сравниваем с часами? И по факту, СП, как метрика — это говно. Потому что СП неформулизуемы, субъективны и неизмеримы. С другой стороны — часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.


                                                                            Почему вдруг эти показатели понятны и полезны для бизнеса?

                                                                            Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует. Будет доставлено, или не будет.


                                                                            "что-то не успели" это сколько тугриков?

                                                                            Это уже не задача лида такие тугрики считать, у него нет соответствующей информации для расчетов. Вот тот, кому лид отчитывался, потом по "успели это не успели то" сможет посчитать тугрики. А по "планировали 100сп, но сделали 80сп" он ничего посчитать не сможет.

                                                                              –1
                                                                              А почему бизнес так же не может выбирать в часах, а не в СП?

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


                                                                              часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.

                                                                              Часы можно измерить постфактум. А на этапе планирования их никак нельзя измерить.


                                                                              Потому что СП неформулизуемы, субъективны и неизмеримы.

                                                                              СП это гипотеза, которая статистически проверяется (обычно) каждые две недели. Чем дольше работает команда, тем точнее оценка в СП. У опытной команды ситуация "планировали 100 СП, сделали 80" говорит о серьезной недооценке задач.

                                                                                –1

                                                                                Потому что оценка в часах не учитывает:


                                                                                • кто будет делать задачу
                                                                                • риски, возникающие при выполнении задачи

                                                                                Рекомендую почитать про феномен ошибки планирования.


                                                                                Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует.

                                                                                Agile позволяет делать эти прогнозы с большей точностью, чем традиционные подходы. Статистический факт =)

                                                                                  +1
                                                                                  кто будет делать задачу

                                                                                  Оценка в СП этого тоже не учитывает. Или предполагается, что если я не успеваю по СП, то я буду сидеть допоздна?


                                                                                  А вообще я не понимаю, в чём проблема планировать задачи так:


                                                                                  • Я спец по C++, многопоточке и отладке. Я набираю себе задач на 10 рабочих дней на следующий спринт по этой тематике.
                                                                                  • Васян спец по построению рекуррентных моделей. Он набирает себе задач на 10 рабочих дней на следующий спринт по этой тематике.
                                                                                  • Ну и так далее.

                                                                                  риски, возникающие при выполнении задачи

                                                                                  В чём принципиальная разница между «эта задача имеет риски, поэтому я оценю её в 5 СП» и «эта задача имеет риски, в лучшем случае я сделаю её за день, в худшем — за 5 дней»?


                                                                                  Чем оба эти подхода лучше, чем «на этой неделе я трачу на эту задачу не больше трёх дней»?

                                                                                    0

                                                                                    По СП не требуется "успевать", потому что СП не оценивает сроки. Ей-богу, уже начинает надоедать снова и снова повторять в тредах к этому посту — СП != часы, это не связанные друг с другом единицы.


                                                                                    Каким образом вы собираетесь набирать себе задач на 10 рабочих дней, если оцениваете задачи в виде "в лучшем случае я сделаю её за день, в худшем — за 5 дней"? Сколько таких задач вы возьмете? 2? Или 10?

                                                                                      0
                                                                                      По СП не требуется "успевать", потому что СП не оценивает сроки.

                                                                                      Теперь я совсем ничего не понимаю. Нафиг они нужны тогда?


                                                                                      Каким образом вы собираетесь набирать себе задач на 10 рабочих дней, если оцениваете задачи в виде "в лучшем случае я сделаю её за день, в худшем — за 5 дней"? Сколько таких задач вы возьмете? 2? Или 10?

                                                                                      Два варианта:


                                                                                      • Минимизирующий latency: я работаю по механизму «я выделяю на эту задачу N дней на этой неделе». Тогда очевидно, как набирать задачи?
                                                                                      • Максимизирующий throughput: передо мной просто есть список задач с приоритетами, я сажусь и фигачу, не думая о спринтах, велосити и сторипоинтах. Я даю свои оценки, в процессе выполнения я их уточняю, а сроки, коммуникация с бизнесом и тому подобная — это задача этих ваших фасилитаторов (всё равно переговорки букать и груминги устраивать больше не надо). Если вдруг приоритеты проектов меняются — пишите письма, я с радостью обновлю приоритеты задач.
                                                                                        0

                                                                                        На ваш вопрос уже отвечено тут: https://habr.com/ru/company/dodopizzaio/blog/456068/#comment_20283998
                                                                                        Почему не подходят часы: потому что предполагаемое время выполнения задачи — это только часть оценки, и если оценивать только время, существует измеримый риск недооценить задачу (см. феномен ошибки планирования, на который я уже устал ссылаться).


                                                                                        Оба ваших варианта существенно увеличивают риски недооценки задач и неправильного прогноза их выполнения.

                                                                                          0

                                                                                          «Берёте уже оцененые» — это, конечно, отличный ответ на вопрос о том, как оценивать задачи.


                                                                                          Оба ваших варианта существенно увеличивают риски недооценки задач и неправильного прогноза их выполнения.

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


                                                                                          Во втором варианте вопрос оценок тоже, тащем, не стоит.

                                                                                            0

                                                                                            Да, разумеется, с чего-то нужно начинать. Обычно за основу берутся какие-то общепринятые шкалы, коих в интернетах полно. В процессе работы, как правило, принятая шкала корректируется и адаптируется под проект.

                                                                                              0

                                                                                              Как эти шкалы выглядят? И что, это задачи не из вашего беклога? Я-то при первом прочтении думал, что задач на 100 сп уже из беклога, и сравнивается это с уже выполненными ранее задачами из вашего же проекта.

                                                                                                0

                                                                                                Вы всё правильно подумали. Тогда в чем вопрос? Да, для оценки новых задач нужно брать уже оцененные, потому что задачи нужно оценивать не сами по себе, а сравнивая с уже выполненными и оцененными.


                                                                                                Если таковых в проекте еще нет — существуют методики для того, чтобы начать оценку.

                                                                                                  0

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


                                                                                                  Мы ведь согласны, я надеюсь, что это немного разные вещи?

                                                                                                    0

                                                                                                    Вопрос в том, как именно оценивать конкретную задачу?

                                                                                                      0
                                                                                                      «Берёте уже оцененые» — это, конечно, отличный ответ на вопрос о том, как оценивать задачи.

                                                                                                      Оценка в СП этого тоже не учитывает.

                                                                                                      Дальше по треду мне было лень подниматься.


                                                                                                      Ну, то есть, если перестать иронизировать (а это мне сложно, прошу простить, от аджайла у меня очень плохие впечатления, максимум, что может как-то работать для тех проектов, что мне интересны — канбан, но все внедряют скрам), то да, вопрос именно в этом.

                                                                                                        0

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


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


                                                                                                        Пару слов о вышеупомянутой шпаргалке — в наших командах она выглядит, как правило, как таблица, строки которой представляют собой ряд "N SP" — "примерное описание типовых задач" — "примеры задач, оцененных в N SP".

                                                                                                          0
                                                                                                          Оценка задачи проводится путем сравнения её с уже выполненными и оцененными.

                                                                                                          А кто мешает так же делать, ну, для оценки в часах?


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

                                                                                                          А смысл, если я спец по плюсам, Васян спец по рекуррентным нейросетям для NLP, Колян спец по питону, и время выполнения для нас может отличаться на порядок в лучшем случае?

                                                                                                            –1
                                                                                                            А кто мешает так же делать, ну, для оценки в часах?

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


                                                                                                            А смысл, если я спец по плюсам, Васян спец по рекуррентным нейросетям для NLP, Колян спец по питону

                                                                                                            Это какой-то абстрактный набор слов, или у Вас действительно есть некий проект, в котором работает ровно три человека с настолько разными наборами компетенций?

                                                                                                              0
                                                                                                              Извините, но я больше не хочу говорить про часы. В обсуждении к этому посту примерно миллиард раз было сказано, чем плоха оценка в часах, и я не хочу повторяться.

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


                                                                                                              Это какой-то абстрактный набор слов, или у Вас действительно есть некий проект, в котором работает ровно три человека с настолько разными наборами компетенций?

                                                                                                              Это чуть экстремальный пример, но да, как раз тот проект из соседнего треда был таким. Над ним работало трое: спец по NLP, спец по C++ и всякой более инженерной ерунде и чувак-всего-понемножку только из вуза, опыта набирался.

                                                                                                                –1

                                                                                                                Нет, никакой магии.


                                                                                                                Сторипойнт — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения. Да, ретроспективно можно посчитать вероятность, с которой задача, оцененная в N сторипойнтов будет выполнена за определенное количество часов, но зачем? Оценка нужна для того, чтобы решить, брать задачу в спринт или не брать. Да, в конкретной задаче можно ошибиться с оценкой, но задач в спринте много, и ошибки нивелируют друг друга.


                                                                                                                Разумеется, вы можете попытаться использовать такую шкалу, в которой 1 сторипойнт будет соответствовать, например 85% вероятности успеть сделать задачу за 1 час, ради бога (хотя на больших задачах начнутся проблемы). Вы даже можете называть эти сторипойнты часами. Но для того, чтобы корректно выстроить такую шкалу, понадобится сделать кучу работы и ради чего? Ради того, чтобы научиться точно оценивать задачу в часах? Но ведь это и не требуется. Оценка в SP проще, чем оценка в часах, при этом она объективнее и позволяет достоверно планировать.


                                                                                                                Мне кажется, в этом основная ошибка всех, кто доблестно сражается со сторипойнтами — непонимание, что оценивать в SP проще, чем в часах.

                                                                                                                  0
                                                                                                                  Сторипойнт — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения.

                                                                                                                  Часы — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения.


                                                                                                                  Почему это высказывание неверно, а то — верно?


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

                                                                                                                    –1

                                                                                                                    Потому что с оценкой в часах люди чаще ошибаются.


                                                                                                                    Давайте я попробую продать Вам идею сторипойнтов под соусом, которым закончил предыдущий комментарий.


                                                                                                                    Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию). Для этого Вам нужно будет сравнивать каждую задачу с довольно-таки большим числом других задач — и всё равно это будет неточно, и каждый раз будут возникать сомнения, а три это часа или четыре, семь или девять и так далее, и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.


                                                                                                                    Каноничная оценка в SP проводится на гораздо меньшей шкале. Самая часто используемая шкала — ряд Фибоначчи из 4-5 чисел. У вас есть 1, 2, 3 и 5 сторипойнтов (ну и, допустим, 8 для особо крупных задач, которые не удалось декомпозировать). Разница между 3 и 5 сторипойнтами, как правило, весьма прозрачна (хотя это тема для отдельного обсуждения).


                                                                                                                    Мой пойнт в том, что оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.

                                                                                                                      0
                                                                                                                      Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов.

                                                                                                                      А вот и нет!


                                                                                                                      Я оцениваю задачу в количестве часов, кратных 8. Иначе говоря, я оцениваю задачу в днях, а не в часах (и 0 — корректная оценка для некоторых задач).


                                                                                                                      И брать для дней ряд Фибоначчи тоже никто не мешает, тащем.

                                                                                                                        0

                                                                                                                        Скажите, задачу, которую Вы оцениваете в 3 дня, Вы действительно делаете ровно три дня?

                                                                                                                          0

                                                                                                                          Зависит. Если я работаю в режиме минимизации латентности (и максимизации предсказуемости), то если она начинает жрать больше трёх дней, я её откладываю. Если она жрёт меньше трёх дней, то я радуюсь и беру следующую задачу (ну или хабр читаю, чего уж).


                                                                                                                          Если я работаю в режиме «быстрее сделать весь проект», то я просто делаю задачу независимо от оценок.

                                                                                                                            –1

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


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

                                                                                                                              +1
                                                                                                                              копите незавершенную работу, но это отдельная тема...

                                                                                                                              Ну чего коплю сразу? Откладываю на следующий спринт, а в этом спринте делаю другие таски.


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

                                                                                                                              Правильно, это не часы, это дни :)


                                                                                                                              вы, во-первых, не стремитесь к точной оценке

                                                                                                                              Мне делать нечего, что ли? Достаточно оценивать со стабильной и не сильно большой дисперсией отклонения, а там ЗБЧ вывезет.


                                                                                                                              во-вторых, пытаетесь учитывать все факторы, влияющие на время выполнения задачи

                                                                                                                              Нет, я оцениваю что-то типа среднего случая и пессимистичного случая. А иногда вообще говорю «да хз».


                                                                                                                              оцениваете задачу, сравнивая её с предыдущими

                                                                                                                              Я сравниваю её со всем опытом, а не с какой-то конкретной эталонной задачей или набором задач.

                                                                                                                                0
                                                                                                                                Я сравниваю её со всем опытом, а не с какой-то конкретной эталонной задачей или набором задач.

                                                                                                                                Да, в конечном счете к этому и приходят. Оценка появляется в голове "сама собой".


                                                                                                                                Достаточно оценивать со стабильной и не сильно большой дисперсией отклонения, а там ЗБЧ вывезет.

                                                                                                                                Да, так работает емкость спринта.


                                                                                                                                В общем-то, чуть-чуть добавить осмысленности и коллегиальности — и будут полноценные сторипойнты. Непонятно, почему Вы с ними воюете ¯_(ツ)_/¯


                                                                                                                                Если вы работаете над потоком задач не командой — то тут уже другой вопрос. Аджайл всё-таки для команд, а не для одиночек.

                                                                                                                                  0

                                                                                                                                  Ну, почему коллегиальность не работает, я уже писал выше. Почему воюю ­— потому что первый (и часто единственный) вопрос, который я себе задаю — «сколько дней у меня это займёт?».

                                                                                                                                0

                                                                                                                                по-моему, все противники часов в треде забывают про уже давно существующие "сторипоинты" ещё со времён мануфактур и заводов…
                                                                                                                                Называются они "человекочасы".
                                                                                                                                И вы не поверите… К хронологическим часам они привязаны весьма и весьма относительно.


                                                                                                                                // и мне уже полтреда так и хочется попросить рассказать как же сисадминам/инженерам/техподдержке и т.п. оценивать абсолютно разные каждый раз задачи (появляющиеся в процессе спринта, а не заранее) в сторипоинтах?


                                                                                                                                TL;DR версия описанного ниже: смысл оценки в сторипоинтах, если постоянно всплывают такие задачи, что за планируй-не-планируй, а за спринт, в который пытаются упихнуть — не взлетит.


                                                                                                                                Плюс, ладно в компаниях где я консультирую существует такой человек как я, который при обсуждении любого вопроса всегда прикидывает максимально возможное количество трудностей, которые помешают реализации (хотя и я, порой, недооцениваю степень их влияния). Но ведь такие "пессимисты" как я есть далеко не везде, и "привет продалбывание спринтов". А ещё есть менеджеры, штрафующие команду за продолбанные спринты.


                                                                                                                                Так вот...


                                                                                                                                Ну да, задачи "настроить NginX" на одном на другом сервере, казалось бы, можно друг относительно друга посчитать.
                                                                                                                                Хотя, ведь, даже тут "заказчики" любят постоянно чего-то недоговаривать в задаче: то у них ОС окажется слишком старая, то окажется, что проект не умеет в современный php/python/whatever, и php/… надо древнючий из глубин ада достать, то вообще nodejs из bleeding edge воткнуть.


                                                                                                                                То от апстрима неожиданные сюрпризы...


                                                                                                                                А что делать с потоком задач которые банально невозможно оценить без предварительного погружения в стек технологий?


                                                                                                                                Например, всю жизнь жили на парке железок, вдруг высокое начальство ставит задачу "переезжаем в амазон", под которую нанимает внешнего специалиста.
                                                                                                                                Потом начальство задалбывается от срывов сроков (возникших из-за недооценки, произошедшей из-за постоянных недоговорок об особенностях, ну и, может от особенностей компетенции нанятого специалиста в конкретных используемых стеках внутренностей проектов), и когда всё уже готово оно принимает решение вернуться на железки.


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


                                                                                                                                Что, строим планирование исходя из теоретических знаний, которые позволят "примерно" прикинуть?
                                                                                                                                Нуок. Построили.


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


                                                                                                                                А вот тут выясняется, что Elasticsearch чтобы работать с больше чем 16 ГБ оперативки надо выставлять параметры ядра, а докер такое умеет только когда вне кластера. А в кластере — not implemeted yet.


                                                                                                                                А ещё внезапно оказывается что в java завезли баг, из-за которого она ложно предполагает что не может создавать лок-файлы на многослойных ФС, один из слоёв которой — сетевой.


                                                                                                                                И встреваем ещё на полспринта, пока строим костыли.


                                                                                                                                Потом ещё какая-нибудь внезапная херня типа бага стабильном релизе Sentry, который делает нормальную работу с ним вообще невозможной.


                                                                                                                                И так проект "на полгода" просрачивается ещё месяца на три.


                                                                                                                                А тут ещё начальство вдруг "что-то мы бюджет превышаем, давайте-ка срежем пучок серверов"...


                                                                                                                                И как в таких условиях стори-поинты помогут в прогнозах хотя бы на йоту?

                                                                                                                                  0

                                                                                                                                  А, и да, забыл самое главное:
                                                                                                                                  Если сторипоинты, по итогу, "Нарекаем этой задаче 5 сторипоинтов", то почему так же нельзя наречь ей "5 человекочасов"? Зачем было придумывать сторипоинты?

                                                                                                                            0
                                                                                                                            и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.

                                                                                                                            оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.

                                                                                                                            То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?

                                                                                                                            Вы говорите о создании продукта или о прикрытии зада перед начальством?

                                                                                                                            Мой спринт такой:
                                                                                                                            — если работал и помнишь код, где нужно поменять и знаешь как это поменять, то 0,5 часа
                                                                                                                            — если не работал с кодом, но понимаешь, что поменять нужно чуть — 1 час
                                                                                                                            — если понимаешь, что поменять чуть, но с кодом не работал, в архитектуру вникать нет смысла и нужно обсуждать с заказчиком нюансы — 2 часа
                                                                                                                            — создание новой фичи на знакомом коде без архитектурных изменений — 4 часа
                                                                                                                            — любые работы, вызывающие изменение бизнес-логики или архитектуры решения — 6 часов на старте, затем по итогам этих 6ти часов
                                                                                                                            — отсутствие точных требований к задаче — плюс 1 час к расчетному времени
                                                                                                                            — ввод в работу нового проекта (подготовка рабочего окружения, изучение архитектуры) — 3-4 часа в зависимости от стека

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

                                                                                                                            Продуктивный день разработчика 6 часов. За 20 лет работы не видел ни одного уникума, способного кодить 8 часов с перерывом на обед. Чай/кофе/перекуры легко съедают 2 часа рабочего времени. Да и санитарные нормы 45/15 в час не на пустом месте придуманы были.

                                                                                                                            Без морали.
                                                                                                                              0
                                                                                                                              То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?

                                                                                                                              Абсолютно так.


                                                                                                                              Мой спринт

                                                                                                                              Вы работаете в одиночку?

                                                                                                                                0
                                                                                                                                То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?

                                                                                                                                Абсолютно так.

                                                                                                                                Это фиаско
                                                                                                                                Есть красное русское слово для этого случая — «очковтирательство». Кажется, оно как нельзя лучше подходит для иллюстрации смысла планирования в сторипоинтах.

                                                                                                                                Вы работаете в одиночку?

                                                                                                                                Отнюдь. «Мой» означает, что я использую эти критерии в работе. Вне зависимости мою или чужую работу планирую.
                                                                                                                                Критерии «известен-код, известно-что-делать, есть-все-требования» значительно точнее, чем «джун-мидл-сеньор» в вашем способе планирования. Вкупе с более точным инструментом измерения дают вообще фантастическую точность относительно спринтов через сторипоинты.
                                                                                                                                  +1

                                                                                                                                  Это не фиаско, потому что главная задача SP и всего подхода в целом — не конкретную задачу оценить, а скорость работы команды.

                                                                                                                              0
                                                                                                                              Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию).

                                                                                                                              Вы чушь сейчас говорите, на практике оценка в часах идет так же как в СП, потому что по факту в часах никто не меряет, а меряют скорее так: "надо полдня" или "два дня" или "ну это на полспринта/на весь спринт таска, надо побить, вообще говоря". Ну и потом ставят полдня*длина_рабочего_дня часов, например.
                                                                                                                              То есть в итоге идет оценка путем сравнения как раз с некоторой задачей, которая решается за полдня-день, и человек виртуально представляет, насколько дольше/быстрее он сделает оцениваемую задачу по сравнению с эталонной. Это все то же самое что и с СП, только в данном случае сравнивается конкретный и четкий показатель (ожидаемая продолжительность выполнения) а не абстракцию, которую численно и оценить-то никто не может, на самом деле.

                                                                                                                                0

                                                                                                                                Вы переходите на личности. Извините, но с Вами я больше не буду дискутировать.

                                                                                                                                  0
                                                                                                                                  Вы переходите на личности.

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

                                                                                                                                    0
                                                                                                                                    > Вы переходите на личности. Извините, но с Вами я больше не буду дискутировать.

                                                                                                                                    Так бы и писали — ой, все.
                                                                                              0
                                                                                              Потому что оценка в часах не учитывает:

                                                                                              Кто будет делать учитывается ровно так же, как и в случае СП — если вы не выбирали среднее. Риски учитываются заведомо, т.к. при оценке вам всегда дают квантиль. Т.е., когда вы спрашиваете у человека "за сколько выполнишь задачу?" то он отвечает на самом деле на какой-то вопрос вроде: "сколько нужно часов, чтобы уложиться в вероятностью 9/10" (это так мозн работает при интуитивных стат. оценках). С-но, чем выше дисперсия для требуемого времени (т.е. риски) тем дальше будет смещен квантиль и выше оценка.


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

                                                                                              Оценка в часах будет всегда в среднем точнее. Математический факт.
                                                                                              Просто в силу того, что оценки в СП очень неточны — вы, в отличии от оценки в часах, не можете их проверить.
                                                                                              Ну то есть с часами вам сразу понятно — оценили как 10, делали 15, вот вам ошибка в 5 часов. А в СП наличие ошибки в оценке доказать вообще сложно, можете давать любую оценку, хоть рандомайзером, и по итогу она окажется "точной".


                                                                                              Рекомендую почитать про феномен ошибки планирования.

                                                                                              СП этим ошибкам точно так же подвержены.

                                                                                          –1

                                                                                          Логика вывода SP у всех должна быть общая — для этого достаточно провести 15-минутную лекцию с объяснением, что это и как работает. Проверено личным опытом =)


                                                                                          Пожалуйста, хватит говорить про часы. Оценка в часах не работает. Это тоже статистический факт.

                                                                                            0
                                                                                            1 спринт = N сторипойнтов. 1 спринт = M недель. M недель = L часов (скрам подразумевает неукоснительное соблюдение сроков). Следовательно, 1 спринт = L часов.

                                                                                            Любой процесс в этой вселенной завязан на время. Ваши сторипойнты лишь производная.
                                                                                              0

                                                                                              Да, часы можно вывести из СП. Обратная конвертация не работает, и оценить задачу корректно в часах невозможно.

                                                                                                0
                                                                                                Неужели? Чтобы написать этот комментарий мне потребуется две минуты.

                                                                                                Если такая конвертация невозможна, то сторипойнты вообще ничего не значат — это просто случайные числа, непригодные для планирования.

                                                                                                UPD: Ну вот, справился за плоторы. Один сторипойнт позволил бы мне пинать хер остаток дня.
                                                                                                  0
                                                                                                  Чтобы написать этот комментарий мне потребуется две минуты.

                                                                                                  Вы серьезно аргументируете этим Вашу способность оценивать задачи, требующие несколько часов а то и дней работы?


                                                                                                  Такая конвертация не нужна, и сторипойнты не имеют особого смысла применительно к одной задаче. Они имеют смысл в масштабе нескольких спринтов. В отличие от часов, в которых ошибка планирования имеет тенденцию накапливаться, сторипойнты благодаря механизму их проставления отображают производительность команды гораздо корректнее и точнее. Именно поэтому они позволяют планировать, а часы — нет.


                                                                                                  Один сторипойнт позволил бы мне пинать хер остаток дня.

                                                                                                  Если Вам действительно хочется нести подобный бред — предупредите сразу, я не буду мешать.

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

                                                                                                    Не, вы уж говорите как есть — в отличии от часов, для которых ошибка планирования очевидна и измерима, в сторипоинтах можно давать любые оценки, и они всегда будут заведомо "правильными", т.к. для того чтобы они были "правильными" их достаточно таковыми объявить. И обратного (что оценка в сп была плохой) доказать нельзя.

                                                                                                0
                                                                                                Следовательно, 1 спринт = L часов.

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

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

                                                                                                  А вот ответьте на такой вопрос — если бы сторипоинты не коррелировали никак с часами, то в них был бы какой-то смысл и какая-то польза? Если да — раскройте, пожалуйста, какой смысл и какая польза.

                                                                                                    0

                                                                                                    Они не могут не коррелировать по определению. Но как комплексная оценка, где время лишь один из параметров, они приносят больше пользы, чем чистые часы.

                                                                                                      0
                                                                                                      Они не могут не коррелировать по определению.

                                                                                                      Это ответ не на мой вопрос. Предположим, они не коррелируют, что тогда?


                                                                                                      Но как комплексная оценка, где время лишь один из параметров, они приносят больше пользы, чем чистые часы.

                                                                                                      Вы можете указать для примера, какие именно факторы учитываются в оценке СП, но не влияют при этом на время выполнения задачи? Вот конкретно. А то все, что до этого было перечислено — на время выполнения задачи влияет, с-но, при оценке часов учитывается.

                                                                                                        0

                                                                                                        Например, время на восстановление после выполнения задачи определнного типа или определнного стейкхолдера. Куда вы это время отнесёте при оценке в часах? На оцениваемую задачу? Время нужно когда задача уже закрыта. Разнести по другим по минуткам? Сделать задачу "отдых"?


                                                                                                        Вот как в оценке в часах учитывать разную скорость разных людей на разных задачах? Оцениваем все вместе, кто будет делать неизвестно.

                                                                                                          0
                                                                                                          Разнести по другим по минуткам? Сделать задачу "отдых"?

                                                                                                          Ну да :)
                                                                                                          Если это отдых, и он вам нужен, то это и должен быть — "отдых", а не часть какой-то задачи. Но:


                                                                                                          Куда вы это время отнесёте при оценке в часах?

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


                                                                                                          Вот как в оценке в часах учитывать разную скорость разных людей на разных задачах?

                                                                                                          Ну вот у вас каждый оценил и вы видите оценку каждого человека, с-но знаете кто готов угадать эту мелодию за 4 ноты, а кто — за три :) С-но команда сразу в процессе эти оценки же тоже видит и сама прекрасно может определиться с тем, кто, что, когда и как :)
                                                                                                          А в случае СП как это делать? У вас оценки будут одинаковые, т.к. оценки СП не зависят от производительности исполнителя. С-но, информации никакой нет, если только вы не ведете специально бумажку, типа "Вася лучше Пети на задачах Х", и потом в соответствии с этой бумажкой назначать.

                                                                                                            0
                                                                                                            При желании, если вам так хочется, вы можете относить туда же, куда относите соответствующие СП :)

                                                                                                            СП относятся к задачам, после которіх необходим "сверхурочный" отдых. Но при оценке в часах так делать нельзя по многим причинам. А оценивается он в СП интуитивно, если не в первый раз. Это комплексная же оценка, включаяющая не только оценку времени, но и оценку стресса, оценку уровня интеллектуального и эмоционального напряжения. Пускай даже не отдых буквально подразумевает, но понимание (необязательно осознанное) того, что следующую задачу будешь делать дольше, чем без такой задачи прямо перед ней.


                                                                                                            Ну и при качественных оценках время выполнения всегда статистически завышается,

                                                                                                            Что это за качественная оценка, которая завышается? Не учитываются положительные риски?


                                                                                                            Ну вот у вас каждый оценил и вы видите оценку каждого человека, с-но знаете кто готов угадать эту мелодию за 4 ноты, а кто — за три :) С-но команда сразу в процессе эти оценки же тоже видит и сама прекрасно может определиться с тем, кто, что, когда и как :)

                                                                                                            Ну то есть план на пару недель составляется под конкретных исполнителей? Не считаю это хорошей практикой в общем случае.


                                                                                                            У вас оценки будут одинаковые, т.к. оценки СП не зависят от производительности исполнителя.

                                                                                                            Бинго! Бывают разные, конечно, как излишне оптимистичные, так и излишне пессимистичные, но сведутся к одной, скорее к более авторитетной.


                                                                                                            С-но, информации никакой нет

                                                                                                            Информация есть. Даже если фактическое время работы над задачей не логируется вообще, реально только бумажки на доске передвигаются без всяких джир, то за две недели, да ещё с ежедневной "рефлексией" можно легко посмотреть кто сколько СП сделал лично из общего вклада и понять почему так много/мало от ожидаемого уровня. То ли пробелы в знаниях (которые в процессе могли закрыться, а могли нет), то ли архитектура неподходящая была (которая в процессе могла быть изменена, а могли быть костыли забиты), то ли сработали какие-то риски, которые в скоуп задачи заложить нельзя было (оценка типа "подключу такую-то либу и если критичных багов в ней не окажется, то за час закрою задачу, а если окажется, то 2 недели и то не факт, что хватит" как по мне бесполезна для планирования календарных графиков, только для риск-менеджмента.


                                                                                                            По ретроспективе неудачных или слишком удачных спринтов можно понять, да, "Вася лучше Пети на задачах Х" (а можно понять "все вместе слишком оптимистично/пессимистично оценили задачу"). Причём хоть в часах их оценивать, хоть в СП, это обычно очевидно и бумажки не требует, для оценок "лучше/хуже" по крайней мере. А вот что с этим делать проще решить с СП. Может Вася вообще лучше Пети в целом и ему надо работать над общим увеличением перфоманса, а пока просто учитывать этот факт при планировании, а может надо закрывать пробелы, а может просто не брать таких задач в будущем если резерва по времени нет.

                                                                                                              0
                                                                                                              СП относятся к задачам, после которіх необходим "сверхурочный" отдых. Но при оценке в часах так делать нельзя по многим причинам.

                                                                                                              Почему нельзя? Можно. Точно так же интуитивно добавляете в задачу и все. Хоть какие-то причины из этих "многих" сможете назвать?


                                                                                                              но понимание (необязательно осознанное) того, что следующую задачу будешь делать дольше, чем без такой задачи прямо перед ней.

                                                                                                              Так тогда СП надо добавлять в следующую задачу, не в эту. Причем только в том случае, если эта следующая будет у того же исполнителя. В итоге у вас оценка в СП будет меняться от того, какому исполнителю поставили задачу.


                                                                                                              Что это за качественная оценка, которая завышается? Не учитываются положительные риски?

                                                                                                              Оценка, соответствующая требованием. Любая оценка — статистическая, по-этому сумма вероятностей оценить задачу выше и оценить задачу ниже — всегда 100%. С-но, в предположении о симметричности распределения (ну оно по факту не симметрично, но максимально к нему близко), если вы даете оценку точно по мат. ожиданию, то вы будете просирать сроки в половине случаев. Это же плохо? Плохо, с-но, вы берете квантиль, чтобы укладываться в сроки, например, в 90% случаев. Но это значит, что в 90% случаев ваша оценка будет завышена.


                                                                                                              Если к этому добавить, что вы даете оценку не точную (так, что минимальный интервал сильно меньше по сравнению с дисперсией), то ситуация еще больше сдвигается в сторону переоценки — т.к. если при нужном квантиле вы в интервал не попадаете, то вы почти всегда подвинетесь на следующий вперед.


                                                                                                              Информация есть. Даже если фактическое время работы над задачей не логируется вообще,

                                                                                                              А что толку его логировать, если не с чем сравнивать?


                                                                                                              можно легко посмотреть кто сколько СП сделал лично из общего вклада и понять почему так много/мало от ожидаемого уровня.

                                                                                                              И что это даст? Непонятно. СП же не отражают никаких "физических" показателей. С-но, из них нельзя сделать никаких выводов.

                                                                                                                0
                                                                                                                Почему нельзя? Можно. Точно так же интуитивно добавляете в задачу и все.

                                                                                                                То есть задачу сделал, пора передавать дальше, но ты её не закрываешь, а сидишь отдыхаешь? Неправильно как-то.


                                                                                                                В итоге у вас оценка в СП будет меняться от того, какому исполнителю поставили задачу.

                                                                                                                Оценка как раз не должна, время будет зависеть, но не оценка. Оценка может оказаться неверной, а может оказаться что конкретный исполнитель медленно "делает СП" на таких задачах.


                                                                                                                С-но, в предположении о симметричности распределения (ну оно по факту не симметрично, но максимально к нему близко), если вы даете оценку точно по мат. ожиданию, то вы будете просирать сроки в половине случаев. Это же плохо?

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


                                                                                                                А что толку его логировать, если не с чем сравнивать?

                                                                                                                Есть с чем. С другими задачами этого исполнителя в этом спринте. С задачами других исполнителей в этом спринте. С прошлыми спринтами по разным разрезам и т. п.


                                                                                                                И что это даст? Непонятно. СП же не отражают никаких "физических" показателей. С-но, из них нельзя сделать никаких выводов.

                                                                                                                СП отражают вполне конкретный "физический" показатель: какие конкретно задачи мы собирались закрыть в спринте. Если уложились точно, то на ретроспективе основная тема "как можно закрывать больше". Если не успели, то основная тема "случайность или где провтыкали", если успели раньше — "случайность, ошибка оценок принципиальная или выросла скорость и можно брать больше"

                                                                                                                  0
                                                                                                                  То есть задачу сделал, пора передавать дальше, но ты её не закрываешь, а сидишь отдыхаешь? Неправильно как-то.

                                                                                                                  Ну и с СП то же самое.


                                                                                                                  Оценка как раз не должна

                                                                                                                  Не должна, но в вашей схеме зависит. Т.к. у вас сложность задачи определяется не сама по себе, а исходя из того, какие задачи делал до этого исполнитель. Если до этого он делал сложные задачи и устал — то сложность текущей возрастает.


                                                                                                                  Нет, не плохо объективно.

                                                                                                                  Нет, это объективно плохо. Просирать половину сроков — это провал. Даже треть. Даже четверть. С-но для многих людей и 10% — это чересчур.


                                                                                                                  В спринте отклонения в разные стороны с большой вероятностью компенсируют друг друга.

                                                                                                                  Я вам уже выше сказал — это просто когнитивное искажения, согласно которому, если подбрасывать монетку, то вы будете оставаться около нуля (в плане разницы между количеством орлов и решек). По факту же ошибка в подобных случайных процессах нарастает, т.е. подбрасывая монетку вы будете уходить от нуля все дальше и дальше.


                                                                                                                  А ошибка в одной задаче объективно ничего не решает, без микроменеджмента и успешно закрытом спринте никто и не узнает может быть.

                                                                                                                  Так это плохо, что никто не узнает. Если ошибка есть — она должна быть обнаружена. Даже если она и не привела ни к каким последствиям. Потому что это она сейчас не привела.


                                                                                                                  СП отражают вполне конкретный "физический" показатель: какие конкретно задачи мы собирались закрыть в спринте.

                                                                                                                  Этот показатель отражает список ваших задач на спринт. При чем тут СП?

                                                                                                                    0
                                                                                                                    Ну и с СП то же самое.

                                                                                                                    То же, да не совсем. Тратится общее время спринта, а не конкретной задачи и даже не конкретного человека. При оценке в часах конкретного исполнителя надо или закладывать ему после таких задач время отдыха сверх условных 20 часов в спринт, то есть ставить ему не 60 часов, а, например, 58. Или делать фейковые задачи для отдыха, или ещё как-то обходить. В СП такой необходимости просто нет, а даже если есть, то она решается добавлением СП в задачу, но нет никакой проблемы сделать задачу, изменить статус, и отдыхать. С часами нужны какие-то трюки специальные.


                                                                                                                    Нет, это объективно плохо. Просирать половину сроков — это провал. Даже треть. Даже четверть. С-но для многих людей и 10% — это чересчур.

                                                                                                                    Чем єто обїективно плохо, если скоуп задач за спринт крайне редко не выполняется? Запланировали на день две задачи по 3 часа, одну сделали за 2, другую за 4 — чем объективно плохо это?


                                                                                                                    При чем тут СП?

                                                                                                                    На основании двух чисел в СП (оценок и результатов прошлых спринтов) мы решили, что включать в спринт, а что нет. По сути СП за спринт — это количество задач за спринт с учётом сложности каждой задачи.

                                                                                                                0
                                                                                                                Ну вы понимаете, что для меня это звучит так, как будто если команда еженедельно успешно выполняет 200 СП разных неизвестных задач, то появляется ощущение, что они в оценку вкладывают 50% запаса по времени?)
                                                                                                                  0

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

                                                                                                                    +1
                                                                                                                    Причём каждую закрывает в срок, а не так, что одну сделал на 2 часа быстрее чем оценил, а другую на 2 часа больше.
                                                                                                                    Если в ±5 минут, то что команда выросла в СССР. Где в этом году мы тут вот улучшим, в следующем вот тут. Итого через 5 лет изначально хреново спроектированный продукт будет улучшен на 50% дабы все радостно получали премию за план по улучшению качества продукта.
                                                                                          0
                                                                                          Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт.

                                                                                          Чем это отличается от количества часов в неделю, помноженных на количество людей в команде?

                                                                                        0
                                                                                        Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.

                                                                                        Скажите, а зачем-таки нужна оценка в SP, если планирование ведется все равно в часах?
                                                                                        Ну то есть, если SP нельзя перевести в часы — оценка автоматом становится бесполезной, т.к. ее нельзя использовать для планирования.
                                                                                        Если же ее можно перевести в часы — то можно использовать часы. Что на счет этого?


                                                                                        Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.

                                                                                        Так ведь скорость — это, по определению, количество В ЧАС. То есть, чтобы оценить скорость работы команды — надо оценить задачу в часах.

                                                                                          +2

                                                                                          Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.

                                                                                            0
                                                                                            Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.

                                                                                            Ну так типовая задача — это в итоге все равно Х часов. Зачем промежуточный показатель, если можно сразу измерить в часах? 2 недели спринт = 10 дней, каждый день пусть по 6 часов, с-но 60 часов на человека. В итоге производительность команды можно сразу узнать, просто умножив количество человек в команде на 60.

                                                                                              +1

                                                                                              Нет, X часов не константа даже в пределах одного спринта: разработчики разные.

                                                                                                0
                                                                                                Нет, X часов не константа даже в пределах одного спринта: разработчики разные.

                                                                                                Так в этом случае SP использовать нельзя. Они должны переводиться в часы, это необходимое условие, т.к. часы это единственная измеримая метрика. В противном случае знание SP не дает вам никакой информации, с-но вы при оценке просто зря потратили время. Можно просто рандомом SP устанавливать и все тогда.

                                                                                                  0

                                                                                                  У нас есть статистика сколько SP поставила команда за прошлые спринты и результаты ретроспектив непопадания. Естественно, предполагается, что оценки были нерандомные. А часы как раз могут плавать в зависимости от того, кто делал. У нас всё же не строительство, где нормируется на задачи человеко-часы разных специалистов разных разрядов. Можно, наверное оценивать задачи типа "тут требуются 2 часа сеньор фронта, 3 часа миддла бэка, 5 часов джуна фронта" а потом как-то композировать задачи, чтобы на каждого выходило условных 60 часов за 2 недели. Но субъективно непопадания в планы будут гораздо чаще, хотя бы потому что сеньор сеньору рознь.

                                                                                                    0
                                                                                                    Звучит так, что SP это некая временнáя оценка, умноженная на некий коэффициент неопределенности (непопадания, если угодно). Любой опытный разработчик выполняет эту нехитрую калькуляцию, оглашая предполагаемый срок.

                                                                                                    Можете называть итоговую цифру сторипойнтами, если угодно, но ее природа от этого не изменится.
                                                                                                      0
                                                                                                      Да вообще странно. Когда просят указать в чем четко разница и как её четко просчитывать — люди отвечают в духе «это потому что вы не понимаете, а те кто понимают, они умеют».
                                                                                                      Но четкую формулу, что характерно, не приводят.
                                                                                                      Это примерно как обсуждать вред ГМО, информационную структуру воды и алюминий из прививок. Все те, кто противники противников данных вещей — просто ничего не понимают. Но механизм четко никто из сторонников таких теорий объяснить не может.

                                                                                                      Я уже второй день пытаюсь понять, как же именно я, как IT специалист должен считать эти стори, дабы улучшить взаимодействие с другими IT и программистами — и не понимаю…
                                                                                                      PS. Ну хоть кто-нибудь как для дебила бы написал пошаговость расчёта этого параметра.
                                                                                                        0

                                                                                                        Здесь уже несколько раз отвечалось на этот вопрос — оценка производится сравнением с уже выполненными и оцененными задачами.

                                                                                                          0
                                                                                                          В времени мы оцениваем так же. Дальше?
                                                                                                            0

                                                                                                            Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?

                                                                                                              0
                                                                                                              С тех пор, как мы начали общаться напрямую с программистом, то его слова сделаю до завтра, это мне надо часик сейчас посидеть, это примерно на неделю — укладывается. Ну, потом ещё ошибки править приходится часто, но это вообще быстро получается, если в новом коде.

                                                                                                              А до этого у нас вообще информации никакой не было, ибо она терялся на этапе инженеры внедрения-программист да с учетом ещё висения над ними начальства. И задачи решались месяцами и годами.
                                                                                                              собственно, одну задачу, к которой они год приступить не могли, мы смогли решить в течении пары недель-месяца.
                                                                                                              Если же по админству, то либо задачи изначально для нас новые (поднять кластер, когда ни разу не делали), либо стандартные которые так же по времени оценить не проблема и оно так и идёт (если только баг в информационной системе не всплывет, тогда добавляется время работы программиста из первого абзаца). Но в общем да, если говорим два рабочих дня, то тот кто говорит — укладывается. Другой может не уложиться, ибо у него другие наборы навыков тренируются.
                                                                                                              Итааак, дальше?
                                                                                                                0

                                                                                                                Нет, вы не поняли. Под "делается" я имею ввиду весь процесс — от начала работы до перевода в статус "готово". И речь не про "укладывается". Можно назвать срок в три дня, сделать за час — и формально это будет "уложился".

                                                                                                                  0
                                                                                                                  А программист сидит дома и кодит по ночам. Вообще без понятия сколько часов в реале уходит. Нам то что, если при этом он говорит завтра к утру сделаю на тест — значит сделает.
                                                                                                                  Если говорит неделю, то за это время будет несколько тестовых сборок для поиска ошибок. Плюс ещё в основной версии ошибки будет править.
                                                                                                                  Да, на сложных задачах вида исправить информационную систему с обычной на версионную сразу четко срок конечный не даст (ибо там не только базу, но и половину приложений изменять надо было). Но промежуточные задачи четко делал.
                                                                                                                  Если есть задачи кроме нас — он так и говорит, что столько то часов будет занят.
                                                                                                                  Но, собственно, задачу на час он до трех дней не растягивает. Хотя бы потому, что мы не поймём такого финта, хоть и не программисты.
                                                                                                                  Но если говорит в течении часа, завтра к утру и т.п. — значит сделает.
                                                                                                                    0

                                                                                                                    Он у вас один?


                                                                                                                    А программист сидит дома и кодит по ночам

                                                                                                                    Извините, я не очень в сарказм сейчас, это шутка или действительно так?

                                                                                                                      0
                                                                                                                      Во-первых, он не у нас)
                                                                                                                      Во-вторых, никаких шуток.
                                                                                                                      Два админа, один программист внешний. Но он не только по ночам, да.
                                                                                                                        0

                                                                                                                        Тогда это ужасно. Нет, это его выбор, разумеется, но на мой взгляд это ужасно.


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

                                                                                                                          0
                                                                                                                          Тогда это ужасно. Нет, это его выбор, разумеется, но на мой взгляд это ужасно.
                                                                                                                          Ну, возраст такой — не спится ему по ночам…
                                                                                                                            0
                                                                                                                            Возвращаясь к делу — скрам в целом и стори-пойнты в частности не особо применимы к, скажем так, одиночным забегам.

                                                                                                                            Эм… Итак, то есть вы утверждаете, что скрам не применим к ситуации, когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы, полностью обеспечивающую как раз таки функционирование этого бизнеса? И не имеющих конкретной цели завершения проекта (то есть цель — долговременное функционирование системы и своевременное её изменение под новые требования)
                                                                                                                              0
                                                                                                                              Итак, то есть вы утверждаете

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

                                                                                                                                0
                                                                                                                                Я написал ровно то, что написал — скрам для команд, а не для одиночек.
                                                                                                                                Я вам описал команду из трех человек. Но по вашему это не команда, а одиночки? Ясно, понятно.
                                                                                                                                  0

                                                                                                                                  Вы мне сказали, что у Вас задачи ставятся на одного программиста, я Вам ответил, что скрам не для таких кейсов. Остальное — Ваши домыслы и демагогия.


                                                                                                                                  Если будет желание обсудить что-то по делу — прошу в личку.

                                                                                                                                    0
                                                                                                                                    Остальное — Ваши домыслы и демагогия.
                                                                                                                                    Это вы про то, что не умеете читать других? Цитирую:
                                                                                                                                    Я уже второй день пытаюсь понять, как же именно я, как IT специалист должен считать эти стори, дабы улучшить взаимодействие с другими IT и программистами
                                                                                                                                    Если же по админству, то либо задачи изначально для нас новые (поднять кластер, когда ни разу не делали), либо стандартные которые так же по времени оценить не проблема и оно так и идёт (если только баг в информационной системе не всплывет, тогда добавляется время работы программиста из первого абзаца).
                                                                                                                                    Два админа, один программист внешний.
                                                                                                                                    вы утверждаете, что скрам не применим к ситуации, когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы, полностью обеспечивающую как раз таки функционирование этого бизнеса?
                                                                                                                                    Так кто после этого в домыслы и демагогию уходит? Зеркало вам показать?
                                                                                                                                    Собственно, конкретно вы в этой теме постоянно отвечаете демагогически, не зря именно ваши тексты у меня прочно ассоциируются с текстами, выдаваемыми людьми, верующими в шарлатанский бред — схожестью приемов.
                                                                                                                                    Почему VolCh может нормально ответить в комменте ниже, почему скрам не катит, а вы всё время скатываетесь на то, что общающимся с вами недостает тайных знаний и озарений от рептилоидов?
                                                                                                                                      0
                                                                                                                                      когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы,

                                                                                                                                      Вы мне это сообщили уже после того, как я сказал вам про то, что скрам для команд, нет?

                                                                                                                                        0
                                                                                                                                        Возьмите не Мск а маленький город.
                                                                                                                                        То есть остальные вы не читали, так и запишем. Или понимали что-то своё.
                                                                                                                                0

                                                                                                                                Скрам слабо применим в ситуации, когда практически невозможно зафиксировать планируемый объём работ на 1-4 недели, когда с вероятностью близкой к 100% кто-прибежит и скажет бросать все задачи и делать новую, очень важную, с одной стороны, а с другой, сложно вообще сказать будет ли что делать через это время.

                                                                                                                                  0
                                                                                                                                  а с другой, сложно вообще сказать будет ли что делать через это время.
                                                                                                                                  Ну вот задачу игры в герои 3 мы еженедельно проваливаем по причинам того, что делать есть практически всегда)
                                                                                                                                  Хотя заранее спрогнозировать поступление и класс новых задач — да, невозможно.
                                                                                                                                    0

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

                                                                                                                                      0
                                                                                                                                      Да, я уже это понял. То есть у нас это режим, когда мы внедряем нововведение глобальное, выделяя под него процентов 50 из рабочего времени на протяжении пары недель/месяца.
                                                                                                                    0
                                                                                                                    Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?

                                                                                                                    Если вы оценили задачу в 5сп, то как часто оказывается, что она действительно 5сп?

                                                                                                                    0

                                                                                                                    И накапливается ошибка из-за изменений условий. Год назад вы сделали эталонную задачу за час, а теперь она потребует полчаса, из-за роста квалификации, новой инфраструктуры и т. п. Или, наоборот, теперь потребует 2 часа, потому что надо писать тесты, проводить кодревью, уговаривать админов дать сервер вне очереди и т. д.

                                                                                                                  0

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