Нажмите "Enter", чтобы перейти к содержанию

Ускоряем: Ускоряем Cycle Time и растим счастье в команде / Хабр

Ускоряем Cycle Time и растим счастье в команде / Хабр

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

Меня зовут Никита Дубко, я беларус и мастер подземелий в D&D. А ещё — доброжелюбный бородач из подкаста «Веб-стандарты» и руководитель службы разработки HR Tech Яндекса. Моя задача — оптимизация процессов. О том, как я это делаю, и пойдёт речь в статье. Текст написан по мотивам моего доклада на TeamLead Conf 2022.

Эффективность

Начнём с того, что такое эффективность. В Википедии сказано, что эффективность — «это соотношение между достигнутым результатом и использованными ресурсами». Красивое определение, но давайте посмотрим, как с ним работать.

Рассмотрим Scrum. В нём есть разные методики работы с теми или иными артефактами. Можно заставить команду бежать одну или две недели, то есть устроить спринт. Также можно попытаться оценивать задачи с помощью сторипоинтов (SP): вот эта задача на 500 сторипоинтов, а эта — на 3. Таким образом, эффективность можно рассчитать, измерив, на сколько сторипоинтов команда выполнила работы в спринте:

E = SP / спринт

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

Потому что не всегда получается взять и всё сделать идеально. В 2021 году на Saint TeamLead Conf был классный доклад Яна Ашенкампфа «Как я выбираю, кому повысить зарплату?». Там он разбирал много примеров, показывающих, почему любой способ оценить эффективность по количественным метрикам обречён на манипуляции со стороны команды.

Смотреть доклад

Например, если вы будете оценивать строчки кода, то рано или поздно появится правило в линтере, которое будет мотивировать добавлять эти самые строчки где попало. А если оценивать количество коммитов, то любая задача начнёт дробиться на мелкие правки, чтобы коммитов стало больше. Ну и даже, если оценивать по сторипоинтам, то команда сможет обосновать, почему задача была выполнена не за 2 SP, а за 8. Потому что команда, как правило, сама устанавливает «стоимость» 1 SP, при этом она же и оценивает задачи — чувствуется неувязка.

А что, если попробовать оценивать не по сторипоинтам, а по количеству фич в спринте? То есть:

E = количество фич / спринт

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

Допустим, что фича — это тикет в трекере задач. Тут можно подсмотреть, как работают адепты Kanban.

В Kanban есть Cycle Time. Cycle Time — это время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки. С точки зрения тикета, это время перехода из In Progress в Closed, то есть в продакшен. Будем считать, что релиз — это тот самый статус Closed. Если на этот переход тратить меньше времени, фича будет быстрее попадать в прод. А чем быстрее она окажется в проде, тем выше эффективность команды.

Как с этим работать? Я расскажу вам две истории из личного опыта о том, как Cycle Time можно использовать в разных местах с разным объёмом задач.

История №1: большой продукт

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

Особенности Поиска

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

У нас есть «зелёный» транк. Это такой подход, когда всё максимально покрывается тестами, чтобы что-то упало в CI на любую правку в коде, если тесты при этом не поправили. И даже если всё хорошо, тестировщики всё равно посмотрят релиз. Не дай бог какой-то баг! Баги нельзя пропускать, потому что их увидят миллионы — такая особенность.

Статусы задач

Статусы задач в этом процессе выкатки были такие:

  • Open — менеджер завёл тикет, но пока в нём нет ничего, кроме описания.
  • Need info — разработчик начал что-то делать, но ему не хватает информации. Например, где дизайн или указаний о том, что делать с бэкендом.
  • In progress — разработчик уже работает над задачей.
  • In review     — разработчик написал код, закоммитил и ждёт, когда его коллеги придут и скажут, где всё замечательно, а где нужно поправить.
  • Review completed — ревью пройдено, можно работать с тикетом дальше. Этот промежуточный статус иногда очень полезен для торможения тикета.
  • Ready for test — статус говорит тестировщикам, какие задачи можно забирать.
  • Testing — идёт тестирование.
  • Tested — задача протестирована.
  • Ready for Dev — тикет готов к тому, чтобы его залили в основную ветку, которая называется Trunk.
  • Dev — код попал в ветку Trunk и готов к выкатке релиза.
  • Release candidate — код попал в релиз, который сейчас едет в продакшен.
  • Closed — всё классно, код в продакшене.

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

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

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

