Ну и в заключении поговорим о том, какую доску следует использовать – физическую или электронную. На самом деле, ограничение тут единственное: если у вас распределенная команда, то физическую доску использовать невозможно. У каждого варианта есть свои плюсы и минусы. Опыт показывает Физическая доска гораздо лучше для команды, у которой вообще не было навыков работы с досками и таск-трекером, она способствует коллективным обсуждениям и коммуникации в команде, и к ней быстрее возникает эмпатия. А еще физические доски обладают гораздо большей вместимостью, приведенная в качестве примера доска в центральном банке в электронном варианте была бы невозможна. С другой стороны, использование только физической доски без электронной и таск-трекера не позволяет работать с метриками на длинных временных горизонтах. В целом опыт развития Agile говорит об одном: это решение должна принимать сама команда. При этом, хотя использование таск-трекера в IT является стандартом, есть случаи использования физической доски с поддержкой синхронности различными методами: первичным источником при этом может быть как доска, так и таск-трекер. Кстати, в Банке России наряду с физической доской был список задач, и тоже проводилась синхронизация, это входило в обязанности отдельного сотрудника. Таск-трекеров существует громадное количество, и большинство из современных умеют представлять задачи в виде досок. И есть много обзоров этих инструментов, которые, впрочем, как обычно не дают однозначного ответа. Так что выбирать вам самим.

Итерации Scrum – целостная схема, а не прикольная картинка

Я хочу начать со схем итерационного процесса Scrum. Собственно, наличие такой схемы, в которой собраны связанные и дополняющие друг друга элементы, обеспечивающие целостность процесса, и делает Scrum фреймворком, а не просто методом организации работы. Схема показывает, как функционально следует устроить процесс, чтобы он работал, чтобы его элементы взаимодействовали между собой и в комплексе обеспечивали результат. Функционально, а не процедурно – наполнение конкретных функций может быть различно, оно сильнее зависит от условий и содержания конкретного проекта или потока работ, и его надо адаптировать. А вот рассказывают схему часто в сильно упрощенном варианте, делая фокус не на функциях элементов схемы, а на процедурах, которые могут их обеспечить в простом случае. Вред понятен: люди видят, что конкретную процедуру в их проекте применить нельзя, и не понимая функциональной схемы, заменяют упрощенным вариантом и в реализации получаются функциональные дыры, в результате «Scrum не работает». Так вот, не работает не Scrum, а его плохая адаптация. И потому дальше я буду подробно останавливаться на функциях элементов и вариантах адаптации.

Отметим, что создатель Scrum Джеф Сазерленд в своей книге «Scrum – революционный метод управления проектами» пишет о том, что он был скептически настроен по применению Scrum за пределами IT, потому что полагал, что фреймворк сильно нагружен IT-спецификой. Однако, по мере того, как его пробовали использовать и достигали успеха, его скепсис развеялся, и в книге он приводит различные примеры использования. Кстати, я рекомендую эту книгу всем, кто хочет понять дух и культуру Scrum и Agile в целом. При этом Джеф описывает сам фреймворк, логику и историю его создания, и дает множество кейсов применения. А еще книга достаточно очищена от IT-специфики, так что может быть обобщенным руководством. Кстати, говорят, что это – одна из двух книг, прочитав которые Герман Греф проникся новым менеджментом. Вторая «Открывая организации будущего» Фредерика Лалу.