Почему Scrum иногда не работает и что с этим делать

Среди ваших знакомых наверняка есть люди, которые попробовали Scrum и решили отказаться. Возможно вы сами были в такой ситуации. Я обучался скраму у Джима Коплина, внутреннего тренера Microsoft, в Швеции. Работал в нескольких компаниях, в которых всё было по скраму. А так же в тех, где использовали классические методологии разработки. В этой статье я расскажу свои наблюдения и постараюсь раскрыть тайну скрама, почему же многим он так и не даётся. Читайте под катом.

Что такое Scrum? Зачем он нужен и какие преимущества даёт? Это важные вопросы, потому что многие начинают использовать Scrum как дань моде, но это инструмент, и довольно специфический. Прежде всего это гибкая методология разработки, позволяющая относительно легко адаптироваться к активно меняющимся требованиям. Приведу пример: на одном проекте решили делать классическое многостраничное приложение для видео, через пару месяцев наверху решили делать одностраничное, половину кода пришлось выбросить, половину переписать. Ещё через пару месяцев решили, что нужно делать не только для видео, но и для картинок, а это влечёт полную переработку дизайна. Ещё через некоторое время сменился главный дизайнер и высшее руководство, и у нового были свои представления насчёт того, как и что нужно делать. Это не считая регулярных правок и довольно фундаментальных изменений от отдела маркетинга, который тестировал макеты на реальных пользователях и постоянно что-то менял в зависимости от пользовательской обратной связи. Да, пожалуй в этом случае Scrum нужен, так как он даёт ту самую гибкость. Более того, это единственный возможный путь существования такого проекта. Безусловно есть потери времени на стендапы, ретроспективы и т.п., безусловно совместное владение кодом и ограничение на число одновременных задач снижают общую эффективность, но это малая плата за то, чтобы проект стабильно двигался в условиях высокой изменчивости. Scrum создавался не от хорошей жизни, а от необходимости.

Другой пример: веб-студия выполняет свой 50-й проект, это типичный интернет-магазин на популярной CMS. Заказчик хоть и не знает чего хочет, но опытный менеджер направляет его хаотичные мысли в правильное русло, так что появляется и согласованное ТЗ и макеты. Дизайнер в этом месяце сделал уже три таких же проекта и набитой рукой, подключая весь свой креатив, просто делает дело. Его даже не проверяют, потому что знают, что он работает давно и выполняет работу всегда отлично. Верстальщик и программист, одним глазом читая хабр, другим смотря в IDE, монотонно делают привычную работу. Работа сдаётся заказчику, и он, ну надо же, с первого раза не принял, выкатил список правок. Сработает Scrum на таком проекте? Давайте разберёмся. Может менеджер изначально составить план работ? Безусловно может. Может заказчик внезапно отказаться от какого-либо ключевого модуля в середине разработки? Думаю вряд ли, по крайней мере заплатить за уже сделанную работу ему придётся. Даже если не так – такие ситуации случаются довольно редко, скажем, не каждый второй заказ. Могут специалисты на основе предыдущего опыта предположить, как проект будет развиваться дальше и подстраховаться к изменениям? Безусловно, ведь у них большая экспертиза именно в таких задачах. Даже если где-то классический подход даёт сбой – эти потери не настолько большие, чтобы бить в барабаны.

Скрам даёт потрясающую гибкость, но достаётся не бесплатно. Ответьте для своего проекта: а действительно ли у меня настолько большая изменчивость, что мне необходим скрам? Что же делать если на вашем проекте скрам не сработал? Ответ прост: не используйте его, значит для вашего случая он не подходит. Можете почитать труды Тейлора и Друкера, в IT повально недооценивают достижения классического менеджмента. Можете почитать мою статью про то, (рекламная пауза) как выдерживать сроки на проектах, управляемых по классической методологии. Не нужно отказываться от того, что отлично работает при правильной настройке, есть масса классических способов повысить эффективность.

Но конечно всё это не объяснишь своему директору. Когда высший менеджмент видит, что Скрам наладил работу на изменчивом проекте, который иначе никак не двигался — они начинают думать, что это универсальная пилюля. Скрам это прогрессивно и инновационно, и когда ты говоришь, что работаешь по скраму, это звучит круче, чем если ты работаешь по классике. И не важно, что менеджмент в IT (будем честны) находится в зачаточной стадии и сильно отстаёт от менеджмента в других отраслях. Ведь мы даже не научились точно планировать сроки. Но хотим всё новое и передовое, забывая о проверенных и работающих методиках менеджмента, таких как разделение труда, назначение зон ответственности, мотивация, контроль. Бытует миф, что в IT всё по другому, например, совместное владение кодом полезно, потому что повышает bus-фактор. А как же другие отрасли в этим справляются? Чиновники, скажем, не повышают bus-факстор, а наоборот размытая ответственность считается признаком забюрократизированности. Кстати, модный сейчас continuous integration (замечательная вещь) – это всего лишь банальное разделение функций исполнения и контроля, принцип придуманный задолго до нашего рождения и изобретения компьютеров. А скрамовский стендап-митинг – по сути, обычная советская планёрка, проводимая раньше на большинстве предприятий в начале каждого трудового дня. Поэтому, коллеги, читайте классику и критически относитесь к тому, что вам пытаются продать.

Резюмируя: если у вас большая, действительно большая изменчивость на проекте – Scrum сможет поднять эффективность вашей работы. Если вы можете составить план и примерно знаете, что будет через месяц-два – не используйте Scrum, он вам сильно не поможет, но всё равно придётся заплатить, временем, удобством работы и т.п… Ну и конечно используйте здравый смысл, не возбраняется использовать Scrum по частям, если какие-то идеи оттуда кажутся вам интересными и кажется, что будут работать – смело забирайте их и используйте, главное без фанатизма. Надеюсь статья оказажется полезной и поможет в нужный момент выбрать методологию.

P.S.: Всё высказанное в статье является личным мнением автора, наработанным за 10 лет практики разработки программного обеспечения. Многие моменты отличаются от мейнстрима, думайте своей головой и не принимайте ничего за абсолютную истину. Пишите свой совпадающий или противоположный опыт, если есть, в комментариях. И да прибудет с вами удача в скрам-покере и скрам-преферансе!