Почему не работает SCRUM 25.02.2016


Методология Scrum эффективна только при внедрении всех описанных в ней приемов. На первый взгляд все, что предлагает Scrum внедрить не так сложно, однако на практике получается обратное. Вроде и Scrum, но не совсем, да и результат какой-то не такой.

Как правило, решив применить Scrum на практике, компания или команда в первую очередь заимствует только имиджевые черты методологии — те, которые сразу бросаются в глаза и могут пустить в них пыль. Однако, внедрив все по списку (ежедневные stand up — собрания и ретроспективу, Scrum-доску ,оценку задач, разбиение процесса разработки на спринты, обратную связь и т.д.), получить волшебный прирост производительности, обещанный гуру методологии Scrum, не получается.

Здесь я рассмотрю некоторые проблемы, с которыми мне пришлось столкнуться на практике.

Ежедневные Scrum-митинги организуются не только для того, что бы отчитаться о проделанной работе. Методология Scrum предполагает, что все участники должны внимательно слушать друг друга, а не просто ждать своей очереди для выступления, и, в случае возникновения у одного из участников проблемы с той или иной задачей, помочь с ее решением. Препятствия, с которыми сталкивается команда, обсуждаются и оперативно устраняются.

На практике же часто бывает, что отчетность действительно оказывается единственным назначением ежедневных встреч. В результате все концептуальные идеи stand up-митинга, призванные увеличить эффективность команды и обеспечить ее “разгон”, не работают — участники не слушают друг друга, а проблемы, с которыми сталкивается команда, могут оставаться без внимания долгое время.

Scrum предполагает итеративный подход к разработке, при котором объём пула задач для реализации определяется скоростью разработки и сроком итерации. Реальность часто оказывает влияние и на это предположение. Длительность спринта не является постоянной и в отличие от концепции Scrum является величиной, производной от пула задач, запланированных для реализации в рамках итерации. На первый взгляд различия не выглядят принципиальными, однако контроль эффективности разработки для спринтов разной длительности заметно усложняется. Необходимость назвать сроки выполнения пула задач (релиза) как результат планирования делают оценку задач в человеко-часах более подходящей, а учёт сложности чем то бессмысленным. Отказ от оценки относительной сложности задач в свою очередь делает невозможным подсчёт скорости и контроль ускорения разработки от спринта к спринту.

В результате получается, что многие компании, утверждающие, что при разработке используют Scrum, на деле используют что то другое — свою собственную методологию, — да, Agile, но не Scrum, ведь cистема определяется не только тем, что она рекомендует делать, но и тем, как и для чего она рекомендует это делать.

by 25.02.2016