Почти каждый, кто начинает внедрять Scrum, очень быстро задает вопрос “А какие инструменты помогают построить хороший Scrum?”.

Мне задавали этот вопрос на тренингах и на недавнем вебинаре. И почти половина спонсоров недавней конференции AgileEE были компании, которые выпускают разные “инструменты”.

Однозначно инструменты нужны. Вопрос в том, – какие, и какие именно помогут сделать хороший Scrum.

Прежде всего, хочу напомнить, что мы говорим о Scrum и, соответственно об Agile подходах, которые основаны на Agile манифесте. Первым же положением манифеста было заявлено:

Мы ценим людей и сотрудничество выше, чем любые инструменты и процессы.

Поэтому, на мой взгляд, стоит всегда помнить, что инструменты должны лишь помогать наладить взаимодействие. К сожалению, я достаточно часто вижу, как люди излишне “увлекаются” и начинают строить свой процесс вокруг “инструмента”, и тем самым сводят свою работу к тому процессу, который себе придумали разработчики самого инструмента ;-).

Если все-таки говорить о позитиве, то инструменты нам нужны еще, чтобы визуализировать состояние дел на проекте. Поэтому самыми главными и полезными инструментами, являются “доски задач“. Доски, как подход к визуализации существовали во многих отраслях и задолго до эры Agile.

В случае Scrum команды доска делится на три колонки: “Запланировано”, “В работе” и “Завершено”. Используются бумажные карточки (post-it или просто плотная бумага), на которых пишутся все истории и задачи. На момент планирования итерации все карточки помещаются в колонку “Запланировано” согласно приоритетам (сверху вниз). Каждый день, когда кто-то говорит “я начал работать над…” карточка с задачей перемещается в колонку “В работе“. На следующем Daily Scrum, каждый, кто говорит “я закончил работу над…” перемещает соответствующую карточку в колонку “Завершено“.

Скептики, которые считают, что такое простое решение не может быть эффективным, могут попробовать сами. Это самый мощный инструмент, который может помочь построить хороший Scrum процесс. Выгоды не заставят себя ждать:

• Все очень наглядно – доска висит на стене в комнате команды или в том месте, где ежедневно проходит Daily Scrum
• Сразу виден прогресс – окинув взглядом доску, можно сразу понять, сколько примерно еще осталось работы
• Сразу видны провтыки препятствия – например, когда задачи берутся снизу и приоритеты игнорируются, или, например, когда задача висит в колонке “В процессе” больше, чем отведено ей времени, и много других “индикаторов”, которые помогут команде своевременно среагировать.

Идея визуализации на доске предельно проста, и ее можно много где использовать, чтобы качественно улучшить наглядность на всем проекте. Как пример, Владелец Продукта может вести себе отдельную доску, на которой планируются релизы, или просто истории пользователей сгруппированы по модулям, ролям и т.п. На ту же доску задач команды можно крепить графики и другие визуальные элементы. На карточках можно делать пометки о приоритетах, модулях, ответственных за выполнение, оценках и т.д. Если нужно, вы можете не останавливаться на трех колонках, а добавить еще колонки в зависимости от этапов, которые проходят истории и задачи в вашей команде. Я часто видел, что команды добавляют колонку “сделано разработчиками”, и тогда “завершено” означает “протестировано”, или же для этого есть еще одна колонка, а окончательно завершает приемку Владелец Продукта.

Все это работает почти идеально для команды, которая сидит вместе. В то же время, большинство команд, с которыми я работал, в той или иной мере распределены. Это совсем не означает, что для них доски работать не будут. Применяя десятый Agile принцип  о Простоте и здравый смысл, мы можем найти решение.

Очевидно, что бэклог продукта для распределенной команды удобно хранить в документе с общим доступом. Это может быть MS Excel Spreadsheet или Google Docs Spreadsheet – технически решение найти несложно.

В случае, когда удаленно сидит только Владелец Продукта (заказчик), то вполне можно договориться о том, чтобы раз в день фотографировать доску команды и отсылать ему фото или выкладывать на общий wiki.

Если же у вас распределена команда разработчиков, то тут конечно вы начнете искать “инструмент”. Еще раз напоминаю об осторожности при выборе. Мне запомнилось высказывание Хидеши Екой (Hideshi Yokoi), который возглавляет северо-американский центр поддержки внедрения “Производственных процессов Тойота” (TPS): “Когда вы кладете проблему в компьютер, то коробка скрывает проблему. Проблемы должны быть видимы!“.

Лично я и команды, с которыми я работаю, остановились на GreenHopper for JIRA. Это объясняется тем, что JIRA сама по себе “универсальный солдат” и позволяет настроить систему под любой процесс, который у вас уже, надеюсь, выработался. GreenHopper в свою очередь реализует визуальные инструменты, как то: Доска Планирования (релизы, итерации – все очень наглядно), Доска Задач (те самые колонки, как и на физической доске), Графики (несколько типов BurnDown построенных на разных типах данных) и даже Архив Графиков и Списков сделанного за прошлые итерации (что позволяет визуализировать среднюю Скорость и другие данные на всем релизе или всем проекте).

Очевидно, что распределенные команды должны общаться очень часто, поэтому единое место для хранения данных по итерации и проекту, просто необходимо.  GreenHopper в виде Доски Задач с помощью проектора (или просто очень большого монитора) помогает визуализировать бэклог спринта, и получается полное ощущение работы с доской.

Для тех же, кто ищет волшебный Грааль, в виде инструмента, который максимально подходит для вашего проекта, Майк Кон собрал целый зоопарк инструментов для управления Бэклогом и Историями пользователя. Большинство инструментов в той или иной мере реализуют весь цикл управления проектом.

Кто ищет, тот найдет. И, пожалуйста, Keep It Simple!