Connect with us

Разработка

Думайте, а не проводите спринты

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

Фото аватара

Опубликовано

/

     
     

Статья разработчика Джона Катлера о том, как бороться с превращением Agile-методик в необдуманный набор ритуалов.

Окей, у вашей команды есть выбор. У вас есть список задач с приоритетами, который нужно реализовать…

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

Какие аргументы обычно учитывают при выборе первого варианта:

  1. При варианте №1 команда будет мотивирована выполнить свои обязательства по спринту.
  2. Всегда хорошо к чему-то стремиться. № 1 позволяет это сделать.
  3. Разработчики должны научиться выполнять свои обещания. Снова №1.
  4. №1 показывает, что разработчики могут работать предсказуемо.
  5. Как мы можем прогнозировать проект без №1?
  6. С №1 мы создадим подходящую для получения обратной связи вещь.

Я могу поспорить, что с вариантом №2 вы можете создавать продукты не менее хорошо.

  1. Вы хотите, чтобы ваша команда работала максимально хорошо. Реализация предопределенного набор функций — это не показатель того, что вы работаете наилучшим образом. Например, вы можете быть вынуждены начать рефакторинг. Это сложно. С №1 вы не выполните свое обещание, работая наилучшим образом.
  2. Вариант номер 2 не отменяет постановку целей. Но этот вариант дает вам гибкость в постановке целей разных типов — создании циклов обратной связи и обучения, циклов поставки и т.д.
  3. Многие команды “придерживаются №2, но с оценками и целями спринта…Мы не относимся к функциям, как к обязательству”. Хмм, ок.
  4. Простой способ выполнять свои обязательства — обещать меньше. Мы этого не хотим.
  5. Предсказуемость и определенность требуют времени. Вариант №2 может стать предсказуемым потоком спустя какое-то время.
  6. На способность делать прогноз сильно влияют факторы, не связанные с временем работы: объем работы, количество незавершенной работы, постоянство среды, мультизадачность, обзоры, коэффициенты полезности и т.д. Эти факторы можно учесть в обоих способах работы, но с помощью №2 это можно сделать с меньшим количеством отвлечений и затрат.

Думайте, а не проводите спринты

И что?

Оба этих варианта не так уж сильно и отличаются. Я могу представить хорошую команду, выбирающую оба стиля работы. Или первый вариант с желанием перейти ко второму со временем, и наоборот. Если команда стремится постоянно совершенствоваться (имеет возможность убирать внешне препятствия и психологически безопасна), она найдет подходящий способ. Я считаю, что первым вариантом и всеми связанными с ним ритуалами постоянно злоупотребляют. Цель не в Scrum и всех его маленьких действиях. Вместо этого нужно принять постоянное совершенствование и контроль эмпирического процесса, прозрачность и адаптацию.

Ничто не останавливает вашу команду от рефлексии по поводу процесса. Ничто не останавливает вашу команду от постановки значимых целей. Поэтому мой совет — не нужно устраивать спринты, начните думать (даже если в итоге вы будете проводить спринты обдуманно). Знайте причины определенных ритуалов. И сделайте экспериментирование и обучение безопасными.

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Наши партнеры:

LEGALBET

Мобильные приложения для ставок на спорт
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: