Что такое спека в it
Перейти к содержимому

Что такое спека в it

  • автор:

Словарик айтишника или Что? Где? Куда? Часть 1

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

image

Это бессмыслица какая-то или деловой язык? Попробуем разобраться.

Язык айтишников

Каждый, кто работает в IT, непременно сталкивался с профессиональным жаргоном и компьютерным сленгом. Его можно любить или ненавидеть, принимать или терпеть, но непреложным остается факт — IT-жаргон существует и от него никуда не деться.

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

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

Я послушала, как говорят разработчики в Wrike, и составила словарик из самых распространенных слов. Слова собраны по тематическим группам.

Scrum-терминология

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

Бэклог

От англ. backlog (дословно — очередь работ) — еще не запланированный объем работы, который требуется выполнить команде. Каждая созданная задача вначале попадает в бэклог, а потом уже в спринт.

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

Примеры употребления:

  • «Надо разгрести бэклог»
  • «Пусть пока задача полежит в бэклоге, не будем брать её в этот спринт»
  • «Не забудь добавить эту задачу в бэклог своей команды»

Гол, голевой

От англ. goal (дословно — цель) — цель спринта (бывает одна или несколько), которую команда берется сделать. Цель состоит из ряда задач, которые нужно выполнить, чтобы его достигнуть.

Слово употребляется и как существительное, и как прилагательное. Может быть множественного числа.

Примеры употребления:

  • «Эта задача голевая, нужно сделать ее в первую очередь»
  • «Все голы в этот раз не выполнили»
  • «Почему неголевые задачи в работе?»

Дейли

От англ. daily (дословно — ежедневно) — ежедневные короткие (от 5 до 30 минут) встречи команды с целью поделиться прогрессом по выполненным задачам за предыдущий день и озвучить план работ на текущий день. Также дейли могут называть стендапом (от daily standup), потому что обычно такие встречи происходят стоя — для большей эффективности.

Примеры употребления:

  • «Ребята, у нас дейли, встаем»
  • «Я сегодня удаленно, подключите меня на дейли по Zoom»
  • «К сожалению, дейлик пропускаю, нужно идти на важный митинг»

Коммититься

Глагол от англ. существительного commitment (дословно — ответственность). Коммититься — значит обещать выполнить определенный объем работы в оговоренные сроки. Это не просто обещание, это сознательное обязательство перед собой и командой. Человек, который закоммитился, обязан сделать всё возможное, чтобы выполнить то, что сам и пообещал реализовать.

Примеры употребления:

  • «Мы на это не коммитились, поэтому надо вернуться к более приоритетным задачам»
  • «Вы уверены, что мы можем коммититься на такое?»
  • «В этом спринте мы выполнили все цели, на которые коммитились»

Спринт

От англ. sprint (дословно — бег на короткую дистанцию) — заданный отрезок времени, за который нужно выполнить запланированный объем работы, чтобы в конце этого отрезка был ожидаемый результат.

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

Примеры употребления:

  • «Опять завалили спринт»
  • «На этот спринт выпадают праздничные дни, поэтому он будет короче»
  • «Невыполненные задачи из прошлого спринта надо перенести в следующий»

Инструменты для работы

Технические, информационные и вспомогательные средства и приложения для работы.

Ветка

От англ. branch (дословно — ветка) — тот редкий случай, когда в ходу русский перевод термина. Веткой (термин git) называют полную копию проекта, в которой ведется разработка. В проекте может быть создано много веток, что позволяет работать одновременно с разными частями кода. Потом все ветки загружаются в мастер. Процесс «ответвления» иногда называют «бранчеванием», уже как раз от branch.

Примеры употребления:

  • «Изменения можно посмотреть в моей ветке»
  • «Я отбранчевался от твоей ветки»
  • «Можешь глянуть на конфликты в этой ветке?»

Мок

От англ. mock-up (дословно — эскиз) — макет с UX-дизайном для разработки. Несмотря на то, что слово дословно переводится как «эскиз» или «прототип», в Wrike моками называют готовые проработанные макеты с дизайном.

