Как выстроить процессы и перестать издеваться над командой

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

    Недавно я выступал на конференции Saint TeamLead Conf 2019, в докладе я рассказал о том, как смог найти ряд проблем в рабочем процессе и потом постепенно поборол их. Здесь я постараюсь описать наиболее ценные практики, которые мне помогли не только наладить рабочий процесс, но и перестать издеваться над разработчиками. У сотрудников изменилось отношение к компании в целом и рабочему процессу.


    Проблемы процесса разработки


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

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

    По сути задача любого руководителя, будь это TL или CTO, сводится к тому, что он должен стать связующим звеном между бизнесом и разработкой.

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

    Наводим порядок на доске


    Мы начали рассуждать: если бэкендеры выполнили свою задачу и передали фронтендерам, то те сразу к ней приступят? Глядя на доску, это непонятно. По принципам Kanban мы поделили каждое направление разработки (у нас их было 5: бэкенд, фронтенд, DevOps, QA и дизайн) на две колонки: Do и Done. Сразу стало видно проблему: наша пропускная способность не позволяет сделать столько задач, сколько от нас хотят.



    Ещё Канбан говорит: давайте введём WIP-limit и ограничим количество задач. Как мы определили лимиты? Эмпирическим путём. Конечно, пару раз промахнулись, но потом подобрали так, чтобы у нас не копились задачи в самом узком месте. Дополнительный профит WIP-limit — это триггер, который говорит о том, что как только у нас забрали задачу, мы можем взять следующую. Это своеобразная вытягивающая система.



    К чему это привело? Инженеры стали внимательнее относиться к задачам, потому что когда они не могут решить задачу, то на неё ставится блокер. Больше задач взять нельзя, так как есть WIP-limit, инженеры должны ждать, когда им помогут её решить. Есть шанс остаться без задач.

    Когда мы стали подробно разбирать проблему возвращающихся задач, выяснилось, что все делают их по-разному, например, кто-то пишет тесты, а кто-то нет. На этот счёт были правила, но те, которые спустило сверху начальство. Они не решали проблему разработчиков. Мы ввели новые правила (Definition of Done), которые интегрировали в доску. Они могли действовать как на какую-то колонку, так и на тип карточки. Например, для API нужно, чтобы бэкендер задокументировал все методы и прочее. Правила были всем доступны и видны на доске, а самое главное — шли от самих инженеров и решали их проблемы. Если что-то не было сделано, инженер это видел и шёл делать.



    Оценки задач


    Мы не умели оценивать задачи по срокам, а Канбан нам говорит: «No estimates». Что делать? Накопили статистику и построили такой график. Это спектральная диаграмма, зависимость количества задач от времени.



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



    Мы договорились с заказчиком, то есть с бизнесом, о соглашении качества сервиса (SLA). К нам приходит менеджер и спрашивает: «А за сколько вы сделаете эту фичу?» Мы не можем сказать, за сколько её сделаем точно, но зато можем сказать, сколько времени уйдёт на целую партию таких задач. Отпала необходимость в скрам-покере, и мы перестали пытать людей вопросами о сроках. Просто смотрели в статистику и называли бизнесу сроки.



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



    Потом мы столкнулись с тем, что некоторые задачи стали попадать в другие типы работ. Провели небольшое исследование и выяснили, что какие-то задачи делали намного быстрее, потому что бизнес что-то там обещал партнёрам и просил разработчиков сделать их срочно. А какие-то задачи наоборот были не так важны, их откладывали. Так у нас появились приоритеты, то есть соглашения о классах обслуживания сервисов (CoS), мы их разместили на доске. А чтобы бизнес не злоупотреблял этим и не ставил повышенную срочность для всех задач, ввели горизонтальные WIP-limits.



    Как ускорить разработку


    Опять обратились к статистике трекера задач. Обнаружили, что многие задачи зависают на доске в ожидании доработок, проверок или дополнительных данных, то есть поняли, что разработку можно ускорить. Стали смотреть, сколько задачи копятся, сколько простаивают, и обнаружили, что некоторые фичи разрабатывались меньше, чем ждали приёмку. Решили назначить день принятия фич, и время выпуска задач сократилось. А потом мы прикрутили CD (Continuous Delivery) и стали высылать уведомления.

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



    Что мы отсюда извлекли? Тут легко увидеть lead time (время производства) — горизонтальная линия (ширина потока по оси X) начинается с постановки задачи и доходит до стадии готовности. Таким образом, тут видно, как задача проходит все стадии разработки — линия пересекает все цвета, каждый из которых соответствует своей стадии. А также суммарный WIP-limit доски — высота потока по оси Y. Как увеличить скорость разработки? Можно уменьшить WIP-limit (то есть сделать поток на графике более узким), а можно сделать так, чтобы наш поток, который направлен от начала координат в верхний правый угол графика, стремился вверх ещё сильнее (то есть задрать направление потока ещё сильнее вверх, уменьшить его угол относительно оси Y). Чтобы поток направить сильнее вверх, можно ввести какую-то новую практику, например, внедрить Docker или сделать удобную базу знаний. Это необязательно должно быть техническое нововведение, такой эффект может дать и новый подход в управлении.


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

    Планирование с бизнесом, срочные и бесполезные задачи


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

    Условно говоря, мы выделяем слоты определённого размера, в соответствии с WIP-limits, куда можно положить задачи. Каждый слот вмещает только ограниченное количество задач. По-другому, этот метод называется «планирование стаканчиками».



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

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

    Также мы обратили своё внимание на проблему срочных задач. Стали анализировать статистику по ним и поняли, что эти задачи не такие срочные. Например, нужна акция по сезонной смене колёс у автомобилистов. Мы знаем, что это всегда происходит 2 раза в год. Раз они повторяются, давайте на доске резервировать слоты под такие задачи заранее. Не будет ничего срочного — возьмём другую задачу из очереди, без работы не останемся. В итоге мы выяснили, что 60% срочных задач на самом деле не срочные.

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

    Мы стали так тестировать 85% фич, что в итоге освободило кучу времени, которое потом тратили на проверенные на практике гипотезы. Они уже приносили компании деньги. Также если в процессе что-то шло не так, то заказчик фичи со стороны бизнеса мог вносить правки на ранней стадии, а не через весь цикл разработки.

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

    Встречи


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

    В итоге все совещания по болтологии преобразовались в следующие типы встреч:

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

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

    Мотивация и вовлеченность команд


    Всё что мы внедрили: WIP-limits, оценку задач на основе статистики, отказ от бесполезных задач и прочее, описанное выше, привело к тому, что у инженеров освободилось время. А чем они будут теперь заниматься? Самое большое заблуждение, что никто ничего не будет делать. Я сам неоднократно слышал от ребят: «Я бы этот код зарефакторил, а то там уже чёрт ногу сломит». Да, вначале инженер действительно выспится и отдохнёт 2–3 недели, а что дальше? Он сидит без задач, начинает подходить к коллегам с предложением помощи, помогает сделать задачи, потом уже оба сидят без задач. «Пошли баги пофиксим» — колонка с багами опустела. «Пошли код зарефакторим» — код стал быстрее писаться, WIP-limit можно увеличить. Дальше начинают внедрять CD/CI, пишут базу знаний. Что произошло? Инженеры начинают делать много полезного, до чего у них не доходили руки. Это и есть та скорость, которую хочет бизнес, но почему-то никак не может ни от кого получить. Раньше инженер был злой, хотел, чтобы от него все отстали, а теперь парадигма человека изменилась до: «А сейчас чем я могу тебе помочь?» Количество инициатив выросло, и все они шли снизу, а не сверху. И в итоге оказались куда полезнее.

    Кратко об итогах


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

    Выводы


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

    Можно внедрить что-то «в лоб», прочитав умные книжки или прослушав доклад про гибкие методологии, так возможно даже ускорится разработка или продукты будут работать лучше. Но мы часто забываем, что эти продукты делают люди, а чем лучше мы сделаем их жизнь, тем лучше они будут делать продукты. Я, например, хожу к ребятам и спрашиваю: «А какие у вас боли? Что не так?», перед тем, как что-то начать внедрять. И только благодаря такому подходу, мне удалось сделать то, что хочет бизнес — скорость и качество в разработке.

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

    Подробнее
    Реклама

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

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

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


      Вот это та самая ключевая мера, которая может решить большую часть проблем в любой разработке. Хвала вашему менеджменту, который осилил приоритеты. Не смог бы — все эти метрики, налаживание процессов, вовлеченность, оценка — все коту под хвост. Я видел массу примеров, когда даже слабые тех команды с хиленькими процессами при хорошем проектном менеджменте, который умел фокусироваться на приоритетах, показывали крутой результат, а крутые команды из топовых спецов шли на дно, когда менеджмент не мог элементарно определиться, что же продукту важнее.
        +3
        Из всех методологий, с которыми я сталкивался, работал только Kanban. А четкие приоритеты задач и достаточное количество ресурсов позволяло решать задачи.
        Если ресурсов нет, то никакие изменения процессов не вытащат завал и не уменьшат технологический долг.
          +5

          Все верно.
          "Порядок", бьёт "класс".


          Условный бизнес "принял" ограничения и случилась "ещё одна оглушительная победа гибких методологий", продолжил бы заваливать нелепостями с приоритетом major и critical — получили бы как всегда.

            +2

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

              0
              Не только. Второй ключевой момент — метрики. Начали снимать метрики процессов -> смогли оценивать эффективность -> смогли эти процессы менеджить. Кашу метриками не испортишь.
              Конечно, без расстановки приоритетов показаниями метрик бы просто подтирались каждую итерацию.
              0
              Спасибо за TL;DR
              0

              Подскажите, сколько времени ушло на внедрение этих фич.

                +1
                У меня на это ушло чуть меньше двух лет. Набивали шишки, экспериментировали и т.д. Сейчас, мне кажется, сделал бы за год или чуть больше (в тех же условиях). Совсем быстро не получится, это утопия.
                0
                Мы начали рассуждать: если бэкендеры выполнили свою задачу и передали фронтендерам, то те сразу к ней приступят?

                Хм, а что мешало дефинировать интерфейсы и позволить обеим командам работать параллельно?

                  +1
                  Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы. И простой нашего узкого места равен простою всей системы. То есть мы должны эффективно распределять задачи. Например, бекенд может 10, а фронт 5. Если мы завалим всех работой, то на фронтендеров вывалится столько задач, сколько они не смогут отработать. А если мы эти задачи будем копить, то может получиться так, что эти фичи за время ожидания потеряют актуальность. Хотя можно было бы за это время и код отрефакторить, и баги пофиксить.
                    0
                    Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы.

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


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

                  +2
                  бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой

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

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

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

                    т.е. планировать больше сверху-вниз, а не лишь бы задеплоить в прод как можно больше фичей как бизнес требует (а-ля хуяк-хуяк и в продакшен)
                      0
                      В компании, в которой я это делал, было так. Бизнесом я называю разные юнит единицы: основатель, отдел продаж, отдел логистики, отдел по работе с партнерами и т.д. Не было роли выделенного архитектора, были техлиды направлений. Были аналитики, которые занимались описанием фич, также они занимались и выясняли, что можно сделать для пользователя. Даже мне приходилось выполнять роль продукт-оунера. Отдельной роли продукт оунера не было.
                        0
                        Это одна из ключевых проблем: отсутствие единого ПО. Он нужен как раз для того, что бы все конфликты «бизнеса» превратились в конфликты в его голове и он смог их однозначно решить, расставить приоритеты и выдать roadmap развития продукта.

                        А без ПО excel-файл будет работать только до тех пор, пока бизнес может и хочет решать конфликты на своей стороне, а это ситуация точно не стабильная.
                      0
                      Как мне кажется многие ваши беды это то, что команда без продукта и кросс-функциональной команды. Конечно интересно, как вы решили проблемы.
                        0
                        Скажите, а чем именно Вы пользуетесь в качестве канбан-доски?
                          0
                          Сначала использовали Trello, потом пробовали Kaiten (https://ru.kaiten.io/)
                            0
                            Можете в двух словах их сравнить? На чём в итоге остановились? Почему решили сменить Trello? Я для себя пытаюсь выбрать доску, не знаю на какие элементы обратить внимание в первую очередь.
                              0
                              Смотрите, в Trello у вас есть доска, но вы не можете разделить, колонки, например, на do и done, также нет возможности поставить WIP-limits. По горизонтали тоже поделить не получится. Кроме того, в Trello нельзя добавлять удобные правила, которые срабатывают, когда вы перетаскиваете карточку из одной колонки в другую. Также там нет инструментов, чтобы строить спектральную и накопительную диаграммы. В Kaiten это все есть.
                                0
                                Понял, спасибо! Гляну на всё это :)
                          0
                          Очень наглядно, все разложено по полочкам
                            0
                            Святой Хаббард!
                              0
                              Я в своей компании использую Trello. Тоже сначала был хаос. Начали переносить все задачи в Trello ставить сроки (конечно с запасом), ответственных. В итоге закончели разработку магазина за 3 месяца.
                              Мне лично как руководителю не хватало в Trello возможности создать диаграмму Ганта. Для визуализации прогресса по проекту в целом. И держать отчет перед руководством с наличием такой диаграммы намного легче. Так как можно визуализировать все этапы процесса и прогресс по каждому из них. Особенно полезно когда проекты долгосрочные белее чем пол года например.
                                0

                                А вы нашли инструмент для построения Ганта? Поделитесь, пожалуйста :) потому что тоже очень его не хватает

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

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

                                  Потрясающий ход!
                                    +1
                                    Вы не представляете насколько руководство не может понять что значит полностью загружены. Даже если списком задачи в работе писать они тоже не понимают. Но когда рисуешь таблицу по часово и закрашиваешь в ней клеточки. О чудо. Доходит сразу.
                                    0
                                    Больше задач взять нельзя, так как есть WIP-limit, инженеры должны ждать, когда им помогут её решить. Есть шанс остаться без задач.

                                    А что, собственно, должен делать инженер в такой ситуации?
                                      0
                                      Они могут фиксить баги, делать рефакторинг, улучшать и т.д. Все то, что я писал в пункте «Мотивация и вовлечённость команд».
                                        0
                                        Как-то все равно непонятно. Получается что когда кончаются задачи, инженер может взять еще задач (фиксить баги, делать рефакторинг, улучшать и т.д.). Но взять то ему их нельзя, т.к. «есть WIP-limit». Какой-то замкнутый круг. Или имеется в виду, что багофикс, рефакторинг и прочее это отдельный скоуп, который в WIP-limit не учитывается?
                                      0
                                      У нас есть WIP-лимиты, но никто на них не смотрит. Задач гораздо больше, чем в лимитах, вся доска красная. Ну и ладно, вроде ничего страшного не происходит.
                                        0
                                        Звучит как «пришло время пересмотреть WIP-лимиты»
                                          0
                                          Скорее, звучит как «у нас нет WIP лимитов».

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

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