Гибкий образ мышления — это совокупность двух факторов: постоянного желания обучаться и нацеленности на результат. Если в команде большинство людей с гибким мышлением, то проблем в применении гибких практик не возникнет.

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

Ценности Agile — это то, что важно людям, работающим в Agile-команде. Четыре такие ценности зафиксированы в «Agile-манифесте», который появился в 2001 году:

Слово «важнее» — это не противопоставление, а, скорее, не совсем точный перевод английского слова «over». Правильнее: вначале — люди и взаимодействия, потом — процессы и инструменты, и т.д. Нельзя просто забыть о документации или первоначальном плане, здесь нужно соблюдать баланс.

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

Это конкретные рекомендации, как строить свою работу. Перед внедрением Agile соотнесите свою команду или организацию с этими принципами — насколько они соответствуют каждому из них по шкале от 0 до 10.

Идеальная гибкая и готовая к изменениям Agile-команда наберет двенадцать десяток (но таких я еще не встречал). «Труп» компании наберет двенадцать нулей (такого я тоже не видел). Обычно компании оказываются посередине шкалы, отличными результатами считаются 7−10 баллов по всем принципам. Можно даже не внедрять Scrum, а всеми возможными способами дотянуть свои результаты до 5−6 баллов по каждому пункту, уже тогда будет классный результат.

Инструменты — это конкретные инструкции, как работать: проводить встречи, планировать, делегировать и т. д. Если инструмент не противоречит Agile-принципам, это Agile-инструмент.

Итак, Agile — это люди с гибким образом мышления, разделяющие ценности Agile-манифеста, строящие работу согласно его принципам и, возможно, использующие инструменты Agile.

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

Поставив далекую цель, которой хотим достичь, мы планируем маленький шажок к ней, работаем (например, две недели), смотрим на результат и спрашиваем себя, заинтересованных лиц и клиента: а это то, что нам надо? Мы этого хотели? Что можно сделать лучше? Может, что-то убрать? Далее — получаем раннюю обратную связь, проверяем гипотезы и на основе полученных результатов планируем следующий отрезок времени. Максимальный отрезок времени в Scrum — месяц, самый популярный — одна-две недели.

Что важно: в конце каждого отрезка времени мы должны получать реальный и ощутимый результат (работающий прототип, новых клиентов и т. п.), который можно оценить и получить обратную связь. Если в конце месяца мы говорим, что сделали 5% от проекта, в этом нет никакого смысла.

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

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

Единственным источником знаний по Scrum является Руководство по Scrum, и я настоятельно рекомендую с ним ознакомиться.

Как это работает? Владелец продукта ставит перед командой цель, команда самостоятельно придумывает, как она этой цели будет достигать. Если достижение цели невозможно, команда должна сразу сообщить об этом, чтобы вместе решить, что с этим делать. Пропадает диктатура руководства в плане сроков, потому что при жестких задачах и ограниченном времени страдает качество (если что-то идет не так). Scrum — это система работы с гарантированным качеством, здесь важен результат.

Чтобы эта система заработала, необходимо научиться вместо задач ставить цели. Например, отделу маркетинга говорить не «провести три рекламные кампании», а «привлечь еще 20 клиентов» или «повысить выручку на n рублей». И команда сама придумывает, как это сделать, или признается, что этого добиться невозможно. Это делает команду Scrum более ответственной и мотивированной.

Контроль при этом никуда не исчезает, только его точка смещается с предварительного в постконтроль. Спринты обычно короткие, и поэтому риск, что команда сделает непоправимую ошибку, минимален. Поэтому присутствие владельца продукта на обзоре результатов спринта обязательно. Именно здесь команда предоставляет результат и хочет услышать мнение: что сделали правильно или нет, что следует переделать, а чего лучше больше никогда не делать. На этом этапе и проявляется контроль.

Как происходит планирование и оценка одной итерации в Scrum?

Среди всех задач выбираем одну-две самых простых и ставим им один балл. Перебираем все остальные и смотрим, во сколько раз они сложнее. Под сложностью понимаются трудоемкость, риски и время.

Оцениваем все задачи по шкале 1, 2, 3, 5, 8, 13, 20, 40, 100 баллов. Это так называемая стандартная шкала оценки для этой техники. Если попадутся задачи меньше базовой, ставим ½ балла, а если больше 100, то знак бесконечности. Так у каждого проекта из общей суммы баллов задач складывается общая сложность. В течение работы команды базовая задача остается прежней, чтобы не происходило инфляции сложности.

Чтобы ответить на вопрос, когда будет сделана вся работа, необходимо знать второе число — скорость работы команды. Если у нас сложность проекта 1000 баллов, а мы знаем, что команда за неделю делает 50 баллов, значит, понадобится 20 недель для завершения проекта.

Плюсы подхода:

Используем это значение при долгосрочном планировании, чтобы рассчитать время работы над проектом, а также при планировании итераций: команда знает, что за неделю выполняет задачи на 32 балла сложности, и берет в работу не более, например, 35 баллов.

Такой подход не перегружает команду, но дает амбициозные цели и держит ее в здоровом ритме работы. Потому что, если взять в работу 70 при среднем 30−35, то сделаете, скорее всего, 15. При перегрузе скорость команды обычно сильно падает.

Этот же подход применяется при работе внутри спринта. Например, на неделю в работу принято задач на 100 баллов. Значит, при каждой ежедневной встрече количество баллов должно уменьшаться на 20. Нарисуйте график сгорания задач и сравнивайте реальный ход работы с идеальным. Если в середине недели окажется, что осталось нерешенных задач на 60 баллов, а должно быть не более 40, значит, команде надо это обсудить и принять решение, как вернуться в график.

В Scrum существует только три роли:

Других ролей в Scrum быть не может. Если речь идет о программном обеспечении, то мы отменяем привычные роли программиста, тестировщика и аналитика, и все становятся разработчиками программного продукта. Это изменение необходимо, чтобы объединять людей вокруг цели.

Роли владельца продукта и Scrum-мастера могут быть объединены с ролью участника команды разработки. Но роли владельца продукта и Scrum-мастера совмещать в одном человеке нельзя.

Scrum-команда — это одноранговое образование. Владелец продукта не начальник разработчикам и Scrum-мастеру. В Scrum нет начальников и подчиненных, нет иерархии. У ролей разная зона ответственности:

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

Руководство фактически делегирует всей команде принятие решений и не вмешивается в процесс работы. Команда, в свою очередь, должна быть готова взять на себя эту ответственность. Лучше договариваться об этом в самом начале, чтобы после не было «серой зоны» и почвы для конфликта.

Бэклог продукта (в виде эксель-таблички или стены со стикерами) — это все пожелания, что мы хотим увидеть в будущем продукте, и их приоритет.

Бэклог спринта — планы на ближайшую итерацию. Это большой лист бумаги, разделенный на три колонки: «План», «В работе», «Готово». Задачи, написанные на стикерах, висят в одной из трех колонок в зависимости от того, на какой стадии они находятся.

На листе А4 на этапе планирования нужно отметить, сколько задач всего (по вертикали) и сколько рабочих дней в спринте (по горизонтали), и соединить две точки прямой линией. Каждый день на встречах считайте, сколько работы осталось, и рисуйте столбики: если ваш столбик выше прямой, то у вас проблемы, если ниже — отличная работа.