Примеры употребления:

  • «А моки где?»
  • «Моки еще не закончены, но уже можно глянуть внешний вид»
  • «Как было в моке, так я и сделал»

Прод

От англ. production (дословно — промышленная среда) — ветка с рабочей версией продукта, которую видят пользователи. Это окончательная точка куда попадает результат разработки. Иногда так же называют мастер.

Примеры употребления:

  • «Этот баг на проде»
  • «Мы готовы катить эту задачу на прод?»
  • «На проде нет этих изменений»

Реф

От англ. reference (дословно — пример) — схожий функционал или внешний вид, который используется для ориентира. Он служит для сравнения.

Примеры употребления:

  • «Я тут нашла несколько рефов, давайте обсудим»
  • «Для подобного функционала даже рефов нет»
  • «Рефы есть в задаче»

Спека

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

Примеры употребления:

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

Таска

От англ. task (дословно — задача) — задача, заведенная или планируемая на любого работника.

Примеры употребления:

  • «Заведи на это таску, чтобы мы не забыли»
  • «Кинь мне таску с этим багом, я гляну»
  • «А чьи это таски висят в бэклоге?»

Разработка

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

Буст

От англ. boost (дословно — ускорение) — процесс повышения производительности, ускорение загрузки.

Примеры употребления:

  • «Я создала задачу на буст списка»
  • «Мы бустили открытие диалоговых окон»
  • «Мне кажется, что сейчас уже заметный буст есть»

Катить

Отправлять готовую работу в деплой, предпринимать шаги для подготовки ветки к мерджу в продуктовую ветку.

Примеры употребления:

  • «Тут ручное тестирование не требуется, я сам задачу закачу»
  • «Не забудьте, мы завтра катим эту фичу»
  • «Когда катится задача со списками?»

Комплитить

От англ. complete (дословно — заканчивать) — завершать задачу, закрывать задачу, когда она полностью готова.

Примеры употребления:

  • «Я закомплитила родительскую таску, потому что все сабтаски закомпличены»
  • «Можно уже комплитить таску?»
  • «Сторю пока комплитить рано, надо вначале баги пофиксить»

Консистентность

От англ. consistency (дословно — системность) — общее единообразие во всех частях продукта.

Примеры употребления:

  • «В моке кнопка серая, а у нас везде синие, неконсистентно получается»
  • «Сделала миксин и переменные так же, как там, чтобы поддержать консистентность»
  • «Выглядит консистентно»

Матчится

От англ. match (дословно — совпадать) — полное соответствие чего-либо с чем-либо. Процесс приведения к единообразию.

Примеры употребления:

  • «Этот стиль вот совсем не матчится с тем, что сейчас на проде»
  • «Нужно сматчить эти два мока»
  • «Отлично матчится с недавно зарелиженной фичей»

Пинать

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

Примеры употребления:

  • «Надо допинать уже эту таску»
  • «Подопни чутка и можно в тестирование»
  • «Мы уже столько раз допинывали эту фичу»

Ручка

От англ. handler (дословно — обработчик) — бэкэнд-термин, означающий ответ от сервера, в котором приходят данные.

Примеры употребления:

  • «Какое название у ручки, в которой пользователи приходят?»
  • «Тут дергаются сразу три ручки»
  • «При клике на кнопку мы из этой ручки получаем айди объекта»

Скоуп

От англ. scope (дословно — объем) — набор фич и частей продукта, закрепленных за отдельной командой.

Примеры употребления:

  • «В чьем скоупе данная фича?»
  • «Это в скоупе вот этой команды, спроси у них»
  • «Нет, это не из нашего скоупа»

Фича

От англ. feature (дословно — характеристика) — определенная часть или деталь от общего продукта, которая разрабатывается изолированно.

Примеры употребления:

  • «Завтра релизим эту фичу вместе с фиксом багов»
  • «Ваша команда классную фичу разработала»
  • «Для нового функционала обязательный фича-тур»

Флоу

От англ. flow (дословно — течение) — порядок действий при работе над задачей. Например, вначале задача берётся в разработку, потом проходит ревью, далее тестируется и т.д.

