{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Kanban.club: posts tagged scrum", "_rss_description": "Кратко и по делу о Kanban, Scrum, LeSS, SAFe и все, что может пригодиться в работе менеджеру", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.kanban.club\/?go=tags\/scrum\/", "feed_url": "https:\/\/www.kanban.club\/?go=tags%2Fscrum%2Fjson%2F", "icon": false, "authors": [ { "name": "Роман Петров", "url": "https:\/\/www.kanban.club\/", "avatar": false } ], "items": [ { "id": "84", "url": "https:\/\/www.kanban.club\/?go=all\/keys-scrum-posle-3-mesyacev-raboty\/", "title": "Кейс. Scrum после 3 месяцев работы", "content_html": "

Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.<\/p>\n

Что имеем из фактуры, над которой можно поработать:<\/b><\/p>\n

    \n
  1. Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина – задачи не связаны друг с другом, а раз так, то и разные цели)<\/li>\n
  2. Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)<\/li>\n
  3. Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать<\/li>\n
  4. На ревью пользователи не приходят, так как им нечего показывать<\/li>\n<\/ol>\n
    \n\"\"\n<\/div>\n

    Варианты, что можно улучшить Скрам-мастеру в его команде:<\/b><\/p>\n

      \n
    1. Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат – демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.<\/li>\n<\/ol>\n
        \n
      1. Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т.д.<\/li>\n<\/ol>\n
          \n
        1. Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD<\/li>\n<\/ol>\n
            \n
          1. Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.<\/li>\n<\/ol>\n
              \n
            1. Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС – для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.<\/li>\n<\/ol>\n

              Обязательно не забывать об экологичной обратной связи между всеми участниками процесса, чтобы не получить проблему на пустом месте.<\/i><\/p>\n

              После такого разбора, за такой период, СМ сказал: “Ааа.... я все сломал, ничего не работает, я почти убил команду” :)<\/p>\n

              И здесь лежит ловушка в том, что Scrum всегда не работает – и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.<\/p>\n

              Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.<\/p>\n

              Автор Роман Петров<\/p>\n", "date_published": "2019-06-28T19:10:23+03:00", "date_modified": "2019-06-28T19:10:09+03:00", "tags": [ "DoD", "scrum", "scrum-case" ], "image": "https:\/\/www.kanban.club\/pictures\/Scrum-case-1.jpg", "_date_published_rfc2822": "Fri, 28 Jun 2019 19:10:23 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "84", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kanban.club\/pictures\/Scrum-case-1.jpg" ] } }, { "id": "81", "url": "https:\/\/www.kanban.club\/?go=all\/instrument-pautinka-ocenka-sobytiy-scrum\/", "title": "Инструмент “Паутинка” для оценки событий Scrum", "content_html": "

              Порой Scrum-мастер задаётся вопросом: “Хорошо ли у нас проходят события Scrum?” однако, не может найти подходящий инструмент.<\/p>\n

              Инструмент “Паутинка” позволит команде на ретроспективе оценить события и совместно разработать план по улучшению.<\/p>\n

              \n\"\"\n<\/div>\n

              Инструмент состоит из 3-х частей:
              \nI часть – выравнивание критериев оценки с командой, что для команды 1, а что 5
              \nII часть – совместная оценка событий участниками команды
              \nIII часть – сведение полученных оценок и разработка плана по улучшению<\/p>\n

              I. Выравнивание критериев оценки с командой<\/h2>\n

              Подготовка<\/i>: флипчарт с нарисованной шкалой оценки от 1 до 5<\/p>\n

              Команда и Scrum-мастер пишут на стикерах, что для них оценка “1”, а что оценка “5”.
              \nНапример:
              \n“1” – нет цели\/регулярное опоздание участников\/плавающие события (в разное время)\/отсутствие участников без уважительной причины;
              \n“2” – тайминг не соблюдён\/цель не досигнута\/отсутствие участников без уважительной причины;
              \n“3” – тайминг соблюдён\/цель достигнута;
              \n“4” – всё хорошо, фасилитирует Scrum-мастер;
              \n“5” – команда всё делает сама, Scrum-мастер фасилитирует только ретроспективу<\/p>\n

              Команды, начинающие использовать данный инструмент, вырабатывают критерии оценок, которые будут подходить для всех событий. Освоив инструмент, команды придут к тому, что захотят расширить критерии для каждого события.<\/p>\n

              \n\"\"\n<\/div>\n

              II. Совместная оценка событий участниками команды<\/h2>\n

              Подготовка<\/i>: флипчарт с матрицей событий<\/p>\n

              После того как команда договорилась об оценках, Scrum-мастер просит участников команды оценить каждое событие Scrum. Для этого достаточно подготовить флипчарт с названиями событий и попросить каждого участника написать на стикере свою оценку для каждого события и прикрепить к соответствующему:<\/p>\n