О некоторых уроках, полученных мной во время работы по этой методологии, я буду писать в блоге.
Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"
Понятие commitment в скраме обозначает объем работ, который команда обязуется выполнить за спринт.
Чем плохо невыполнение обещанного объема работ:
- невозможно спланировать конечную дату релиза продукта
- недовольство стейкхолдеров всех уровней
- недовольство собой команды, что в конечном итоге ведет к понижению производительности ее труда ("Мы снова сфейлили спринт. Но мы всегда фейлим, так что все в нормально и так.")
- конфликты внутри команды ("Я успел сделать, что от меня требовалось, а из-за этих лентяев мы снова сфейлили.")
- стресс и усталость.
Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).
Лучше откусить кусок поменьше и добрать задачи. В конечном итоге, команда может сделать бОльший объем работы в более комфортных условиях.
Плюсы:
- удачно законченные спринты улучшают микроклимат в команде
- повышается производительность труда
- заинтересованные лица тоже довольны
- со временем команда учится более точно соизмерять свои силы и возможности.
А мы перешли на новый confluence и там статьи можно like-ать, дайте в блогах :)
ReplyDeleteОчень здорово описано, а главное - злободневно!
Спасибо :)
DeleteСпасибо за интересную статью. Предложу альтернативное мнение: кусать нужно ровно столько, сколько можете проглотить. Если не можете рассчитать укус, то нужно тренироваться. Если вы берете на планировании меньше задач, чем сможете сделать за итерацию, то снижается мотивация к оптимизации как планирования("все равно потом доберем задач, если что") так и узких мест процесса внутри команды("давайте подольше, на всякий случай, потестируем/порефакторим/и т.д. эту задачу, все равно еще есть запас времени"). Когда планируется больше задач, бесспорно, это весьма негативно: команда выходит из зоны комфорта, но также это является стимулом для оптимизации работы, развития команды. Команда, планирующая задачи с временным запасом, рискует, в отсутствии мотивирующего фактора, превратиться в застоялое болотце.
ReplyDeleteDamaskus, спасибо за справедливое уточнение.
DeleteВ нашем случае выходило так, что на "рюшики" не было ни капли времени из-за большого скоупа задач, что в итоге влекло к снижению качества кода и появлению\увеличению технической задолженности.
Безусловно, нужно учиться планировать точно.
Однако,попадание сразу в 100% точные эстимейты - это фантастика или очень большая удача. Нам не так повезло :) Для повышения точности планирования я и веду статистику по типу той, что продемонстрирована выше, - она служит команде наглядной демонстрацией того, на сколько мы перепрыгнули или не допрыгнули в каждом спринте. Анализируются причины, делаются выводы и соответствующие корректировки.
Знакомая история с увеличением техдолга в погоне за внешним, продаваемым, качеством продукта. Затем это приведет, в процессе роста сложности продукта, к перманентному увеличению процентного показателя времени, затрачиваемого на реализацию функционала и исправление ошибок. Может быть стоит, на планировании, ввести фиксированный временной множитель, для выделения дополнительного времени под практики улучшения внутреннего качества продукта(рефакторинг затронутого кода, ревью, реализация оптимального покрытия нового/измененного кода модульными интеграционными тестами и т.д.). Например: "дополнительные 10% от запланированного на задачу времени, мы тратим на внутреннее качество продукта". Останется только донести заказчикам необходимость дополнительных временных затрат, желательно на их же языке, например так: "Сейчас нам, для реализации задачи Х,необходимо 10 человекодней. В случае, если мы не будем выделять время на улучшение внутреннего качества, то через год, на задачу с таким же уровнем сложности, нужно будет потратить 15 человекодней". Подвести необходимую для заказчиков статистику со страшным трендом увеличения временных затрат, думаю, не составит труда ;) После этого можно планировать итерации не опасаясь нехватки времени на "рюшики".
DeleteМы не стали вводить коэффициент, а решили сразу делать хорошо. Благо, "продавать это заказчику" нам не нужно.
DeleteЕсли через несколько спринтов выясняется, что что-то сделали не так хорошо, как могли - не выставляем этим изменениям стори поинты, считая это устранением нашего технического долга.
В статье я хотела показать, как сжатые сроки влияют на производительность команды. При этом никто команду не гонит никуда, просто каждый спринт она уверена, что сделает тот объем задач, на который коммититься.
А управление рисками пока развито не достаточно.
This comment has been removed by the author.
DeleteСпасибо. Было интересно с Вами подискутировать
DeleteПолностью согласен! Тут часто срабатывает психологический фактор и команда, воодушевленная своими успехами, успевает сделать больше запланированного. В Agile подходах гораздо важнее прозрачность процесса и предсказуемость результатов, к которой как раз и приводят надежные неоптимистичные оценки на планировании итерации. А про опасность применения буферов я как раз на этой неделе писал: http://xpinjection.com/2012/09/02/dangerous-practice-of-using-buffers-in-scrum/.
ReplyDelete