Teamlead Roadmap
Подписывайтесь на Telegram-канал Teamlead Good Reads: ежедневные статьи про управление людьми, командами и процессами!

# Конструирование методологии

# Описание

Для организации разработки применяются различные методологии, по сути каждая методология – это набор правил, ритуалов и артефактов, помогающих команде двигаться в заданном направлении. В компаниях редко встречаются методологии в «книжном» варианте. Часто за основу берётся какая-то общеизвестная, а потом подпиливается под себя. Также встречаются варианты, когда даже в одном отделе в зависимости от критичности или специфики работы методологии могут отличаться. Есть методологии, которые оставляют довольно много пространства для улучшения, но для работы с ними требуется уметь их конструировать. Есть те, что жёстко описывают как должно быть и этого пространства не оставляют.

# Почему ветка важна?

Для тимлида:

  • Появляется возможность доработать методологию под свою команду.
  • Во всех методологиях есть «слепые зоны», про которые они ничего не говорят. Хорошо, когда тимлид может продумать их самостоятельно.
  • Умение гибко подбирать и модифицировать методологию при появлении новых ответственностей команды.
  • Тимлид может выбирать методологию исходя из ценностей и картины мира команды.

Для команды:

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

# Что будет, если её не делать?

Можно не уметь собирать методологию с нуля, но тогда необходимо хорошо разбираться в одной или нескольких существующих.

Ниже рассмотрены кейсы, в которых тимлид умеет в лучшем случае в одну из общеизвестных:

  • У лида нет возможности что-то значительно поменять в методологии.
    • Будет получаться, что команда подстраивается под методологию.
  • Нет сформулированной методологии. Люди просто делают работу.
    • Это приводит к хаосу в случае отклонения от обычного сценария. Например, приходит лид соседней команды и просит сделать какую-то задачу. Участники и лид не понимают, как надо в такой ситуации действовать.

# На кого может быть делегирована?

  • Scrum-мастер
  • Project-менеджер
  • Тимлид ниже уровнем

# Примеры поведения

# Примеры плохого поведения

  • Изменение методологии опускается сверху. Например, включается режим «Scrum в каждый дом».
  • Разница между ценностями команды и ценностями, которые постулируются в внедряемой методологии, сильно отличаются.
  • Методологии меняются очень часто. Это плохо из-за того, что каждый переезд длителен по времени.
  • Методология работает по принципу карго-культа. Никто не понимает зачем нужны те или иные «ритуалы».

# Примеры хорошего поведения

  • Тимлид понимает, как работают разные методологии, может комбинировать практики из разных.
  • Методология развивается исходя из потребностей команды.

# Способы прокачки

# Практика

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

# Подготовка

# Расписываем User Story

Пример:

User Story:
Как разработчик я хочу найти свою следующую задачу и приступить к её реализации.

Acceptance Criteria:
Как разработчик я могу посмотреть все мои актуальные задачи
Как разработчик я могу оценить срочность/приоритет задач

Exceptions:
Если задач нет, то разработчик знает, кого спросить

Links:
Сценарии подготовки краткосрочного плана

Это позволяет заранее сформулировать ожидания от методологии, которая должна получиться, заложив особенности работы команды и компании. Далее заменяем роли на реальных людей в команде. Это позволяет лучше увидеть узкие места. Убираем лишние артефакты, коммуникации. Чем более простая методология, которая работает, тем более она идеальная.

# Выбираем инструменты

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

  • Коммуникации: мессенджеры, инструменты для проведения код-ревью
  • Хранение информации и визуализация: доски задач, борды для проектирования, графики сгорания задач, база знаний
  • Разработки: IDE, инструменты работы с VCS, CI/CD, линтеры

Важно выбрать удобные инструменты, иначе ими не будут пользоваться. Удобство инструмента надо проверять самостоятельно.

# Активно обсуждаем

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

# Внедрение

# Уважение коллег
  • Бережём чужое время. Максимально автоматизируем всю рутину. Это позволяет команде экономить силы на важные задачи.
  • Помогаем при переходе. Подсказываем, если что-то непонятно.
  • Описываем конкретные действия. Документация помогает фиксировать методологию и договорённости.
# Внедряем постепенно
  • Не все практики сразу. Это позволяет проводить методологии плавно и по возможности безболезненно для команды.
  • Тропинки протаптываются сами. Не нужен жёсткий workflow. Это позволяет появиться практикам, которые позже превратятся в правила.
  • KISS. Чем проще, тем лучше.

# Поддерживаем

  • Заранее закладываем время своё и команды на поддержку. Процессы не бывают бесплатными.
  • Сразу исправляем ошибки.

# Консультации

# Теория

# Видео

← Получение задач →