Проблемы команд при работе по Scrum: как их избежать?
Далеко не у всех разработка по Scrum идёт гладко. Мы подготовили карточки, чтобы напомнить, как можно избежать распространённых проблем при использовании гибких методологий в рабочем процессе 👇

🔥3 дня до круглого стола по безопасности IT-продукта.

Эксперты SimbirSoft вместе с заместителем директора центра разработок АО «ИнфоТеКС» рассмотрят:
– Из чего складывается IТ-безопасность и как её выстроить?
– Какие расходы критически важны, а какие второстепенны?
– Способны ли аудиты безопасности принести реальную пользу?
Время
🔹25 августа в 14:00 (по МСК)
Место встречи
🔹Онлайн. Узнать больше о программе круглого стола и зарегистрироваться можно по ссылке: https://s.simbirsoft.com/7JmP
Стоимость
🔹Бесплатно

На видео наш операционный директор Дмитрий Петерсон рассказывает подробнее, что вас ждёт на мероприятии 🔥 Приятного просмотра 🤗


Информационные партнеры
IB-BANK.RU — сетевое издание по информационной безопасности в банковской сфере.
Cyber Media (securitymedia.org) — портал, освещает новости и тенденции из сферы информационной безопасности и технологий.
RB.RU — независимое издание о технологиях и бизнесе

Один день из жизни релиз-менеджера

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

1. Собираем список задач, которые должны попасть в релиз. Здесь может быть несколько подходов:
🔹 Заводим задачу релиза в таск-трекере, смотрим в нем задачи, у которых есть атрибут «номер релиза: {версия}» и добавляем их списком в общую релизную задачу.
🔹 Заводим задачу в таск-трекере, а оунеры продуктовых команд оставляют комментарии с задачами, которые должны попасть в релиз. Также в комментариях оставляют всю необходимую дополнительную информацию, например: нужно выполнить определенные действия в админке, добавить конфигурации, обновить шаблоны и т.д.
2. Создаем релизную ветку и вливаем все задачи релиза в нее.
3. Собираем релиз-кандидат для проведения регресса.
4. Меняем статус у всех задач, которые попали в релиз-кандидат.
5. Во время регресса следим за блокерами релиза (баги с высокой критичностью, краши). У каждого бага должен быть ответственный, а если его нет, то назначаем, поскольку пока баг не исправлен, релиза не будет.
6. По мере необходимости при исправлении багов регресса собираем новые релиз-кандидаты, обновляем общую задачу, дополнив списком багов, которые заехали в очередном релиз-кандидате, меняем статус у задач.
7. При сборке релиз-кандидатов следим, чтобы заливали только исправления багов, обнаруженные во время регресса. Никакие новые фичи на этом этапе не вливаются, даже если очень хочется. Так как часть функциональности уже проверена, новая фича может повлиять на многое и придется проводить регресс снова, есть риск не уложиться в дедлайн. Тут могут быть исключения — при согласовании и под ответственность команды.
8. Когда последний релиз-кандидат устраивает команду QA и нет багов, которые блокируют релиз, то собирается релизная сборка (такая же, как последний релиз-кандидат).
9. Прописываем релизноты, загружаем сборку в магазин приложений (для мобилок). Для мобилок могут быть тонкости, например, плавная раскатка версии на пользователей.
10. Сообщаем QA, которые имеют доступ «к бою», чтобы они скачали сборку из магазина приложений (мобилки), либо зашли на «боевой» стенд и провели необходимые проверки.
11. Закрываем все задачи, которые заехали в новой версии.
12. Ветку релиза вливаем в мастер, мастер вливает в develop. В мастере добавляем тег с номером версии.
13. В течение нескольких дней после релиза следим за крашами. Дальше по согласованию с тимлидом решаем, нужен ли хот-фикс.

Подробнее о технической части и документации процесса управления релизами читайте здесь 😎

🔥 Обсуждаем безопасность ИТ-продукта с точки зрения кода и инфраструктуры в прямом эфире. Подключайтесь!
Реальные примеры с проектов, конкретные рекомендации, которые «написаны кровью», активные участники 😏