Примеры употребления:

  • «В нашем флоу ревью обязательно, нельзя его пропускать»
  • «Та команда работает по другому флоу»
  • «Какое флоу у вебсайта?»

Должности

Некоторые должности, названия которых вошли в обиход в виде сокращений с английского.

Девопс

От англ. DevOps, сокращенно от Developer Operations (дословно — интеграция разработки и эксплуатации) — специалист, занимающийся внедрением DevOps-методологии. Полное название должности — DevOps-инженер, но в речи вторую часть всегда отбрасывают.

Примеры употребления:

  • «Спроси об этом у девопсов»
  • «Кто из девопсов занимался архитектурой?»
  • «Это в в зоне ответственности девопсов»

Пио

От англ. PO, сокращенно от Product Owner (дословно — владелец продукта) — роль по скрам-методологии, человек, ответственный за проработку продукта и распределение бэклога. Он знает о требованиях пользователя и возможностях команды.

Примеры употребления:

  • «Мы не можем зарелизить без пио»
  • «Надо узнать у пио — делать или не делать»
  • «Прежде, чем взять задачу в спринт, узнай у пио, есть ли на это ресурсы»

Пиэм

От англ. PM, сокращенно от Product Manager (дословно — менеджер продукта) — менеджер, который отвечает за продукт, его обязанности совпадают с обязанностями пио, отличие только в том, что это название должности, а не роли в скраме. Так же, как пио, пиэмов могут называть продакт.

Примеры употребления:

  • «Ищем пиэмов в новый юнит»
  • «А кто пиэм у этой команды?»
  • «Пиэм должен знать ответ, спроси у него»

Организационное

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

Дейоф

От англ. day-off (дословно — выходной) — просто выходной.

Примеры употребления:

  • «У меня завтра дейоф»
  • «Он взял дейоф за свой счет»
  • «Почему я не в курсе о ее дейофе?»

Драйвер

От англ. driver (дословно — водитель) — человек, который берет на себя инициативу управления проектом/процессом/задачей. В его обязанности входит следить за тем, как протекает созданный им процесс, и руководить им. Он мотивирует других людей выполнять работу для достижения поставленных целей.

Примеры употребления:

  • «Для этой инициативы нужен драйвер»
  • «Кто будет драйвить этот проект?»
  • «Как драйвер ты должен периодически всех пинать, чтобы работали»

Консёрн

От англ. concern (дословно — тревога, участие) — в английском языке слово «консёрн» имеет много различных значений, при этом очень часто употребляется в русской речи. Какое именно значение вкладывает в него автор, известно только ему самому. Иногда — это смесь многих значений, таких как: особый интерес, беспокойство, цель, настороженность, опасение и т.д.

Примеры употребления:

  • «У меня есть консёрны относительно этой идеи»
  • «Мой консёрн в том, что это может не работать»
  • «А какие у тебя консёрны?»

Окиары

От англ. OKR, сокращенно от Objectives and Key Results (дословно — цели и ключевые результаты) — система по постановке и достижению целей. Она нужна для синхронизации работы всех участников компании/отдела/команды, чтобы все двигались в одном направлении, с понятными приоритетами и постоянным ритмом. В отличие от KPI, это амбициозное целеполагание, достижение окиаров (окров) на 70-80% — отличный результат.

Примеры употребления:

  • «Когда мы узнаем окиары на следующий квартал?»
  • «У команды не может быть окиаров, они есть только у юнитов»
  • «Впечатляющие окиары!»

Оффер

От англ. offer (дословно — предложение) — предложение о работе / приглашение на работу.

Примеры употребления:

  • «Ему выслали оффер, ждем ответа»
  • «Кандидат отклонил наш оффер»
  • «По итогам собеседования мы хотим сделать вам оффер»

Поинт

От англ. point (дословно — точка) — чаще всего употребляется в значении «точка зрения», сокращенно от point of view. Также в значениях: «суть», «смысл», «довод».

Примеры употребления:

  • «Мой поинт в том, что надо заранее планировать работу»
  • «Согласна, в этом есть поинт»
  • «Какие поинты у этого решения?»

Спек

