главе 3

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

«Парное программирование (разработка через тестирование или другие практики) не подходят мне».

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

«Agile не подходит для нашего бизнеса».

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

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

«Именно это мы и делаем, только называется по-другому».

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

Попробуйте ввести в строку поиска «Agile – ерунда» (Agile sucks), и обнаружите высказывания людей, которые сделали именно это. Они называют Agile «очковтирательством», считая, что это просто практики каскадной модели, но под новыми названиями. Agile даже будут называть способом «запутать» принципы разработки программного обеспечения, диктуемые здравым смыслом.

Как коуч вы должны признать, что это делается не по злому умыслу. Это естественная реакция человека, который никогда не видел, что такое настоящая Agile (но думает, что видел). Задача коуча – помочь команде понять, что Agile действительно отличается от всего того, что они до сих пор делали, а вовсе не «ерунда».

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

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

  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