Графики

Как работают эти графики? Что на них происходит? Во-первых, есть

фильтр задач.

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

Во-вторых, есть скользящее окно. Что это и зачем оно? Представим, что мы считаем, как долго задачи находились в статусах от In progress до Closed. Возьмём задачи, которые перешли в Closed за последние 28 дней. Это нам показывает график:

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

85-й перцентиль в окне в 28 дней — это значение метрики, в которое попадает 85% задач за эти 28 дней. Оно и попадёт на график.

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

В-третьих, есть второй график, который показывает все статусы с таким же скользящим окном и перцентилем:

Можно также выделять конкретные статусы и смотреть на их динамику:

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

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

Как сделать лучше?

Задача оптимизаторов — минимизировать время в статусе. Мы смотрим на эти графики и пытаемся придумать, как сделать лучше. Конечно, самый простой способ — прийти в команду и попробовать заставить её работать быстрее, сказав: «Тестировщик, ты чего медленно тестируешь? Давай быстрее». Но это вряд ли сработает. По-хорошему, нужно спрашивать у команды, что ей мешает делать быстрее. Что нужно сделать внутри команды, чтобы ей стало лучше?

Конвейерный метод

Это Генри Форд. В 1914 году он внедрил конвейерный метод, перевернув индустрию — один человек теперь не должен был отвечать за всё, ведь появился выстроенный процесс. Каждый делает одну часть работы и передаёт её дальше. Причём значительную долю задач взяли на себя машины. Если присмотреться, движение тикетов — это тоже в какой-то мере конвейер доставки задач в продакшен.

Я выписал три принципа оптимизации производительности труда по Форду:

  1. Ограничивать число операций, которые выполняет рабочий. Если мы говорим про тестировщика или разработчика, то нужно посмотреть, что он делает, и убрать лишнее и ненужное из этого процесса.
  2. Приближать задачу к исполнителю. Разработчики должны не просто продвигать тикеты и внедрять код, а понимать, зачем они это всё делают, иметь продуктовое видение.
  3. Учитывать последовательность выполнения операций. Если мы оптимизируем процесс в каком-то одном месте, в другом он может сломаться. Так бывает. Поэтому нужно проводить ретро.

Ретро про процессы

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

Вот какие вопросы можно задавать:

  • Что хорошо в процессах? Что нужно закрепить?
  • Что болит? Где стало плохо? Почему процессы замедлились?
  • Как улучшить процессы? Что мы можем сделать, чтобы не болело?

Принцип Парето

Это Вильфредо Парето — человек, который научил менеджеров использовать числа 20 и 80 где попало. Принцип Парето гласит, что 20% усилий приводят к 80% результата. Фишка в том, что, конечно, команда может нагенерировать много идей — обалденных и не очень — однако не всегда они реализуемы и по-настоящему полезны. Например, у нас была идея убрать встречу об оценке задач из календаря и переложить этот муторный процесс на ML. Казалось бы, классная и современная идея. У нас есть исторические знания о старых тикетах, берём их и просто скармливаем модели. А она уже пусть оценит, сколько там было сторипоинтов и реального времени на разработку. Но вот нюанс: тикеты не всегда хорошо заполнены. Иногда это просто заголовок, что, прямо скажем, грустно. И участники команды не всегда корректно присваивают статусы тикетам. К тому же, теряется очень важный этап обсуждения сути

