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