Компания
29,13
рейтинг
7 марта 2013 в 11:30

Разное → 85 заблуждений и препятствий внедрения гибкой разработки



Термин «скрам-бат» (от «scrum, but..») впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».

Типичные примеры скрам-батов, соответственно, выглядят так:
  • У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
  • У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».

Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.

Если вы уже работаете по фреймворку скрам, или его модификации, возможно, вы найдете полезным этот список для само-диагностики. Попробуйте задать себе вопросы: «Хм, а почему на самом деле у нас так?» и «Что еще мы можем сделать, что бы изменить ситуацию?» на каждый пункт, который относится к вашему процессу.

Мне стало интересно проранжировать этот список и получить топ-лист препятствий, с которыми приходится сталкиваться командам гибкой разработки на русско-говорящем пространстве. Буду благодарна за помощь в этом (анкета с такими же пунктами по ссылке) и обязательно поделюсь результатами. Итак,

С КАКИМИ ЗАБЛУЖДЕНИЯМИ И ПРЕПЯТСТВИЯМИ ПРИХОДИТСЯ СТАЛКИВАТЬСЯ КОМАНДАМ В AGILE/SCRUM ПРОЕКТАХ


ПРОЦЕСС

  1. Команда не уполномочена или не информирована о том, что может менять свой процесс разработки
  2. В команде недостаточно смелости для качественного изменения процесса
  3. В команде недостаточно усердия для следования принятым изменениям
  4. Нет списка проблем и систематической работы над их устранением
  5. Не выделяются инвестиции (время, деньги) для работы над проблемами
  6. Длина спринта увеличивается в его ходе или часто меняется
  7. Работа разбита на фазы, каждая из которых выполняется за один спринт (“water-scrum-fall”)
  8. Команда регулярно оветаймит, что бы достичь цели спринта или выполнить беклог полностью
  9. Непостоянный ритм разработки с паузами между спринтами
  10. Нет договоренностей о рабочем процессе (Working agreements)
  11. При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи
  12. На поддержку функционирующего продукта не выделены отдельные люди или время команды
  13. Ограничения приобретенного инструмента обуславливают процесс (Jira, TFS, etc.)

ПРОДУКТ

  1. Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)
  2. Видение продукта, цели релизов и спринтов не донесены до всех членов команды
  3. Цели итераций не корректируются на основании обратной связи от рынка (после выхода в live)
  4. Беклог продукта содержит конкретные способы реализации
  5. Беклог продукта не отображает ценность элементов в нем
  6. Беклог продукта содержит большие истории (размером в полспринта), команда не умеет разбивать их на более мелкие

ТЕХНОЛОГИИ

  1. Критерии Готовности (Definition of Done) не определены или не донесены членам команды
  2. Отсутствие или слабое использование инженерных практик (CI, Code Review, Refactoring, TDD, etc.)
  3. Члены команды комитят код без проверки работоспособности билда
  4. Работы по тестированию не включены в один спринт с разработкой
  5. Тестирование не автоматизировано

ВЛАДЕЛЕЦ ПРОДУКТА

  1. Владелец Продукта недоступен по ходу спринта
  2. У Владельца Продукта недостаточно времени для работы со всеми командами в достаточном объеме
  3. У Владельца Продукта нет власти для принятия решений
  4. Есть несколько Владельцев Продукта для одной команды
  5. Приоритеты Владельца Продукта не построены на основе стратегии обучения и бизнес-ценности
  6. Владелец Продукта стремится реализовать все фичи, не используя принцип Парето для работы с беклогом
  7. Владелец Продукта — босс Скрам-Мастера
  8. Владельца Продукта не приглашают на ретроспективу
  9. У Владельца Продукта нет доступной команды для поиска лучших способов реализации историй (Product Discovery Team: PO, UX, Architect)
  10. Владелец Продукта не знает своих ключевых пользователей и клиентов
  11. Владелец продукта не дает обратную связь команде

СКРАМ-МАСТЕР

  1. Нет выделенного Скрам-Мастера или он меняется каждый спринт
  2. Скрам-Мастер находится в другой локации чем команда
  3. У Скрам-Мастера недостаточно знаний в области гибкой разработки (принципов, ценностей, практик)
  4. У Скрам-Мастера недостаточно социальных навыков (soft skills) для работы с людьми
  5. У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile
  6. Скрам-Мастер является техническим лидером и диктует свои решения команде
  7. Скрам-Мастер “по-совместительству” выполняет роль Владельца продукта
  8. Один Скрам-Мастер работает более чем на 3-4 команды