Что мы сделали в нашей команде?

  • Стали реализовывать простые идеи и сделали автоматизацию призывов в тикеты. Теперь, когда нужно, чтобы тестировщик посмотрел ту или иную задачу, трекер призывает его в комментарии через триггеры, а ещё присылает на почту письмо с призывом. Выглядит это примерно так. Допустим, назначается демо в конце спринта. Тогда трекер просит через триггер заполнить блок «Тезисы для демо внутри тикета»:

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

  • Добавили умные подсказки-комментарии в нужные моменты. Важно, чтобы человек был ближе к задаче. Когда разработчик переводит тикет в статус In Review, поднимается стенд с доработанной версией приложения, которую тут же можно тестировать. Триггер добавляет комментарий о том, как подготовить тикет к тестированию:

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

  • Порой можно нарушать общие правила в части кросс-ревью. Поиск большой — его делает огромное количество людей. Полезно делать «перекрёстное опыление», когда на код-ревью приходят разработчики из разных команд. Однако иногда это очень сильно тормозит Cycle Time, так как погружаться в чужой код долго, в бизнес-процессы другой команды — сложно, а релиз желательно выкатить уже завтра. Поэтому мы решили ревьювить код только у себя внутри. Но если вдруг кто-то захочет прийти, то пусть приходит — мы не будем игнорировать замечания и внесём правки в рамках техдолга.
  • Написали генераторы кода. Мы заметили особенность наших экспериментов: обёртка в коде у них везде повторяется. Сама генерация — очень банальная, она просто подставляет названия флагов («включателей» экспериментов) и правильно называет папки. Но такая генерация экономит огромное количество времени. Причём автогенерация может быть какой угодно. Можно взять и придумать инструмент, а затем протащить его тикетом в спринт. Например, инструмент, помогающий удобнее дебажить сниппеты. Так мы в Поиске делали сниппеты, а также отдельный инструмент под них, который принимает JSON и рисует сниппет такой же, как в проде, но без доступа к бэкенду. Если у вас, например, React-стек или Storybook, напишите какую-то обёртку, которая поможет посмотреть всё, что нужно.

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

  • Завели шаблоны тикетов. Если какое-то поле не заполнено, в тикете оно выделяется жёлтым или красным цветом. Так можно проверять менеджеров на халтуру. Мы даже договорились, что плохо заполненные тикеты не будем брать в работу.
  • Придумали, как поднять команде настроение. Когда мы добавляем автоматизацию, появляется слишком много роботов, но слишком мало настроения. Мы начали разбавлять описания тикетов и комментарии в них мемами и похвалой.
  • Оптимизировали календарь встреч. Мы выяснили, что ребятам не нравится, когда за встречей на 15 минут следует получасовой перерыв, после которого — снова встреча на 15 минут и так далее. В таких условиях работать невозможно. Поэтому мы прошлись по календарю и выпилили ненужные встречи к чёрту.
  • Сделали отбивки по Cycle Time. Графики Cycle Time можно взять и вставить в комментарии через iframe, чтобы показать, какой Cycle Time был у той или иной задачи. Мы назвали это «отбивки в тикет с Cycle Time». Для тех, кто занимается оптимизацией, это очень удобно. Если вдруг проявилась какая-то аномалия, можно зайти в тикет и посмотреть:

    Здесь, например, тикет долго висел в статусах Need Info и Ready For Test — тестировщик не приходил.

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

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

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

    Ещё у нас появилась прикольная штука — клуб по интересам. Там люди, которые оптимизируют Cycle Time, стали обсуждать разные интересные фишки: что они сделали и где собрали какой-то инструмент. Это позволило делиться идеями.

  • Мы устроили багатоны. Если баги не критичные, мы не чиним их в течение всего спринта, а выделяем для этого отдельные дни — багатоны. Чем это полезно? Когда мелкие баги прилетают в течение недели, они меняют контекст. Например, я занимался большой фичей, но, вдруг, переключился на мелкий баг, для которого нужно писать тесты. В результате — фича не доделана. Это очень тормозит разработку. Теперь же мы с командой в один день просто накидываемся на баги, и, не поверите, так мы стали лидерами по ZBP — Zero Bug Policy.
  • Потраченное на внедрение улучшалки время должно привести к экономии и/или приросту настроения в будущем. Это важно, потому что если команда довольна своей работой, она работает чуть лучше и эффективнее. А если потратить много времени на сложную оптимизацию, но она в итоге почти не принесёт пользы, вряд ли команда будет рада.

