Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Шрифт:
Чем ниже спускаемся по бэклогу – тем меньше необходима степень проработки. Пустая трата времени формализовывать то, до чего годами не дойдут руки. И наоборот, хотелки вверху списка должны быть ясные, с высокой степенью готовности к работе.
Все заинтересованные лица могут добавлять что-то в бэклог. Но только Product Owner определяет приоритеты. Для этого нужно периодически просматривать бэклог, выкидывать оттуда мусор, обновлять приоритеты и улучшать формулировки.
Есть специальные методики приоритизации, снижающие субъективное мнение (галлюцинации) Product Owner о важности той или иной хотелки. Подробнее о техниках
RoadMap – предварительный календарный график выпуска релизов. Этого нет в Scrum, но без него картинка проекта теряется.
Как выглядит Roadmap
Задачи, попавшие в Sprint Backlog, менять нельзя. В отличие от задач из Product Backlog, в котором можно менять все что угодно до тех пор, пока команда разработки не заберет и не запланирует верхние хотелки.
Обычно Sprint Backlog у нас попадает на канбан-доску в тикет-системе. Это привычный многим инструмент, где есть карточки с задачами и колонки, соответствующие статусам работы. Как минимум это Plan, In Progress, Check, Done. Чертовски напоминает цикл Деминга.
Можно придумывать свои колонки, добавлять критерии готовности, чек-листы, ограничения одновременно выполняемой работы (WIP, work in progress) – тут все гибко.
Канбан-доска спринта в Jira
Команда обычно работает с этой доской: каждый разработчик забирает интересный ему тикет. Выбирает сам, а не назначает начальство. Пишет код, перемещает карточки по доске, трекает время и так далее. Доска может быть как физической, так и электронной.
Команда – такой мини-спецназ
Ежедневно, в одно и то же время и в одном и том же месте, команда собирается на Стендап (Daily Scrum), где каждый по очереди отвечает на три вопроса:
1. Что было сделано вчера (для достижения целей спринта)?
2. Что будет сделано сегодня?
3. Какие есть проблемы?
Если вдруг случится амнезия, и вы забудете все из этой
Как проходят стендапы в «Сибирикс»
Важно модерировать такие встречи, не давать уходить в технические дебри и не говниться. Если есть вопросы, требующие детального разбора, их нужно выносить на отдельные встречи.
Тоскливо, когда на вопрос: «Что было сделано вчера», вам отвечают что-то вроде: «Я размышлял об архитектуре», перечисляют номера тикетов или закидывают техническими деталями. Пальцем, дружок, на экране покажи, что там нового напрограммировалось!
На стендапах удобно повесить перед глазами сформулированную кратко цель спринта – помогает сфокусировать команду не на микро-тикетах, а на цели.
В конце спринта команда проводит демонстрацию – показывает Product Owner и всем заинтересованным прирост функциональности. Тут же получает обратную связь. Иногда жесткую – это, кстати, бодрит. И идет на ретроспективу. На ретроспективе все вспоминают, что было хорошего, что плохого, и думают, как улучшить рабочий процесс. По итогам ретроспективы команда может насоздавать себе тикетов на самоулучшение.
Намылить, смыть, повторить.
3.2. Внедряем!
Мы внедряли у себя Scrum в начале 2000-х, когда это еще не было мейнстримом, а про Agile не говорил Греф из телевизора. Наломали, конечно, дров, но быстро все исправили. Первое, что внедрили – итерации и стендапы с тремя каверзными вопросами. Скорость и управляемость сначала выросли, а потом упали. Команды начали либо грустить, либо бунтовать. В воздухе витало «ща долбанет». И долбануло бы!
А что не так? Не было ретроспектив. У команд копились вопросы «а зачем все это» и ощущение, что с них выдаивают результат. Этакая вечная сессия.