…вы используете Скрам, как движок для улучшения. Скрам-команда должна проводить эффективные Ретроспективы Спринта и быть готовой Лопнуть Пузырь Счастья. Базовые механики Скрама на месте и вы хотите использовать Скрам для реализации своего видения кайзен (смотрите также Kaizen and Kaikaku):
Кайзен или kai-zen (カイゼン) японская бизнес-философия постоянного совершенствования методов работы, личной эффективности и т. д. В переводе с японского ‘улучшение’.
Посмотрите также Toyota Kata.
✥ ✥ ✥
Лишь небольшая часть Скрам-команд сдвигает парадигму к радикально новому уровню производительности и способности создавать ценность. Так происходит из-за того, что большинству команд не удается выявить и устранить препятствия.
Их работа не Done (смотри Definition of Done), их Бэклог не Ready(see Definition of Ready), команда не самоорганизуется для повышения производительности.
Сложные препятствия могут потребовать чрезвычайно целенаправленных усилий для устранения. Работа над многими препятствиями одновременно часто приводит к большому объему работ с небольшим выхлопом и может деморализовать команду.
Поэтому:
Определите самое важное препятствие на Ретроспективе Спринта и устраните его до конца следующего Спринта. Чтобы устранить самое важное по приоритету препятствие, поместите его в Бэклог Спринта как задачу с приемочными тестами (смотри Testable Improvements) которые будут определять, когда задача Готова. Затем оцените статус задачи, как и любой другой, на Обзоре Спринта.
Фокус внимания на препятствии высшего приоритета будет иметь побочный эффект самоорганизации команды для устранения других препятствий высокого приоритета, не теряя при этом внимание на препятствии самого высокого приоритета.
✥ ✥ ✥
Этот паттерн обеспечивает постоянное повышение эффективности или устойчивой работоспособности высокого уровня, возможно, измеряемой по скорости (см. Notes on Velocity). Если вы не улучшаетесь постоянно, ваша пропускная способность будет оставаться постоянной или уменьшаться со временем. Эксперт по Бережливости (Lean) Хьюго Хейтс (Hugo Heitz) подчеркнул, что Скрам-команды не уделяют достаточно внимания процессу улучшения: “Им нужно поместить кайзен в Бэклог. Им нужен Скрам Скрама. Им нужно использовать Скрам, чтобы сделать Скрам лучше.”
Пока Скрам-мастер владеет процессом создания и приоритизации списка препятствий, вся Скрам-команда владеет устранением препятствия. Члены команды могут разобраться со множеством препятствий самостоятельно. В других случаях команде может понадобиться помощь менеджмента (см. Involve the Managers).
Устранение препятствия высшего приоритета должно немедленно отразиться в улучшении командной производительности. Если это не так, значит Скрам-команда не проанализировала должным образом динамику системы и не поняла причину первичной дисфункции.
Когда команде удастся увеличить пропускную способность или повысить ее эффективность, система восстановит свою стабильность после устранения препятствий. Тем не менее, следующее самое важное препятствие может быть в неожиданном месте. Так что для команды, вероятно, расточительно работать над несколькими препятствиями или ограничениями одновременно. Сосредоточьтесь на препятствии с наивысшим приоритетом.
Скрам – фреймворк для инспекции и адаптации для достижения постоянного улучшения путем устранения препятствий. Непрерывное улучшение может значительно повысит производительность даже за счет неотъемлемых факторов пропускной способности.
Бидл и соавт. ранее установили (см. “Scrum: A Pattern Language for Hyperproductive Software Development”), что Скрам является языком паттернов для высокопроизводительной и продуктивной разработки программного обеспечения.
Опыт показывает, как в высоко дисциплинированных организациях, так и в дисфункциональных организациях предполагает, что любая команда может достичь необычайно высокого уровня эффективности с помощью внедрения определенных практик Скрама. Например, Systematic, компания 5-го уровня зрелости CMMI в Дании, продемонстрировала, что все команды смогли удвоить объем выполненной работы, обеспечивая тестирование на уровне фич и отсутствие багов внутри Спринта. Второе удвоение произошло благодаря высокой степени готовности Бэклога Спринтак началу Спринта.
Пример:
Команда использовала Happiness Metric для идентификации и приоритизации процессных улучшений. Они спрашивали друг друга: “По шкале от 1 до 5 оцени: (1) Как вы относитесь к своей роли в компании? (2) Как вы относитесь к компании? Затем участники команды делились тем, что заставит их чувствовать себя лучше, затем они использовали Planning Poker для оценки ценности улучшений. Также команда оценивала ценность (не стоимость) элементов Бэклога. Команда оценила весь Бэклог Продуктасуммарно около 50 баллов ценности.
Элемент “Улучшить пользовательские истории” имел наивысший приоритет улучшения для команды. Команда оценила, что устранение этого препятствия даст более 60 баллов ценности. Главный Владелец Продукта из Команды Владельца Продуктазадавался вопросом, может ли устранение этого препятствия удвоить скорость (velocity), так как его ценность была выше, чем ценность всего Бэклога Продукта для Спринта. Владелец Продуктапоместил элемент “Улучшить пользовательские истории” в Бэклог Продукта и разработчики выбрали его в следующий Спринт с Критериями Готовности (Definition of Done). Команда определила этот Definition of Done как приемочные тесты, имеющие метрики, которые они могут посчитать на следующем Обзоре Спринта. Метрики включали в себя:
Несмотря на то, что улучшение качества пользовательских историй никогда не заканчивается, Обзор Спринта показал значительное в этом элементе бэклога, что было измерено с помощью приемочных тестов. Значительное улучшение привело к увеличению скорости после нескольких Спринтов. После того, как скорость удвоилась, это препятствие упало с вершины списка препятствий, и его место заняло другое.
График ниже показывает скорость команды, работающих недельными Спринтами. В Спринте 86 (около 27 декабря 2010 года) команды выросла в размере. Со Спринта 89 “Улучшение пользовательских историй” стало элементом бэклога каждого Спринта. В течение трех Спринтов скорость более чем удвоилась. Команда поняла, что в среднем 10-процентное увеличение скорости в Спринт в последующих Спринтах произошло с помощью Scrumming the Scrum.
Некоторые команды предпочитают явно поместить элемент улучшения процесса в верхнюю часть Бэклога Продукта вместо того, чтобы сразу же помещать его в Бэклог Спринта. Это подчеркивает, что рабочие препятствия – это настоящая работа, а что-то, что делают разработчики на полях. Это также официальное подтверждение того, что Владелец Продукта учел стоимость и ценность работы.
Кайзен или kai-zen (カイゼン) японская бизнес-философия постоянного совершенствования методов работы, личной эффективности и т. д. В переводе с японского ‘улучшение’.
Посмотрите также Toyota Kata.
✥ ✥ ✥
Лишь небольшая часть Скрам-команд сдвигает парадигму к радикально новому уровню производительности и способности создавать ценность. Так происходит из-за того, что большинству команд не удается выявить и устранить препятствия.
Их работа не Done (смотри Definition of Done), их Бэклог не Ready(see Definition of Ready), команда не самоорганизуется для повышения производительности.
Сложные препятствия могут потребовать чрезвычайно целенаправленных усилий для устранения. Работа над многими препятствиями одновременно часто приводит к большому объему работ с небольшим выхлопом и может деморализовать команду.
Поэтому:
Определите самое важное препятствие на Ретроспективе Спринта и устраните его до конца следующего Спринта. Чтобы устранить самое важное по приоритету препятствие, поместите его в Бэклог Спринта как задачу с приемочными тестами (смотри Testable Improvements) которые будут определять, когда задача Готова. Затем оцените статус задачи, как и любой другой, на Обзоре Спринта.
Фокус внимания на препятствии высшего приоритета будет иметь побочный эффект самоорганизации команды для устранения других препятствий высокого приоритета, не теряя при этом внимание на препятствии самого высокого приоритета.
✥ ✥ ✥
Этот паттерн обеспечивает постоянное повышение эффективности или устойчивой работоспособности высокого уровня, возможно, измеряемой по скорости (см. Notes on Velocity). Если вы не улучшаетесь постоянно, ваша пропускная способность будет оставаться постоянной или уменьшаться со временем. Эксперт по Бережливости (Lean) Хьюго Хейтс (Hugo Heitz) подчеркнул, что Скрам-команды не уделяют достаточно внимания процессу улучшения: “Им нужно поместить кайзен в Бэклог. Им нужен Скрам Скрама. Им нужно использовать Скрам, чтобы сделать Скрам лучше.”
Пока Скрам-мастер владеет процессом создания и приоритизации списка препятствий, вся Скрам-команда владеет устранением препятствия. Члены команды могут разобраться со множеством препятствий самостоятельно. В других случаях команде может понадобиться помощь менеджмента (см. Involve the Managers).
Устранение препятствия высшего приоритета должно немедленно отразиться в улучшении командной производительности. Если это не так, значит Скрам-команда не проанализировала должным образом динамику системы и не поняла причину первичной дисфункции.
Когда команде удастся увеличить пропускную способность или повысить ее эффективность, система восстановит свою стабильность после устранения препятствий. Тем не менее, следующее самое важное препятствие может быть в неожиданном месте. Так что для команды, вероятно, расточительно работать над несколькими препятствиями или ограничениями одновременно. Сосредоточьтесь на препятствии с наивысшим приоритетом.
Скрам – фреймворк для инспекции и адаптации для достижения постоянного улучшения путем устранения препятствий. Непрерывное улучшение может значительно повысит производительность даже за счет неотъемлемых факторов пропускной способности.
Бидл и соавт. ранее установили (см. “Scrum: A Pattern Language for Hyperproductive Software Development”), что Скрам является языком паттернов для высокопроизводительной и продуктивной разработки программного обеспечения.
Опыт показывает, как в высоко дисциплинированных организациях, так и в дисфункциональных организациях предполагает, что любая команда может достичь необычайно высокого уровня эффективности с помощью внедрения определенных практик Скрама. Например, Systematic, компания 5-го уровня зрелости CMMI в Дании, продемонстрировала, что все команды смогли удвоить объем выполненной работы, обеспечивая тестирование на уровне фич и отсутствие багов внутри Спринта. Второе удвоение произошло благодаря высокой степени готовности Бэклога Спринтак началу Спринта.
Пример:
Команда использовала Happiness Metric для идентификации и приоритизации процессных улучшений. Они спрашивали друг друга: “По шкале от 1 до 5 оцени: (1) Как вы относитесь к своей роли в компании? (2) Как вы относитесь к компании? Затем участники команды делились тем, что заставит их чувствовать себя лучше, затем они использовали Planning Poker для оценки ценности улучшений. Также команда оценивала ценность (не стоимость) элементов Бэклога. Команда оценила весь Бэклог Продуктасуммарно около 50 баллов ценности.
Элемент “Улучшить пользовательские истории” имел наивысший приоритет улучшения для команды. Команда оценила, что устранение этого препятствия даст более 60 баллов ценности. Главный Владелец Продукта из Команды Владельца Продуктазадавался вопросом, может ли устранение этого препятствия удвоить скорость (velocity), так как его ценность была выше, чем ценность всего Бэклога Продукта для Спринта. Владелец Продуктапоместил элемент “Улучшить пользовательские истории” в Бэклог Продукта и разработчики выбрали его в следующий Спринт с Критериями Готовности (Definition of Done). Команда определила этот Definition of Done как приемочные тесты, имеющие метрики, которые они могут посчитать на следующем Обзоре Спринта. Метрики включали в себя:
- Сколько историй попало в Спринт, которые не соответствовали критериям INVEST (незамедлительно действующие, обсуждаемые, ценные, оцениваемые, небольшие и проверяемые)? Там не должно быть ни одного.
- Сколько раз разработчикам приходилось обращаться к Владельцу Продукта, чтобы уточнить PBI (Элемент Бэклога Продукта) во время Спринта?
- Сколько раз зависимости блокировали PBI во время Спринта?
- Сколько историй имели эффективность процесса более 50 процентов? (Эффективность процесса = фактическое рабочее время / календарное время)
- Сколько историй были непонятны для Разработчиков? Измеряется по количеству членов команды разработки, которые жаловались на PBI.
- Сколько историй подразумевает техническую реализацию, а не уточнение желаемого пользовательского опыта?
- За сколько историй Разработчики поняли связь между PBI, темой, которая породила этот PBI, эпик, сгенерированный эту тему и бизнес-потребностью, которая стоит за этим эпиком? Измеряется количеством членов команды, жалующихся, что они не понимают, почему они делают PBI.
Несмотря на то, что улучшение качества пользовательских историй никогда не заканчивается, Обзор Спринта показал значительное в этом элементе бэклога, что было измерено с помощью приемочных тестов. Значительное улучшение привело к увеличению скорости после нескольких Спринтов. После того, как скорость удвоилась, это препятствие упало с вершины списка препятствий, и его место заняло другое.
График ниже показывает скорость команды, работающих недельными Спринтами. В Спринте 86 (около 27 декабря 2010 года) команды выросла в размере. Со Спринта 89 “Улучшение пользовательских историй” стало элементом бэклога каждого Спринта. В течение трех Спринтов скорость более чем удвоилась. Команда поняла, что в среднем 10-процентное увеличение скорости в Спринт в последующих Спринтах произошло с помощью Scrumming the Scrum.
Некоторые команды предпочитают явно поместить элемент улучшения процесса в верхнюю часть Бэклога Продукта вместо того, чтобы сразу же помещать его в Бэклог Спринта. Это подчеркивает, что рабочие препятствия – это настоящая работа, а что-то, что делают разработчики на полях. Это также официальное подтверждение того, что Владелец Продукта учел стоимость и ценность работы.