Результаты

Хочется поделиться результатами оптимизации:

Если посмотреть на начало семестра, на 75-м перцентиле по плавающему окну в 28 дней тикеты находились в работе около 11 дней. А в конце семестра — 7 дней. То есть оптимизация достаточно сильная.

История №2: почти аутсорс

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

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

Проблемы

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

Как я внедрял Cycle Time?

Можно было бы сдаться и жить без графиков Cycle Time. Но я решил, что не смогу так.

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

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


    Кликабельно

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

  • Каждому проекту пришлось выставить индивидуальный перцентиль. Это необходимо, чтобы отсечь аномалии на графике. Дело в том, что есть проекты, в которых очень много задач. Для них стоит ставить 90-й перцентиль, так аномалии будут лучше видны. Но если брать проекты, где задач мало, лучше ставить 60-й перцентиль, так как из-за малой выборки получается очень много аномалий. С ними нужно разбираться отдельно.
  • Важно было объяснить команде, что такое приборы для наблюдения. Хотя эти графики изучает, в первую очередь, руководитель, команда тоже должна о них знать. Так обеспечивается эффект наблюдателя. Зачем? У меня был такой случай: я принёс графики Cycle Time, а команда никогда с ними не работала. Ребята подумали, что графики нужны, чтобы я следил, как медленно команда решает задачи. Мне пришлось объяснять, что это не слежка, а придумано для того, чтобы найти места, где можно оптимизироваться. Смысл графиков нужно объяснить всей команде и конкретно тем, кто против такого подхода, чтобы в целом все более или менее с ним согласились.
  • В моём календаре появилась встреча с самим собой. Раз в неделю примерно один час я трачу на изучение графиков и аномалий. Потом аномалии приношу, например, на ретро или подхожу к людям и спрашиваю, почему так получилось. Они знают, что я делаю это не для того, чтобы узнать, почему у них так медленно идёт тикет. Они знают, что я пытаюсь оптимизировать процесс, придумать какую-то автоматизацию.
  • У нас появилось ретро про процессы с командой. Оно привнесло в работу много интересного, потому что я в команде был новым человеком, а разработчики уже давно сидели с какими-то болями. Что мы выяснили на ретро? Низкий бас-фактор в некоторых проектах, иногда только один человек знал, как что-то делать. Эту проблему надо было решать.
  • Получилось улучшить декомпозицию некоторых задач. Теперь, когда менеджер приносит задачу, мы пробуем сделать в одном тикете бэкенд, а в другом — фронтенд. Или большую фичу дробим на самостоятельные кусочки, которые можно показать на стенде и протестировать независимо.
  • Мы ускорили код-ревью — перестали ждать, когда кто-то придёт на код-ревью, а начали прямо в чате команды писать: «Ребята, посмотрите, пожалуйста, #review_request».
  • Выстроили новые процессы работы с дизайнерами. В этом месте процессы шли медленнее, потому что у нас есть и внутри дизайнеры, и на аутсорсе. С ними нужно работать по-разному. Пришлось подумать, как сделать удобнее.
  • Завели шаблоны для создания новых задач. Причём для багов и фич шаблоны разные. Для багов важно уметь их воспроизвести, а для фич — понимать ожидаемый результат.
  • Я сходил в команду инфраструктуры, они добавили автоматизацию — закрытие тикетов по релизу. Теперь, когда выкатывается релиз, тикеты автоматически закрываются. Например, я качу релиз, в котором 20 тикетов, но мне не нужно проходить по каждому и закрывать руками. Экономия каких-то пяти минут, но каждый раз радует.
  • В некоторых проектах убрали тестирование из PR, оставили только релизное. Благодаря такому решению мы очень сильно ускорились в определённых местах.

Помогло ли это?

Посмотрим на графики.

По этому фильтру работа началась приблизительно в июне, то есть мы с 19 дней на задачу ускорились до 9 дней. Результат ещё круче, чем в Поиске!

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

Итоги и советы

