Альпинист совершает только одно движение за раз. Так он нащупывает новые выступы и выемки, обеспечивая себе безопасность за счет трех точек контакта со скалой.
...человек или команда (любая) пытается измениться к лучшему, либо в том, что они создают, либо в том, как они это делают.
✥ ✥ ✥
Если одновременно внедрять несколько изменений, то сложно понять, какое из них привело к улучшению.
Размышления любого рода обычно побуждают людей предлагать множество возможных кайдзенов (инкрементальных улучшений; см. Kaizen and Kaikaku). Ведь каждая команда сталкивается со сложностями. Одни связаны с погрешностями в исполнении или понимании, другие — с ограничениями, которые мешают постоянному прогрессу. Желание исправить все проблемы – это естественно; мы все стремимся к совершенству.
Однако, невозможно исправить все сразу. Это слишком энергозатратно. Если пытаться улучшить все и сразу, то заметного прогресса не будет нигде. Кроме того, при попытке решить несколько проблем разом, часто непропорционально много времени уделяется таким вещам, как оценка приоритетов и планирование. Минуту, потраченную на администрирование, лучше посвятить улучшению продукта или процесса. Попытка исправить все и сразу ведет к постоянному переключению внимания между разными проблемами. Большинство людей не слишком хорошо с этим справляется.
Потенциальные улучшения, как правило, взаимозависимы. Велика вероятность, что любое изменение подорвет текущие базовые показатели. Одно улучшение может изменить динамику команды так, что другое улучшение станет избыточным или даже контрпродуктивным. Внедрение нескольких изменений может привести к ненужной работе или работе над разными целями.
Поэтому:
действуйте инкрементально — внедряйте одно улучшение за раз. «Улучшение» может быть изменением самого продукта, линии сборки и инструментов, разработки командой или самого процесса разработки.
Пронумеруйте (1, 2, 3) очередь задач (Product Backlog, Impediment List) вместо того, чтобы делить их на категории («нужно иметь», «следует иметь», «хочу»). В противном случае менеджеры и стейкхолдеры могут решить, что команда будет одновременно работать над несколькими элементами. Пусть артефакты четко указывают на то, что вся команда будет единовременно работать над одним элементом. Руководствуйтесь здравым смыслом. Если список содержит несколько независимых маленьких элементов, не требующих внимания всей команды, то разумнее будет выполнить немного параллельной работы.
Если очередь задач не упорядочена, как это может быть в Sprint Backlog, то команде следует единовременно работать над одним согласованным изменением. В контексте Sprint Backlog все члены команды должны работать надо всеми Sprint Backlog Items, составляющими один общий Product Backlog Item. Соответствующие изменения в продукте, как правило, получают статус Готово (см. Definition of Done), прежде чем команда перейдет к следующему Product Backlog Item (PBI). См. Swarming.
Команда может одновременно вносить по одному изменению в несколько разных и несвязанных друг с другом областей, если будет проявлять осторожность. Например, едва ли может возникнуть путаница, если вносить изменение в процесс и одновременно с этим — в продукт. Но «едва ли может» не то же самое, что «не может», поэтому команде стоит внимательно следить за тем, чтобы не было влияния на показатели, определяющие успешность этих изменений отдельно друг от друга или в совокупности.
Калибруйте изменения по размеру, чтобы их можно было внедрять как можно раньше и чтобы, в идеале, иметь возможность быстро оценить их эффективность (см. Small Items). Если указанная разработка или инициатива принесет ценность только через длительное время, инспектируйте и адаптируйте ее, примите на себя обязательство объективно оценивать результаты усилий в запланированную дату и время. Аннотация к Product Backlog Item — отличное место для фиксации обязательства, взятого на себя командой.
В выражении «улучшение продукта» команда должна интерпретировать слово улучшение в самом его узком его смысле. Если актуальный продукт определенным образом решает задачу пользователя, а поставщик вносит изменения в этот продукт, чтобы добиться большего удобства в достижении того же результата, или улучшает результат — это «улучшение». Добавление новой функциональности автоматически считается «улучшением» продукта, но клиенты могут игнорировать нововведения, которые им не нужны. Это не вредит продажам, но тогда поставщик создает продукт, которым никто не пользуется. В отличие от настоящего улучшения, это добавляет незначительную или нулевую ценность. Согласно корпоративной культуре Тойоты, избыточное производство — основной источник потерь.
✥ ✥ ✥
Если выполнять одну задачу за раз, то количество почти готовых задач уменьшится. Благодаря пошаговому подходу команда и стейкхолдеры получают более точное представление о текущем статусе производства (например, «готово к поставке», «исправлено» или «в эксплуатации»). С его помощью можно управлять ожиданиями в отношении пока не оконченной работы (если у всех задач указан статус «в работе», едва ли команда успеет управиться к крайнему сроку).
Уделяйте внимание одной задаче в одну единицу времени и работайте над ней тщательно — так вы скорее добьетесь успеха, чем если будете хвататься за все сразу. Требуется дисциплина, чтобы намеренно решить не делать то, что, по вашему мнению, принесет пользу, даже если уже предпринято другое усилие по улучшению. В этом могут помочь короткие итерации. Например, Sprint — это короткая итерация, которая позволяет улучшать один процесс за раз.
Более подробную информацию о выборе улучшений см. в статье Testable Improvements.
Короткие итерации также могут защитить от последствий нескольких изменений. Представьте себе альпиниста: чтобы подняться выше, он переставляет только одну руку или ногу за раз, сохраняя при этом контакт со скалой в трех точках. Так он нащупывает новые выступы и выемки, обеспечивая себе безопасность за счет трех точек контакта со скалой. Так и с разработкой: сохраняйте основу рабочего продукта или практик, которые точно работают, пока изучаете следующий этап разработки продукта или улучшение процесса.
Работа над одним единственным элементом в одну единицу времени лежит в основе Скрама. Это основа любого непрерывного улучшения. В этом заключается суть командной работы. Это отличает данный подход от тех, что основаны на микроменеджменте с целью оптимизации расходования «ресурсов».
Необходима группа лиц, которая будет изучать каждое изменение и решать, нуждается ли оно в доработке, или же команда может переходить к следующему. Как правило, в эту группу входят Development Team или Product Owner, но решение может учитывать мнение и других стейкхолдеров, например, менеджмента или клиентов. Руководствуйтесь здравым смыслом, пока за Product Owner остается последнее слово по решениям, касающимся функциональности продукта. Улучшение процессов должно проходить тщательную проверку, которая, как правило, согласовывается на этапе Sprint Retrospective для получения объективных показателей ценности по возможности. Команде следует придерживаться принципа «одно улучшение процесса на Sprint», чтобы не оказаться в ситуации, в которой невозможно будет выявить конкретную причину улучшения в ценности, интервале или качестве. Sprint обеспечивает необходимую периодичность проведения обзоров. Если Development Team решит взять в один Sprint два улучшения процессов, ей следует выполнять их по очереди, тщательно изучая и проверяя результаты каждого их них, прежде чем переходить к следующей задаче. Более подробно этот вопрос рассматривается в статье Kaizen Pulse.
One Step at a Time — это не просто применяемый паттерн, а способ применения паттернов. Кристофер Александр объяснил, что путешествие по языку паттернов происходит со скоростью один паттерн за раз. Выберите один паттерн и примените. Если он сработает, перейдите к другим паттернам, которые могут усовершенствовать систему. Если он не сработает, от него нужно отказаться и внедрить другой паттерн. One Step at a Time можно считать руководством по применению паттернов.
Данный принцип распространяется и на многие другие паттерны и практики Скрама. Паттерн «Whack the Mole» предполагает решение проблем по мере их появления, то есть по одной проблеме за раз. В разработке ПО практика непрерывной интеграции рекомендует пересборку и тестирование ПО для каждого отдельного изменения, а не группы таких изменений. Это не только позволяет уменьшить масштаб изменений, затрагивающих других разработчиков, но и позволяет локализовать возникающие проблемы, которые относятся к одному текущему изменению. Так обеспечивается плавный поток работы. В паттерне «Good Housekeeping» таким «шагом» One Step at a Time является один день. В конце каждого дня должно быть чувство завершенности. Паттерн “Scrumming the Scrum” также предполагает одно изменение процесса за раз.
Этот паттерн хорошо работает, когда команда может вводить каждое изменение независимо или когда команда может сериализовать их введение в действие. Хотя этот подход может работать в комплексных системах, он не может работать хорошо или вообще работать, когда соответствующие изменения имеют комплексные причинно-следственные связи между собой. Существуют важные области, в которых не имеет смысла делать один шаг за раз и лучше работать над несколькими задачами одновременно, как команда, постоянно получая обратную связь на изменения. Скрам традиционно определяет отдельные элементы для работы, как Product Backlog Item, а обязательно параллельно выполняемые элементы, как Sprint Backlog Items. Например, пользовательский интерфейс объектно-ориентированной программы и ее базовая объектная модель соответствуют одинаковой не вполне понятной ментальной модели конечного пользователя. Разработку новой функции в интерактивной, объектно-ориентированной системе следует относить к PBI, а работу над кодом объектов, разработку графического пользовательского интерфейса и логики предметной области следует относить к параллельно выполняемым задачам и из вида PBI приводить их в формат Sprint Backlog Item. Каждый такой элемент дорабатывается в соответствии с требованиями, возникающими в результате работы над другими элементами. Скрам рекомендует разрабатывать одну небольшую фичу за раз (на уровне PBI), но при этом работу над разработкой, внедрением и тестированием (любой отдельной поставки) необходимо выполнять параллельно (на уровне Sprint Backlog Items). Это главное обоснование для Cross-Functional Team и Swarming.
