Comments 12
Отличная статья, подходы импонируют. Единственное что режет глаз: не очень точно используются понятие SLA, рекомендую ознакомиться с пояснением схожих понятий
спасибо большое за комментарий, давайте скорее поправим неточности, в каком конкретном месте предлагаете заменить ?
Я думаю во всех, SLA -> SLO. В книге Google SRE мысль примерно так звучит: если юристы и финансовые штрафы не грозят после пробития ожиданий, то это не SLA.
Для нас тайминги всё же скорее — это agreement, а не objectives. Для команды это практически внешнее обязательство: если мы не уложимся в это время, то это повлияет на работу других команд. Это не "желаемое значение", а строгое требование, поэтому SLA, кажется уместнее.
ITIL с этим мнением не согласен.
Очень интересная и познавательная статья!
Хотел бы спросить у автора по поводу моральной составляющей разработчиков. Все описанное как-будто бы делает работу разработчиков очень динамичный и постоянно напряженной, так как надо каждый час за чем-то следить и быстро править. Как с этим справляется команда? Или есть условно дежурные, которые периодически меняются и команда является не сильно маленькой, чтобы не бросать груз ответственности на пару людей?
благодарю за то, что подсветили интересный момент. Вы абсолютно правы - есть некоторые трудности в случае, если у нас постоянная нагрузка на одних и тех же сотрудников. Эти трудности решаются введением дежурств среди системных администраторов, которые дежурят 24 часа в сутки, разработчиков, которые хорошо погружены и могут помочь починить проблемы с чужим кодом, ошибками и другими трудностями и тестировщиков, которые могут оперативно воспроизвести проблему или проверить предполагаемое решение.
Простите, но выглядит как ИБД, могу понять, если kpi построен на кол-ве «фичей» в месяц.
сам по себе kpi на количество фичей достаточно бессмысленен. 100 фичей в месяц, которыми неудобно пользоваться, не дадут никакого профита для продукта. Лучше ставить kpi на timespent, nps и другие объективные метрики (с разными допущениями конечно). А фичи, большие и маленькие, и в том числе их своевременный запуск или, в случае чего фикс, помогают достигать потребительской лояльности. И не наоборот.
Спасибо, интересная статья.!Подчеркнул для себя некоторые моменты. Единственное, есть уточнение, что ChromeDevTools в режиме эмуляции Nokia Lumia эмулирует только разрешение и dpi экрана, и почти не даст никакой гарантии, что на данном старом девайсе все заработает. Т.к. для фетчинга, лэйаута, рендеринга и пэинтинга будет юзаться ваш новейший chromium движок ;).
Очень рад, что вам понравилось. Основная идея пункта про Nokia Lumia это no js. Что бы проверить этот пункт, разработчику нужно потратить 10 секунд, а нам это экономит кучу времени. В статье представлен чеклист разработчика перед передачей в тест, когда тестировщик берет эту задачу, у него уже другие чеклисты и физические девайсы.
Качество, так вот почему плеер в ВК стал периодически фризиться. Всё дело в подходах к качеству) И меню настроек теперь юзерфрендли, после экспериментов, вероятно. Часть настроек с меню с левой стороны, часть с правой. Это убирает тунельный синдром, приходится шире двигать мышкой.
Как обеспечивать качество при релизах раз в час