Выбрать главу

В целом, люди, работающие дома, не стали для нас проблемой.

Памятка ScrumMaster’а

Напоследок я познакомлю вас с нашей памяткой ScrumMaster'а. Она содержит наиболее важные административные задачи, за которые отвечает ScrumMaster. Есть вещи, про которые очень легко забыть. Но есть и очевидные, такие как «устранять препятствия на пути команды», которые мы не включаем в наш список.

В начале спринта

• После планирования создать «страницу с информацией о спринте».

a) На стартовой странице wiki-портала поместить ссылку на созданную страницу.

b) Распечатать эту страницу и повесить её на стене, которая у всех на глазах.

• Разослать e-mail'ы с уведомлением о начале нового спринта. Не забыть указать цель спринта и дать ссылку на «страницу с информацией о спринте».

• Обновить статистику спринтов. Добавить оценку предварительной производительности, размера команды, длины спринта и т. д.

Каждый день

• Следить за тем, чтобы ежедневный Scrum начинался и заканчивался вовремя.

• Следить за тем, чтобы в случае добавления или удаления истории из sprint backlog’а все было сделано, как положено, чтобы эти изменения не сорвали график работ.

a) Следить за тем, чтобы product owner знал про эти изменения.

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

• Следить за тем, чтобы все проблемы решались. Как вариант можно проинформировать о них Product owner’а и/или начальника отдела разработки.

В конце спринта

1. Провести открытую демонстрацию результатов спринта.

2. За несколько дней до демонстрации напомнить всем про её проведение.

3. Провести ретроспективу при участии всей команды и Product owner’а. Пригласить начальника отдела разработки, чтобы он помог найти оптимальное решение проблем.

4. Обновить статистику спринтов. Внести значение реальной производительности и основные тезисы прошедшей ретроспективы.

Заключительное слово

Фух! Вот уж не ожидал, что это займёт столько времени.

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

Поскольку Scrum всё равно необходимо подстраивать под каждую конкретную среду, спор по поводу общих практик заведомо будет неконструктивен. Однако мне всё же интересно получить от вас отзывы и предложения. Расскажите мне, чем ваши подходы отличаются от наших. Поделитесь идеями, как стать лучше!

Пишите мне наhenrik.kniberg@crisp.se.

Кроме того, я заглядываю сюда: scrumdevelopment@yahoogroups.com.

Если вам понравилась эта книга, вы, вероятно, захотите иногда заглядывать на мой блог. Я надеюсь и впредь писать там заметки по Java и разработке софта:

http://blog.crisp.se/henrikkniberg/

А ещё никогда не забывайте … Это ведь просто работа, правда?

Список рекомендованной литературы

Ниже перечислены книги, которые стали для меня источниками идей и вдохновения. Настоятельно рекомендую!

От переводчика: большая часть рекомендованных Хенриком книг не переведена на русский язык. Приведенные переводы достаточно точны, качественные и не меняют смысла написанного в оригинале.

• Donald G. Reinertsen «Managing the Design Factory»

• Mary Poppendieck, Tom Poppendieck «Implementing Lean Software Development»

• Mike Cohn «Agile Estimating and Planning»

• Джоэл Спольски «Джоэл о программировании»

• Mary Poppendieck, Tom Poppendieck «Lean Software Development. An Agile Toolkit»

• Barry Boehm, Richard Turner, «Balancing Agility and Discipline»

• Ken Schwaber, Mike Beedle, «Agile Software Development with Scrum»

• Фредерик Брукс «Мифический человеко-месяц»

• Ken Schwaber, «Agile Project Management with Scrum»

• Кент Бек «Экстремальное программирование»

• Том ДеМарко, Тимоти Листер «Человеческий фактор»

Об авторе

Хенрик Книберг (henrik.kniberg@crisp.se) — консультант компании Crisp в Стокгольме (www.crisp.se), специализируется на java и agile-разработке.

С тех пор как увидели свет agile-манифест и первые книги по XP, Хенрик начал следовать agile принципам и изучать, как наиболее эффективно их применять в организациях различного типа. Будучи соучредителем и генеральным директором компании Goyada в 1998–2003 гг. он получил прекрасную возможность поэкспеременировать с TDD и другими agile-практиками, поскольку он начинал с нуля, управлял технической платформой и отделом в тридцать человек.

В конце 2005 года Хенрик по контракту стал главой отдела разработки в шведской игровой компании. Компания была в кризисе и нуждалась в срочном разрешении организационных и технических проблем. Используя инструменты Scrum и XP, Хенрик помог компании преодолеть кризис, внедрив принципы гибкой и бережливой (lean) разработки на всех уровнях.