Или: Почему диаграмма Ганта не работает.
Разработчики вместе решают, как упорядочить рабочие элементы каждый день.
...Development Team создала план работ— Sprint Backlog — из Product Backlog Items вытянутых из топа Product Backlog в соответствии с велосити команды (смотри Notes on Velocity). Она приступила к Production Episode и хочет разобраться с тем, как начать работу над Product Increment или сохранить вчерашний импульс, наилучшим образом упорядочив план работы.
✥ ✥ ✥
Скрам требует приверженности конкретной цели только в одном случае: когда Development Team прогнозирует достижение Sprint Goal к концу текущего Sprint. А хорошие Scrum Teams в среднем выполняют свои прогнозы по выполнению Sprint Backlog. Команда планирует заранее, создавая прогнозы на следующие два или три Sprints, но только текущий Sprint является единицей выполнения плана. Разумеется, даже этот план может не совпадать с реальностью из-за возникающих требований, но успешная Scrum Team достаточно регулярно выполняет свои прогнозы, чтобы на нее можно было положиться.
Даже Скрам-практикам иногда трудно понять The Spirit of the Game: контроль над Sprint находится в их руках. Легко потерять из виду автономность, которой пользуются Scrum-команды, когда они фокусируются на ожиданиях заинтересованных сторон и на выполнении обязательств команды. В начале Sprint команда берет на себя обязательства по достижению Sprint Goal. Некоторые Скрам-команды считают, что они также должны создать план работы, который следует первоначальному порядку Product Backlog Items (PBI). Если они сделают именно так, то они смогут получить удовлетворение от того, что завершили самые важные Sprint Backlog Items (SBIs), несмотря на то, что не все элементы были завершены к концу Sprint. Но такой образ мышления ведет к самоуспокоению: Development Team может потерять стимул сжигать содержимое Sprint Backlog до нуля. Это приводит к практике "мы берем на себя обязательства, но...", которая лишает прогноз сроков всякого отношения к обязательствам и оставляет Product Owner неуверенным в собственной способности управлять ожиданиями рынка.
Оптимальное упорядочение Sprint Backlog заранее - сложная задача. Если есть пять PBI и каждый из них имеет девять SBI, то существует 45 факториальных возможных упорядочиваний (около 2 x 1056)! В дополнение к этим исходным SBI, возникающие требования заставляют команду добавлять новые по ходу Sprint (или, в некоторых случаях, удалять их). Выполнение работы в одном порядке может ускорить разработку, в другом - замедлить, переупорядочивание происходит каждый день. Суть Скрама в том, чтобы команда нашла самый быстрый порядок. Для этого и существует Daily Scrum.
Product Owner не влияtт на то, как команда достигает своего прогноза. Кен Швабер, перефразируя Нонаку, говорит: "Команда имеет полную власть и автономность во время Sprint". Порядок Product Backlog отражает пожелания Product Owner. Хотя Product Owner, безусловно, имеют полную власть над порядком PBI, они не имеют власти над тем, как Development Team организует свою работу. Если план работ следует порядку PBI, это создает брешь в границах (см. Firewall) между Product Owner и Developers, позволяя Product Owner негласно управлять или нарушать организацию работы Development Teams.
Если план работ разработчиков следует порядку Product Backlog, а в середине Sprint приоритеты рынка меняются, Product Owner может потребовать изменить порядок поставки. Это равносильно тому, что Product Owner вмешивается в работу Developers в середине Sprint. Если это происходит и Development Team не справляется с поставкой к концу Sprint, легко обвинить Product Owner, и трудно поверить, что то же самое не повторится в следующем Sprint. Это лишает Development Team желания вообще заботиться о том, что будет или не будет завершено в Sprint.
Такой принудительный план работ может чрезмерно нагрузить незрелую Development Team, которая не является идеально Cross-Functional Team. Например, если в Development Team мало специалистов по базам данных, а топ PBI требуют работы с ними, и если Development Team практикует непрерывный поток One-Piece Continuous Flow, то это не позволит команде продвинуться в PBI, которые лучше подходят для имеющегося набора навыков. С другой стороны, участники Development Team могут обнаружить новые возможности для обучения и работы за пределами своих основных компетенций, что в долгосрочной перспективе повысит гибкость многопрофильной команды, если она скорректирует план работы в этом направлении
Когда препятствия нарушают ход Sprint, это снижает ценность, которую Developers могут доставить в ходе Sprint. Важно не останавливать разработку, когда возникают препятствия, однако заранее составленные планы работ не могут этого предусмотреть. Более того, людям, не входящим в Development Team, сложно понять, как ориентироваться в многочисленных вариантах решения этих проблем, чтобы сохранить наибольшую ценность.
Development Team прогнозирует Product Owner доставку всего Sprint Backlog. Sprint Backlog часто представляет собой единицу поставки на рынок; то есть на уровне рыночных кампаний Product Owner должен иметь возможность рассматривать все содержимое Sprint Backlog как минимальную фичу, пригодную для вывода на рынок - Product Increment. Product Owner имеет право полагаться на прогнозы Development Team для формирования маркетинговых планов. Development Team теряет мотивацию, если Product Owner требует от нее всегда первым выполнять самые важные пункты работы, в то время как она стремится завершить все. Иногда Development Team не успевает выполнить весь Sprint Backlog, что является естественным следствием возникновения новых требований. Команда может извлечь уроки из неполной поставки, но неразумно навязывать извне даже самые благие намерения по упорядочению работ, если команда жертвует самоорганизацией, которая оптимизирует шансы на получение наилучшей долгосрочной ценности.
Поэтому: Пусть участники Development Team решают как лучше упорядочить задачи, чтобы достичь прогнозируемой Sprint Goal выполнения всего Sprint Backlog. Development Team должна самоорганизоваться, чтобы выполнять работу в том порядке, который, по ее мнению, потребует наименьших затрат или времени, или, наоборот, обеспечит наибольшую общую ценность. Пусть порядок Product Backlog информирует, но не управляет этими решениями. Development Team берет на себя ответственность за создание продуманного и рационального порядка вместо внешнего порядка, произвольного по отношению к возникающим требованиям к разработке.
По мере того как уровень детализации элементов становится все более высоким, ограничения на упорядочивание их внутри группы (всегда первым - по Sprint; вторым - по PBI) становятся все менее строгими.
✥ ✥ ✥
В результате получается упорядоченный план работ, который основан на гибкости и использует коллективные знания Development Team для наилучшей поддержки бизнес-целей - воплощенных в Sprint Goal - для Product Increment. Development Team ежедневно пересматривает план и может часто обновлять его в зависимости от прогресса команды, изменения рынка, Sprint Goal и других фактов, имеющихся в распоряжении Developers. Как участники Development Team могут самоорганизоваться, если кто-то говорит им, как что-то делать? Задача ScrumMaster — стимулировать команду к тому, чтобы выйти на этот уровень самоорганизации.
Как и в случае с погодой, объем работы, который команда предполагает завершить в течение Sprint, - это прогноз или оценка, а не обещание. Прогноз частично основан на недавних исторических показателях (см. Yesterday’s Weather). Кроме того, план динамичен: команда обновляет его каждый день на Daily Scrum.
Если Development Team создает свой собственный порядок плана работ, то она имеет больше возможностей для самоорганизации без излишнего влияния со стороны Product Owner. Development Team может легко упорядочивать задачи, опираясь на ее сильные стороны и знания о том, как лучше организовать свою работу. Это может быть освобождением, особенно для команды, которая страдала от микроменеджмента, и в то же время призывом к приверженности, дисциплине и чувству ответственности за план работ. Развитие этого чувства ответственности и сопричастности требует фокуса, и в этом часто может помочь ScrumMaster, особенно когда команда переходит от микроменеджмента к Autonomous Team.
Конечно, любое упорядочивание Product Backlog, продиктованное прогнозируемыми техническими зависимостями между PBI, также будет отображаться как зависимость между пунктами рабочего плана. Developers могут использовать эту информацию, чтобы правильно упорядочить план работ для удовлетворения технических зависимостей.
Случайное упорядочивание пунктов рабочего плана может привести к большому количеству частично завершенных PBI в конце Sprint. Чтобы исправить это, используйте One-Piece Continuous Flow.
В некоторых традициях Скрама принят подход под названием "Самое важное сначала", который обязывает команду поставлять элементы Product Backlog Item в порядке их появления в бэклоге. Идея заключается в том, что команде не нужно тратить время на согласование порядка, и что следование порядку PBI лучше всего соответствует пожеланиям Product Owner. Мы считаем, что это косвенный способ Product Owner контролировать команду и ослаблять ее способность к самоуправлению. Такие внешние ограничения, скорее всего, снизят скорость работы команды, поскольку они препятствуют оптимизации плана работ.
Команды должны стремиться разрешить зависимости между элементами к середине Sprint: см. Dependencies First. Если Product Owner чувствует, что его неспособность контролировать план работы команды подвергает риску важные элементы PBI, он может снизить риск либо с помощью Sprint Goal, либо путем стратегического изменения длины Sprint.
Рассмотрим ситуацию, когда Product Owner должен отреагировать на непредвиденные изменения на рынке, немедленно предоставив PBI из текущего Sprint. Product Owner может изменить порядок поставок - но только сделав исключение видимым и заставив решить вопрос с помощью Emergency Procedure. Только в самых опытных и зрелых Scrum Team Product Owner может обсуждать порядок выполнения плана работ Development Team, но даже в этом случае только с согласия Development Team.
Джефф Сазерленд написал, “Команда выбирает порядок задач Sprint Backlog, чтобы максимизировать скорость разработки и качество "готовой" функциональности”. Смотри Definition of Done.
Сравните One-Piece Continuous Flow и Informal Labor Plan.
