Давайте сравним скрам и «водопад»

С точки зрения управления «водопад» подразумевает довольно сложное администрирование. Много ответственных. Есть главный разработчик. Есть главный тестировщик. Есть главный по коммуникациям внутри проекта. Главный аналитик. Возникает «дерево» людей, которые должны как-то коммуницировать, ими надо управлять. Какой артефакт отражает результат проекта? Незыблемый план проекта. Что в этом плане происходит? Мы выставляем какие-то проценты – задача сделана на столько-то. Определяет это менеджер проекта, он устанавливает правила игры.

При этом риск удачи или неудачи находится в самом конце проекта. Основные риски отнесены на момент, когда проектпора сдавать. До этого момента риски незначительны, мы можем их фиксировать как потенциальные, описывать действия по работе с ними, но у нас всегда слишком мало информации, чтобы точно сказать – мы уже близки к реализации этого риска? Он уже реален или нет? Чаще всего возможна только экспертная оценка.

Что происходит в скраме? Происходит очень большое упрощение администрирования проекта. Там всего три роли: владелец проекта, тот, кто говорит, что ему нужно, и именно он постоянно принимает решения о том, что полученный продукт – это то, что ему нужно или нет. Вторая роль – это скрам-мастер, модератор, помогающий контролировать исполнение правил игры. Третья роль, совершенно новая сущность – команда разработки. Внутри нее нет деления на роли.

Нет никаких формальных тестировщиков, аналитиков, разработчиков. Вся эта работа выполняется, но кто что делаети когда – это коллективная ответственность команды за результат. Претензии могут быть только к команде в целом, но ни к кому-то персонально. Поэтому команда должна перестроить свою работу так, что бы принимать решения. Вы как команда подрядились за спринт, за три недели обычно, сделать определенное продвижение? Ну так давайте. В этой методологии действительно нет ничего нового. Она просто принуждает людей перестраивать свои мозги. Нет никого, за кого можно спрятаться, как за менеджера проекта.

Еще одна интересная черта скрама – продуктивная ретроспектива. В конце каждого спринта собирается проектная команда, обсуждает спринт, и решает, что было удачно, хорошо, и стоит это развивать, а что было плохо. Принимаются решения, что надо исправить, изменить так, чтобы больше подобных проблем не было. Сильная управленческая обратная связь. Кроме того, если берем мы нового человека, то что он за работник, ясно через три недели ровно. Видно все. Важнейший навык работы в команде проверяется немедленно и точно.

Так как скрам предполагает итерационность разработки, а периоды, спринты, очень короткие, то очень высокая степень прозрачности. Мы не занимаемся планированием бесконечного будущего. Возможность изменений закладывается в архитектуру продукта. Есть очень серьезное распространенное возражение против скрама – вы не фиксируете масштаб проекта, границы, цель, пределы. На самом деле это неверно. Все фиксируется. Мы определяем, какую же задачу мы должны решить. Мы фиксируем изменения внутри этой задачи. Если мы начали делать CRM, то мы не станем «вдруг» делать SCM потому что «что-то поменялось». Все это приводит к тому, что надо сразу же очень четко определить цели, очертить, какую задачу же мы решаем. Это накладывает ответственность не только на команду разработки, но и на владельцев продукта. Это позволяет до нуля уменьшить нереализованные требования. Но в этот момент начинают появляться новые требования. Ответственность владельца продукта в том, чтобы не менялись границы требований вообще.

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

Если мы еще не сделали «кубик» – вы можете передумать. Если мы уже сделали и вы приняли, а теперь хотите чтобы мы переделали – это новая работа, иначе нехорошо получается. На каждом этапе мы спрашиваем – ваше мнение не изменилось? Вы все еще хотите эти «кубики»? Это приводит к тому, что риски не накапливаются.

Если изначально мы не определили, что нам нужно, и пытаемся автоматизировать непонятно что, значит, мы не подумали, какие требования к продукту должны быть поставлены. Тогда мы и начинаем отсекать лишнее и формировать требования как нечто, что будет в развитии. Мы за конкретный период времени должны достичь конкретного результата. Если вы, заказчик, хотите получить еще больше результат, мы отнесем его на следующий период времени. Участвуя в этом процессе постоянно, заказчик начинает понимать реальные границы своих требований и объем задачи. Здесь проявляетсяодна из отличительных особенностей скрама – высокая вовлеченность клиента в проект, большой объем общения.

Скрам построен на системе встреч. Их много. У нас трехнедельный спринт. В первый день мы планируем спринт. Два раза в неделю – встречи с бизнес заказчиком. В конце третьей недели происходят две важные встречи: первая – демонстрация, мы показываем, что сделано. Заказчики говорят – то ли это, что хотелось. Вторая встреча– с владельцем продукта. Смотрим на один из немногих артефактор скрама – бэклог, список всех наших задач, который непрерывно ведется, может прирастать и сокращаться. В нем есть толстая красная черта – то, что мы уже сделали и то, что мы точно успеем сделать, это «коробочка». Отдельно – новые требования, но мы их не успеваем сделать за время проекта. В конце каждого спринта идет пересмотр бэклога, полного перечня задач. Что-то удаляется, что-то вносится, расставляются приоритеты.

Степень неопределенности падает к концу проекта. Грамотное тестирование еще более минимизирует риски. Все это дает возможность мониторить отношение бизнес-заказчика к процессу. Мы постоянно в контакте. Надо сказать, что бизнес заказчики очень быстро понимают, что за кажущуюся потерю времени, высокую свою вовлеченность они получают прозрачность и управляемость доселе невиданную. Все проблемы при такой методологии вылезают на свет, причем своевременно.

Если клиент общаться не хочет, и говорит – я вам сейчас расскажу, что мне нужно, а вы потом приходите ко мне с готовым продуктом, то проект практически наверняка обречен на неудачу. Так может не надо нам ввязываться в такой проект? Может быть, стоит объяснить бизнес-заказчику наш подход или отойти в сторону?

Возникает вопрос – где скрам нельзя сделать? Его нельзя делать там, где не нужна прозрачность.

http://www.it.ru/press_center/blog/11110/