И «Готово» - это лишь часть пути

Почему «Готово» важно для Scrum-команд

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

Сложные адаптивные проблемы непросты и неуловимы. Понимание потребностей клиентов может быть сложной задачей. Дизайн - это сложно, а кодирование - сложно. Тестирование изнурительно, а освобождение болезненно. Это все сложно. Мы получим это.

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

Другими словами, создавая продукты, нам нужно, чтобы работа была сделана и доставлена ​​в руки наших клиентов как можно раньше. Однако «готово» - это только начало пути. «Готово» помогает нам учиться на отзывах клиентов.

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

Адаптивный - это то, что будет дальше. Наши проблемы адаптивны, но насколько мы адаптивны?

Мы все?

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

Чтобы снизить риск отклонения от графика из-за всей этой сложности, Scrum-команды планируют относительно небольшие объемы работы. Они делают небольшие шаги вперед и часто связываются друг с другом и со своими заинтересованными сторонами, чтобы задать один и тот же вопрос разными способами:

Мы уже на месте?

Скрам-команды задают этот вопрос в ежедневных схватках (собираемся ли мы достичь нашей цели спринта?), на сессиях проектирования (правильно ли мы строим?), в коде обзоры (обслуживается ли этот код?) и со всеми видами тестирования (соответствует ли он критериям приемлемости и нефункциональным требованиям без ошибок?)

Мы также просим об этом в демонстрациях для владельца продукта (готово ли это для клиента?) и в обзорах спринтов с клиентами или другими заинтересованными сторонами (ценно ли это для вас? )

Ответы на эти вопросы могут открыть новую сложность в любой момент. Большой. Мы узнали больше. Теперь ... что будет дальше?

Адаптируйся или умри

Хорошие Scrum-команды используют любую возможность, чтобы выслушать отзывы. Лучшие команды Scrum извлекают уроки из этой обратной связи и используют ее для адаптации своего подхода. (Совет шляпы Джеффу Уоттсу).

Дизайн может потребовать большего внимания. Качество кода может потребовать дополнительных инвестиций. В устаревших системах ошибки могут быть или не быть внесены в результате этой работы, и нам нужно время, чтобы понять влияние… и все это до, которое мы даже дойдем до демонстрации для PO или наших клиентов.

Я часто участвовал в обзорах спринтов, когда покупатель говорил что-то вроде:

Ты сделал хорошую работу. Это то, о чем я просил ... теперь, когда я это вижу, думаю, нам нужно внести некоторые изменения ...

Подобные предложения в Обзоре Спринта - хорошая проверка покерных лиц в комнате. Я видел, как Scrum-команды немного умирают внутри, когда достигают этой точки. Всю ту работу, которую мы проделали !? А теперь нам нужно изменить?

В Scrum Teams «готово» не обязательно означает, что мы закончили: это означает, что мы готовы к обратной связи.

И вот что интересно: эта обратная связь может изменить то, что мы сделали!

Вот руководящий принцип, на который мы можем ссылаться в подобной ситуации:

Приветствуем меняющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента . (AgileManifesto)

Когда элемент бэклога продукта или приращение описывается как «Готово», это означает, что мы готовы прислушиваться к дальнейшим изменениям.

«Совершенство - враг добра»

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

Нам нужно избегать риска сделать слишком мало и поставить под угрозу качество. Нам также нужно избегать побуждения делать слишком много и тратить ненужные усилия на функции, о которых наш клиент никогда не просил и даже не нуждался.

Фраза «Совершенство - враг добра» резюмирует это. На первый взгляд это может показаться гномичным и непонятным, но оно основано на здравом смысле и задолго до появления любых представлений об Agile или даже программном обеспечении.

Пословица Вольтера предостерегает нас от крайностей. Достаточно хорошо, достаточно хорошо.

Команды Scrum должны выполнить свою работу, чтобы услышать отзывы клиентов. Слишком много делать - это риск, потому что это задерживает обратную связь. Если мы создадим что-то, что клиенту не обязательно понадобится, это также будет пустой тратой.

Dropbox должен был быть готов до того, как стать идеальным

Первоначальный запуск Dropbox - отличный пример того, как сделать все пораньше, не стремясь к совершенству.

Изначально они запустили простой веб-сайт, на котором клиенты могли регистрировать интерес с помощью адреса электронной почты. На сайте также был размещен видеоролик, объясняющий концепцию. Это все.

В трехминутном видео основателя Dropbox Дрю Хьюстона продемонстрировано, как работает программа для управления файлами. Видео объяснило основные особенности продукта и привлекло отзывы 75000 человек, заинтересованных в нем. Повторюсь, они получили эту обратную связь до того, как было выпущено какое-либо программное обеспечение.

На приведенном ниже слайде Дрю Хьюстон резюмируется, что для Dropbox означало доведение чего-либо до клиентов на раннем этапе.

Готовьтесь, получайте отзывы, готовьтесь к адаптации

Dropbox не создал идеальную версию своего продукта, пока что-то не попало в руки клиентов. У них есть видео, которое дает отличное представление о том, на что он может делать.

Мог ли продукт уже делать все, что было показано на видео? На тот момент это не было большой проблемой. Продукт еще не был готов, но видео действительно ясно показало, чем Dropbox хочет, чтобы он стал.

Этого также было достаточно, чтобы получить обратную связь от 75 000 потенциальных клиентов. Благодаря этой волне положительных отзывов они знали, что у них есть жизнеспособный продукт с клиентской базой, готовой участвовать и участвовать в процессе разработки продукта. Завидно!

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

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

Скрам-команды решают адаптивные задачи. Это означает, что у нас очень мало шансов получить оценку «А» с первой попытки. Чем раньше мы сможем «сделать» что-то и попасть в руки наших клиентов, тем раньше мы сможем получить отзывы о нашем решении этой проблемы.

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