update team, test

docs/team/02-processes.md

@@ -0,0 +1,186 @@
+---
+sidebar_position: 2
+---
+
+# Процессы в команде
+Источник: https://www.youtube.com/watch?v=zCamBnDSbxs
+
+01:52 Методологии работы
+В канбан-методологии нет четкого планирования на следующий день.
+В скрам-методологии спринты имеют определенное планирование.
+Спринты автоматизируют процесс разработки, но требуют постоянного планирования.
+
+02:51 Спринты и их структура
+Спринты состоят из десяти рабочих дней, включая выходные.
+В спринте делается только одна основная фича.
+Обычно идет два спринта параллельно.
+
+04:39 Этапы разработки
+Первый этап: подготовка, где аналитики и дизайнеры работают над ТЗ.
+Второй этап: реализация, где команда работает над задачей.
+Груминг и планирование обсуждают задачи на следующий спринт и текущий спринт соответственно.
+
+06:41 Оценка задач и синхронизация
+Каждая задача оценивается по времени на планировании.
+Важно, чтобы все команды были синхронизированы, чтобы избежать рассинхрона.
+Идеальный менеджмент должен учитывать возможные изменения в командах.
+
+10:04 Введение в синхронизацию команд
+Важность синхронизации команд для успешной работы.
+Проблемы, возникающие при увольнении члена команды.
+Два варианта решения проблемы: уменьшение нагрузки или переработка.
+
+11:57 Роль менеджера в синхронизации
+Менеджер передает задачи от бизнеса команде.
+Важность правильного объяснения задач команде.
+Влияние менеджера на мотивацию и эффективность команды.
+
+12:51 Груминг задач
+Груминг как процесс выбора задач для работы.
+Пример задачи по созданию сторис.
+Декомпозиция задачи на более мелкие и выполнимые части.
+
+15:39 Роль продакт-менеджера
+Продакт-менеджер как связующее звено между бизнесом и командой.
+Важность поддержки бизнеса и команды.
+Влияние продакт-менеджера на процесс принятия решений.
+
+17:28 Планирование и ретроспективы
+Планирование спринтов и ежедневных задач.
+Роль менеджера в успокоении бизнеса.
+Ретроспективы как отчет о проделанной работе.
+
+19:17 Заключение
+Важность планирования и синхронизации для успешной работы.
+Примеры использования инструментов для планирования.
+Обзор различных подходов к отображению задач в проекте.
+
+20:02 Декомпозиция задач и груминг
+Аналитики, дизайнеры и бэкендеры проводят груминг, уточняя задачи и подготавливая их для разработчиков.
+Цель груминга - расхламление бэклога, удаление неактуальных задач и багов.
+Груминг помогает понять, справится ли команда с задачами и уменьшить количество задач в бэклоге.
+
+21:59 Оценка задач в стори пойнтах
+Оценка задач в стори пойнтах помогает понять сложность задачи.
+Стори пойнты абстрактны и не всегда точны, но полезны для понимания команды.
+Задачи оцениваются по шкале от одного до тринадцати пойнтов, где один пойнт - простая задача, а тринадцать - очень сложная и абстрактная.
+
+24:52 Проблемы с грумингом и планированием
+Если задачи на груминге слишком сложные и абстрактные, это указывает на проблемы с декомпозицией.
+На планировании должны быть задачи с оценкой один-пять пойнтов, а большие задачи нужно дробить.
+Планирование помогает менеджеру и команде понять, что делать на спринт, и доказать, что все задачи поняты и спланированы.
+
+28:28 Оценка задач в часах и стори пойнтах
+Команды обычно работают в часах, а не в стори пойнтах.
+Оценка задач в часах и стори пойнтах одновременно сложна и требует дополнительной абстракции.
+Плайн-покер позволяет разработчикам оценивать задачи в часах и стори пойнтах, что помогает экономить время и деньги компании.
+
+29:27 Проблемы с оценкой задач
+Оценка задач может сильно различаться, что требует уточнения.
+Если оценки сильно отличаются, это может указывать на разные уровни понимания задачи.
+В слабых командах лучше выбирать среднюю оценку, чтобы избежать срывов сроков.
+
+31:21 Декомпозиция задач и оценка
+Декомпозиция задач помогает менеджеру убедиться, что все члены команды понимают ТЗ.
+Важно, чтобы вся команда присутствовала на встречах для оценки задач.
+Пример из практики: андроид-команда отставала на полгода, что привело к рассогласованию работы.
+
+32:55 Дейлики и их значение
+Дейлики помогают менеджеру понять, что команда делает и планирует на день.
+Дейлики включают ответы на три вопроса: что сделано вчера, что будет сделано сегодня, и есть ли блоки.
+Дейлики могут быть бесполезными, так как команды работают над разными задачами.
+
+34:26 Проблемы с дейликами
+Дейлики могут быть скучными и бесполезными, так как команды обсуждают разные задачи.
+Важно планировать свою речь на дейликах, чтобы не тратить время впустую.
+Делики помогают менеджеру понять, что команда работает в одном направлении.
+
+35:26 Адаптация к делитам
+В первые месяцы работы важно активно участвовать в делитах и планировать свою речь.
+Делиты могут быть разными в разных командах, и важно адаптироваться к их стилю.
+Важно понимать, что делиты могут быть сухими и по фактам, или затягиваться на час, обсуждая детали.
+
+38:20 Введение в ежедневные встречи
+Важно адаптироваться к стилю общения в команде.
+Ориентируйтесь на всех членов команды, а не только на менеджера.
+Повторяйте структуру и стиль общения команды на ежедневных встречах.
+
+39:19 Ежедневные ритуалы и их значение
+Ежедневные встречи могут длиться от 5 до 40 минут.
+Важно мимикрировать под команду и её поведение.
+Ежедневные встречи помогают менеджеру понимать текущую ситуацию в команде.
+
+40:13 Демонстрация и её значение
+Демонстрация показывает результаты работы всех отделов.
+На демонстрации могут присутствовать представители бизнеса и крупные игроки.
+Цель демонстрации — показать бизнесу, что команда выполнила задачи и попросить больше ресурсов.
+
+41:12 Процесс демонстрации
+Демонстрация включает показ работы всех команд продукта.
+На демонстрации могут быть голосования и раздачи мерча.
+Презентация включает демонстрацию функционала и планы на будущее.
+
+44:03 Ретроспектива и её значение
+Ретроспектива проходит в конце спринта и обсуждает результаты работы.
+Демонстрация и ретроспектива помогают бизнесу понять, что команда выполнила задачи.
+Важно, чтобы на демонстрации показывался реально рабочий функционал.
+
+44:44 Демонстрация работы продукта
+Демонстрация работы продукта часто скрывает ошибки и недоработки.
+Команды могут показывать только часть функционала, чтобы создать иллюзию работы.
+Проблемы с бэкендом, тестированием и аналитикой могут привести к задержкам и ошибкам.
+
+47:25 Ретроспектива и её значение
+Ретроспектива помогает выявить проблемы и избежать их в будущем.
+Встреча может быть как позитивной, так и негативной, в зависимости от команды и менеджера.
+Важно, чтобы вся команда присутствовала и делилась фидбеком.
+
+48:22 Процесс ретроспективы
+Ретроспектива включает обсуждение успехов и неудач спринта.
+Команда делится фидбеком анонимно, часто через карточки.
+Менеджер зачитывает фидбек и создает тикеты для будущих улучшений.
+
+49:39 Ретроспектива и планирование
+Ретроспектива проводится в конце спринта для подведения итогов.
+Груминг может быть в середине недели для планирования.
+Компании могут экономить на аналитиках, что негативно сказывается на подготовке к разработке.
+
+51:50 Релизные циклы
+Релизные циклы включают двухнедельный спринт и отправку на ревью.
+В понедельник проходят созвоны и планирование, в пятницу подводятся итоги.
+Разработка занимает 5-6 дней, остальное время уходит на общение и тестирование.
+
+54:27 Код-ревью и тестирование
+Код-ревью помогает привести код к стандартам компании.
+Тестирование проводится после код-ревью для проверки работоспособности.
+Тестировщики могут отправлять сборки на тестирование в среду или четверг.
+
+57:20 Работа с багами
+Баги фиксируются в личных сообщениях или тикетах.
+Второй вариант с публичными отчетами о багах менее эффективен.
+Быстрое решение багов в личных сообщениях экономит время и деньги компании.
+
+59:14 Решение проблем в личных чатах
+Решение проблем в личных чатах или личных сообщениях нормально.
+Не обязательно создавать тикеты для каждой мелочи.
+Важно, чтобы все работало и соответствовало документации.
+
+01:00:12 Быстрое выполнение задач
+Бизнесу важно быстро выполнить задачу, даже если код не всегда чистый.
+Пример с приготовлением салата: можно быстро сделать вкусный салат из доступных ингредиентов.
+Важно получить результат, а не стремиться к идеальному качеству.
+
+01:01:08 Правило Парето
+80% усилий приносят 80% результата, и наоборот.
+Пример с салатом: можно быстро приготовить вкусный салат, сэкономив время.
+Бизнесу важен результат, а не детали.
+
+01:02:06 Рефакторинг и чистота кода
+Рефакторинг существует, несмотря на чистый код.
+Не стоит беспокоиться о чистоте кода, главное – соответствие требованиям.
+Важно соответствовать запросам бизнеса, а не стремиться к идеалу.
+
+01:03:05 Срезы и сборки
+Срез – это актуальная версия кода для тестировщиков.
+Срез может называться по-разному, но суть остается той же.
+Важно понимать, что это просто актуальная версия приложения.