главе 5

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

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

Эти команды по-прежнему создают громоздкие спецификации до начала разработки продукта (BRUF, big requirements up front development) и просто добавляют к ним пользовательские истории. А вместо того, чтобы использовать разработку через тестирование, некоторые при попытке внедрить ХР просто хотят убедиться, что их код полностью покрыт тестами, которые они разрабатывают после сборки кода, что означает, что тесты никаким образом не влияют на архитектуру, потому что она полностью завершена к моменту, когда пишутся тесты.

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

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

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

Почему члены команды так часто настаивают на принятии только таких практик, которые кажутся им знакомыми, и отвергают любые другие, не известные им на данный момент?

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

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

Вспомните: когда нас просят выполнить незнакомые задачи, мы ощущаем эмоциональный стресс, если не уверены, что сможем легко овладеть новыми навыками. Глубоко в нашем подсознании сидит охотник-собиратель, который рассуждает так: «Вчера я не сомневался, что выполню свою работу и принесу домой еду для всей семьи, но сегодня я в этом уже не уверен». Это важная причина, объясняющая беспокойство сотрудников, когда от них ждут изучения чего-то нового, и их, казалось бы, иррациональную реакцию на изменения (которая на самом деле вполне ожидаема).

Другая причина, почему люди отвергают перемены и тяготеют к тому, в чем хорошо разбираются, заключается в том, что они чувствуют недостаток времени, не позволяющий им спокойно обдумать все приводимые доводы. Например, обычно команды внедряют Agile после опробования ее на пилотном проекте. Часто это начинается с чтения книги об Agile. После этого человек пытается внедрить какую-либо методологию в команде, одновременно занимаясь дедлайнами, ошибками, конфликтами, изменениями требований и прочими проблемами, которые присущи любому проекту. Все это не самая идеальная атмосфера для внедрения совершенно нового способа думать о работе. Люди будут стараться изо всех сил, но если столкнутся с чем-нибудь непонятным, скрывающимся за общей вывеской Agile, названиями методологий и практик, то фактически в их работе мало что изменится. Контрольные точки в плане проекта теперь будут называться «спринты», или кто-нибудь решит использовать доску задач, которая не повлияет на выполнение работы. В конце концов команда вернется к прежнему стилю работы, потому что она так привыкла и к тому же существуют дедлайны.

Когда команда использует названия известных agile-практик, но не меняет при этом способа работы, нетрудно понять, почему люди разочаровываются в новых идеях. Они приходят к выводу, что Agile – это просто другое название того, чем они давно занимаются. Думая, что внедрили Agile, они не изменили способа работы и продолжают получать прежние результаты.

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

Именно поэтому командам необходимы agile-коучи. Их важнейшая задача – определить момент, когда люди сталкиваются с чем-то новым, и помочь им принять эти изменения. Коуч должен объяснить каждому члену команды суть изменения, чтобы тот понимал «зачем» (а не только «что» конкретно нужно). Это поможет команде изменить способ работы, а не просто взять название какой-нибудь гибкой методологии и присвоить его привычной практике.

Хороший коуч старается максимально понятно объяснить, как ежедневные scrum-митинги помогают самоорганизоваться, а разработка через тестирование – мыслить функционально и двигаться в сторону инкрементального проектирования. Как пользовательские истории дают возможность каждому члену команды понять позицию людей, применяющих программное обеспечение. Коуч помогает выйти за рамки простого принятия новых правил, и люди начинают видеть правильное направление движения и то, что оно способно им дать.

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме главе 5:

  1. Введение к главе
  2. Введение к главе
  3. Введение к главе
  4. Введение к главе
  5. Введение к главе
  6. Введение к главе
  7. Введение к главе
  8. Введение к главе
  9. Введение к главе
  10. Введение к главе
  11. Главе 18
  12. Выводы по главе 1
  13. Выводы по главе 2
  14. Выводы по главе 3
  15. Выводы по главе 4
  16. Выводы по главе 5
  17. Выводы по главе 6
  18. Выводы по главе 7
  19. Выводы по главе 8