Scrum – передовой фреймворк (платформа), созданный в 90-е специально для разработки, передачи и поддержки сложных продуктов. Сейчас используется и в других сферах. Суть: весь объем работы делится на короткие этапы в 2–4 недели (спринты), в рамках которых выполняется конкретный перечень задач из бэклога (списка всех задач, упорядоченных по приоритетности). Подробнее о Скраме мы поговорим в главе 3.
Карта компетенций – таблица со списком и уровнем необходимых навыков по каждому сотруднику. Благодаря ей можно оптимально распределять людей по командам, следить за прогрессом каждого из них и давать задачи на прокачку недостающих навыков. Подробнее о картах компетенций говорим в главе 7.11. Пример карты компетенций ищите в Приложении 1.
Хакатон – форум для разработчиков, во время которого специалисты из разных областей разработки программного обеспечения сообща решают какую-либо проблему на время.
CSS-файл – каскадная таблица стилей, которая применяется для оформления веб-страниц. С помощью CSS-файла задается цвет, шрифт, положения отдельных блоков на странице.
Developer Tools – панель инструментов веб-разработчика. Обычно встроены по умолчанию в современные браузеры, чтобы можно было легко просматривать исходный код сайта.
Часть 3
Пятиминутный scrum
Настало время кратко посмотреть на Scrum – фреймворк разработки проектов. «Фреймворк» означает, что в чистом виде, по книге, у вас это вряд ли заработает. Ладно-ладно, заработает, но не с первого раза. Его нужно будет настраивать и сращивать с вашими текущими процессами.
Фреймворк уже зрелый: по нему много литературы, курсов и сертификаций. Поэтому здесь мы поговорим о нем коротко – только в той мере, в которой он нам нужен для повседневной, практической работы. Фреймворк не без косяков, с известной зоной действия и ограничениями. Но пока принципиально лучше ничего не придумали. И Scrum хорошо работает с удаленными командами.
3.1. Схема scrum. Артефакты. Роли. Процедуры
Итак, продукт выпускается поэтапно. Сначала минимальная версия. Затем постепенно наращиваем функциональность.
Каждый цикл разработки называется Спринтом. Рекомендованная продолжительность спринтов – от 1 до 4 недель, подбирается экспериментально. Нужен ритм «рывок-отдых». В итоге каждого спринта должна получиться новая версия продукта с приростом функций – инкрементом.
Product Owner (Владелец Продукта) отвечает башкой за стратегию и приоритеты разработки. К нему поступают «хотелки» пользователей, метрики, жалобы, баги, идеи стейкхолдеров. Коллективная ответственность в расстановке приоритетов не работает. Но рутину вроде сбора обратной связи можно делегировать.
В Scrum-е нет нудного толстого технического задания, которое выполняется от корки до корки. Нет попытки предусмотреть все и сразу. Вместо ТЗ хотелки складываются в специальную табличку – Product Backlog – и сортируются по приоритетам с точки зрения бизнеса. Можно по ходу работы менять, выкидывать и добавлять функции.
Примерно так это выглядит:
Простой бэклог в Google Docs
Минимальный состав бэклога: хотелка и приоритет. Можно добавлять свои поля. Например, описание и предварительная трудоемкость. Чаще всего, в условных единицах – Story Point. Берем за 1 балл самую простую хотелку, все остальные оцениваем относительно нее. Бэклоги удобно хранить в Google-таблицах. Можно дать доступ команде и синхронизировать с таск-трекером типа Jira.
Приоритет – чем больше число, тем выше. При ручной расстановке приоритетов удобно делать между ними зазоры (100, 200, 500). Так проще будет вставлять хотелку между двумя другими. Одинаковых приоритетов, по классике, быть не должно.
Чем ниже спускаемся по бэклогу – тем меньше необходима степень проработки. Пустая трата времени формализовывать то, до чего годами не дойдут руки. И наоборот, хотелки вверху списка должны быть ясные, с высокой степенью готовности к работе.
Все заинтересованные лица могут добавлять что-то в бэклог. Но только Product Owner определяет приоритеты. Для этого нужно периодически просматривать бэклог, выкидывать оттуда мусор, обновлять приоритеты и улучшать формулировки.
Есть специальные методики приоритизации, снижающие субъективное мнение (галлюцинации) Product Owner о важности той или иной хотелки. Подробнее о техниках поговорим в главе 4.
RoadMap – предварительный календарный график выпуска релизов. Этого нет в Scrum, но без него картинка проекта теряется.
Как выглядит Roadmap
Команда разработки. По умолчанию имеются в виду программисты. Команда забирает верхнюю часть бэклога в работу, дербанит каждую хотелку на технические тикеты и оценивает. Мы используем Planning Poker, о нем чуточку позже. Так формируется бэклог спринта (Sprint Backlog) – то, что команда считает реальным сделать за следующий Спринт.
Задачи, попавшие в Sprint Backlog, менять нельзя. В отличие от задач из Product Backlog, в котором можно менять все что угодно до тех пор, пока команда разработки не заберет и не запланирует верхние хотелки.
Обычно Sprint Backlog у нас попадает на канбан-доску в тикет-системе. Это привычный многим инструмент, где есть карточки с задачами и колонки, соответствующие статусам работы. Как минимум это Plan, In Progress, Check, Done. Чертовски напоминает цикл Деминга.
Можно придумывать свои колонки, добавлять критерии готовности, чек-листы, ограничения одновременно выполняемой работы (WIP, work in progress) – тут все гибко.
Канбан-доска спринта в Jira
Команда обычно работает с этой доской: каждый разработчик забирает интересный ему тикет. Выбирает сам, а не назначает начальство. Пишет код, перемещает карточки по доске, трекает время и так далее. Доска может быть как физической, так и электронной.
Команда – такой мини-спецназ
. Компактная: рекомендуется не более семи человек. Кросс-функциональная: есть все компетенции, чтобы сделать проект. Самоорганизующаяся (упс!), самообучаемая и ответственная. Большие проекты дробятся на компоненты и распределяются по своим командам.
Ежедневно, в одно и то же время и в одном и том же месте, команда собирается на Стендап (Daily Scrum), где каждый по очереди отвечает на три вопроса:
1. Что было сделано вчера (для достижения целей спринта)?
2. Что будет сделано сегодня?
3. Какие есть проблемы?
Если вдруг случится амнезия, и вы забудете все из этой книги – хотя бы эти три вопроса оставьте при себе. Помогают вернуть управляемость в самом гиблом деле вроде затянувшейся стройки.
Вопросы задает специально обученный человек, Scrum Master. Он следит за соблюдением процедур Scrum. Например, может отбиваться от Product Owner, возжелавшего поменять состав спринта прямо по ходу работы. Scrum Master также помогает команде оперативно решить возникающие проблемы.
Как проходят стендапы в «Сибирикс»
Важно модерировать такие встречи, не давать уходить в технические дебри и не говниться. Если есть вопросы, требующие детального разбора, их нужно выносить на отдельные встречи.
Тоскливо, когда на вопрос: «Что было сделано вчера», вам отвечают что-то вроде: «Я размышлял об архитектуре», перечисляют номера тикетов или закидывают техническими деталями. Пальцем, дружок, на экране покажи, что там нового напрограммировалось!
На стендапах удобно повесить перед глазами сформулированную кратко цель спринта – помогает сфокусировать команду не на микро-тикетах, а на цели.
И Burndown Chart (диаграмму сгорания), по которой видно, успеваем ли мы, или все пошло «через плохо». Эти и другие метрики полезны, но нос держим по ветру и чутко реагируем на то, что говорит команда. Управлять только через метрики не получится.
В конце спринта команда проводит демонстрацию – показывает Product Owner и всем заинтересованным прирост функциональности. Тут же получает обратную связь. Иногда жесткую – это, кстати, бодрит. И идет на ретроспективу. На ретроспективе все вспоминают, что было хорошего, что плохого, и думают, как улучшить рабочий процесс. По итогам ретроспективы команда может насоздавать себе тикетов на самоулучшение.
Намылить, смыть, повторить.
3.2. Внедряем!
Мы внедряли у себя Scrum в начале 2000-х, когда это еще не было мейнстримом, а про Agile не говорил Греф из телевизора. Наломали, конечно, дров, но быстро все исправили. Первое, что внедрили – итерации и стендапы с тремя каверзными вопросами. Скорость и управляемость сначала выросли, а потом упали. Команды начали либо грустить, либо бунтовать. В воздухе витало «ща долбанет». И долбануло бы!
А что не так? Не было ретроспектив. У команд копились вопросы «а зачем все это» и ощущение, что с них выдаивают результат. Этакая вечная сессия.
Начали проводить ретроспективы, объяснять, как устроен Scrum. Реально собирать обратную связь от команд. Решать их проблемы. Дали почитать литературу. Обучили Scrum-мастеров внутри команд и сказали, что теперь менеджеру можно говорить слово из трех букв («Цыц!»), если он нахальничает. И начало получаться.
Примерный план действий при внедрении:
1. Дать команде почитать про Scrum, какие есть роли и артефакты, и какие плюсы он дает.
2. Нулевая ретроспектива. Собрать команду. Обсудить ее проблемы. Посмотреть, сможет ли Scrum улучшить ситуацию, обсудить, как именно. Рассказать еще раз весь процесс. Ответить на вопросы. Распределить роли.
3. Организовать итеративную работу (спринты) и стендапы. Запретить менять постановки внутри спринтов. Для начала выбрать недельные циклы. Потом – откорректировать.
4. Приучиться расставлять приоритет, создать бэклог и регулярно его пересматривать. За основу можно взять ТЗ (если оно было) или смету, или просто собрать все хотелки проекта из головы в один файлик.
5. Внедрить регулярные ретроспективы и корректировать процесс. Чем более зрелая команда, чем меньше проблем в проекте, тем меньше времени нужно на ретроспективы (если не накопилось фундаментальных косяков, которые непонятно даже с какой стороны решать).
Я бы вообще начал внедрение Scrum-а с ретроспектив. Раз в неделю-две собирал бы команду, обсуждал проблемы и решал их, улучшая рабочий процесс. Глядишь, через месяц весь Scrum нормально заработает.
