Всем привет! Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей. 

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

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

Вместе с PHP-разработчиками Александром Макаровым (@SamDark), Валентином Удальцовым (@vudaltsov) и наставником Хекслета по PHP Владленом Гилязетдиновым (@funkylen) разбираемся, какие новые фичи появились в PHP 8.2, насколько эти изменения глобальны и какую роль в них сыграл проект РHP Foundation.

Эта статья — саммари стрима YouTube-канала PHP Point. Кстати, ежегодный опрос русскоязычного PHP-сообщества с итогами года запущен! Результатами поделимся в конце января.

Всем привет! Меня зовут Иван и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее – QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»

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

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

Однажды приходит осознание, что нужно расти. Но куда?

Привет! Меня зовут Лёша Дидух, я тимлид команды личного кабинета в Skyeng. Это текстовая адаптация моего доклада про ретроспективы на DUMP-2022 в Екатеринбурге. 

Когда я пришёл в компанию пару лет назад, то немножко обалдел от разницы в подходах к управлению проектами и командами между моей прежней работой и Skyeng. Такой скачок между диаметрально противоположными культурами заставил меня переосмыслить и собрать воедино всё, что я знаю о ретроспективах. Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?».

В конце статьи можно найти запись доклада по теме.

Начнем издалека (но не просто так)

В 2000 году влиятельные ребята из мира IT, среди которых были Роберт Мартин (автор принципов SOLID и огромного числа книг про программирование) и Джеф Сазерленд (один из авторов Scrum), встретились, чтобы, как говорит сам дядя Боб, лучше узнать друг друга в надежде, что тесное общение приведет к чему-то интересному. 

Это лишь часть таблицы инструментов, которые мы рассматривали. Подробнее по ссылке.

Мы используем New Relic в каждом из наших 250 PHP-сервисов. С его помощью отслеживаем взаимосвязи между сервисами, их зависимости, смотрим нагруженные транзакции, анализируем полный трейс запроса пользователя. Наши основные функциональные требования: связи, оценка по времени отклика и параметру APDEX (собирательное значение удовлетворенности пользователя).

Отказаться от New Relic хотели давно. Главная причина — он стал дорогой. Весной добавилась вторая причина — мы из России. Запереживали, что нас могут отключить. А мы в команде инфраструктуры стараемся все сервисы держать на своей стороне.

В августе закончился договор с New Relic, так что заранее стали искать ему замену. И вот, как оно было.

Привет! На связи Влад из команды видеоплатформы Skyeng. Мы отвечаем за аудио и видео коммуникацию в образовательных продуктах, применяем WebRTC и реализуем фичи вокруг Video Conferencing. О реализации одной из них хочу рассказать: мы сделали видеоэффекты для веба.

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

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

Все сошлось. Решили делать.

• Балансом между костылями и оверинжинирингом.
• Балансом между тестированием кода и быстрой выкаткой на прод.
• Балансом между техническим долгом и TTM.
• Балансом между «пиши код» и «развивай своего джуна» и так далее.

В чаты по PHP часто приходят с вопросами про развитие: какие книги стоит прочитать в первую очередь, на какие каналы подписаться, какие курсы хороши. Если повезет, в ответ чат поделится парой рекомендаций. Мы решили агрегировать их в список и собрали 150+ мнений по актуальным ресурсам для PHP-разработчика. 

Без длинных интро. Самые упоминаемые ресурсы идут первыми в разделах, а те, которые советовали новичкам, отмечены флажком 🚩. 

О жизни с внешними сервисами

• Операторам и менеджерам приходилось вручную создавать задачи. Такая рутина забирала много времени. Ошибиться проще простого.

Наша команда отвечает в Skyeng за личный кабинет и CJM пользователя до оплаты. Изначально проект был написан на Symfony 4.4 и представлял собой набор слабо связанных компонентов, которые были ответственны за правила работы для фронтенда.

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

У нас были лишь юнит-тесты: каждый покрывал логику одного класса. Все тесты вместе давали покрытие основной логики кода и гарантию, что все работает правильно. Но 100% покрытие кода тесты не обеспечивали. И сейчас не обеспечивают.

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

И мы обратились к функциональным.

• Продукт, где находятся все базовые запросы сотрудников. По нажатию пары кнопок можно получить все нужные справки, доступы, отметить отпуск, отгул или вообще оформить увольнение. То есть не надо ни с кем разговаривать. Каждое действие запускает набор скриптов, который создаёт все нужные задачи в Джире или автоматически оформляет все нужные документы.
• Сами наборы скриптов. У любой заявки есть процесс, который мы продумали и автоматизировали, то есть не надо ничего придумывать. Например, при смене роли пользователя (переходе на другую должность) собираются и добавляются-отзываются все доступы и ставятся все нужные задачи.
• SLA на каждое действие. Как только есть описанный процесс — можно назначать ответственных и сроки. Теперь, если вам нужна какая-то бумажка от кадров, не вы заходите и спрашиваете, готово ли, а уже кадры должны уложиться в свои SLA, и у каждого шага есть ответственный.
• Бота, который в первые дни работы «ведёт» сотрудника.
• Автоматизацию микромоментов. Например, за день до ухода в отпуск в слаке проставляется соответствующий статус плюс у сотрудника становится видно в профиле, кто за него работает и по каким вопросам.

Вы когда-нибудь встречали такие операторы, как materialize и dematerialize в RxJS? А что насчет класса Notification? Вероятно, многие слышали, но не до конца представляли, где их можно применить на практике.

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

Materialize

Для начала вспомним, какие типы значений может эмитить объект типа Observable: это next, error и complete. Если вы не помните, что это значит, здесь можно почитать.
Соответственно и про observer, набор коллбэков (onNext, onError, onComplete), тоже советую вспомнить.

Вот что говорится в документации о materialize операторе: «A function that returns an Observable that emits Notification objects that wrap the original emissions from the source Observable with metadata».

1. Собрал по данным методологических исследований карту навыков английского языка, разбитую на сотни отдельных веток, связанных друг с другом, как в хорошей RPG.
2. Отскринил несколько реальных учеников по этой карте и придумал, как с её помощью вычислить образовательный прогресс.
3. Наложил карту навыков на контент, чтобы каждое упражнение автоматически учитывалось в оценке прогресса (о, это было долго и сложно).
4. Провалидировал на тысячах внутренних тестов, не зависящих от системы оценки прогресса.
5. Заложил адаптацию для учеников разных языковых групп, поскольку родной язык ученика даёт ему какие-то навыки сразу, а какие-то делает очень сложными.
6. Семь раз усложнил, а после существенно упростил систему.