Отзыв о Scrum and XP from the Trenches

scrumскрамhenrik kniberg

Звкончил читать книгу "Scrum and XP from trenches" by Henrik Kniberg. На русский перевод не нашел, но она и на английском читается прекрасно и легко. Написана в моем любимом стиле - истории из личного опыта. Хенрик в первой редакции описал опыт использования скрама через год после начала. А вот вторую версию не стал менять, просто добавил врезки с комментариями по прошествии 8 лет. Получилось очень живо и полезно. Какие основные мысли вынес я:

  1. Ребята начали использовать скрам и сразу же начали его адаптировать под себя. Сейчас многие молятся на скрам гайд, боятся от него отступить и в итоге получают не гибкую методологию, а карго культ. Автор рассказывает о множестве экспериментов, например, одной целью на несколько спринтов, если не получалось выделить на спринт. И это нормально, Scrum находится под зонтивокм Agile, что вообще то он должен быть гибким.
  2. В первой версии самой важной встречей называется Планирование. Оно, кстати, было совмещено с груммингом (PBR), что тоже не совсем классический подход. А вот уже вот втором издании Хенрик признает - важнейшее события - ретро! Без него команда не может двигаться вперед.
  3. Вначале не только аналитики, но и тестировщики были вне команды. Это для меня стало полной неожиданностью. Но то, что тестировщика таки "взяли" в команду ко второму изданию, говорит о движении в сторону кросс-функциональности. По сути, сейчас с аналитиком во многих командах происходит по сути то же самое.
  4. Очень важными практиками Хенрик называет и инженерные практики вроде TDD и парного программирования. Из скрама их намеренно убрали (со слов автора, ссылающегося на Джеффа Сазерленда) в угоду простоте. Но их использование приносит огромную пользу программному продукту.
  5. Демо спринта правильнее называть спринт ревью. Потому что демо - презентация, а на демонстрации результатов спринта должен быть быть и обзор и обсуждение и в целом ворох задач для развития. Это очень ценное замечание.
  6. Несколько ценных советов по организации разработки продукта несколькими командами: перекрестная фасилитация скрам мастерами у "не своих" команд, разделение синк митов на несколько уровней, выделение дежурной команды или дежурного внутри каждой команды, чтобы не дергали всех.

Кто тоже читал книгу - приходите в комменты, обсудим