→ Графики Cycle Time — полезный инструмент. Не считайте Cycle Time в Excel, попробуйте внутри команды сделать свой инструмент. Дайте задачу фронтендерам сверстать эти графики, бэкендерам — собрать для них данные. Это не сложно. Ещё и приятное переключение с рутины на сайд-проект.

→ Не мешайте команде делать работу. Не нужно постоянно приходить к людям с предложением: «Давайте оптимизировать Cycle Time, давайте бежать быстрее». Команда хочет работать, а не оптимизировать ваши процессы и графики.

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

→ Донесите до команды, что Cycle Time — это не про наказание. Этот инструмент не для того, чтобы следить и заставлять работать быстрее — он призван сделать процессы лучше.

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

→ Попытайтесь сделать рутину веселее и проще. Добавьте настроения в ваш трекер.

→ Обязательно спрашивайте у команды, где болит. Если у вас где-то болит, это не значит, что у команды та же проблема. Может, у разработчиков всё нормально. Тут важно придумать, как поддерживать баланс.

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

→ При любой аномалии задавайте вопрос «Почему?». О каждой бесполезной встрече в календаре я спрашиваю: почему она произошла? Здесь явно что-то пошло не так в процессах. Может быть, нужно что-то автоматизировать или просто убрать какие-то задачи, не делать их больше никогда.

→ Иногда люди просто ленятся или не могут работать по объективным причинам. Бывает такое, когда приходишь на работу, открываешь новости и работать не хочется. К этому тоже нужно относиться с пониманием.

→ Работа над процессами — не факультатив. Если вы будете заниматься Cycle Time, не делайте это факультативно. Это ваша работа. Берёте тикет «Работа над процессами» и доводите его до ума в рабочее время. У меня, по крайней мере, не получалось факультативно.

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

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

→ Feature Time. Можно попробовать оптимизировать, если с Cycle Time уже всё хорошо. Это классная метрика, но, внедряя её, важно выстроить работу с менеджерами. Feature Time используется, когда берётся не отдельный тикет, а эпики — например, когда мы целый экран хотим выпустить в прод. С этой важной метрикой тоже нужно уметь работать.

→ Lead Time. Эта метрика измеряет время от момента, когда мы завели тикет, до момента, когда мы его закрыли. То есть не от взятия в работу, а от его появления в трекере. Используя эту метрику, можно находить «бриллианты» в бэклоге и чистить его от того, что никогда в работу не попадёт.

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

Gilev.ru | Ускоряем 1С:Предприятие | Gilev.ru

Услуги
Полный аудит производительности 1СПодбор оборудованияПомогаем мигрировать 1С на PostgreSQL
Аудит подходит прежде всего когда нужен полноценный анализ производительности системы. с фиксацией в явном виде узких мест и проблем с производительностью, подробным документированием и главное обоснованием основанном на объективных данных и замерах – в чем заключается причина проблем и главное как именно можно решить проблему и достигнуть целевых результатов.Цена ошибки при неправильном выборе оборудования может быть очень велика, для предприятий с сотнями и тысячами пользователей мы рекомендуем перед принятием важного решением воспользоваться нашим опытом при подборе оборудования.Если в ваших планах использовать PostgreSQL, то перед переездом нужно провести значительную подготовительную работу. В том числе ряд работ можно выполнить с нашей помощью[email protected]
      подробнее            подробнее            подробнее      
Подготовка к миграции на PostgreSQL
Свертка базыПеревод на управляемые блокировкиИзменение режима совместимости
Одним из выгодных экономически приемом для увеличения производительности (потому что не надо покупать более мощное оборудование) является — свертка базы. Наша команда имеет большой опыт и готова предоставить услуги для свертки баз любой сложности. При миграции с одной субд на другую через dt размер может иметь критическое значение с точки зрения достаточности аппаратных ресурсов и времени технологического окна на процесс.При работе с высокой конкуренцией за ресурсы (большое количество пользователей) в какой-то момент влияние избыточности блокировок становится заметным с точки зрения производительности при параллельном режиме.
Для исключения этих блокировок рекомендуется перевести конфигурацию полностью в управляемый режим блокировки данных в транзакции. Такой перевод требует некоторой доработки исходного кода конфигурации. Полноценная работа с PostgreSQL возможна только в управляемом режиме блокировок.		В нашей практике достаточно часто требуется переводить режим совместимости в режим совместимости 8.3.10 и выше, если есть такая потребность, мы можем выполнить работы нашими силами. Для старых конфигурация в режиме совместимости 8.2.ХХ есть смысл поднять совместимость хотя бы до 8.3.10 для лучшей работы управляемых блокировок и механизмов 8.3
      подробнее            подробнее            подробнее      
