какой объект jira используется при расчете time to market
Measuring time to market in JIRA
Soo I got this cute little problem and waaay too little actual experience with jira to understand what the best solution is. So I’ll breakdown the problem and see if someone clever can point me in the best direction.
Problem: We have a few steps in our software management process, where todays workflow is based on when responsibility for approval changes. However we want to be able to improve on our time-to-market, which includes timing the steps in between the statuses in our workflow. Checkpoints so to speak.
The averages does not need to be part of the solution if we can export the data in some way to whatever tool for analysis.
Note that im not interested in the hours a person spends on a step, only time from opening to closing.
I have considered using:
Statuses in the workflow: However it doesnt make sense to change status for a step which is for example, created business case, and its quite the long list of statuses needed, and transitions between them is hard as its not always done in the same order. It simply makes jira harder to use.
Checklists: Its simple, but the timestamps and dataextraction is a problem I do not understand how to handle.
Subtasks: These can give me the timestamps for «open since», I could also automate creating new sub-tasks once the previous step has completed. But there are often other actual sub-tasks which needs to be done, and everything might get very cluttery. Possible sulition would be to have different sub-task types, but I dont know if this is possible.
Custom fields: Using custom fields for each step and inputing like dates for completion. Its manual, but it’s at lest simple. I think.
Anyone have anything similar they could share their experiences on out there? 🙂
Time to market: не теряйте время, это слишком дорого
В современном бизнесе есть понятие time to market — это время, которое компания тратит на реализацию и выпуск бизнес-идеи своим клиентам. Чем ниже time to market, то есть чем быстрее фича отправляется в продакшн, тем быстрее зарабатываются деньги для бизнеса. Подробнее — в статье руководителя отдела производства продукта для магазинов Леонида Савченкова.
В Яндекс.Маркете мы внедрили несколько изменений, которые помогли нам сократить время разработки новой фичи с 64 до 46 дней. Их можно применить в любой команде, которая разрабатывает софт.
После того, как разработчик написал код и убедился, что всё работает как ожидается, обычно требуется ещё несколько шагов до выкладки в прод. Сначала нужно провести код-ревью и тестирование. Затем код нужно упаковать, обновить конфиг, подготовить изменения в базе данных. В общем случае это выглядит так:
Теперь давайте посмотрим, как можно ускорить каждый из этапов.
Если код-ревью для вас — обязательный этап, максимально оптимизируйте его. Отдайте линтеру все стилистические требования, чтобы живой человек на них не отвлекался. Договоритесь в команде о правиле, что на код-ревью отводится 24 часа. Внедрите инструмент, который автоматически раздаёт задачи на код-ревью — с учётом справедливости, опыта членов команды и календаря отсутствия.
Вот так у нас получилось ускорить этот этап (на графике изображён 80-й персентиль времени, за которое коммит проходит код-ревью):
Ручная проверка готового релиза QA-инженерами может занимать много времени. Как правило, она проходит в два этапа: тестирование новой функциональности, ради которой и затевался релиз, и регрессионное тестирование, чтобы убедиться, что мы ничего не сломали. Ускорить процесс поможет уменьшение размера релизов и автоматизация тестирования.
Если релизы будут небольшими и простыми в развёртывании (см. следующий пункт про CI и CD), их легко будет тестировать. Стоит целиться в один релиз в день.
Далее избавляйтесь от ручного регрессионного тестирования — пишите интеграционные тесты на весь регрессионный пак. Для бэкенда это достаточно легко. Тесты должны писаться против контрактов API и покрывать все возможные ситуации. Интеграционные тесты при этом прогоняются против настоящего тестового окружения или с использованием моков наиболее сложных сервисов, состояние которых непросто воспроизвести. Тесты пусть пишут сами разработчики. Для фронтенда тесты пишутся против интерфейса и, как правило, ближе к концу реализации фичи. Фронтенд-тесты часто играют роль интеграционных.
После такого подхода к автоматизации профессия тестировщика бэкенда в Яндекс.Маркете исчезла как класс. Существующие QA-инженеры остались для фронтенда.
Вручную они теперь проверяют только новый функционал, а для регрессионного тестирования пишут автотесты.
Вот так мы избавились от ручного регресса для личного кабинета партнёров Маркета в 2019 году:
Time-to-Market как козырь для внедрения DevOps
Представьте себе фантастическую ситуацию — директор компании решает внедрить DevOps. Сам, без давления со стороны технарей. Без убедительного примера конкурентов. Руководство само признало, что повысить качество продукта, предсказуемость, прозрачность и повторимость бизнес-процессов при разработке и внедрении ПО невозможно без средств DevOps.
Представили? Получилось? Вы успешно прошли тест на самое богатое воображение!
На самом деле, конечно же, всё не так. Чаще всего руководству не до наших ИТ-шных штучек. Поэтому приходится убеждать. Но как?
Когда в качестве аргумента приводится повышение культуры общения между программистами и системными администраторами, то легко можно нарваться на контраргумент: а сейчас вы некультурные, что ли? Или даже могут напомнить о затратах, которые уже понесла компания год-два назад, когда вы дружно переходили на Agile. Неужели в ИТ каждый год появляется фича, способная продвинуть процессы революционным способом?
Насчёт повышения качества продукта тоже можно заикнуться. Но осторожно. Поскольку задачу программировать без ошибок ещё никто не отменял. Да, без багов никак, но именно поэтому в компании есть «целый отдел тестировщиков», не так ли?
Предсказуемость процессов — это вообще такой субъективный фактор, обосновать который и избежать шуток про Вангу и Нострадамуса довольно сложно.
При этом, если мы говорим о типичном энтерпрайзе, то в такой компании, скорее всего, есть уже сложившаяся ИТ-команда. И эта команда в старом (если не считать Agile) привычном ритме трудится вместе немало лет и вряд ли горит желанием (опять) что-то менять. Всех всё устраивает, кроме, естественно, руководства. Которое видит, что в их ПО постоянно сыплются какие-то ошибки, смещаются сроки выпуска новых версий.
Конечно, можно предположить ещё один вариант, когда в компанию приходит человек с опытом в DevOps, ясно представляющий, в чём проблема и как её нужно решать. И который способен донести своё мнение до руководства. Однако давайте не будем надеяться на чудо-дядю.
И на этом многие ломаются. Начинают говорить, что никто их не поддерживает, что в этом болотце ничего внедрить невозможно и затем просто уходят в другую компанию, где цикл повторяется.
Получается замкнутый круг? Нет, просто постепенно мы приходим к выводу, что с бизнесом нужно говорить только на понятном ему языке — на языке денег. Для этого мы достаём из широких штанин рукава главный козырь — сокращение Time-to-Market. Нужно показать, что благодаря DevOps новые версии продукта будут выпускаться, как горячие пирожки. А все остальные вышеперечисленные выгоды от внедрения DevOps давайте оставим для итоговой презентации, которую мы создадим для директора, когда все получится. Многие скажут, что это слишком очевидно. Нет!
Нам нужно что-то, что займет у нас минимум времени и ресурсов (ведь никто не разрешит списывать человеко-месяцы на внедрение некоего DevOps и не закупят для нас срочно новых серверов), но при этом даст очень ощутимый результат (реально сократит Time-to-Market).
Для начала нужно найти бутылочное горлышко, а оно всегда одно (первый шаг в теории ограничений Голдратта). После успешного внедрения Agile (а все это имеет смысл только после внедрения Agile), в плане разработки софта всё равно им остается ручное тестирование. Даже при наличии пула свободных рук, регрессионное тестирование может занять две-три недели. А уж от том, как тестировщики «любят» проводить регрессионное тестирование, знаю все.
Итак, мы определили, что бутылочным горлышком является тестирование. Тогда начать нужно с его автоматизации. Многие заметят: легче сказать, чем сделать. Уже написаны миллионы строк кода, и хорошо, если программисты хоть что-то покрыли модульными тестами. На самом деле все не так страшно, как кажется. Как показывает опыт, 80 % успешного результата в виде серьезного снижения Time-to-Market достигается за счёт 20 % усилий. Именно во столько примерно обходится автоматизация тестирования в нашем случае.
Совсем по закону Парето, ага.
И самое главное, запустить автоматизацию тестирования можно ещё до того, как руководство согласится выделить ресурсы на внедрение остальных частей DevOps. Небольшой такой пилотный проект, который можно сделать собственными силами за одну-две недели.
Но при этом такая ситуация нам даёт шанс одержать эффектную и, самое главное, быструю победу. После которой, имея позитивный настрой и благословение руководства, уже можно просить и деньги, и ресурсы.
Начнём с того, что, наверняка, ваши программисты уже используют какое-либо серверное ПО для ежедневной сборки. Это может быть TeamCity, либо Bamboo, либо Jenkins, — не принципиально. Главное, часть автоматизации уже есть и это нужно использовать, а если нет, то за день его легко развернуть.
Сначала надо автоматизировать «дымовые» тесты. А как понять, что автоматизировать? Да просто посмотрите, что у вас регулярно ломалось при выкладке изменений за последние полгода.
Дальше нужно создать несколько тестов проверки работы основных бизнес-процессов. Как их определить? Задать вопрос вашим аналитикам/директорам/представителям бизнеса, при какой поломке в кабинет к программистам вбегает разъяренный директор и ставит задачи повышенным голосом.
Неделя, ну максимум две на создание таких тестов. В результате — очень быстрый фидбек на предмет глобальных ошибок.
И пока проект в режиме proof of concept, не надо заниматься подготовкой того же автоматического развертывания сервера для тестирования и прочими бантиками, а всё сделать вручную. Эту красоту потом можно с удовольствием сделать вместе с админами.
К чему это приведёт, догадаться не сложно. Разработчики сразу будут видеть (и исправлять) свои ошибки. Тестировщики будут избавлены от рутины в виде проведения долгих и нудных тестов на регресс. Им останется пара-тройка дней для того, чтобы протестировать только те места кода, которые были подвержены правке. Да-да, именно так. А если нет, то вернитесь в начало и еще раз поговорите с аналитиками/директорами/представителями бизнеса на тему критичных для бизнеса процессов.
Бутылочное горлышко, из-за которого возникали основные тормоза, ликвидировано. Теперь остаётся только выпустить несколько новых релизов в продуктивную среду, снять статистику «было/стало» и идти с этими цифрами к руководству. Профит!
После такой убедительной победы уже можно разговаривать про автоматизацию развертывания стендов (как минимум для тестирования). Далее выпрашивать средства на мониторинг и прочие прелести DevOps. При этом нужно помнить, что остальные компоненты системы уже не будут иметь вау-эффекта для бизнеса.
Пример в студию
В завершение поста, думаю, уместно будет привести пример успешно завершенного проекта по внедрению DevOps, который реализовала наша компания.
У одного крупного ритейлера около 20 % бизнеса приходится на интернет-магазин. При этом реагировать на рыночную ситуацию и вносить необходимые изменения в ПО нужно очень быстро. И часто. И качественно. Любой косяк на сайте может повлиять на конверсию, риски выражаются в реальных деньгах.
Для сокращения времени обновления и повышения качества была создана специализированная платформа автотестов, на которой были автоматизированы рутинные задачи по тестированию изменений и регресса сайта. Кроме того, был выстроен процесс взаимодействия группы автоматизированного тестирования с командами разработки. Это позволило разработчикам сразу выявлять и исправлять дефекты в обновляемой системе, не дожидаясь финального приемочного тестирования.
Представители ритейлера сочли опыт успешным и решили применить его к остальным софтверным продуктам.
И ещё небольшой пример, но уже из практики одной крупной страховой компании. До внедрения автоматизации тестирования релизы выходили раз в полгода. Не потому, что так требовал бизнес, — просто чаще не получалось. А заказчик как раз хотел. Так вот, через два месяца после начала внедрения средств автотестирования, ИТ-команда перешла на двухнедельные итерации выпуска релизов.
Достаточно показательно, чтобы начать этим заниматься, не так ли?
Сергей Страмнов, пресейл-архитектор Центра программных решений «Инфосистемы Джет»
Как сократить time-to-market: история про автоматизацию тестирования в «М.Видео»
Быстрая и эффективная разработка ПО сегодня немыслима без отточенных рабочих процессов: каждый компонент передается на сборку к моменту установки, изделие не простаивает в ожидании. Еще два года назад мы совместно с «М.Видео» начали внедрять такой подход в процесс разработки у ритейлера и сегодня продолжаем его развивать. Каковы промежуточные итоги? Результат полностью себя оправдал: благодаря реализованным изменениям удалось ускорить выпуск релизов на 20–30 %. Хотите подробностей? Вэлком в наше закулисье.
Со Scrum на Kanban
В первую очередь была реализована смена методологии — переход со Scrum, то есть спринтовой модели, на Kanban. Раньше процесс разработки выглядел так:
Есть ветка разработки, есть спринты для пяти команд. Они кодят в своих собственных ветках разработки, спринты заканчиваются в один день, и все команды в тот же день объединяют результаты своей работы с мастер-веткой. После этого в течение пяти дней прогоняются регрессионные тесты, затем ветка отдается в пилотную среду и после неё — в продуктивную. Но, прежде чем запустить регрессионные тесты, приходилось 2–3 дня хоть как-то стабилизировать мастер-ветку, убирая конфликты после объединения с командными ветками.
В чем преимущество Kanban? Команды не ждут конца спринта, а объединяют свои локальные изменения с мастер-веткой по факту окончания реализации задачи, каждый раз проверяя, нет ли конфликтов объединения. В назначенный день все объединения с мастером блокируются и запускаются регрессионные тесты.
В результате удалось избавиться от постоянных сдвигов сроков вправо, регрессы
не задерживаются, release candidate отгружается вовремя.
Вездесущая автоматизация
Конечно, одной лишь смены методологии было недостаточно. Вторым этапом мы совместно с ритейлером автоматизировали тестирование. Всего проверяется около 900 сценариев, разбитых на группы по приоритетам.
Около 100 сценариев — так называемые блокеры. Они должны работать на сайте —интернет-магазине «М.Видео» — даже во время атомной войны. Если какой-то из блокеров не работает, значит на сайте большие проблемы. Например, к блокерам относятся механизм покупки товаров, применение скидок, авторизация, регистрация пользователей, оформление кредитного заказа и т.д.
Ещё примерно 300 сценариев — критически важные. К ним относится, к примеру, возможность выбирать товары с помощью фильтров. Если эта фича сломается, то вряд ли пользователи будут покупать товары, даже если будут работать механизмы покупки и прямого поиска по каталогу.
Остальные сценарии — major и minor. Если они не будут работать, люди приобретут негативный опыт использования сайта. Сюда относится множество неполадок разной важности и заметности для пользователя. Например, поехала верстка (major), не отображается описание акции (minor), не работает автоподсказка по паролям в личном кабинете (minor), не работает восстановление (major).
Вместе с «М.Видео» мы автоматизировали тестирование блокеров на 95 %, остальных сценариев — примерно на 50 %. Почему около половины не автоматизированы? Причин много, и разных. Есть сценарии, априори не поддающиеся автоматизации. Есть сложные интеграционные кейсы, подготовка к которым требует ручной работы, например, позвонить в банк и отменить заявку на кредит, связаться с отделом продаж и отменить заказы в продуктивной среде.
Автоматизация регрессионных тестов сократила их длительность. Но мы пошли дальше и автоматизировали еще и smoke-тесты для блокеров после каждого объединения веток команд с мастер-веткой.
После автоматизации тестов мы окончательно избавились от задержек после завершения объединений с мастер-веткой.
Gherkin в помощь
Чтобы закрепить успех, наша команда переработала сами тесты. Раньше это были таблицы: действие → ожидаемый результат → фактический результат. Например, я с таким-то логином и паролем авторизовался на сайте; ожидаемый результат: всё в порядке; фактический результат — тоже всё в порядке, перехожу по другим страницам. Это были громоздкие сценарии.
Мы перевели их в нотацию Gherkin и автоматизировали некоторые шаги. Возьмём ту же авторизацию на сайте, сценарий теперь формулируется так: «как пользователь сайта я авторизовался с авторизационными данными, и процедура прошла успешно». При этом «пользователь сайта» и «авторизовался с авторизационными данными» вынесены в отдельные таблицы. Теперь мы можем быстро прогонять тестовые сценарии вне зависимости от данных.
В чём ценность этого этапа? Допустим, тестированием проекта занимается один тестировщик. Ему плевать, как он пишет тесты, он может делать проверки хоть в виде чек-листа: «авторизация проверена, регистрация проверена, покупка картой проверена, покупка Яндекс.Деньгами проверена — я красавчик». Приходит новый человек и спрашивает: а ты авторизовался по e-mail или через Facebook? В результате чек-лист превращается в сценарий.
В проекте работают пять команд, и в каждой минимум по два тестировщика. Раньше каждый из них писал тесты, как ему заблагорассудится, и в результате тесты могли поддерживать только их авторы. С автоматизацией всё было глухо: либо нужно набирать отдельных автоматизаторов, которые весь зоопарк тестов переведут на скриптовый язык, либо забыть об автоматизации как о явлении. Gherkin помог всё изменить: с помощью этого скриптового языка мы создали «кубики» — авторизация, корзина, оплата и т. д. — из которых тестировщики теперь собирают различные сценарии. Когда нужно создать новый сценарий, человек не пишет его с нуля, а просто подтягивает нужные блоки в виде автотестов. Нотации Gherkin обучили всех функциональных тестировщиков, и теперь они могут самостоятельно взаимодействовать с автоматизаторами, поддерживать сценарии и разбирать результаты.
На этом мы не остановились.
Функциональные блоки
Допустим, релиз 1 — это функциональность, которая уже есть на сайте. В релизе 2 мы захотели внести какие-нибудь изменения в пользовательские и бизнес-сценарии, и в результате часть тестов перестала работать, потому что функциональность изменилась.
Мы структурировали систему хранения тестов: разбили её на функциональные блоки, например, «личный кабинет», «покупка» и т. д. Теперь, когда вводится новый пользовательский сценарий, в нём уже галочками отмечены необходимые функциональные блоки.
Благодаря этому после объединения с мастер-веткой разработчики могут проверять работу не только блокеров, но и сценарии, относящиеся к предметной области, которую затрагивают сделанные изменения.
Второе следствие — стало гораздо легче поддерживать сами тесты. Например, если что-то поменялось в личном кабинете, оформлении заказа и доставке, нам не нужно перетряхивать всю регрессионную модель, потому что сразу видны функциональные блоки, в которые внесены изменения. То есть поддерживать тестовый набор в актуальном состоянии стало быстрее, а значит, и дешевле.
Проблема со стендами
Раньше никто не проверял работоспособность стендов до приемочного тестирования. Например, передают нам какой-нибудь стенд на тестирование, мы гоняем на нём несколько часов регрессионные тесты. Они падают, разбираемся, исправляем, снова запускаем тесты. То есть теряем время на отладку и повторные прогоны.
Проблема решилась просто: написали всего 15 API-тестов, проверяющих конфигурацию стендов, которые никак не связаны с функциональностью. Тесты не зависят от версии сборки, они лишь проверяют все интеграционные точки, критичные для прохождения сценариев.
Это помогло сэкономить очень много времени. Ведь до автоматизации у нас было 14 тестировщиков, проверки были громоздкие и длительные, были сценарии практически на весь день работы, состоящие из 150 шагов. И вот ты тестируешь, и где-нибудь на 30–40–110-ом шаге понимаешь, что стенд не работает. Умножаем потерянное рабочее время на 14 человек и ужасаемся. А после внедрения автоматизации и проверки стендов удалось сократить количество тестировщиков вдвое и избавиться от простоев, что принесло много радости главбуху.
Вишенки на торте
Первая вишенка — bugflow. Формально, это жизненный цикл любого бага, а на самом деле любой сущности. К примеру, мы оперируем этим понятием в Jira. Один дополнительный статус позволил нам ускорить релизы.
В целом процесс выглядит так: нашли инцидент, взяли его в работу, завершили над ним работу, передали в тестирование, протестировали, закрыли.
Мы понимаем, что дефект закрылся, проблема решена. И добавили еще один статус: «для регрессионного тестирования». Это значит, что после анализа, сценарии, обнаруживающие критичные баги, добавляются в регрессионный набор из 900 сценариев. Если их там не было, или если у них была недостаточная детализация, значит, у нас происходит моментальная обратная связь по состоянию продуктива или пилота.
То есть мы понимаем, что есть проблема, и мы её по какой-то причине не учли. И теперь добавление сценария проверки бага сильно экономит время.
Также мы на уровне тестирования внедрили ретроспективу. Выглядит это так: составили табличку «номер релиза, количество багов в нём, количество блокеров и других сценариев, и количество резолюций». При этом мы оценивали количество невалидных резолюций. К примеру, если из 40 багов получается 15 невалидных, то это очень плохой показатель, тестировщики впустую тратят не только своё время, но и время разработчиков, которые работают над этими багами. Ребята начали рефлексировать, разбираться с этим, внедрили процедуру ревизии багов более опытными тестерами перед отправкой в разработку. И они очень хорошо с этим справились.
Таким образом, происходит постоянная рефлексия и работа по улучшению качества. Все баги с продуктива анализируются: на каждый баг создается тест, который сразу включается в регрессионный набор. По возможности данный тест автоматизируется и запускается на регулярной основе.
Результаты
Изначально планировалось увеличить частоту релизов и снизить количество ошибок, но итог несколько превзошел ожидания. Разумно построенный процесс автоматизации дал возможность нарастить количество автоматизированных тестов за короткое время, а проводимый анализ пропущенных багов позволил команде разработки и тестирования оптимально выстроить приоритеты в сценариях и фокусироваться на самом важном.