Чтобы ответить на этот вопрос, вначале давайте ответим, почему Скрам стал таким популярным фреймворком в Software development?
Большинство людей скажут, что залог успеха в его простоте. И будут правы.
Скрам гайд помещается, примерно, на 10 страницах (привет PMBoK), а в нём самом простые церемонии и правила.
Поэтому многие компании и команды внедряют Скрам быстро и просто.
Но тут кроется большое заблуждение.
И Скрам, на самом то деле, куда сложнее внутри (попробуйте сдать PSM I просто прочитав пару раз гайд (про PSM II и III вообще молчу)) и внедряют 99% не Скрам, а лишь его элементы.
Многие ошибочно думают, что Скрам это гибкий фреймворк.
"А разве не так?" - спросят многие - "Он ведь относится к Agile. А это про гибкость."
Скрам, на самом деле, это жесткий набор правил и настоятельных рекомендаций.
Дейлики растягиваются до 30 минут - нет, это не Скрам.
Решили скипнуть ретро, так как команда вымотана в конце спринта - нет, это не Скрам.
РО решил сам погрумить задачи без команды - нет, это не Скрам.
Нет Скрам мастера - нет, это не Скрам.
Сделали шаг влево от гайда - нет, это не Скрам.
Соблюдать все обязательные пункты и следовать рекомендациям Скрам гайда 99% командам сложно (а иногда просто и невозможно), но без этого, Скрам гайд говорит: «У вас не Скрам».
И тут есть один нюанс: у 99% команд не Скрам, но все при этом все они как-то работают. Ведут разработку. Добиваются каких-то результатов.
Я видел команды, у которых от Скрама были только дейлики (растянутые иногда до часа) и спринты (каждый раз с разной длительностью). Но при этом, они говорили, что работали по Скраму и умудрялись деливерить приличный результат.
Да, Скрам подойдет не всем, не каждой компании/команде. Но его в чистом виде и нет почти нигде.
Зато его элементы есть повсюду. И по отдельности они тоже отлично работают и помогают достигать целей.
Жалко, что такое подход Скрам запрещает называть Скрамом.
Дак в чем же сложность?
Один из главных факторов, создающих сложности для многих команд, - это его философия.
1.Сложность для новичков и неподготовленных команд:
Философия Scrum предполагает высокую степень самоорганизации, коллаборации и обучения на практике. Для команд, которые только начинают свой путь с Agile-подходами, внедрение Scrum может быть сложным. Новым участникам может быть трудно понять ценности Agile и адаптировать свои повседневные практики под принципы Scrum.
2. Ограниченная применимость в некоторых ситуациях:
Хотя Scrum может быть эффективным для большинства проектов, существуют определенные сценарии, в которых он может быть ограничен или неэффективен. Например, проекты с высокой степенью неопределенности или постоянно меняющимися требованиями могут столкнуться с трудностями в применении строгих рамок Sm.
3. Проблемы масштабирования на большие проекты и в организации с несколькими командами:
Scrum хорошо работает в небольших и средних проектах, но его масштабирование на более крупные проекты или в организациях с несколькими командами может быть сложным. Управление зависимостями между командами и согласование общих целей может стать вызовом.
4. Ограничения гибкости, особенно в отношении быстрой реакции на изменения:
Scrum предоставляет структуру и предсказуемость через итеративные спринты, что обеспечивает стабильность в процессе разработки. Однако, из-за строгих временных рамок и внесения изменений только в конце спринта, командам может быть сложно быстро реагировать на неожиданные изменения.
5. Проблемы с коммуникацией и координацией внутри команды и между командами:
Scrum подразумевает тесное взаимодействие между членами команды и активную коммуникацию. В больших командах или в организациях с несколькими командами может возникнуть сложность в поддержании эффективной коммуникации и координации между всеми участниками.
6. Отсутствие формальной документации может привести к проблемам в передаче знаний и управлении знаниями:
Scrum ставит акцент на рабочие продукты над полной документацией, что может затруднить передачу знаний и опыта между участниками команды. Это особенно актуально в ситуациях с переходами участников команды или в проектах с высоким уровнем сложности.
7. Недостаточное внимание качеству продукта из-за упора на быструю доставку работающих продуктов:
Из-за фокуса на доставку работоспособного продукта в конце каждого спринта, некоторые команды могут уделить недостаточно времени тестированию и обеспечению качества. Это может повлиять на стабильность и надежность окончательного продукта.
8. Не всегда подходит для проектов с жесткими временными рамками или высокой степенью неопределенности:
Scrum предполагает гибкость, но в проектах с строгими временными ограничениями или когда требования меняются ежедневно, использование Scrum может быть сложным или неприменимым.
9. Сложности оценки и планирования, особенно при работе с неопределенными или новыми задачами:
Scrum предполагает оценку и планирование на основе опыта команды, что может быть сложным, если команда сталкивается с новыми технологиями или неопределенными задачами.
10. Трудности в изменении рабочей культуры и привычек команды для соответствия принципам Scrum:
Внедрение Scrum требует изменения рабочей культуры и привычек команды. Это может быть вызовом, особенно в случае, если участники команды привыкли к другим методологиям разработки.
В заключение, фреймворк Scrum имеет ряд недостатков, связанных с его сложной философией. Сложность для новичков, ограниченная применимость в некоторых ситуациях и трудности масштабирования являются главными проблемами, которые могут возникнуть при использовании Scrum. Несмотря на его популярность, командам следует тщательно рассмотреть свои потребности и реальные возможности перед принятием решения внедрять данный фреймворк.