Развертывание в Линукс
 
  
 Установка веб-сервераУстановка сервера 1СУстановка PosgreSQL 
 Вы можете воспользоваться нашими услугами, если у вас потребность опубликовать вашу информационную базу 1С через веб-сервер.Если вы до этого работали в среде Windows и у вас нет времени осваивать линукс, вы можете воспользоваться нашими услугами по установке сервера 1С.Помогаем с развёртыванием PosgreSQL. 
       подробнее            подробнее            подробнее       
 
  

 

Настройка PostgreSQL
Обновление статистикиОчистка старых версийКонсультации по настройке параметров
Для оптимальной работы 1С необходимо настроить регламенты по обслуживанию базы данных. По сравнению с MS SQL Server требуется большее погружение в особенности настроек и их влияния. Загрузка базы из dt, массивное вливание данных через обмены или данных из других источников может также потребовать донастройки.Механизм версионирования PG может агрессивно увеличивать размер базы. Для противовеса постоянно работают «уборщики утративших полезность» данных. Настройка механизма и регламента по обслуживанию требует квалификации, так как даже просто увеличение мощностей в виртуалке требует ручной донастройки.В отличии от MS SQL Server в PostgreSQL не имеет постоянной автонастройки и нуждается в ручной вмешательстве в ряд параметров (которые могут неоднократно менятся по мере увеличения размера базы). Зато можно задать влияние дисков с разными скоростями.
      подробнее            подробнее            подробнее      

 

 
Курс обучения повышению производительности 1С для ПРОГРАММИСТОВ.
 
  Даты проведения Статус
    22 — 26 мая 2023Рекомендуем планировать и записываться заранее, места быстро заканчиваются. Для записи пишите на [email protected].       подробнее о курсе       

 

Узнай бесплатно производительность своего компьютера
Нашей командой разработан один из самых известных тестов по производительности — «Тест Гилева». Прямо сейчас вы можете воспользоваться им. Узнать производительность своей системы и, что самое важное, сравнить свой результат с другими результатами, полученными на различных вариантах конфигураций оборудования.
 
 
Прочитать подробнее о тесте   Скачать бесплатно тест TPC-GILV

 

Почему тормозит виртуалка?
  

 

Автоматический аудит MS SQL Server онлайн сервисом
При необходимости анализа параметров базы MS SQL Server, рекомендуем воспользоваться анализом при помощи онлайн-инструментов gilev. ru. Услуга подходит для клиентов которым нужен простой и удобный инструмент для анализа и имеются сотрудники, имеющие базовые знания по производительности 1С
010203
Проверка эффективности процессораПоиск проблем с дискомЭффективность работы с памятью
Загруженность. Распределение по базам данных. Ожидания на процессоре MS SQL Server. Устаревание моделей. Топ запросов. Параметры влияющие на характер нагрузки.Отклик дисков в разрезе баз данных. Ожидания на процессоре MS SQL Server. Контроль свободного места на диске.Использование памяти в разрезе баз данных. Факты нехватки. Типы ожиданий на памяти. Обнаружение проблем с обменом данных через память Shared Memory.
040506
Тестирование сетиАудит ПОАнализ объемов данных
Поиск избыточных сегментов. Обнаружение проблем с сетью. Отклик. Ожидания MS SQL Server по сети. Логические соединения СУБД.Контроль версий программного обеспечения. Анализ необходимости обновления. Влияние параметров настроек. Проблемы лицензирования. Моменты времени изменения кода конфигурации. Контроль режима управления блокировками и совместимости. Важные события субд. Дампы.Соответствие оборудования текущим объемом. Прогноз роста. Обнаружение проблемных таблиц. Отсутствие индексов. Актуальность статистики. Архитектурные ошибки. Контроль нулевых итогов. Фрагментация.
Подробнее
Бесплатные инструменты для анализа
 
  
 Сервис анализа долгих запросовСервис анализа ожиданий на блокировкахСервис анализа взаимных блокировок 
 Основная функция сервиса – детализация параметров исполнения проблемных запросов на разных уровнях информационной системы и локализация проблемных мест информационной системы, снижающих скорость исполнения операций.Сервис выполняет детальный анализ ожиданий на блокировках MS SQL Server.