Смотрите трансляцию:
— на канале SimbirSoft на YouTube: https://youtu.be/j5agHZq9iEI

Подключайтесь к обсуждению по ссылке: https://bbb-ext.simbirsoft.com/b/mze-hlo-off-heb

Инсайты обсуждения ☝️

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

Что изменилось, когда к команде подключился Scrum-мастер?
🔹 Повысили точность оценки задач. Когда появилось достаточно сделанных задач, Scrum-мастер провёл пару встреч-упражнений по калибровке их оценки.
🔹 Встречи стали эффективнее. Scrum-мастер продумывает сценарии для встреч с бизнесом, ретро, спринтов и кварталов. Команда придерживается этого плана – это позволяет сосредоточиться на целях собрания и продуктивно участвовать в нём.
🔹 Оптимизировали время работы специалистов. Часть организационных работ взял на себя Scrum-мастер: заведение задач и заявок на доступы к ресурсам компании, планирование и создание встреч-созвонов. Также специалисты больше не устраняют «препятствия», например, в виде задач-блокеров – коммуникацию с ответственными лицами ведёт Scrum-мастер, а команда занимается проектом.

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

«Дело было осенью. Шел четвёртый месяц работы над MVP.

Все команды, забыв о квартальном планировании, трудились над срочным запуском продукта. Я подключился к проекту на этапе вывода MVP. К слову, тот запуск был образцово-показательным. Но не обошлось без потерь: по разным причинам ушли QA-специалист и скрам-мастер. Однако на проекте остались крутые и вовлеченные люди, которые приобрели и сохранили весь пережитый опыт.

Что мы имели на входе?..»

Отрывок нового IT-романа, дневник разработчика? Неееет, это статья нашего QA о том, как метрики помогают выстроить работу команды и решить проблемы на проекте – от ограниченного ресурса до ошибок на проде.

В Телеграфе вы найдёте:
🔹 пошаговый путь к метрикам на примере одного проекта;
🔹 мемы;
🔹 реальные графики-результаты проделанной работы;
🔹 (ещё мемы).
Полгода труда точно стоили того – прочитайте и убедитесь сами 😏

Смена подрядчика: как не наступить на старые грабли
К подрядчику, который перенимает продукт, требования намного выше, чем к команде-«первопроходцу». Создать и развивать продукт самому легче, чем переделывать за кем-то. Нужно проанализировать:
🔹чужой код;
🔹что можно переиспользовать (беря во внимание риски);
🔹как довести продукт до ума.
Это трудоёмкий процесс, поэтому сначала предлагаем присмотреться к своей старой команде. Если же присматриваться больше не к кому, следующий пункт в посте можно пропустить.

А может и не стоит менять подрядчика?
Перед принятием решения внимательно изучите:
🔹документы по планированию, оценке затрат, учету рисков;
🔹процессы разработки, коммуникацию в команде;
🔹этапы разработки и наличие специалистов на проекте.
Пример.
Проблема: постоянно нарушаются дедлайны.
Возможные причины:
1. Проект оценивала другая команда, а в новой некоторые специалисты работают над двумя вашими продуктами.
2. В процессе появились новые стейкхолдеры, и они детализировали фичи.
3. На проекте нет аналитика, соответственно, корректной постановки задач. Разработчикам приходится несколько раз переделывать фичи, прежде чем конечный пользователь скажет: «Да, это я и имел в виду».
Возможные решения: переоценка с учетом актуальной специфики проекта, корректировка процессов разработки и управления.

Всё-таки стоит: на что обратить внимание
Вы выбрали несколько компаний по рекомендациям/отзывам, соответствию технического стека и опыту в вашей сфере. Далее присмотритесь к процессам, которые он предлагает вам при перенятии проекта. Схема должна выглядеть следующим образом:
1️⃣ Изучение системы
2️⃣ Аудит
3️⃣ План выполнения задач
4️⃣ Разработка + Аналитика + Тестирование
5️⃣ Релиз
Если подрядчик сразу говорит, что в условный день он готов приступить к работе, вероятность плохого результата возрастает многократно.
Это похоже на смену лечащей компании: вы приходите с болями в области печени в новую клинику. Странно, если вам тут же предложат лечить этот орган. Сначала специалист начнёт сбор анамнеза, изучит ваши жалобы.

