3. Пояснение
На
Скрам-‐планерке
команда
делится
3
вопросами,
один
из
которых
«что
меня
тормозит
в
работе»
Скрам-‐мастер
(по
книге)
должен
устранять
эти
препятствия
Если
кто-‐то,
к
примеру,
не
может
отладить
JavaScript, должен
ли
Скрам-‐мастер
это
делать? WTF
?!
Скрам-‐мастер
должен
устранять
только
процессные
препятствия
–
то,
что
мешает
внедрению
гибкой
разработки.
И
отфутболивать
остальное
обратно
команде –
let the team eat its dog food.
5. Пояснение
Дизайнеры
–
редки
люди
с
хорошим
эстетическим
вкусом.
Они
часто
оказываются
вне
Скрам-‐команд
–
их
мало.
Их
задача
часто
видится
в
поставке
детальных
дизайнов
команде.
Это
лишает
команду
свободы
обсуждения
требований
с
заказчиком.
Но
дизайнеры
и
дизайны
нужны.
WTF
?!
Есть
два
варианта
решения
этой
проблемы
Посадите
дизайнера
в
команду
ProductOwner-‐а
–
пусть
использует
свои
навыки
для
помощи
донесения
бизнес
идей
в
скетчах.
Если
же
нужны
детальные
«пиксель-‐в-‐пиксель»
дизайны
для
верстки,
то
подчините
дизайнера
команде
–
пусть
он
это
делает
по
запросу
команды
уже
после
обсуждения
требований.
7. Пояснение
Я
более
трех
лет
работаю
как
Скрам-‐коуч,
помогая
внедрять
Скрам,
и
читаю
тренинги
по
тематике.
Я
сознаюсь
–
некоторое
время
мои
тренинги
не
освещали
вопросы
инженерных
практик.
Ведь
Скрам
–
это
всего
лишь
каркас
управления
проектами.
Но
как
сказал
Ron Jeffries: “Agile software development still requires some software development”
-‐ WTF
?!
Без
акцента
на
качестве
кода
–
мы
никуда.
Это
путь
в
лже-Agile.
Я
считаю,
что
успешное
внедрения
Agile невозможно
без
(это
минимум):
1- Continuous Integration, 2- юнит-‐тестирования
(пусть
не
TDD), 3- автоматизации
функционального
тестирования
(пусть
не
полной),
4- постоянного
рефакторинга.
Я
разработчик,
владеющий
этими
практиками,
не
делать
их
просто
непрофессионально.
9. Пояснение
v В
Скраме
по
книге
нет
роли
проектного
менеджера.
v Скрам-‐мастер
–
это
не
переименованный
менеджер.
Это
новая
парадигма.
v Но
менеджеры
обладают
опытом
и
могут
принести
пользу
компании.
В
них
есть
прок.
v Где
же
их
место?
WTF
?!
v Менеджеры
должны
обитать
вне
проектов.
v Они
должны
сверху
смотреть
на
департамент,
где
работают
Скрам-‐команды
со
Скрам-‐
мастерами.
v Они
должны
решать
стратегические
вопросы
управления
организацией.
11. Пояснение
Все
хотят
идеального
книжного
Product Owner’а.
Таких
я
видел
только
в
стартапах.
В
остальных
проектах
–
PO далеки
от
идеала.
Значит
в
большинстве
проектов
Скрам
невозможен?
WTF
?!
Неидеальность
представителя
заказчика
не
вызвана
внедрением
Скрама.
Скрам
делает
дисфункции
организации
видимыми.
Что
делать?
Первое:
обучайте
заказчиков
становиться
лучшими
PO.
Второе:
часть
работы
PO
могут
делать
аналитики.
Третье:
не
прекращайте
поисков
лучших
кандидатов
в
PO.
Но
не
ищите
PO
в
отделе
IT.
Потому
что
вы
его
там
найдете!
Вам
не
нужен
PO,
который
будет
давать
задачи
на
уровне
баз
данных.
13. Пояснение
Agile
утверждает,
что
люди
превыше
процессов.
Скрам
–
это
Agile.
Но
если
вы
меняете
Скрам,
это
называется
ScrumButt – “we do Scrum, but …»
Так
что
важнее
-‐
люди
или
процессы?
WTF
?!
Не
вступайте
в
СКРАМНО!
Я
советую
не
менять
правила
игры
в
Скрам
до
тех
пор,
пока
вы
не
научитесь
хорошо
по
ним
играть.
Поработайте
3,
5,
7
спринтов.
И
потом
уже
думайте
над
тем,
что
вам
мешает
в
процессе
и
стройте
свой
Agile.
15. Пояснение
Скрам-‐мастер
–
это
full-‐time
или
part-‐time
активность?
Может
ли
Скрам-‐мастер
писать
код?
Кто
лучше
подходит
на
роль
Скрам-‐мастера
–
разработчик?
тестировщик?
менеджер?
Выходят
ли
лучшие
Скрам-‐мастера
из
женщин?
Я
видел
разные
кейсы:
работали
и
не
работали
разные
варианты.
WTF
?!
Скрам-‐мастером должен
стать
человек,
который
горит
за
улучшение
процесса.
Тот,
кто
разделяет
ценности
гибкой
разработки.
Тот,
кто
станет
проводником
процессных
улучшений
в
проекте.
Скрам-‐мастер
– агент
будущего.