Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн книгу. Автор: Кен Швабер, Джефф Сазерленд cтр.№ 45

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

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

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

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

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

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

Внимание на качестве в Scrum

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

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

Со Scrum знакомят оставшиеся команды, составляющие 25–30 % общего персонала организации. Существующие практические приемы продолжают совершенствоваться и распределяться между командами, чтобы достигнуть закрепления гибкого подхода к разработке в организации. Только теперь строгие правила, в соответствии с которыми Scrum осуществляет свою деятельность, могут быть скорректированы, чтобы лучше соответствовать потребностям организации. Клиентам может быть предложено принять участие во внедрении через обучение в качестве владельцев продукта и Scrum-мастеров. Эта фаза продолжается до тех пор, пока все команды не будут вовлечены в Scrum. Механизмы Scrum по инспекции и адаптации будут способствовать дальнейшему улучшению процессов и практических методов.

К этому моменту организация уже достигнет существенной производительности, а также оценит деловые и культурные преимущества Scrum.

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

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

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

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

Препятствия, как правило, встречаются в четырех областях.

1. Сам Scrum-процесс – какие препятствия стоят на пути его применения?

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

3. Инженерные методы разработки продукта – какие методы мешают оптимизации возврата инвестиций или максимизации целей организации с точки зрения перспективы продукта, какие препятствия есть в оптимизации разработки и выпуска продукта?