Неправильное понимание Scrum

Scrum (да и вообще Agile методологии) иногда понимают не совсем правильно. В основном это связано с возведением некоторых рекомендаций в абсолютную степень. Чтобы не повторять долгий путь, проделанный Scrum-методологией (а она развивается с конца 80-х – начала 90-х гг. XX века), полезно изучить некоторые ошибки в понимании Scrum. А заодно и задуматься, а не повторяются ли эти ошибки в данной команде/проекте/компании.

Большую часть ошибок можно разбить на две категории:

  • Взаимоотношения между командой и заказчиком
  • Процесс разработки

Взаимоотношения между командой и заказчиком

В Agile большое значение имеют отношения между заказчиком и командой. В этих отношениях важен баланс. А иногда он смещается.

Заказчик = Хозяин

Этот случай возникает, когда баланс сильно смещается в сторону заказчика, а права команды абсолютно не учитываются. Например:

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

Понятно, что при таких отношениях Scrum не выявит все свои сильные стороны. Необходимо или подобрать другой процесс, или сбалансировать отношения (в некоторых случаях стоит задуматься о том, а выгоден ли компании такой заказчик? – если команда будет сильно демотивирована, то возможен уход самых талантливых, а это прямые убытки и ослабление долгосрочного потенциала компании).

Команда – «Мы здесь главные»

Одно из основных требований Scrum – “honesty and visibility”. Но возможен перекос и в сторону команды – когда права заказчика не учитываются. Характерные особенности:

  • «Мы лучше знаем, что надо сделать, и когда»
  • «Product backlog не менять!»
  • Не предоставляется достаточная информация о ходе проекта, нет прозрачности
  • Команда занимается постоянным улучшением того, что уже сделано, не учитывая требования заказчика по поводу новой функциональности или тех улучшений, которые действительно важны с точки зрения бизнеса (происходит т.н. gold plating)

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

  • Для самоорганизующейся команды достаточно просто описать эти проблемы – команда сама постарается их решить
  • Если команда хорошая, то необходимо привлечь человека, имеющего опыт реального использования Scrum (а еще лучше Scrum-тренера или опытного Scrum master’a)
  • В некоторых случаях может помочь вмешательство менеджмента (например, division/BU manager) с четким описанием проблем (но желательно не навязывать решение, а просто помочь в его нахождении)
  • Навязать процесс (возможные отрицательные последствия – неприятие процесса командой, демотивация, потеря производительности)

Процесс разработки

В процессе разработки основные ошибки в понимании Scrum’a допускаются в

  • планировании
  • контроле изменений
  • дизайне
Планирование

Как правило, заказчик хочет знать заранее, сколько ему будет стоить этот проект, и когда он будет завершен (хотя бы примерно). Некоторые считают, что Scrum – это никакого планирования больше, чем на спринт. На самом деле, Scrum не запрещает планирование на более длительный срок! Он даже требует его – в виде приблизительной оценки историй в product backlog.

Так что на основании product backlog можно дать начальную оценку (единственная сложность – нет реальной скорости команды, но можно взять некую среднюю, а через несколько итераций сказать заказчику уточненную оценку). Зная скорость команды, на основании оценок в product backlog можно даже запланировать примерную функциональность для отдельных релизов.

Изменения

Agile – «меняй что хочешь и когда хочешь». Нет.

Изменения можно примерно разделить на «большие» и «маленькие» (маленькие, это те, что можно сделать за полчаса-час). Чтобы не вводить дополнительную бюрократию, как правило, заказчику разрешается делать «маленькие» изменения даже в течении спринта (например, в виде feedback’a).

Но «большие» изменения должны пройти через мини-процедуру change management. Они должны быть оценены. Если есть разбивка на планируемые версии, то необходимо уточнить, в какую версию необходимо включать это изменение. Если с учетом текущей скорости команда не успевает сделать эту версию вовремя (допустимый объем версии не больше, чем количество спринтов * скорость команды), то обсудить с заказчиком, какие истории из этой версии следует перенести в другие версии.

Дизайн

«Пишем, рефакторим, пишем, рефакторим, …»

Для больших проектов такой подход может привести к плачевным результатам. Дизайн необходимо встраивать в процесс.

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

Текущий дизайн следует разрабатывать во время sprint planning meeting. Такой дизайн не должен быть чересчур подробным (для многих историй пользователя отдельная разработка дизайна вообще не нужна). Наличие начального дизайна поможет сделать более точные оценки для спринта.

Используйте здравый смысл

Один из принципов Scrum – “use your common sense”. Если какая-то часть процесса лишняя для данного проекта, или наоборот, чего-то не хватает – измените. Экспериментируйте!

Tags:

Post Author

This post was written by who has written 29 posts on Agile.by.

  • http://yuri.shilyaev.com Yuri Shilyaev

    У меня есть такое мнение касаемое четкому следованию правил Скрама. Т.е. когда правила возводятся на уровне скрижалей.
    Аджайл передает право устанавливать ряд правил работы команде. Команда может устанавливать свои собственные правила. И вот этого люди часто не понимают. Для многих самостоятельно задать себе правила немыслима или невозможна. Это как ехать на машине по полю и держаться самой правой полосы. 🙂

  • http://mik-kardash.blogspot.com/ Mik Kardash

    Согласен 🙂

    А еще мне кажется, что Use Your Common Sense – это правило для управления (и работы над) проектами вообще.

    И тут не важно Agile или не Agile, важно то, что если Common Sense не применять то можно завалить любой проект. Опыт, конечно, важен но всетаки…