time to market что это значит
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 что это значит
Один наш клиент постоянно не успевал вовремя выпускать релизы (обновления и новый функционал программного обеспечения) с клиентскими скидками. Его специалисты работали по 14–16 часов в выходные и ненавидели «черные пятницы» и «киберпонедельники». Качество выпускаемого в таком режиме программного обеспечения оставляло желать лучшего, работу в выходные приходилось оплачивать по двойному тарифу, продуктивность падала, сотрудники уставали и увольнялись, покупатели, натыкаясь на критические ошибки при совершении покупок, злились и уходили на сайты других компаний.
При этом ФОТ составлял 13,5 млн рублей в месяц, выпуск «срочного» релиза занимал 2 месяца, релиз в среднем содержал 1–3 блокирующих и до 10 критичных проблем системы, что приводило к репутационным и финансовым потерям.
В попытке разобраться, в чём же причина такого долгого и проблемного релизного цикла, заказчик обратился к нам. Выполнив аудит, мы обнаружили стандартную историю, в которой каждый наверняка найдет знакомые детали: много ручного труда (начиная со сборок и наката релиза на тестовую среду и заканчивая подготовкой тестовых данных); отсутствие автоматизированного тестирования; низкая квалификация сотрудников; наличие полной экспертизы лишь у одного человека, который руководствуется исключительно своими приоритетами (узкое горлышко); нежелание что-то менять; пропасть между ИТ и бизнесом в попытке понять, почему всё так долго и так плохо.
В первую очередь мы занялись основными процессами: выделили самые критичные бизнес-сценарии, автоматизировали их проверку; реализовали автосборку; настроили автораскатку на стенды разработки, тестирования и на продуктив; автоматизировали подготовку тестовых данных; разбили проверки на важные и менее важные, важные начали автоматизировать; команда ручного тестирования получила список самых важных проверок при нехватке времени. К окончанию проекта мы имели 92% автоматизированных проверок из всего объема и смогли сократить команду тестирования на 30%. Разработчики же, освободившись от необходимости тратить время на ручные сборки и раскатки, начали выполнять больший объем работы за тот же период.
Сотрудники счастливы и проводят выходные с семьей, никто не увольняется, бизнес получает свои изменения вовремя и с достойным качеством, у покупателей нет проблем при выборе и покупке товаров на сайте.
Наряду с этим, время вывода среднего релиза сократилось до 2 недель при 30-процентной экономии ФОТ и выводе качества среднего релиза на уровень 0 блокеров, 0–5 критичных багов! Проект обошелся заказчику в один месячный ФОТ текущей ИТ-команды, занял 3,5 месяца и окупился примерно через 2 месяца после внедрения.
Одна крупная компания потеряла 200 млн рублей, выпустив плохо протестированный релиз в продуктив. Причиной этого стала попытка сэкономить на персонале (ФОТ, операционные затраты): тестировщик-стажер халатно отнесся к выполнению тест-кейса — пометил интеграционный кейс как пройденный, ничего на самом деле не проверив. «Честное» ручное прохождение теста заняло бы 15 минут с проверкой настроек системы и логов. Автоматизированный тест занял бы менее 1 минуты плюс пару минут на выяснение, в чём проблема. Цифры и удивляют, и убивают одновременно.
Всегда существует человеческий фактор: люди ошибаются, не высыпаются, ссорятся с женами/мужьями, просто не в настроении, наконец. Поэтому, автоматизируя процессы, мы убиваем двух зайцев: ускоряем процесс и обеспечиваем качество, исключая тот самый человеческий фактор. Автоматизация одного сквозного сценария (с проверкой интеграционных значений) занимает от 2 до 16 часов (в зависимости от сложности). Поэтому решительно непонятно, зачем многомиллиардная компания сэкономила на мелочи, получив потом такие убытки.
Добавим чуть-чуть технических деталей. Чем раньше найдена ошибка в программном обеспечении, тем дешевле обойдется работодателю ее исправление, так как:
1. Разработчик всё еще работает над тем же куском программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и правку он делает буквально «на лету».
2. Другие разработчики не вносят изменения в этот содержащий ошибки программный код.
3. Ветки кода не успели размножиться на последующие релизы, и не нужно будет исправлять один и тот же баг сразу в нескольких местах, учитывая версионность кода.
4. Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.
Маленький пример такой экономии для среднеразвитой системы, изменения в которую вносятся 1 раз в 2 месяца, представлен в таблице.
Умножьте эти цифры на ваш текущий ФОТ ИТ-команды и время вывода изменений в продуктив, и вы узнаете ваши потери.
В век информационных технологий трудно переоценить важность скорости, с которой компании могут внедрять изменения. На рынке всегда найдется пара конкурентов, которые сделают это быстрее или лучше.
Какой путь выберет компания и знает ли она о текущих возможностях?
Можно идти пешком. Можно воспользоваться транспортным средством: велосипедом, машиной, — но без учета пробок на дороге такое движение может оказаться значительно продолжительнее по сравнению с движением пешехода.
Конечно, вопрос о том, как добраться до цели в нужные сроки, правильно выбирая средства и обеспечивая оптимальные затраты, должны решать профессионалы, ведь иногда промедление смерти подобно.
У любой (не только из сферы ИТ) компании это может быть выпуск нового продукта для сохранения конкурентного преимущества при участии в тендере, если речь идет о B2B, или компания просто решила сделать продукт более привлекательным для существующих или новых клиентов в случае B2C.
В конце концов, это могут быть банальное обеспечение соблюдения сроков для устранения замечаний регулятора или доработка решения к какой-то фиксированной дате в связи с введением в действие нового законопроекта. В таких случаях, если компания не успела внести изменения в срок, приостанавливается действие ее лицензии, у нее нет деятельности, нет прибыли, она теряет клиентов.
Важно понимать, что все инструменты, методологии и подходы можно применять и по отдельности — они однозначно будут давать эффект и уменьшать время вывода продукта на рынок. Но наибольший эффект мы можем получить, только применяя все подходы сразу, — тогда сокращение Time to Market (T2M) может стать максимально большим за счет эффективности каждого из процессов.
Для среднего релиза (3 командо-месяца) картинка будет примерно такая: автоматизировали сборку — сэкономили 5% ФОТ и T2M, автоматизировали подготовку тестовых данных — сократили 10% ФОТ и T2M, автоматизировали smoke test — еще 5% ФОТ и T2M, регресс — 10–15%. Добавьте в этот коктейль гибкие методологии разработки, и получите свои законные 40–50% экономии ФОТ и времени вывода релиза.
При этом для системы средней сложности (и ее интеграционных взаимодействий) сам проект занимает не более 4 месяцев, а окупается уже за 2–3 месяца.
Когда непрофильные компании берутся за разработку ПО, они заново изобретают велосипед, не понимая, как улучшить процесс и сделать его по-настоящему эффективным. Как большинство не ИТ-компаний работает сейчас (см. рис. 1).
А вот как должно быть (см. рис. 2).
Правило простое: любое повторяющееся из раза в раз действие должно быть автоматизировано и настроено на регулярный запуск (по расписанию или событию), что позволяет сократить и время, и количество людей, поддерживающих данную рутину.
Кроме того, мы исключаем человеческий фактор: скрипт выполняет одно и то же действие из раза в раз, не устает, у него «не замыливается глаз», он не допускает ошибок, работает по выходным и по ночам — и даже не просит оплаты сверхурочных.
И да, в скором времени нас всех заменят роботы.
В завершение хочется сказать, что даже в одной компании может быть несколько десятков систем, находящихся на разном уровне развития в части автоматизации процессов.
Текущая картина в системе определяется при помощи ключевых точек в процессе разработки и тестирования, и мы легко можем сказать, находится ли система на нулевом уровне развития или она уже на стадии зрелых процессов и относится к продвинутому уровню.
Переход с начальных уровней на высокие, безусловно, дает максимальный и зримый эффект. Для того чтобы понять, на каком уровне развития (зрелости) находится та или иная система, в нашей компании используется четкая методика оценки, из которой легко вычленить цели и результаты, которых мы хотим добиться, автоматизируя процессы в системе. Так заказчик проверяет результаты внедренных изменений, опираясь на четкие KPI. Так он получает ясное представление о тех изменениях, которые будут внесены в процесс.
В настоящее время многие компании-интеграторы начинают предлагать свои услуги в области автоматизации процесса разработки и тестирования. Уже не такими новыми выглядят термины DevOps, CI/CD, pipeline, agile — даже для не ИТ-управленцев. О себе в контексте данной темы мы можем скромно сказать, что съели на этом собаку, кошку и даже маленького слона.
Материал подготовлен Ольгой Шишелиной, руководителем отдела тестирования Дирекции по разработке и внедрению программного обеспечения компании «Инфосистемы Джет»
Ускорение Time to Market: реально ли выпускать обновления в 3-5 раз быстрее?
Для многих компаний проблема выпуска новых версий ПО — это настоящая боль, которая связана с длительным и затратным тестированием, устранением багов и огромными потерями времени. Поэтому сегодня мне хочется рассказать про ускорение Time to Market и о тех бизнес-выгодах, которых можно достичь за счет улучшения процессов разработки ПО и автоматизации тестирования.
Крупные банки, страховые, ритейл и даже промышленность последние 5-6 лет говорят о себе, как об ИТ-компаниях. Но если для fin-, ed-, food-стартапов приставка tech и скорость работы — это их свойства с рождения, то для крупного бизнеса — 4 месяца на выпуск релиза с блокирующими и критическими ошибками на продуктиве — это печальная реальность, с которой компании ведут неравный бой.
По данным Capgemini 25%-40% бюджета в общепринятой мировой практике разработки ПО тратится на Quality Assurance. Это говорит о том, что отсутствие автоматизации является распространенной проблемой, и в результате слишком много ресурсов тратится на ручное тестирование. Больше всего пугает в этом контексте то, что ручное тестирование не решает проблемы качества и скорости разработки, и по мере роста сложности проектов и увеличения объема кода, отсутствие автоматизации все равно приводит к потерям.
У меня сложилось впечатление, что отставание крупных компаний в вопросах ускорения Time2Market объясняется тем, что руководители либо не слишком близко знакомы с ИТ, либо недостаточно погружены в существующие процессы. На некоторых проектах только после длинной серии итераций и общения с ИТ-специалистами (как своими, так и на стороне партнера/подрядчика) у руководства формируется понимание, что своевременный выход релизов с нужным качеством приводит к росту основных показателей бизнеса.
В самых разных отраслях — от розницы и банковского дела до промышленности и добычи полезных ископаемых — финансовые показатели стали напрямую зависеть от того, насколько быстро и качественно была внедрена очередная система. Поэтому все чаще топы VP или C-level уровней откладывают в сторону стратегии и подсчеты P&L и EBITDA и стараются научиться говорить с ИТ на одном языке во имя повышения скорости изменений.
Мы в «Инфосистемы Джет» практически на каждом нашем проекте, связанном с внедрением инструментов и методологий CI/CD/DevOps, сталкиваемся с фактом, что самая трудоемкая часть — не автоматизация, которую умеют делать почти все. Сложнее всего оказывается изменить образ мышления ИТ и бизнеса, помочь им обрести точки контакта и научить говорить на языке друг друга.
Чтобы добиться этого, нам приходится сначала расположить разные отделы к себе как к подрядчику, а далее — подтолкнуть к правильным действиям и научить задавать нужные вопросы. Мы стремимся сделать все возможное, чтобы внутри компании заказчика развернулся и заработал конвейер — пайплайн доставки софта на продуктив.
Без ошибок. Без перерасхода трудозатрат. Без потерь денег. Быстрее конкурентов.
Если раньше можно было тратить месяцы на выпуск новой версии чего-либо — системы, клиентской части интернет-магазина или дополнительных сервисов, необходимых для бизнеса, то сегодня долгий time2market — это фактически приговор. На реальных проектах наши ребята из отдела разработки и тестирования постоянно сталкиваются со следующими проблемами заказчиков:
несоблюдение сроков вывода на продуктив, нарушение SLA;
недостаточно современные подходы и инструменты управления качеством;
Все эти проблемы приводят к дополнительным затратам на разработку и снижению уровня прибыли от каждого нового релиза (которая напрямую зависит от скорости выхода в продуктив, а также наличия или отсутствия ошибок и проблем на стороне пользователей). Таким образом, затраты оказываются обратно пропорциональны скорости и качеству разработки и тестирования. В результате компания, выпускающая за два дня обновление своего сервиса с блестящим качеством, будет намного успешнее на рынке, чем фирма, подготовившая за две недели релиз с ошибками.
Идет ли речь про новый сервис или функциональность уже работающей системы, новую модель машинного обучения или пользовательский интерфейс, реальные результаты для бизнеса от этих инноваций зависят от скорости выпуска релизов. Каждый раз, когда компания планирует вывести на рынок новый сервис или улучшить старый, запускается один и тот же процесс:
Несмотря на то, что во многих организациях считают этот процесс очень простым, именно недостаточная оптимизация вывода ПО на продуктив значительно снижает эффективность работы отдела, приводя к росту затрат и снижению удовлетворенности клиентов. Ведь разработка и тестирование без выстроенных процессов автоматизации — это:
Например, когда новый релиз готовится к выходу в продуктивную среду, команда разработки/тестирования обязательно проводит регрессионные тесты, которые должны проверить совместимость новых функций с уже работающим функционалом. На практике же мы часто видим подобные схемы взаимодействия:
Разработчик: “Я закончил, нужно разворачивать стенд и тестировать”.
Инженер: “Сейчас уже нет времени, завтра запустим”.
Тестировщик: “Сегодня все уже забито, проведём тесты в ближайшие дни”.
Через несколько дней проводятся тесты, в ручном режиме находятся несколько проблем.
Разработчик: “Я уже другую задачу решаю. Как закончу, вернусь, попробую вспомнить, что там было”.
Инженер: “Ну что ж такое, опять стенд готовить”.
Тестировщик: “А, это я уже тестировал, теперь проверю только найденные баги”.
В итоге — критическая ошибка — в заказах теряется информация из поля “телефон клиента”. Приходится срочно откатываться, вносить изменения, выпускать релиз снова.
На реальных проектах видно, что за счет автоматизации хотя бы только этого этапа компания может уменьшить ФОТ проекта до 10%. Если же автоматизировать подготовку данных для последующих тестов, дополнительная экономия может составить еще около 12%. Инвестиции в подобные оптимизации обычно окупаются в срок не более полугода.
Архаичные процессы разработки чреваты появлением серьезных ошибок в продуктивной среде, с которой в конечном счете контактирует клиент. Кроме репутационных потерь, на которых сейчас не будем заострять внимание, проникновение ошибок в готовый продукт приводит к кратному росту затрат.
Проблема заключается в том, что при обнаружении ошибки уже после релиза, компания вынуждена:
Решить эту проблему можно за счет автоматических тестов. При должной автоматизации проверить новый компонент можно моментально после завершения работы, а значит программист сможет сразу же исправить ошибки, которые будут выявлены за несколько секунд вместо нескольких дней, и, главное, еще до тестирования и старта продуктивной эксплуатации.
Когда процессы разработки не выстроены должным образом, бизнес может столкнуться с проблемами разного характера. Это может быть отсутствие работающего механизма сортировки товаров, приводящий к потере клиентов. Или ошибки в формировании цен.
Например, как сообщали Ведомости, интернет-магазин «Связной» из-за сбоя в программном обеспечении продавал смартфоны по заниженным ценам. Клиенты могли заказать iPhone 8 с объемом памяти 64 Гб по цене около 6000 рублей, хотя обычно его цена не ниже 35 000. Более старые модели продавались по 49 рублей. Поскольку речь идет про федеральную сеть и популярный интернет-магазин, такой “распродажей” всего за 15 минут смогли воспользоваться 854 человека, а при сумме “скидки” в десятки тысяч рублей ущерб составил десятки миллионов.
Отсутствие выстроенных процессов приводит к срыву дедлайнов. А это означает, что на финальный этап, подразумевающий тестирование, остается минимальное количество времени. Даже если сотрудники работают без выходных и сидят над проектами ночью накануне выпуска релиза, они просто не смогут гарантировать его 100% работоспособность, если все предыдущие сроки были сорваны.
Но кто хочет оказаться в ситуации, когда выпущенный сервис не соответствует критериям качества и может повести себя непредсказуемо? Именно поэтому практика оптимизации разработки и внедрения современных подходов к тестированию помогает не просто выводить продукты на рынок раньше, но также делать их более совершенными.
Поэтому без внедрения средств автоматизации любое бизнес-направление начнет терять прибыль и сталкиваться с растущими затратами. Это связано с ростом общих объемов разработки, увеличению количества строк кода и взаимосвязанных программных продуктов. Из-за высокой нагрузки разработчики начинают чаще допускать ошибки, а отсутствие консолидированного подхода к выпуску обновлений требует большого объема трудозатрат в области тестирования и исправления ПО.
Наше подразделение тестирования собрало интересную статистику. Например, в системе средней сложности без автоматизации процессов, где трудится 7-10 разработчиков, 1 релиз выпускается за 3-5 месяцев, причем в нем допускается до 100 критичных и важных ошибок! А цена их исправления в продуктиве оказывается несоразмерно выше. Эту проблему подтверждает и мировая практика.
Внедрение автоматизированных тестов и унификация процессов тоже не сразу приводит к экономии. Например, для среднестатистического релиза, на который обычно уходит три месяца работы команды, экономия за счет уменьшения фонда оплаты труда (ФОТ) складывается из таких компонентов как:
При этом проект автоматизации и оптимизации системы средней сложности (и ее интеграционных взаимодействий) занимает не более 4 месяцев, а окупается уже за 2-3 месяца только на экономии ФОТ. На графике четко видно, как затраты возрастают на период старта проекта по построению автоматизации и организации процессов CI/CD, но уже с 5 месяца они оказываются на 25% меньше, продолжая снижаться со временем. То есть с 8 месяца изменения в процессах начинают «приносить прибыль», не говоря уже о том, что мы добиваемся сокращения Time to Market в 1,5-2 раза.
Не стоит забывать, что затраты на «ручные» процессы продолжают постепенно возрастать, т.к. любая система усложняется, и на ее поддержку уходит все больше сил. Растущее количество кода оказывается все затратнее отслеживать в ручном режиме. Поэтому выстраивать процессы нужно сразу в соответствии с проверенными методологиями, иначе затраты на переделывание будет в разы дороже. Но даже через некоторое время перейти на автоматизацию будет дешевле, чем продолжать делать все руками.
В следующей статье я как раз расскажу о реальном опыте ускорения Time to Market, в ходе которого увеличение частоты выхода релизов и повышение качества версий помогло компании снизить затраты на десятки процентов. При этом возможность возникновения значимых ошибок в работе своего интернет-магазина была полностью исключена.
Решить эту проблему можно за счет автоматических тестов. При должной автоматизации проверить новый компонент можно моментально после завершения работы, а значит программист сможет сразу же исправить ошибки, которые будут выявлены за несколько секунд вместо нескольких дней, и, главное, еще до тестирования и старта продуктивной эксплуатации.
Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?
На этапе разработки, даже разработчик(а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию.
Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.
Даже в случае проведения исключительно регрессионного тестирования, имеют место быть трудозатраты, связанные с актуализацией кодовой базы сценариев, с целью убрать побочные эффекты от изменений, затрагивающие существующие сценарии, например.
Так что, даже если «секунды» были гиперболизацией, то все равно, до фазы тестирования вам(нам/всем) ничего не светит. ред.
Мммм, ну лаааадноооо. )
>>Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?
>>>>На этапе разработки, даже разработчик (а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию
>>>>Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.