Фотография

Спек (от амер. формы англ. слова specification) — спецификация, утвержденный документ, являющийся основой для разработки компьютерной программы и для ее тестирования.

#2 Vasiliy

Отправлено 03 сентября 2008 — 10:33

Спек (от амер. формы англ. слова specification) — спецификация, утвержденный документ, являющийся основой для разработки компьютерной программы и для ее тестирования.

А может все же вернем слову женский род?

#3 Alex_Gurevich

Alex_Gurevich

Отправлено 11 сентября 2008 — 12:10

Спек (от амер. формы англ. слова specification) — спецификация, утвержденный документ, являющийся основой для разработки компьютерной программы и для ее тестирования.

А может все же вернем слову женский род?

Василий, а как это сделать? По правилам русского языка «спек» может быть только мужского рода. Не так ли?

О чем говорят в IT: словарь сленга

О чем говорят в IT: словарь сленга

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

FAANG — аббревиатура, каждая буква которой обозначает название компаний-техгигантов: Facebook, Apple, Amazon, Netflix и Google. Часто применяется для обозначения компаний высокого уровня.

Его целью было получить работу в FAANG, поэтому он много времени проводил за решением задач на Leetcode, чтобы не провалить собеседования по алгоритмам.

Айпи — IP — уникальный адрес компьютера в интернете.

Я вычислил ботов по айпи: их учетные записи совпадали.

Аппка — программное обеспечение (мобильное приложение или компьютерная программа).

Наша аппка вышла в топ по скачиваниям в AppStore в этом месяце.

Апдейт — обновление программы, прогресс в работе, изменения.

Когда будет апдейт от клиента по приоритетным задачам — организуем созвон и обсудим.

Баг — ошибка в коде или программе, что приводит к их некорректной работе.

Мы исправим этот баг с отображением таблицы в следующем спринте.

Бэклог — список задач, который скрам-команда планирует выполнить за один спринт.

Кажется, наш бэклог стремится к бесконечности, нужно пересмотреть задачи.

Бенч — сотрудник аутсорс-компании, который не задействован в коммерческом проекте, но получает зарплату в полном объеме и сохраняет социальный пакет. В это время сотрудник посещает собеседования на стороне клиента, а компания ищет ему подходящий проект. Реже — сотрудник занимается самообразованием.

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

Бранч — ветвь в системах управления версиями — направление разработки, независимое от других.

Нельзя создавать бранчи в GitHub как попало, это приведет к хаосу.

Вайтишник — «войти в IT» — человек без релевантного опыта, который только пришел в ІТ-сферу.

В связи с популярностью IT — вокруг одни вайтишники.

Ван-ту-ван — встреча менеджера и подчиненного в формате «один на один» для обсуждения результатов и плана работы.

Обычно на ван-ту-ване мы обсуждаем мою жизнь, менеджер правда заботится о моих делах!

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

Прошлой весной мы выкатили большое обновление библиотеки, а потом нашли там много багов.

Галера — аутсорс-компания.

Мне надоело работать на галере, хочу попробовать свои силы в стартапе.

Гребцы — сотрудники аутсорс-компании, задействованные в разработке программного обеспечения.

Мы простые гребцы и не принимаем участия в стратегических совещаниях топ-менеджмента.

Груминг — встреча, где разработчики обсуждают задачи (включая аналитические) и оценивают их сложность.

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

Дебажить — искать и исправлять ошибки в коде.

С помощью встроенных в браузер инструментов ты можешь дебажить код на фронтенде.

Дейлик — короткая ежедневная встреча или созвон команды для синхронизации работы.

Давай обсудим код-ревью завтра на дейлике.

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

Демка прошла очень хорошо: 90% слушателей подписались на пробную версию приложения.

ДНС — DNS, система доменных имен — иерархическая распределенная система преобразования имени хоста (компьютера или другого сетевого устройства) в IP-адрес.

Должен быть хотя бы один резервный сервер ДНС.

Заасайнить — назначить ответственного за задачу.

Поскольку ты разбираешься в Linux, проджект-менеджер заасайнил исправления тестового окружения на тебя.

