StepanJac626
New member
Я больше десяти лет работаю в IT: был разработчиком, тимлидом и продактом. Скрам видел в разных командах — от стартапов до крупных корпораций. Поэтому вопрос «польза или пережиток» для меня не теоретический: я не раз наблюдал, как один и тот же фреймворк давал совершенно разные результаты.
Нажать чтобы Перейти на сайт
В лучших командах Скрам работал как усилитель. Короткие спринты помогали чаще показывать результат, ретроспективы — честно обсуждать проблемы, а роли и артефакты создавали прозрачность. Мы не тратили месяцы на согласование огромного ТЗ, а проверяли гипотезы небольшими инкрементами. В такие моменты Скрам ощущался не ритуалом, а рабочим инструментом.
Но чаще я видел другую картину. Спринты становились самоцелью, дейли превращался в отчёт для менеджера, а ретроспектива — в формальность без изменений. Если бизнес всё равно требует «сделать всё к пятнице», а Product Owner не имеет полномочий, Скрам превращается в театр. Тогда люди справедливо говорят: это пережиток.
В одной моей команде мы честно попробовали жить по Скраму. Первые полгода были прорывом: предсказуемость выросла, баги ловили раньше, релизы ускорились. Но потом добавили несколько срочных проектов, и спринты начали ломаться. Мы не стали цепляться за догму, а оставили только то, что реально помогало: короткие синки, демо, ретро и ограничение незавершённой работы. Остальное убрали.
Узнать подробнее →
Мой вывод такой: Скрам не польза и не пережиток сам по себе. Это набор практик, который либо решает ваши проблемы, либо создаёт новые. Он полезен там, где есть доверие, автономия и готовность меняться. И становится пережитком там, где его используют для контроля и отчётности. Как и любой инструмент, он не заменяет здравый смысл.
А вы в своей команде используете Скрам потому, что он помогает, или потому, что так принято?
По теме советую почитать: Монетизация IT-продуктов: от идеи до первой прибыли
Нажать чтобы Перейти на сайтВ лучших командах Скрам работал как усилитель. Короткие спринты помогали чаще показывать результат, ретроспективы — честно обсуждать проблемы, а роли и артефакты создавали прозрачность. Мы не тратили месяцы на согласование огромного ТЗ, а проверяли гипотезы небольшими инкрементами. В такие моменты Скрам ощущался не ритуалом, а рабочим инструментом.
Но чаще я видел другую картину. Спринты становились самоцелью, дейли превращался в отчёт для менеджера, а ретроспектива — в формальность без изменений. Если бизнес всё равно требует «сделать всё к пятнице», а Product Owner не имеет полномочий, Скрам превращается в театр. Тогда люди справедливо говорят: это пережиток.
В одной моей команде мы честно попробовали жить по Скраму. Первые полгода были прорывом: предсказуемость выросла, баги ловили раньше, релизы ускорились. Но потом добавили несколько срочных проектов, и спринты начали ломаться. Мы не стали цепляться за догму, а оставили только то, что реально помогало: короткие синки, демо, ретро и ограничение незавершённой работы. Остальное убрали.
Узнать подробнее →Мой вывод такой: Скрам не польза и не пережиток сам по себе. Это набор практик, который либо решает ваши проблемы, либо создаёт новые. Он полезен там, где есть доверие, автономия и готовность меняться. И становится пережитком там, где его используют для контроля и отчётности. Как и любой инструмент, он не заменяет здравый смысл.
А вы в своей команде используете Скрам потому, что он помогает, или потому, что так принято?
По теме советую почитать: Монетизация IT-продуктов: от идеи до первой прибыли