187 lines
15 KiB
Markdown
187 lines
15 KiB
Markdown
---
|
||
sidebar_position: 2
|
||
---
|
||
|
||
# Процессы в команде
|
||
|
||
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 Срезы и сборки
|
||
Срез – это актуальная версия кода для тестировщиков.
|
||
Срез может называться по-разному, но суть остается той же.
|
||
Важно понимать, что это просто актуальная версия приложения.
|
||
|
||
🚀 **Источник: https://www.youtube.com/watch?v=zCamBnDSbxs** |