Инстанс — экземпляр класса в объектно-ориентированном программировании.

Давайте запустим приложение в нескольких инстансах.

Колл — рабочий созвон.

На колле не было девопса, кто-нибудь знает, куда он пропал?

Коммит — сохранение изменений кода в репозитории.

Нам пришлось откатить последний коммит, потому что он положил нам сервер.

Либа — библиотека — готовый код для решения задач разработки.

Для Python существует тысячи либ.

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

Лоад балансер автоматически распределяет входящий трафик приложений по виртуальным устройствам.

Митинг — встреча или созвон для решения рабочих вопросов.

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

Митап — собрание IT-специалистов для обмена опытом и общения в неформальной обстановке. Часто — образовательного характера.

Его выступление о типизации на митапе о JavaScript было самым интересным — и все благодаря примерам из практики.

Мержить — объединять ветки в системе контроля версий.

Ты знаешь, как мержить ветки в Git?

Мокап — макет дизайна интерфейса приложения.

Заказчик передал правки для мокапа, когда сможешь их внести?

Оффер — предложение о работе.

Я пришел к СЕО и сказал, что у меня на руках — оффер от его конкурента, на что он выдал мне контроффер, увеличив сумму зарплаты в два раза.

Пайплайн — процесс разработки по типу конвейера.

Объясните, как реализовать идеальный пайплайн от коммита до продакшена?

Парсить — собирать, систематизировать и анализировать данные с помощью специальных программ, автоматизирующих процесс.

Мы не можем распарсить этот json-файл, потому что в нем есть ошибка.

Песочница — среда для безопасного выполнения программы.

Приложение запустили в песочнице, чтобы протестировать его.

Пиай — PI, Performance Improvement — измерение результатов конкретного бизнес-процесса или процедуры, а затем модификация для повышения результативности.

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

Пингануть — напомнить кому-то о чем-то.

Пингани меня после митинга — и я помогу тебе разобраться с баг-репортом.

Прод — продакшн — рабочая версия продукта.

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

Релиз — выпуск готовой версии продукта.

Релиз новой версии Java запланирован на сентябрь.

Ретро — ретроспектива — мероприятие SCRUM-команды для инспекции своей работы и создания плана улучшений на следующий спринт.

Ретро затянулось на три часа, но оно того стоит, ведь это один самых важных митингов для команды.

Ролбек — откат к ранее развернутой версии.

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

Спринт — период, в течение которого SCRUM-команда выполняет задачи разработки.

Пришло время подвести итоги прошлого спринта и планировать новый.

Спека — спецификация — документация для разработки и тестирования программного обеспечения.

Ознакомьтесь со спекой, и если будут вопросы — задайте проджект-менеджеру, а он передаст их клиенту.

Стендап — регулярная короткая встреча команды, обычно в начале рабочего дня на 15 минут.

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

курс по теме: PHP-разработчик с нуля до PRO
Вячеслав Епанча Senior PHP Developer в Laba с 6-летним опытом разработки

Стейджинг — среда, идентичная продакшн-окружению, но предназначенная для тестирования.

Я перепутал стейджинг с продакшеном — и все изменения попали прямо на прод.

Стори — user story — короткое описание функции программного обеспечения.

Наш бизнес-аналитик хорошо поработал, и у нас уже есть набор стори, чтобы начать разработку.

Таска — рабочая задача.

Сегодня я работаю над таской по созданию новых тегов.

Тест-ноутс — заметки, которые тестировщик делает в ходе тестирования.

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

Фича — особенность, уникальная характеристика или функционал.

Это не баг, а фича.

Хотфикс — быстрое решение проблемы или бага, которое не будет работать в долгосрочной перспективе.

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

Энви (энв) — энвайронмент, окружение — компьютерная система или набор систем, в которых развертывается и выполняется компьютерная программа или программный компонент.

Если перепутать два энви — для тестирования и продакшена — можно все сломать.

Юнит — элемент, подразделение.

В моем юните до сих пор нет бизнес-аналитика.

Что ІТ-специалисты думают о сленге

Олег Миколайченко, Head of Infrastructure в SQUAD

