Скрам, вероятно, есть противопожность семье в толстовской репрезентации: бОльшая часть проблем скрама идентична, и лишь счастье от него приводит компании к разным финансовым результатам.
У нас тоже вызывает недоумение необходимость стэндапов. В опенспейсе их необходимость мала. Но, подневольным нам, приходится ходить на них. Очень редко мы можем уложиться в пол-часа. И это бесит. Я думаю, что основная и единственная цель стэндапа — самоорганизация на основе совестливости команды, недостижима. Кому работать тот работает. Не скажу, что стэндапы не поднимают каких-то важных проблем или не дают быстрого решения тому, кто попал в тупик мысли, однако это редкость. Мне лично проще повернуться и громогласно попросить помощи, если надо. Может быть тут важно, что я не стесняюсь этого, но тут ведь персональное дело.
Вопрос необходимости скрама как стиля работы актуален для всех. Ведь это решение для бизнеса, а не для людей. Развитие и карьерные перспективы тут убиваются самим принципол полной и мгновенной заменимости любого члена команды.
Скрам сосвсем не способен решить вопрос контроля качества. Сазерленд прямо говорит о необходимости отсутствия команды QA. Наш очень долгий опыт показывает, что команда QA поднимает качество продукта на недостижимую юниттестами и code review высоту. То есть это преднамеренная потеря качества.
Как это ни глупо, но скрам рождает гораздо больше менеджмента, чем иерархическая структура. Возможно, это актуально только для интернациональных распределенных команд, но для нас это актуально.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Беды борьбы и управления бэклогом у всех, очевидно, одинаковы и набили аскомину. Исторически у нас сложилось игнорирование эпиков и формирования карманов из неактивных спринтов, что отвратительно, но есть. Возможно кто-то решает это эффективнее. Возможно для небольших проектов вроде клиент-банка такой беды и нет, но для большого прокукта с историей она остра.
Ну и самое смешное, что в конце спринта мы никогда не имеем рабочег продукта. Нам надобится дополнительный спринт на тестирование и залатывание програмных дыр в конце релизного цикла.
Ретроспектива еще одна забытая и бесполезная штука. Я не видел улучшений независящих от команды, наверное, никогда. По идее скрам-мастер должен решать остальное, но у нас его нет. Видимо, в этом=то вся беда и кроется.
Если подытожить, то я никак не вижу радости от внедрения скрама.
У нас тоже вызывает недоумение необходимость стэндапов. В опенспейсе их необходимость мала. Но, подневольным нам, приходится ходить на них. Очень редко мы можем уложиться в пол-часа. И это бесит. Я думаю, что основная и единственная цель стэндапа — самоорганизация на основе совестливости команды, недостижима. Кому работать тот работает. Не скажу, что стэндапы не поднимают каких-то важных проблем или не дают быстрого решения тому, кто попал в тупик мысли, однако это редкость. Мне лично проще повернуться и громогласно попросить помощи, если надо. Может быть тут важно, что я не стесняюсь этого, но тут ведь персональное дело.
Вопрос необходимости скрама как стиля работы актуален для всех. Ведь это решение для бизнеса, а не для людей. Развитие и карьерные перспективы тут убиваются самим принципол полной и мгновенной заменимости любого члена команды.
Скрам сосвсем не способен решить вопрос контроля качества. Сазерленд прямо говорит о необходимости отсутствия команды QA. Наш очень долгий опыт показывает, что команда QA поднимает качество продукта на недостижимую юниттестами и code review высоту. То есть это преднамеренная потеря качества.
Как это ни глупо, но скрам рождает гораздо больше менеджмента, чем иерархическая структура. Возможно, это актуально только для интернациональных распределенных команд, но для нас это актуально.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Беды борьбы и управления бэклогом у всех, очевидно, одинаковы и набили аскомину. Исторически у нас сложилось игнорирование эпиков и формирования карманов из неактивных спринтов, что отвратительно, но есть. Возможно кто-то решает это эффективнее. Возможно для небольших проектов вроде клиент-банка такой беды и нет, но для большого прокукта с историей она остра.
Ну и самое смешное, что в конце спринта мы никогда не имеем рабочег продукта. Нам надобится дополнительный спринт на тестирование и залатывание програмных дыр в конце релизного цикла.
Ретроспектива еще одна забытая и бесполезная штука. Я не видел улучшений независящих от команды, наверное, никогда. По идее скрам-мастер должен решать остальное, но у нас его нет. Видимо, в этом=то вся беда и кроется.
Если подытожить, то я никак не вижу радости от внедрения скрама.