Что должен спросить хороший подрядчик до начала работ: изучение системы
Что было
🔹 Причины смены подрядчика
🔹 Боли: что конкретно не устраивает
🔹 Бизнес-потребности: для чего/ кого продукт делается
Что есть
🔹 Отношения со старой командой: можно ли с ними взаимодействовать
🔹 Исходники: где находятся, версионность и т.п.
🔹 Документация и ТЗ
🔹 Отчеты предыдущих исследований
Что будет
🔹 Ожидания клиента от продукта: цели сейчас и на несколько лет вперёд
🔹 Время, которое клиент будет уделять проекту
Эти вопросы определяют надёжную компанию, которая отвечает за результат. Они помогают соотнести реализацию продукта с вашими ожиданиями и требованиями.

Первый этап договорных отношений: аудит
Что входит:
🔹 аудит кода (обязательно);
🔹 аудит функционала (обязательно);
🔹 аудит архитектуры, БД, инфраструктуры;
🔹 UX-аудит
🔹 аудит процессов.
Результаты:
🔹 документ о состоянии продукта;
🔹 рекомендации к исправлению.
❗️Важно! В рекомендации должен входить перечень шагов с их приоритизацией. Правильный подрядчик предлагает несколько вариантов решения проблем. Вы сможете выбрать наиболее подходящий вам, опираясь на бюджет, требования и сроки.
Кроме того, результаты могут быть неожиданными: иногда проще сделать всё с нуля, чем переделать то, что есть. Возможно, после аудита вы поймете, что можно скорректировать что-то в старой команде и не менять её.

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

3 минуты = рекомендации + объяснения + примеры. Ну и ещё 6 секунд на заставку)

Заботливый мини-спойлер для тех, кому не нужны объяснения и примеры: сообщите, на каком этапе возникла проблема и в чём она состояла, а также предложите вариант решения.

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

С чего все началось
Проект был давно запущен: фронт работы известен и распланирован на крупные и мелкие спринты. Обычно команда работала в спокойном режиме, состав постоянно менялся – к его реализации по возможности подключались временно освободившиеся с коммерческих проектов сотрудники.
К одной из значимых для компании дат был поставлен жесткий дедлайн – необходимо было реализовать важный функционал, на котором были завязаны задачи разных подразделений.
В один из дней в чат пришло сообщение: «Ребят, у нас проблемы, мы не успеем выкатить релиз вовремя».

Что удалось выяснить
Вводные данные:
Релиз предполагал двухнедельный спринт. Команда состояла из ПМа, который подключался лишь изредка, трех разработчиков и одного QA. Планируемая оценка – 150 часов с учетом отвлечения специалистов на другие проекты.
Исследование показало:
К середине первой недели спринта — при передаче проекта от одного ПМа к другому — забыли объяснить часть логики реализации фичи. Road map давно не актуализировался, описание задач было недостаточным. Когда вспомнили про фичу к середине второй недели спринта, это добавило еще 60 часов разработки и ретеста.
В конце первой недели спринта от проекта отвлекли самого осведомленного разработчика и подключили нового. Погружение для него не провели. В конце второй недели главный разработчик вернулся на проект и переписал код новичка. Результат – еще 40 часов разработки.
При смене QA-специалиста также выяснилось, что документацию на том внутреннем проекте не вели. В итоге новый QA затратил еще 25 часов, чтобы разобраться в логике.
Проект потребовал 275 часов реализации: вышел из запланированных двух недель, бюджет превышен в два раза.

Выводы
Чтобы избежать подобных ситуаций на проекте, необходимо:
🔹 разработать и согласовать регламент передачи проекта;
🔹 закрепить ответственных специалистов за внутренними проектами, чтобы не «терять» осведомленность при передаче от одного к другому;
🔹 внедрить шаблон постановки задач, который никогда не помешает, а только упростит работу;
🔹 закрепить обязательный минимум по документированию, в том числе документ по погружению новых специалистов.

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