«Использую больше иноязычных слов и сокращений, чем украинских или русских. На примере DevOps: всегда легче и понятнее сказать «деплоймент» или «релиз», чем «развертывание». Часто, если назвать устоявшиеся вещи как-то по-другому, — будет непонятно и странно.

Например, событийно-ориентированная архитектура. Что это? Я такого реально не знаю. На английском языке звучит как event-driven architecture. Ага, ну это же common practice — кучу раз дизайнил, знаю достаточно глубоко.

Если делать выборку DevOps-слов, получится примерно так:

  • деплоймент, релиз
  • билд
  • бранч, коммит, пул
  • ролбек
  • энвы
  • лоад балансер, инстанс, днс

Есть и термины, которые могут не понимать даже инженеры. Если нужно показать серьезность и сложность проекта — можно использовать в речи “новинки” из отрасли, например, GitOps, SLO, KubeFlow. Solution Architects часто используют такие слова.

Очень не нравятся слова, которые в реальной жизни имеют совсем другое значение. Например, стандартный “артефакт” — результат билда, никак не коррелирует с артефактом, к которому мы привыкли в его первичном значении. Нейминг в ІТ довольно странный, и инженеры часто не могут понять значение слова, если не сталкивались с ним в работе. Как только объясняешь, что, например, артефакт — это результат сборки (контейнер, архив, приложение — что угодно), — все становится на места.

Стараюсь не использовать сленг, когда общаюсь с людьми не из IT. Набрасывать кучу непонятных слов на человека — это неэтично».

Лилия Луценко, Product Analyst в BetterMe

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

Я чаще всего использую слова колл, баг, фикс, релиз, груминг, эплаить (применять). Единственное, которое меня раздражает, — фиксик, уменьшительное от фикс.

Новые слова появляются с обновлением версий языков программирования, программного обеспечения и с изменениями в организации процессов разработки».

Рамелла Басенко, QA Lead в AgileEngine

«Я использую сленговые слова митинг, колл, тест-ноутсы, пиай, ретро, ​​демо, ван-ту-ван, пайплайн, дейли, бранч, стендап, юниты, дедлайн, пушить. Из этого набора только тест-ноутсы — специфические слова для тестировщиков.

В повседневной жизни тоже использую сленг регулярно, родные уже привыкли. В начале 2020 года, в первые месяцы работы из дома, старшие из семьи, а также знакомые, работающие не в IT, воспринимали слово «митинг» от меня как будто я иду митинговать на улицу за какую-то идею. Потом это переросло в шутку, и мой крестник до сих пор, когда я говорю «Ну все, побежала, потому что сейчас митинг», спрашивает что-то вроде «Вы там с транспарантами куда-нибудь пойдете? Ты уже свой подготовила?»».

комментарий переведен с украинского языка.

статьи по теме:

Девопсы из SoftServe и ExtendaRetail рассказывают о профессии.

Как жить QA в условиях проблемной документации

Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.

Что может быть не так со спецификацией

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

Спеки — spec, от сокращённого английского specification — так называют технические требования на внутреннем сленге разработчики и тестировщики. Они могут включать варианты пользовательских сценариев, требования к производительности, стандарты качества и проектные ограничения. Обычно спецификацию составляет заказчик и/или исполнитель.

Проект проекту рознь, и в идеальном мире разработки тестировщик на проекте руководствуется полноценной спецификацией. Такого почти никогда не случается. Бывает, что она устаревшая или в ней есть пробелы. А иногда QA попадает на новый проект, который не имеет спецификации вообще. По внутренней статистике, которую мы собрали, с этим сталкиваются 78% специалистов.

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

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

Мы провели внутренний опрос и получили результат, говорящий сам за себя

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

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

Если документации нет, жить очень грустно. Личное наблюдение: скорость разработки и тестирования без неё падает в пять раз.

Коля Абашидзе, QA-инженер red_mad_robot

Как обстоят дела со спеками

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

Почти 40% в общей сложности ответили, что отсутствие или нехватка документации на проекте сильно мешает работе

