Курс про Команду. Проектное управление. Скрам
Кен Швабер и Джефф Сазерленд "Руководство по Скраму".
Фан-Факт
Скрам - который первый вспоминают, когда говорят о гибких методологиях - максимально НЕ гибкий.
Скрам нельзя менять. Если вы что-то поменяли - то это уже не скрам. Добавить - ну можно, но убирать что-то - категорически запрещено.
Основная идея
Есть большой беклог - список хотелок с расставленными приоритетами. Его можно менять в любой момент, кроме того, когда часть "хотелок" уже взяли в работу.
Из беклога комадна "зачёрпывает горстями" некоторое количество задач и с ними уходит на спринт.
Спринты - всегда одинаковые по времени.
По итогу спринта - команда выдаёт готовый продукт. Что-то, что можно отдать пользователю, и пользователь увидит пользу\изменения.
Пользователь даёт обратную связь - как ему этот результат.
На основании обратной связи - пересматриваем беклог.
Vision в Скрам
Это такой "фокус внимания". 1-3 предложения. Утверждение "над" беклогом. Обозначение общего направления.
Vision - это всегда elevator pitc - коротко и по делу.
Шаблон:
Для (ключевой пользователь), у котрого проблема в..(обозначение проблемы или возможности) наш продукт...(название) поможет - или окажется - тем, что (что умеет или чем является продукт), и подойдёт лучше предложений прямых конкурентов.. (названия конкурентов) потому что... (ключевое преимущество, убедительная причина).
Как второй вариант
можно формулировать vision как "дизайн коробки"
Тезис + картинка и пара абзацев описания (по аналогии с оформлением коробок для настолок)
Важно, что в Vision не пишут тех.детали - не КАК, а ЧТО мы будем делать.
Роли в Скрам
Если кто-то внутри команды становится токсичным, или начинает плохо работать - это проблема, так как нет специального человека (например тимлида), который бы это решал. Команда самоорганизовывается. Никаких 1-1 там тоже нет - всё сами.
Кроссфункциональность в Скрам.
Увы, но нет.
Если команда разнородная (аналитик, разработчик, тестировщик) - то это уже не работает. Каждый должен уметь делать всё - любую задачу на любом этапе. Причём не просто "понимать о чём речь", а реально уметь делать.
Скрам работает для однородных команд и однотипых задач.
Именно потому - разработчик - единственная роль в команде скрам.
T-shape
Есть такие Т-специалисты, которые какую-то область знают хорошо, но ещё - знакомы со смежными областями. Да, это супер и классно. НО. Это только про то, чтобы понимать друг-друга в разговоре. Даже если хороший программист изучал тестирование - то в тестировании он джун и сеньёра заменить не сможет. А быть одновременно сеньёром во всех областях - действительно сложно (да и не надо).
Скрам-Мастер
Консультант такой. Может быть нанят извне, может быть частью команды.
Отвечает за то, чтобы
Это общий список, состоящий из "хотелок" - то, что заказчик хочет, "багов" - то, что надо доделать, "техдолга" - то, что пока сделали на синей изоленте, но надо бы переписать по-хорошему... из элементов.
Хорошо бы задавать пропорцию - в которой берём в спринты задачи разных типов. (Например - 50% новых фич, 30% багов, 20% техдолга) Пропорцию можно менять со временем.
Беглог не должен содержать внутренних связей (каждая задача - отдельная). Ну если связи есть - то прям минимум (5-10%)
Для каждого элемента должно быть прописано
для определения используют РядФибоначчи (0-1-2-3-5-8-13-21-34-55...)
чем больше число - тем ценнее\сложнее задача
Чтобы не перепутать случайно два параметра - часто ценность проставляют в тысячах (1000-2000-3000-5000-8000...)
Сложность задачи - оценивают всегда в "условных единицах" (StoryPoints)
Выбираем самую простую - это 1, остальные сравниваем с ней.
Кому сложно сразу в стори-пойнтах - можно в два этапа
1. "маечная оценка" (S-M-L-XL-XXL)
2. стори-пойнты (над "майками" вешаем цифры и оцениваем каждую "майку" заново - к какой цифре ближе)
За несколько итераций команда привыкает и дальше "майки" не нужны.
Только "майки" - можно использовать в диалогах с заказчиками (чтобы не объяснять про стори-пойнты)
Почему не в часах?
Так работает мозг. В часах - люди чаще ошибаются, особенно если говорят про большие задачи.
В случае story points- надо сравнивать задачи между собой - при этом ошибок получается меньше
Почему именно ряд Фибоначчи?
маленькие задачи оценить проще, для больших - большая неопределённость (всё равно ошибёшься, ну выбери примерно)
Приоритет
фактически - номер спринта, в который пойдёт задача.
При этом не надо приоритезировать вообще весь беклог (он ещё 1000 раз поменяется, скрам - про гибкость) - достаточно, если будут приоритеты на 2-3 спринта вперёд.
Прогнозирование в Скрам.
Как определить - когда готово будет? (Никак)
В начале работы - ничего не известно.
За первые 3-4 спринта - становится понятна Velocity команды.
Velocity - это мощность - сколько story points может сделать команда за спринт.
(потому и в "майках" нельзя - они в цифры не пересчитываются)
Можно определять по-разному:
авторы метода говорят, что команда должна работать с нагрузкой -т.е. velocity- это "было сложно, но мы вытянули"
"по жизни" - лушче, когда "планочка пониже" - совсем чуть-чуть, но всё же скорость для команды комфортная, не со сверх-услиями
Velocity - основная характеристика команды
Важно, что в спринт нельзя брать больше задач, чем velocity команды. Вообще никак.
Более трудоёмкие задачи следует брать в работу первыми.
Не расставлять приоритеты "вдаль" (2-3 спринта)
Беклог - не то же самое, что записная книжка РО - не надо хранить там вообще все идеи, только то, что собираемся делать в ближайшие пол-года.
Беклог спринта
Когда из общего беклога продукта взяли задачи в спринт - появляется беклог спринта
И в начале - уже задачи из беклога спринта анализируем, разбиваем на под-задачи, расставляем им приоритеты.
Всё это - делает уже команда самостоятельно.
И на этапе спринтов - уже можно оценивать задачи в часах (так удобнее в рамках спринта, задачи уже не большие - меньше вероятности ошибиться)
Важно - ответственность за работу не распределяется по людям - она общая на команду.
Иногда можно добавить мини-канбан-доску с тремя колонками ToDo-InProgress-Done - только в рамках спринта.
Прогресс \ Прогнозирование
Диаграмма сгорания (burndown chart)
По вертикали - общее число задач в беклоге
По горизонтали - спринты.
И вот по спринтам видим, как "столбики" уменьшаются.
Там же - видна скорость команды (она же мощьность - Velocity)
Зная эту скорость - можно примерно нарисовать прогноз - мол, если новых задач не будет и работать будем так же - то к такому-то спринту закончим.
НО.
Если замедлились - то замедлились, ничего с этим не делаем. Ну вот теперь новая velocity - перерисовывайте план. Аналогично - если докинули ещё задач.
События в Скрам
Вообще-то - в скраме много планирования. Просто оно "размазано" по спринтам и не так заметно, как в классическом подходе.
расстановка ценности\сложности - приоритета
выполняется по мере необходимости (на 2-3 спринта вперёд)
Планирование спринта
тот момент, когда взяли задачи из беклога продукта и приступили к их анализу\декомпозиции
Ежедневный скрам
оно же - daily-meeting
по людям!
не про статус, а про процесс
по схеме - что сделал, что буду делать, нужна ли помощь
Ревью спринта
оно же "демо". НО
не я показываю-заказчик смотрит, а заказчик садится к продукту и пробует сам - как ему наши новые фичи?
сразу же - собирается обратная связь
Ретро
инструмент улучшения
их может быть много разных (ретро спринта, ретро проетка (или части), ретро компании, ретро календарное, ретро-по-инциденту...)
Состав ретро
Есть 4 роли - исследователь, отпускник, покупатель, заключённый.
Исследователь - готов к активной работе, есть идеи.
Отпускник - устал как собака, зашел посидеть в уголке и отдохнуть
Покупатель - своих идей нет, но готов обсуждать чужие
Заключённый - не хочу тут быть
Спрашиваем каждого - кто он сейчас. Если большинство 1 или 3 - то норм. Если большинство 2 или 4 - то ретро лучше перенести.
На ретро важно
каждому - стикер с цифрой от 1 до 5 - пожалуйста, поставьте оценку как вам - полезно, не полезно, хорошо ли обсудили....
если к оценке ещё и пару строк допишете - вообще огонь.
(их можно прям на дверь клеить на выходе из конфы)
Итого - Скрам
Из беклога продукта берём в беклог спринтов.
Все спринты - одинаковые.
Что взято в спринт - изменить нельзя.
Весь остальной беклог менять можно.
В конце спринта - явный, понятный, применимый для заказчика результат.
Команда от 3 до 9 человек.
Прогресс - через burndown chart - только следим, никак не влияем на скорость
Ретро - критически важно - помогает улучшать процесс.
Масштабируемость Скрам.
Вообще-то - никак.
Но если очень надо - можно через канбан. Мини-команда - по скраму, а выход на следующий уровень - уже канбан-доски.
Есть SAFe, LeSS... (второй вообще фигня, а первый - таки про канбан), Spotify... (но они все не работают)
Чеклист
Фан-Факт
Скрам - который первый вспоминают, когда говорят о гибких методологиях - максимально НЕ гибкий.
Скрам нельзя менять. Если вы что-то поменяли - то это уже не скрам. Добавить - ну можно, но убирать что-то - категорически запрещено.
Основная идея
Есть большой беклог - список хотелок с расставленными приоритетами. Его можно менять в любой момент, кроме того, когда часть "хотелок" уже взяли в работу.
Из беклога комадна "зачёрпывает горстями" некоторое количество задач и с ними уходит на спринт.
Спринты - всегда одинаковые по времени.
По итогу спринта - команда выдаёт готовый продукт. Что-то, что можно отдать пользователю, и пользователь увидит пользу\изменения.
Пользователь даёт обратную связь - как ему этот результат.
На основании обратной связи - пересматриваем беклог.
Vision в Скрам
Это такой "фокус внимания". 1-3 предложения. Утверждение "над" беклогом. Обозначение общего направления.
Vision - это всегда elevator pitc - коротко и по делу.
Шаблон:
Для (ключевой пользователь), у котрого проблема в..(обозначение проблемы или возможности) наш продукт...(название) поможет - или окажется - тем, что (что умеет или чем является продукт), и подойдёт лучше предложений прямых конкурентов.. (названия конкурентов) потому что... (ключевое преимущество, убедительная причина).
Как второй вариант
можно формулировать vision как "дизайн коробки"
Тезис + картинка и пара абзацев описания (по аналогии с оформлением коробок для настолок)
Важно, что в Vision не пишут тех.детали - не КАК, а ЧТО мы будем делать.
Роли в Скрам
- Владелец продукта (product owner) РО
- Команда разработки (все как один - разработчики)
- Скрам-мастер
- Занимается наполнением и приоритезацией беклога
- Формулирует vision - как фильтр для наполнения беклога (не обязательно сам, но его ответственность)
- Следит за тем, чтобы беклог был
- понятен команде
- доступен команде
- приоритезирован
- Объясняет команде - какой эффект принесёт выполнение задач
- Даёт фидбек - а какой эффект реально принесло выполнение задач (в частности - признаёт, если запросил что-то, что не взлетело)
- контролем команды
- распределением задач
- подкручиванием скорости работы
- Несёт коллективную ответственность за результат
- Самоорганизуется
- Кроссфункциональна (может сделать всю работу без привлечения внешних специалистов)
- Не имеет под-команд
- 1 разработчик - 1 продукт (каждый работает только в одной команде - в двух одновременно - нельзя)
- От 3 до 9 человек
Если кто-то внутри команды становится токсичным, или начинает плохо работать - это проблема, так как нет специального человека (например тимлида), который бы это решал. Команда самоорганизовывается. Никаких 1-1 там тоже нет - всё сами.
Кроссфункциональность в Скрам.
Увы, но нет.
Если команда разнородная (аналитик, разработчик, тестировщик) - то это уже не работает. Каждый должен уметь делать всё - любую задачу на любом этапе. Причём не просто "понимать о чём речь", а реально уметь делать.
Скрам работает для однородных команд и однотипых задач.
Именно потому - разработчик - единственная роль в команде скрам.
T-shape
Есть такие Т-специалисты, которые какую-то область знают хорошо, но ещё - знакомы со смежными областями. Да, это супер и классно. НО. Это только про то, чтобы понимать друг-друга в разговоре. Даже если хороший программист изучал тестирование - то в тестировании он джун и сеньёра заменить не сможет. А быть одновременно сеньёром во всех областях - действительно сложно (да и не надо).
Скрам-Мастер
Консультант такой. Может быть нанят извне, может быть частью команды.
Отвечает за то, чтобы
- все захотели работать (по скрам)
- все поняли, как луче всего что-то делать (по скрам)
- делали правильно и с максимальной пользой для заказчика (по скрам)
- Он же может быть Agile-консультантом - если говорить об уровне компании, а не одной команды.
Это общий список, состоящий из "хотелок" - то, что заказчик хочет, "багов" - то, что надо доделать, "техдолга" - то, что пока сделали на синей изоленте, но надо бы переписать по-хорошему... из элементов.
Хорошо бы задавать пропорцию - в которой берём в спринты задачи разных типов. (Например - 50% новых фич, 30% багов, 20% техдолга) Пропорцию можно менять со временем.
Беглог не должен содержать внутренних связей (каждая задача - отдельная). Ну если связи есть - то прям минимум (5-10%)
Для каждого элемента должно быть прописано
- описание
- ценность (проставляет РО)
- сложность (проставляет команда)
- приоритет (зависит от предыдущих двух, проставляется совместно)
- Я (пользователь) хочу (действие) чтобы (цель)
- Я (пользователь) хочу (возможность) чтобы (выгода)
- Кто-Где-Когда-Что хочет-Почему (техника 5W)
- хорошо бы, чтобы формулировалось одинаково для всех задач.
для определения используют РядФибоначчи (0-1-2-3-5-8-13-21-34-55...)
чем больше число - тем ценнее\сложнее задача
Чтобы не перепутать случайно два параметра - часто ценность проставляют в тысячах (1000-2000-3000-5000-8000...)
Сложность задачи - оценивают всегда в "условных единицах" (StoryPoints)
Выбираем самую простую - это 1, остальные сравниваем с ней.
Кому сложно сразу в стори-пойнтах - можно в два этапа
1. "маечная оценка" (S-M-L-XL-XXL)
2. стори-пойнты (над "майками" вешаем цифры и оцениваем каждую "майку" заново - к какой цифре ближе)
За несколько итераций команда привыкает и дальше "майки" не нужны.
Только "майки" - можно использовать в диалогах с заказчиками (чтобы не объяснять про стори-пойнты)
Почему не в часах?
Так работает мозг. В часах - люди чаще ошибаются, особенно если говорят про большие задачи.
В случае story points- надо сравнивать задачи между собой - при этом ошибок получается меньше
Почему именно ряд Фибоначчи?
маленькие задачи оценить проще, для больших - большая неопределённость (всё равно ошибёшься, ну выбери примерно)
Приоритет
фактически - номер спринта, в который пойдёт задача.
При этом не надо приоритезировать вообще весь беклог (он ещё 1000 раз поменяется, скрам - про гибкость) - достаточно, если будут приоритеты на 2-3 спринта вперёд.
Прогнозирование в Скрам.
Как определить - когда готово будет? (Никак)
В начале работы - ничего не известно.
За первые 3-4 спринта - становится понятна Velocity команды.
Velocity - это мощность - сколько story points может сделать команда за спринт.
(потому и в "майках" нельзя - они в цифры не пересчитываются)
Можно определять по-разному:
авторы метода говорят, что команда должна работать с нагрузкой -т.е. velocity- это "было сложно, но мы вытянули"
"по жизни" - лушче, когда "планочка пониже" - совсем чуть-чуть, но всё же скорость для команды комфортная, не со сверх-услиями
Velocity - основная характеристика команды
- Отдельно производительность каждого не учитывается - только всех вместе.
- Если команда поменялась (кто-то заболел, кто-то в отпуске, один уволился-другого взяли...) - velocity будет новая.
- Её никак не меняют, только принимают к сведению.
Важно, что в спринт нельзя брать больше задач, чем velocity команды. Вообще никак.
Более трудоёмкие задачи следует брать в работу первыми.
Не расставлять приоритеты "вдаль" (2-3 спринта)
Беклог - не то же самое, что записная книжка РО - не надо хранить там вообще все идеи, только то, что собираемся делать в ближайшие пол-года.
Беклог спринта
Когда из общего беклога продукта взяли задачи в спринт - появляется беклог спринта
И в начале - уже задачи из беклога спринта анализируем, разбиваем на под-задачи, расставляем им приоритеты.
Всё это - делает уже команда самостоятельно.
И на этапе спринтов - уже можно оценивать задачи в часах (так удобнее в рамках спринта, задачи уже не большие - меньше вероятности ошибиться)
Важно - ответственность за работу не распределяется по людям - она общая на команду.
Иногда можно добавить мини-канбан-доску с тремя колонками ToDo-InProgress-Done - только в рамках спринта.
Прогресс \ Прогнозирование
Диаграмма сгорания (burndown chart)
По вертикали - общее число задач в беклоге
По горизонтали - спринты.
И вот по спринтам видим, как "столбики" уменьшаются.
Там же - видна скорость команды (она же мощьность - Velocity)
Зная эту скорость - можно примерно нарисовать прогноз - мол, если новых задач не будет и работать будем так же - то к такому-то спринту закончим.
НО.
Если замедлились - то замедлились, ничего с этим не делаем. Ну вот теперь новая velocity - перерисовывайте план. Аналогично - если докинули ещё задач.
События в Скрам
Вообще-то - в скраме много планирования. Просто оно "размазано" по спринтам и не так заметно, как в классическом подходе.
- грумминг беклога
- планирование спринта
- ежедневный скрам
- обзор спринта
- ретро
расстановка ценности\сложности - приоритета
выполняется по мере необходимости (на 2-3 спринта вперёд)
Планирование спринта
тот момент, когда взяли задачи из беклога продукта и приступили к их анализу\декомпозиции
Ежедневный скрам
оно же - daily-meeting
по людям!
не про статус, а про процесс
по схеме - что сделал, что буду делать, нужна ли помощь
Ревью спринта
оно же "демо". НО
не я показываю-заказчик смотрит, а заказчик садится к продукту и пробует сам - как ему наши новые фичи?
сразу же - собирается обратная связь
Ретро
инструмент улучшения
их может быть много разных (ретро спринта, ретро проетка (или части), ретро компании, ретро календарное, ретро-по-инциденту...)
Состав ретро
- открытие (буквально несколько минут - перестроить головы с текущих задач на брейншторм)
- сбор данных
- генерация идей
- составление плана действий
- закрытие (сбор фидбека команды о ретро)
Есть 4 роли - исследователь, отпускник, покупатель, заключённый.
Исследователь - готов к активной работе, есть идеи.
Отпускник - устал как собака, зашел посидеть в уголке и отдохнуть
Покупатель - своих идей нет, но готов обсуждать чужие
Заключённый - не хочу тут быть
Спрашиваем каждого - кто он сейчас. Если большинство 1 или 3 - то норм. Если большинство 2 или 4 - то ретро лучше перенести.
На ретро важно
- вспомнить итог прошлого ретро (там были пункты к действию - давайте посмотрим - как сработало, не надо ли что-то подправить?)
- обсудить - что было хорошо сделано и надо продолжать делать так же
- после того, как накидали море идей - сгруппировать их, отфильтровать и выделить то, на чём будем концентрироваться - какие будут действия
- (обычно до половины времени можно кидать идеи, потом пора группировать)
каждому - стикер с цифрой от 1 до 5 - пожалуйста, поставьте оценку как вам - полезно, не полезно, хорошо ли обсудили....
если к оценке ещё и пару строк допишете - вообще огонь.
(их можно прям на дверь клеить на выходе из конфы)
Итого - Скрам
Из беклога продукта берём в беклог спринтов.
Все спринты - одинаковые.
Что взято в спринт - изменить нельзя.
Весь остальной беклог менять можно.
В конце спринта - явный, понятный, применимый для заказчика результат.
Команда от 3 до 9 человек.
Прогресс - через burndown chart - только следим, никак не влияем на скорость
Ретро - критически важно - помогает улучшать процесс.
Масштабируемость Скрам.
Вообще-то - никак.
Но если очень надо - можно через канбан. Мини-команда - по скраму, а выход на следующий уровень - уже канбан-доски.
Есть SAFe, LeSS... (второй вообще фигня, а первый - таки про канбан), Spotify... (но они все не работают)
Чеклист