August 13, 2012

Lessons learned in SCRUM. Lesson 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

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

Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

Понятие commitment в скраме обозначает  объем работ, который команда обязуется выполнить за спринт.
Чем плохо невыполнение обещанного объема работ:
- невозможно спланировать конечную дату релиза продукта
- недовольство стейкхолдеров всех уровней
- недовольство собой команды, что в конечном итоге ведет к понижению производительности ее труда ("Мы снова сфейлили спринт. Но мы всегда фейлим, так что все в нормально и так.")
- конфликты внутри команды ("Я успел сделать, что от меня требовалось, а из-за этих лентяев мы снова сфейлили.")
- стресс и усталость.

Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).
 
 После многих спринтов, когда запланированная работа превышала реально сделанную (столбики 1-5), решили-таки коммититься на меньший объем. Результат поразил - в первый такой спринт команда выполнила почти на 5% больше,чем в предыдущий, а на второй - на 10% больше! (столбики 6 и 7) При этом реально потраченное на выполнение задач время практически не изменилось.

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

Плюсы:
- удачно законченные спринты улучшают микроклимат в команде
- повышается производительность труда
- заинтересованные лица тоже довольны
- со временем команда учится более точно соизмерять свои силы и возможности.

9 comments:

  1. А мы перешли на новый confluence и там статьи можно like-ать, дайте в блогах :)

    Очень здорово описано, а главное - злободневно!

    ReplyDelete
  2. Спасибо за интересную статью. Предложу альтернативное мнение: кусать нужно ровно столько, сколько можете проглотить. Если не можете рассчитать укус, то нужно тренироваться. Если вы берете на планировании меньше задач, чем сможете сделать за итерацию, то снижается мотивация к оптимизации как планирования("все равно потом доберем задач, если что") так и узких мест процесса внутри команды("давайте подольше, на всякий случай, потестируем/порефакторим/и т.д. эту задачу, все равно еще есть запас времени"). Когда планируется больше задач, бесспорно, это весьма негативно: команда выходит из зоны комфорта, но также это является стимулом для оптимизации работы, развития команды. Команда, планирующая задачи с временным запасом, рискует, в отсутствии мотивирующего фактора, превратиться в застоялое болотце.

    ReplyDelete
    Replies
    1. Damaskus, спасибо за справедливое уточнение.
      В нашем случае выходило так, что на "рюшики" не было ни капли времени из-за большого скоупа задач, что в итоге влекло к снижению качества кода и появлению\увеличению технической задолженности.
      Безусловно, нужно учиться планировать точно.
      Однако,попадание сразу в 100% точные эстимейты - это фантастика или очень большая удача. Нам не так повезло :) Для повышения точности планирования я и веду статистику по типу той, что продемонстрирована выше, - она служит команде наглядной демонстрацией того, на сколько мы перепрыгнули или не допрыгнули в каждом спринте. Анализируются причины, делаются выводы и соответствующие корректировки.

      Delete
    2. Знакомая история с увеличением техдолга в погоне за внешним, продаваемым, качеством продукта. Затем это приведет, в процессе роста сложности продукта, к перманентному увеличению процентного показателя времени, затрачиваемого на реализацию функционала и исправление ошибок. Может быть стоит, на планировании, ввести фиксированный временной множитель, для выделения дополнительного времени под практики улучшения внутреннего качества продукта(рефакторинг затронутого кода, ревью, реализация оптимального покрытия нового/измененного кода модульными интеграционными тестами и т.д.). Например: "дополнительные 10% от запланированного на задачу времени, мы тратим на внутреннее качество продукта". Останется только донести заказчикам необходимость дополнительных временных затрат, желательно на их же языке, например так: "Сейчас нам, для реализации задачи Х,необходимо 10 человекодней. В случае, если мы не будем выделять время на улучшение внутреннего качества, то через год, на задачу с таким же уровнем сложности, нужно будет потратить 15 человекодней". Подвести необходимую для заказчиков статистику со страшным трендом увеличения временных затрат, думаю, не составит труда ;) После этого можно планировать итерации не опасаясь нехватки времени на "рюшики".

      Delete
    3. Мы не стали вводить коэффициент, а решили сразу делать хорошо. Благо, "продавать это заказчику" нам не нужно.
      Если через несколько спринтов выясняется, что что-то сделали не так хорошо, как могли - не выставляем этим изменениям стори поинты, считая это устранением нашего технического долга.

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

      Delete
    4. This comment has been removed by the author.

      Delete
    5. Спасибо. Было интересно с Вами подискутировать

      Delete
  3. Полностью согласен! Тут часто срабатывает психологический фактор и команда, воодушевленная своими успехами, успевает сделать больше запланированного. В Agile подходах гораздо важнее прозрачность процесса и предсказуемость результатов, к которой как раз и приводят надежные неоптимистичные оценки на планировании итерации. А про опасность применения буферов я как раз на этой неделе писал: http://xpinjection.com/2012/09/02/dangerous-practice-of-using-buffers-in-scrum/.

    ReplyDelete