* Позволяет обнаруживать причины длительных/излишних блокировок ресурсов SQL-сервера в 1С-коде
* Позволяет оценивать избыточность блокирования ресурсов MS SQL Server
* Предоставляет данные в сервис «Анализа долгих запросов» для оценки «вклада» времени ожидания на блокировке в общую длительность исполнения запроса		Основная задача сервиса – быстро и в удобном виде предоставить данные о причинах взаимных блокировок. Сервис автоматизировано обнаруживает в MS SQL Server данные о взаимоблокировках и собирает дополнительные параметры, необходимые для детального анализа этих ошибок (включая историю действий пользователей, спровоцировавших возникновение взаимоблокировки). 
       подробнее            подробнее            подробнее       
 
  

 

Памятка Заказчику для избежания лишних трат

 

1. При заказе функционале обязательным требованием указывайте ограничение по максимальной длительности операции, логированию фактического исполнения каждого факта исполнения операции.
 
2.При приемке сдаче работ отслеживайте превышение допустимых времен операций. Сами давайте обратную связь и требуйте этого от исполнителя. Примите без контроля — потом будете переплачивать за решение созданных проблем.
 
3. Решение о консолидации нескольких баз, смене продукта — принимайте только на основании результатов тестирования, а не обещаний что так работает у всех. Самые дорогие ошибки – сделанные в начале. Доверяй, но проверяй.
Новые системы должны решать проблемы, а не создавать новые. Консервативный подход «работает – не трогай» взялся не из пустого места: лучше не делать изменений, чем делать это в попыхах опираясь на чьито не проверенные слова.
 
4. Выясняйте и документируйте ограничения по эксплуатации. Ограничения придуманы не для того чтобы усложнить работу, а чтобы сохранить систему в работоспособном состоянии. Не надо думать что программы работают одинаково хорошо на любом железе, любых субд и любых условиях.
 
5. Тестируйте изменения сначала в копии, только потом в продуктиве. И в платформе, и в обновлениях типовых конфигурацию часто бывают ошибки. Людям свойственно ошибаться. Старайтесь вносить одно изменение за раз, чтобы в случае ухудшения можно было понять что именно повлияло.
 
6. Если вы не доверяете своим техническим специалистам, то замените их на тех кому будете доверять. Помните что проблемы создают люди, а не техника. Если же доверяете, то не надо им рассказывать как например надо хранить данные. Вы ставите задачи, они выполняют, вы проверяете результат. Плохо поставите задачу, результат будет непредсказуемый.
 
7. Не всё можно отдать на аутсорс. Ни один аутсорсер за Вас думать не будет. Постановку задачи отдать на аутсорс плохая идея. Впрочем, как и принятие любых стратегических решений и ключевых вопросов.

Ускорение Определение и значение | Dictionary.com

  • Лучшие определения
  • Викторина
  • Связанный контент
  • Примеры
  • Британский
  • Идиомы и фразы

Показывает уровень сложности слова.

[ speed-uhp ]

/ ˈspidˌʌp /

Сохрани это слово!

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

сущ.

увеличение скорости.

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

ВИКТОРИНА

ВСЕ ЗА(U)R ЭТОГО БРИТАНСКОГО ПРОТИВ. АМЕРИКАНСКИЙ АНГЛИЙСКИЙ ВИКТОРИНА