КОМАНДА

  1. Нет общей цели (продукта, релиза, спринта)
  2. Нет ощущения того, что все “плывут в одной лодке”
  3. Члены команды имеют глубокую специализацию и слабое представление о работе своих коллег
  4. Команда разработки разделена на специализированные под-команды по компонентам/слоям
  5. Состав команды изменяется по ходу спринта
  6. Члены команды параллельно работают над другими проектами
  7. Члены команды поощряются/наказываются индивидуально

ЕЖЕДНЕВНАЯ РАБОТА

  1. Дейли митинги проходят несистематично и/или с опозданиям
  2. Дейли-митинг проводится сидя, за рабочими местами
  3. Команда разработки на Дейли отчитывается Скрам-Мастеру или Владельцу Продукта
  4. Технические и бизнес-решение обсуждаются в ходе Дейли, затягивая этот митинг более чем на 15 минут
  5. В распределенной команде проходят отдельные Дейли по локациям
  6. Команду отвлекают в ходе проведения встречи (Планирование, Дейли, Ретро, Демо)
  7. Члены команды отвлекаются на гаджеты на встречах
  8. Команда работает над беклогом в произвольном порядке, не учитывая приоритеты Владельца Продукта

ПЛАНИРОВАНИЕ

  1. Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)
  2. Фокус командного комитмента в ходе планирования направлен на беклог спринта, а не на его цель
  3. Команда договаривается кто над какими задачами будет работать в ходе спринта
  4. Незавершенная работа прошлого спринта автоматически переходит на следующий

ДЕМОНСТРАЦИЯ

  1. Регулярно есть незавершенная работа в конце спринта
  2. Нет формальной оценки “успешных” и “не успешных” спринтов
  3. Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта
  4. В реализованных историях есть баги, при этом они считаются завершенными
  5. Демонстрации проходят без подготовки, нет структуры встречи
  6. Команда разработки презентует результаты спринта всегда только Владельцу Продукта

РЕТРОСПЕКТИВА

  1. Обвинения и поиск виновных имеют место в ходе встречи
  2. В конце Ретроспективы нет плана действий с датами и именами ответственных
  3. Слишком много изменений в ходе одной итерации
  4. Нет метрик и способа оценки изменений в процессе
  5. Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч
  6. Проблемы идентифицируются, есть план действий, но нет самих действий


МЕНЕДЖМЕНТ

  1. Есть менеджер проекта, отвечающий за успешность его реализации перед высшим руководством компании
  2. Менеджмент не понимает сути командных оценок и от команды требуют “выполнить обещание”
  3. Есть девелопмент-менеджеры, релиз-менеджеры, скрам-менеджеры и другие типы менеджеров, ответственные за выделенную часть работы
  4. Менеджеры используют командные артефакты как оценку и ожидают получить “красивые” диаграммы (burndown) и скорость (velocity)
  5. Менеджеры имеют давление на Скрам-Мастера и “выжимают” скорость работы команды через него
  6. Насильственное внедрение Scrum менеджментом, который не следует принципам и ценностям Agile

РАБОЧЕЕ ПРОСТРАНСТВО

  1. Нет удобных средств организации коммуникаций в распределенной команде
  2. Неудобное пространство для организации командных встреч
  3. Офис в формате open space с перегородками на столах
  4. Неудобное помещение для парной работы

Если вы дочитали до этого места — снимаю шляпу! Тогда, возможно, вы хотели бы добавить что-то еще к этому списку? Вы можете сделать это в анкете, правда, ее заполнение займет еще минут 5-ть :) Но благодаря вашей инвестиции времени, мы сможем получить интересную информацию к размышлению и действиям. Нет времени заполнять?) — Просто оставьте комментарий к статье.

Если вы хотите оспорить некоторые пункты списка — боюсь, мне будет не с чем поспорить: ваш контекст лучше вас никто не знает. Эти пункты появились потому, что имели место в командах, с которыми нам в SCRUMguides, или нашим коллегам приходилось работать.

