Процессы в команде

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