Существует огромная разница между тем, как люди говорят по-английски в США и Великобритании. Способны ли ваши языковые навыки определить разницу? Давай выясним!

Вопрос 1 из 7

Правда или ложь? Британский английский и американский английский различаются только сленговыми словами.

Происхождение ускорения

Впервые зафиксировано в 1920–1925 гг.; существительное использование глагольной фразы speed up

Ближайшие слова speed-up

speed shop, конькобежный спорт, катание на коньках, спидстер, ловушка скорости, ускорение, скоростная ходьба, скоростная ходьба, спидвей, вероника, спидрайтинг

Dictionary.com Unabridged На основе Random House Unabridged Dictionary, © Random House, Inc., 2023

Слова, относящиеся к ускорению

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

Как использовать ускорение в предложении

  • «Я думаю, что для транс-мужчин, которые встречаются каждый раз, когда они встречаются, у них есть еще один выход», — сказал Сэндлер.

    Проблема трансгендерных знакомств Гриндра|Дэвид Левсли|9 января 2015 г.|DAILY BEAST

  • На этой фотографии у Мерабета широкая улыбка, которая распространяется по всему лицу и освещает его глаза.

    Полицейский-мусульманин убит террористами|Майкл Дейли|9 января 2015 г.|DAILY BEAST

  • Ограничения по срокам могут быть предписанием для ускорения изменений.

    Невыносимая белизна Конгресса|Дин Обейдаллах|8 января 2015 г.|DAILY BEAST

  • В этом сезоне мы не узнаем, хотя это время от времени всплывает.

    Создатель «Лучника» Адам Рид раскрывает секреты 6-го сезона: от сюрреалистических сюжетных линий до жизни после ИГИЛ|Марлоу Стерн|8 января 2015 г.|DAILY BEAST опасность.

    Создайте своего собственного динозавра: Эра индивидуальной ДНК|Джастин Джонс|8 января 2015 г.|DAILY BEAST

  • Что нужно смотреть направо или налево, когда вы поглощаете свободную милю за милей головокружительной дороги?

    Веселые приключения Аристида Пужоля|Уильям Дж. Локк

  • Большинство мужчин вскочили, схватили копья или ножи и бросились прочь.

    Великан Севера|Р.М. Баллантайн

  • Через несколько недель кредитор оказался в Бостоне и, идя по Тремонт-стрит, встретил своего предприимчивого друга.

    Книга анекдотов и бюджет веселья;|Разное

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

    Эдинбургский журнал Blackwood, № CCCXXXIX. Январь 1844 г. Том. LV.|Various

  • Избранная невеста подбегает к нему, и они оба спускаются к рампе.

    Физиология оперы | Джон Х. Сваби (также известный как «Scrici»)

Определения ускорения в Британском словаре

ускорить

глагол (наречие)

увеличить или вызвать увеличение скорости или темпа; ускорить

существительное ускорить

пример этого; ускорение

использование для ускорения

Прошедшее время и причастие прошедшего времени для ускорения ускоряется, а не ускоряется

Английский словарь Коллинза — полное и полное цифровое издание 2012 г. © William Collins Sons & Co. Ltd., 1979, 1986 © HarperCollins Издательство 1998, 2000, 2003, 2005, 2006, 2007, 2009 гг., 2012

Другие идиомы и фразы с ускорением

ускорение

Ускорение, ускорение, увеличение скорости, как в Автомобиль ускорился, когда он пошел вниз, или Трудно ускорить производство без нового оборудования. [Конец 1800-х]

Словарь идиом американского наследия® Авторские права © 2002, 2001, 1995, издательство Houghton Mifflin Harcourt Publishing Company. Опубликовано издательством Houghton Mifflin Harcourt Publishing Company.

УВЕЛИЧЕНИЕ СКОРОСТИ (ЧТО-ТО) определение | Кембриджский словарь английского языка

Примеры увеличения скорости (чего-то)

увеличения скорости (чего-то)

Но теперь задокументирована скорость — до потока с этих ледников.

Из ВРЕМЕНИ