К тому же, споры по 85-ти пунктам, просто не по зубам моим запасам свободного времени :) Но я с удовольствием пообщаюсь лично (skype, почта) и постараюсь ответить тем, кто заполнил форму и/или хочет пообщаться о ситуации в команде в формате коучинга.
Автор: @Natatara
SCRUMguides
рейтинг 29,13
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (26)

  • +1
    «Скрам-бат» странно звучит, но «скрам-но» звучит еще хуже :) Может писать «scrum-but»?
    • +1
      Как ни пиши — на деле оно не лучше, чем звучит :) Но я попробую…
    • +3
      scrum-butt
    • 0
      недоскрам ;)
    • 0
      Если попытаться более гибко перевести, то
      «типа-скрам»
      «скрам-только...»
  • 0
    Например, в аутсорсинге проектов из США, иногда назначают скрам-мастера там, поближе к Владельцу Продукта, что бы удобно было через него отжимать команду. В результате вместо «дейли» получаем 40-минутные статус-отчеты по скайпу, и другие «но»
  • 0
    Если выполнить все эти требования, стоимость разработки вырастет примерно в 3-5 раз по сравнению с комплектом PO+команда. Увеличится ли эффективность в пять и более раз?
    • 0
      В английском языке есть понятия efficiency и effectiveness, по-нашему это эффективность и продуктивность. Будет ли команда работать эффективнее — не возьмусь утверждать. Но вы с большей вероятностью построите качественный продукт, нравящийся пользователям и ценный для рынка — в случае, если ваша идея хороша и своевременна. Либо потратите меньше сил и денег на ее проверку.

      Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
      • 0
        Это всё круто, но насколько «продуктивность» будет выше в сравнении с затратами? Просто для понимания реалий — scrum-master — это такой профан, который носится по конторе с своей «библией», отрывает людей от работы и требует соблюдения идиотских правил, даже если ради этого придётся пожертвовать результатом. Рядом есть PO, который срать хотел на заморочки программистов и который не может понять как программист не может понять разницы между маршрутизируемой сетью и канальным сегментом (или дерюгой и вельветом, если хотите), рядом есть программисты, которые частично ощущают, что их не достаточно ценят, частично хотят попробовать новый фреймворк в деле, а рядом есть начальник, которого всё это мало волнует и интересует «мы решили, что запуск нашего нового убийцы Найк произойдёт в первом квартале 2012, уже 2013, и?».

        Хорошо, когда полные энтузиазма люди делают правильные вещи, которые точно покупаются, кредиты дешёвые, все друг друга хорошо понимают и поддерживают и никто не умирает.

        Реальная жизнь чуть-чуть другая, и чем глубже методология, тем больше она требует для себя. А что она даёт взамен? То, что она даёт в замен имеет эквивалентную рыночную стоимость?
        • +1
          От профанов с библией ни одна методология не спасает. К слову говоря, библия PMBook значительно толще 10-ти правил скрам.

          Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:

          Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.

          Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.

          Про жизнь я в курсе :) Честно говоря, работая в формате коучинга, я не всегда понимаю — какие именно действия привели к этому результату, но изменения в процессе, команде и ее продуктивности бывают разительны. Спасибо за ваш коментарий, я поняла какие вопросы задать в последних компаниях, с которыми работали в последнее время.

          • –1
            Вы пропустили вопрос: насколько «продуктивность» будет выше в сравнении с затратами?
            • 0
              Для небольших команд ведущих беспорядочную разработку, как моя бывшая можно получить прирост 2-3 раза 8))))
              • 0
                Небольшая команда, это сколько? Допустим, два программиста.

                К двум программистам мы теперь добавляем scrum master'а, product owner'а, и имеем двухуратный прирост. При двухкратном росте затрат, так?
                • 0
                  4 человека
                  прирост будет если у вас очень не систематизированная разработка, если взять скажем команду из двух человек, у которых есть четное тз по реализации, с обратной связью, континьюс интегрейшен, гит и всякие плюшки, то тут конечно особого прироста не увидеть в производительности, но есть большая вероятность получить более качественный продукт на выходе.
                  Скрам я бы назвал хорошим для неорганизованных команд, чтобы начать организовываться.
                  Ваш случай тоже утрирован и в целом ваше недовольство ответами мне понятно.
                  Но опять таки если разработка заказная то овнером должен стать представитель заказчика, а скрам мастером может быть один из разработчиков. Хотя я конечно могу и во всем ошибаться.
                  Внедрять скрам я бы стал пробовать если есть проблемы разработки, если их нет то у вас и так все хорошо.
                • 0
                  Я ждала конкретного примера, спасибо. В описанном вами случае прироста производительности не будет.

                  В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).

                  При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.

                  В команде из двух человек нет потребности в формальном скрам-мастере, но стоит обучить обоих участников, что бы их понимание гибкой разработки было общим. В такой команде нет необходимости в выделенных 15-минутках, но стоит обратить внимание на распределение задач командой и сделать процесс планирования и принятия ответственности максимально общим — тогда им будет о чем говорить по мере необходимости.

                  Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
  • 0
    Я было думал, что у нас уже почти идеальный скрам… Оказывается, есть куда еще совершенствоваться.
  • 0
    Agile — это религия. (© не помню, кто первый эту мысль высказал)
    • 0
      В таком случае это религия опыта. Пока не попробуешь — кажется что не сработает. Быстро попробуешь — тоже не сработает. Многие из пунктов появляются как раз в результате внедрения «на скорую руку». А без понимания что и зачем поменять, кропотливого оттачивания процесса тут не обойтись. На и да, евангилизм — это часть работы. Как в продуктах так и в процессах.
      • 0
        Я скорее всего не прав, но вот что мне видится:

        1. На внедрение Agile требуется время, много времени
        2. Всё это время разработка происходит менее продуктивно за счёт «втягивания» и оттачивания техники
        3. Оттачивание техники Agile отвлекает непосредственно от работы
        4. Сроки разработки увеличиваются, а значит и стоимость проекта возрастает

        Кроме того:

        5. Высший менеджмент компании не в курсе, что такое Agile, они лишь решили попробовать что-то новенькое, что обещает повысить эффективность
        6. Эффективность снижается на неопределённый срок
        7. «Вернём как было, а то сроки-то не резиновые!»

        Таким образом, мои выводы:

        1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
        2. В небольших фирмах и для новых проектов это может действительно дать результат
        3. Среди имеющихся менеджеров и прочих сотрудников фирм вряд ли легко найдутся «пропитанные духом Agile», что потребует найма новых людей в команду, которые опять же на время «вникания в проект» на более-менее руководящей должности снизят эффективность
        4. Так и бросят сие благое начинание

        Опять же, во многих крупных фирмах это работает, из чего я делаю вывод, что руководство там выделило достаточно времени, денег и терпения/понимания для достижения такого результата.
        • 0
          Вы правы, по крайней мере на мой взгляд.

          По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
        • 0
          1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
          2. В небольших фирмах и для новых проектов это может действительно дать результат.


          Не знаю насчет перевода уже имеющихся больших проектов на эджайл, не сталкивался. Но насчет новых — я за последние 5 лет работал на нескольких крупных проектах, везде — эджайл. Современный крупный проект невозможно (или неэффективно) вести методом ватерфолла — оттого эджайл и распространился.
          На мелких проектах эджайл — лишняя возня с размазыванием работы по спринтам.
          • 0
            Думаю, вы говорите конкретно о скрам? На мелких проектах лучше работает канбан (чуть выше об этом писала). Визуализация потока работ, фокус на ценности работы, уход от детальной заготовленной наперед спецификации — будут оправданы.
            • 0
              Да, мы скрамим. В позапрошлом году пытались что-то канбанить, но это прошло мимо меня, и насколько оно было эффективно, судить не могу.
  • +1
    Мне кажется, что команд, которые внедрили на 100% scrum можно пересчитать по пальцам.
    Все-таки Agile это методология, и в рамках своего типа деятельности (сектора) ты подстраиваешь его под себя.
    Конечно в этом случае разбрасываться фразой «А у нас в компании scrum» не стоит.
  • +1
    Некоторые пункты слишком теоретические и притянуты за уши:

    В команде недостаточно усердия для следования принятым изменениям
    В команде недостаточно смелости для качественного изменения процесса


    Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.

    При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи


    У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.

    Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)


    Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.

    Беклог продукта не отображает ценность элементов в нем


    Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.

    Владельца Продукта не приглашают на ретроспективу


    И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.

    Нет выделенного Скрам-Мастера или он меняется каждый спринт


    Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.

    У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile


    Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.

    Один Скрам-Мастер работает более чем на 3-4 команды


    Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.

    Дейли-митинг проводится сидя, за рабочими местами


    В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.

    В распределенной команде проходят отдельные Дейли по локациям


    А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…

    Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)


    Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.

    Команда договаривается кто над какими задачами будет работать в ходе спринта


    Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.

    Регулярно есть незавершенная работа в конце спринта


    Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.

    Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта


    Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.

    Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч


    Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
  • 0
    Наши менеджеры называют это «адаптивный скрам». )

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное