печать

Что нужно знать о Scrum?

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

Scrum: возможности & особенности
    Идеальный «климат» для Scrum: гибкие сроки и бюджет; творческий проект; клиент, понимающий суть Scrum и одобряющий этот подход; технически компетентный Product Owner с готовностью и возможностью выполнять свои функции в проекте; сработавшаяся профессиональная ответственная команда с энтузиазмом и низким уровнем эго в работе.

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

 Скрам хорош для нетривиальных, долгих, сложных, развивающихся в процессе проектах.

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

    Короткие итерации позволяют сосредоточить внимание заказчика и команды на конкретной задаче и решить ее с минимальной степенью недопонимания.

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

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

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

Переход на Scrum & Scrum-команда

  Перед решением о переходе на Scrum необходим, тщательный анализа процессов в компании для понимания целей.

  Скрам может работать в одной команде и, напротив, разрушать другую. Для работы по Аgile-подходам, и в том числе по скрам, нужна команда с высоким уровнем ответственности, сработанности и профессионализма. Хорошо, когда Scrum-команда максимально кросс-функциональна.
    Команда выбирает тот подход работы, который удобен ей и эффективен. Но она может быть переведена на скрам и по желанию руководителя. Внедрение Scrum может занять несколько месяцев. Реакция на переход зависит от конкретной команды: скрам может быть встречен с энтузиазмом или с негативом разработчиков. Необходимы разъяснения, обучение, тренинги.

Лучше, если необходимость перехода на скрам назрела в самой команде, а не спущена «сверху» – тогда выше уровень приятия и мотивации. Команда может неявно «сопротивляться» переходу, если процессы работы и так были отлажены и переход навязывается ей как дань моде или желание менеджмента внедрить прогрессивные подходы.

  Руководителю/менеджеру нужно быть готовым к временному ухудшению качества исполнения проектов в период, пока команда переходит на скрам. После адаптации эффективность обычно возрастает.

  Скрам позволяет каждому члену команды понять сроки, планы, последовательность, суть продукта и направление его развития; быть в курсе того, чем занимаются коллеги и выбирать себе задачи из резерва спринта; обновлять свой vision.
    Для Scrum не слишком подходят специалисты, которым важна индивидуальная оценка работы, поскольку оцениваются командные результаты.
    Есть мнения, что по Scrum сложно/невозможно работать в компаниях, где одновременно идет работа над несколькими проектами и не получится создавать стабильные группы для каждого отдельного проекта.
    Скрам помогает определить слабое звено в команде или слабые компетенции каждого разработчика – и совершенствовать подготовку прицельно.
    Команда разработчиков может состоять из 7-9 человек и работать над долгим сложным проектом (полгода, год). Но на практике элементы Scrum могут быть использованы и малыми командами в коротких проектах. Ежедневные обсуждения по трем ключевым вопросам могут выявить, что часть команды в действительности не требуется в маленьком проекте. В небольших проектах скрам полезен тем, что позволяет улучшить внутренние процессы в команде. Опыт применения Scrum очень разнообразный, это предполагается самой сутью гибких подходов.
    С точки зрения личностных особенностей, для Scrum больше подходят «командные игроки»: специалистам необходимо все время находиться в контакте для поиска оптимальных решений и идей для улучшения продукта. Но можно попробовать и развивать специалистов для командной игры, учитывать их особенности, сильные и слабые стороны.

Заказчики & отношения с заказчиками
  В каких проектах и с какими заказчиками подходит Scrum – вопрос открытый и дискуссионный. Нередко говорят, что Scrum не работает при заниженном бюджете проекта, нереалистично оцененных сроках, при низкой квалификации команды и менеджера проекта.
 Работает ли Scrum на государственных заказах – разные отзывы: одни команды говорят, что не работает, а другие – что такие особенности госзаказчика, как постоянные изменения требований, обусловливают необходимость Scrum, поскольку множество итераций и демонстраций позволяют снизить риски.
  Scrum хорош для разработки продукта (ПО) в креативных проектах с высокой степенью неопределенности, поэтому подходит для стартапов и нестандартных проектов.
    Есть мнение, что скрам больше подходит компаниям для работы с собственными продуктами, чем с продуктами заказчиков.

 Скрам хорош для заказчика, который хочет «классно», но не знает, чего и как именно.
  После каждого спринта происходит прирост функциональности, то есть заказчику можно показать готовую протестированную часть продукта, созданную за этот и предыдущие спринты. Таким образом, возможен ранний запуск продукта (сайта, например) с базовой функциональностью. «Оптимально частые» демонстрации тестовых версий проекта с приростом функций дают возможность заказчику и команде свериться и подтвердить правильность исполнения, оговорить то, что нужно учесть в следующих спринтах.

Демонстрация клиенту промежуточной версии продукта один раз за одну итерацию оптимальна: чаще и реже – чревато. Но насколько часто это необходимо, зависит также от уровня взаимопонимания с заказчиком и частоты возникновения новых пожеланий к функциональности.

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


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

    Одним клиентам важно знать, что их продукты будут разрабатываться методично, по фреймворку скрам. Другим это не важно. А третьим это знать не обязательно. Главное – чтобы заказчик вовремя смотрел демонстрации и высказывал соображения, которые нужно учесть в дальнейшей разработке, либо подтверждал, что работа идет в верном направлении.
    Клиент при разработке продукта по Scrum получает важную роль в проекте и постоянно находится в контакте с командой, например, смотрит демо после каждой итерации. Такой режим работы не всем удобен и не со всеми заказчиками будет разумным. Кроме того, при поэтапной оплате клиенту может быть сложно оценить бюджет и сроки единовременно. Однако существенным плюсом для клиента будет возможность быстро запустить продукт с ключевой функциональностью, избежать рисков и затрат на переделку целого продукта.

Нужно иметь в виду, что некоторые клиенты боятся работать по Scrum: боятся роли Product Owner, то есть необходимости принимать решения при планировании работ и после демо; боятся неконкретных бюджетов и сроков; не готовы к возможности сразу модифицировать продукт, быстро отреагировать на отклик пользователей.

     Заказчику либо его представителю (Product Owner) нужно будет принимать много решений при работе по Scrum, поэтому предполагаются ясность видения проекта, право принятия решений, а также высокий уровень компетентности, ответственности и общей адекватности.
    Если роль Product Owner выполняет представитель агентства, нужно учитывать, что он фактически является посредником: не всегда имеет актуальную информацию о продукте и его изменениях, не может принимать ключевых решений по срокам и бюджету. То есть выполнение многих ключевых функций Product Owner для него затруднено или невозможно.
    Есть мнение, что в компании-исполнителе должен быть свой сотрудник, выполняющий роль Product Owner и максимально контактирующий со стороной заказчика.

    Нередко на практике, в зависимости от личных качеств и отлаженности процессов, происходит смещение/смешение функций Product Owner, менеджера проекта и Scrum-мастера. Канонически классические роли Scrum-мастера и Product Owner не должны сливаться или меняться местами. Однако на практике могут происходить интересные деформации, отход от типичного образа, причем как в лучшую, так и в худшую сторону, в зависимости от особенностей конкретного сотрудника.

Нюансы в работе по Scrum

  Техзадание имеет смысл изначально отдавать на оценку и тестировщикам.
  В Backlog можно внести перечень задач из технического задания и доработки, возникающие в процессе. ТЗ и доработки фиксируются в договоре и дополнительных соглашениях.
  Важно не превращать ежедневные встречи, на которых члены команды отвечают на вопросы «Что было сделано вчера?», «Что будет сделано сегодня?» и «Какие есть проблемы?» в обсуждение технических деталей проекта.

  Работу с дизайном и контентом сайта многие команды выводят за Scrum, хотя адаптивность подхода не запрещает внести и эти этапы.
  Необходимо внимание к стыковке параллельных процессов, чтобы не разбалансировать сроки.


Юридические и финансовые аспекты

    С точки зрения работы с бюджетом есть разные подходы к реализации проектов по Scrum: фикспрайс, гибкий бюджет, поэтапная оплата, выстраивание графика релизов с выносом дополнительных функций в допсоглашения и отдельные договора и т. д. Хочется, но не стоит рассчитывать на гибкий бюджет – практики говорят, что пока таких заказчиков в России немного. При нефиксированном бюджете заказчику необходимо осознавать высокую вероятность перерасхода.
    Экспертная оценка работы может быть дана менеджером проекта или техническим директором. Planning Poker – достаточно точный инструмент оценки, но оптимистичный.
    Можно заключить договор на поэтапную разработку проекта. Возникающие пожелания в этом случае будут отражены в допсоглашениях.

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


Статьи этой же рубрики
Facebook Twitter Youtube Instagram