Чаще всего, по опыту респондентов, в работе не хватало функциональных и нефункциональных требований, описания API/Swagger и макетов.

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

Роботы разных специальностей чаще всего привлекали к этой задаче аналитикаНо участвовали и сами

Поделимся своим опытом и тремя рабочими подходами — что делать и к кому обращаться в таких ситуациях.

Подход первый. Осторожный

Самый простой, при этом самый редкий подход из тех, которые мы используем. Если QA берёт на себя восстановление или создание спецификации, у него есть риск стать точкой входа информации о продукте. Кроме того, может случиться (а скорее всего, так и будет), что работа по написанию функциональных требований окажется недостаточно качественной — и тестировщик столкнётся с критикой в свой адрес. Этого не хочется никому.

При осторожном подходе действуем так:

  1. Тестовую документацию для нужд тестирования создаём исходя из опыта тестировщиков и результатов исследовательского тестирования, когда мы пробуем узнать, для чего предназначена та или иная кнопка, нажав на неё.
  2. На командных встречах настойчиво подсвечиваем недостатки спецификации и необходимость её восстановить или создать.
  3. Находим людей из других практик (frontend- и backend-разработчиков, менеджеров и других специалистов), которые могут взять на себя задачу, — чтобы распределить ответственность.
  4. При таком подходе QA избегает общения с владельцем продукта. QA не всегда умеют получать от людей информацию в формате, пригодном для использования в качестве документации, а продакт оунер может не понять, что именно от него нужно.

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

Оля Никитина, старший QA-инженер red_mad_robot

Подход второй. Обычный для робота

У нас не принято искать крайних, если что-то пошло не так. Если QA взялись писать спецификацию, но итоговое качество оставляет желать лучшего, то негатива они не получат — просто потому, что они QA, а не аналитики.

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

  1. Если есть устаревшие фрагменты спецификации, то проводим их ревью и указываем на необходимость обновить и исправить недочёты.
  2. Параллельно пишем тестовую документацию. Стараемся опираться в ней не только на опыт тестировщиков, но и на фрагменты информации, которые могут помочь обнаружить неучтённые белые пятна в спецификации.
  3. К продакт оунеру здесь тоже стараемся не обращаться, так как не хотим стать точкой входа информации о проекте.

Если документация неполная, это не так страшно — нужно создать алгоритм по дополнению и восстановлению. А все дополнения заносить в виде сносок в Confluence либо в другом инструменте хранения документации.

Коля Абашидзе, QA-инженер red_mad_robot

Подход третий. Робот на максималках

При таком подходе QA принимают максимально активное участие в написании спецификации — фактически пишут её сами.

  1. Эту задачу включают в график работ, выделяя на неё от получаса до двух часов в день. На тест-кейсы «из головы» время при таком подходе не тратится, так как они в итоге сформируются по ходу восстановления документации.
  2. Ключевые методы и функциональность описывает QA-лид. Тем не менее не оставляем попытки заполучить на проект аналитика, напоминая о потребности менеджеру проекта и подсвечивая проблемы на встречах.
  3. При таком подходе мы не избегаем общения с продакт оунером. Просто фиксируем всё услышанное и передаём на оценку менеджеру проекта. Главное, чтобы сам продакт оунер был согласен на общение с QA без аналитика.

После ознакомления с продуктом QA составляет чек-лист его проверки. За основу берёт здравый смысл и набор критичной функциональности — этот список помогает составить продакт-менеджер. Обкатали чек-лист на тестировании, продакт-менеджер сделал ревью — QA начинает писать тест-кейсы с более подробными сценариями. Подключает разработчиков — как консультантов и источник информации. Составляет подробный тест-кейс для проведения регресса.

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

Далее можно приступить к описанию новых фичей по мере их разработки, и тут похожий сценарий: новую фичу добавляем в чек-лист, а если есть время — подробно описываем в тест-кейсах.

Настя Корень, QA-инженер red_mad_robot

А какой подход в работе используете вы? Расскажите в комментариях.

Над материалом работали:
текст — Маша Кузнецова,
редактор — Виталик Балашов,
иллюстрации — Юля Ефимова.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *