Поддержка: внутренняя.
Описание: проекты организационных изменений устраняют возникающие препятствия в разных ведомствах предприятия.
III. Оценка и адаптация
Продолжительность: каждый спринт.
Поддержка: внешний/внутренний Scrum-мастер.
Описание: обзор количественных и качественных показателей. Добавление дополнительных показателей и обзор того, какие показатели фиксируются каждый раз, когда происходят непредвиденные случаи.
1.4.5. Действие 4 измерение, оценка и регулировка
Цель этого действия заключается в оценке прогресса организации и создании более широкого набора показателей, служащих основой для дальнейшего расширения. Руководитель должен быть в курсе, что предстоящее обсуждение новых показателей может вызвать как споры, так и поддержку в связи с тем, что многие традиционные показатели, которые применялись в организации до внедрения Scrum (например, показатель полноты документации), теряют свое значение. К счастью, Scrum и гибкие методы разработки действительно контролируемые и измеряемые, поэтому использующие эти методы исполнители получают набор показателей, предоставляющих качественную и достаточную обратную связь как на уровне процесса разработки, так и на уровне проекта.
Но перед началом обсуждения новых показателей должна быть четко проведена граница между множеством традиционных процессов разработки программного обеспечения и гибкими процессами, то есть Scrum.
Основной показатель гибкого метода разработки программного обеспечения существует ли реально работающее программное обеспечение и подходит ли оно для использования по планируемому назначению. В Scrum этот ключевой индикатор определяется опытным путем, путем демонстрации в конце каждого спринта.
Эта первичная мера качества программного обеспечения и производительности сущность процесса гибкой разработки. Таким образом, со Scrum вы не можете отойти слишком далеко от цели, не зная, где находитесь. Все остальные показатели находятся в подчинении этой цели и постоянно повторяющегося принципа «частой поставки рабочего программного обеспечения».
На данном этапе процесса адаптации Scrum значительная часть организации уже работает в гибкой манере. Результаты спринтов первоначальных проектов основные показатели эффективности новой модели поведения команды и новых процессов. Эти данные должны быть опубликованы и проанализированы.
Более того, теперь самое подходящее время для определения набора вторичных показателей, служащих ориентиром организации на пути реализации Scrum. При этом есть два типа показателей, которые могут быть применены.
Показатели процесса в первую очередь качественные показатели эффективности команд и организации в усвоении Scrum. Это такие элементы, как эффективность команд по управлению бэклогом продукта, эффективность Scrum-процессов, например ежедневного Scrum-митинга, планирования спринта и так далее.
Показатели процесса в первую очередь качественные показатели эффективности команд и организации в усвоении Scrum. Это такие элементы, как эффективность команд по управлению бэклогом продукта, эффективность Scrum-процессов, например ежедневного Scrum-митинга, планирования спринта и так далее.
Показатели проекта на уровне проекта дополнительный набор показателей может быть применен для оценки результатов конкретной Scrum-команды и службы, компонента или системы, за которую эта команда несет ответственность. Этот набор может включать в себя некоторые традиционные показатели, например подсчет дефектов, процент кода с юнит-тестированием, процент кода с автоматическим регрессионным тестированием и так далее. А также специфические Scrum-показатели: количество законченных пользовательских историй и демонстраций в конце каждого спринта.
Внимание на качестве в ScrumКлиенты часто оказывают давление на организации разработчиков программного обеспечения с целью получить функциональные возможности быстрее, чем это возможно. Некоторые организации идут на это за счет снижения качества продукта, отбрасывая рефакторинг, урезая время тестирования и других необходимых инженерных манипуляций. Это не поддерживается в Scrum-процессах, так как система или продукт корпоративный актив, который постоянно усовершенствуется и объективно оценивается, а не одноразовый проект активов. Инженерные организации, поддавшиеся этому давлению, в конце концов строят «мертвые модели» систем, которые не могут эффективно обслуживаться и улучшаться. Организация тратит огромные средства на переписывание и повторный выпуск существующей основы программного кода. Чтобы этого избежать, только на уровне высшего руководства может быть принято решение о снижении качества.
1.4.6. Действие 5 распространение до победного конца
На основе уже выполненных в организации мероприятий с определенным набором показателей для направления и оценки прогресса в будущем теперь настало время распространить использование Scrum на всю организацию. Деятельность на этом этапе внедрения ориентирована на дальнейшее масштабирование метода в пределах организации.
Со Scrum знакомят оставшиеся команды, составляющие 2530 % общего персонала организации. Существующие практические приемы продолжают совершенствоваться и распределяться между командами, чтобы достигнуть закрепления гибкого подхода к разработке в организации. Только теперь строгие правила, в соответствии с которыми Scrum осуществляет свою деятельность, могут быть скорректированы, чтобы лучше соответствовать потребностям организации. Клиентам может быть предложено принять участие во внедрении через обучение в качестве владельцев продукта и Scrum-мастеров. Эта фаза продолжается до тех пор, пока все команды не будут вовлечены в Scrum. Механизмы Scrum по инспекции и адаптации будут способствовать дальнейшему улучшению процессов и практических методов.
К этому моменту организация уже достигнет существенной производительности, а также оценит деловые и культурные преимущества Scrum.
Тем не менее, прежде чем мы перейдем к масштабированию Scrum на самые большие проектные условия, мы должны взглянуть на типы организационных препятствий, которые могут мешать эффективным Scrum-процессам.
1.5. Организационные препятствия при адаптации Scrum
Приложения, разработанные в любой организации, предназначены для оптимизации способности компании выполнять ее коммерческую миссию. Тем не менее с течением времени организации развиваются таким образом, что это не всегда способствует производительности команды, которая разрабатывает и поддерживает эти приложения. В самом деле, некоторые организации развились до состояния, при котором многие практические методы разработки программного обеспечения в значительной степени имеют дисфункции и, несмотря на неоднократные попытки по их улучшению, организационная структура и политика компании препятствуют эффективному изменению. Этот раздел описывает источник и природу таких препятствий, чтобы лучше вооружить руководителя, ответственного за изменения, для дальнейшей работы.
1.5.1. Выявление препятствий при помощи Scrum
Сама природа Scrum его непрекращающиеся требование к качеству программного обеспечения, предоставляемого как можно быстрее, его постоянное требование необходимости работы с конечными пользователями для обеспечения эффективного применения и его постоянные механизмы инспекции и адаптации, быстро выявляющие плохо функционирующие методы и «блокирующие элементы». Этот эффект становится все более выраженным, когда Scrum также используется как процесс по внедрению и масштабированию Scrum в организации.
Сама природа Scrum его непрекращающиеся требование к качеству программного обеспечения, предоставляемого как можно быстрее, его постоянное требование необходимости работы с конечными пользователями для обеспечения эффективного применения и его постоянные механизмы инспекции и адаптации, быстро выявляющие плохо функционирующие методы и «блокирующие элементы». Этот эффект становится все более выраженным, когда Scrum также используется как процесс по внедрению и масштабированию Scrum в организации.
Вы не можете определить все препятствия заранее, так как они встроены в организацию и стали привычными, а потому не могут быть легко идентифицированы. Только когда вы начнете использовать Scrum, они станут очевидными. План реализации выступает в качестве доказательства того, что должно быть изменено, и готовности организации внести изменения, когда такая необходимость возникает.
1.5.2. Описание препятствий
Препятствия, как правило, встречаются в четырех областях.
1. Сам Scrum-процесс какие препятствия стоят на пути его применения?
2. Методы работы людей какие методы работы по разработке, выпуску, поддержке и использованию продуктов стоят на пути максимальной производительности всех вовлеченных в эту работу людей?
3. Инженерные методы разработки продукта какие методы мешают оптимизации возврата инвестиций или максимизации целей организации с точки зрения перспективы продукта, какие препятствия есть в оптимизации разработки и выпуска продукта?
4. Организационные вопросы какие системные организационные проблемы, которые явно лежат вне поля контроля команды, мешают командам быстрее поставлять программное обеспечение пользователям?
Мы хотим разделить отдельные категории организационных препятствий в бэклоге продукта, потому что они требуют уникальных навыков для решения. Кроме того, они должны иметь приоритет по влиянию и требуют некоторых усилий при размышлении, кто в организации лучшим образом может устранить препятствие.
1.6. Масштабирование Scrum
Экономическая выгода от применения Scrum и гибких методов наиболее легко достигается, если комплексные команды немногочисленны, работают в непосредственной близости друг от друга и в идеале состоят из 11 или меньше человек (включая владельца продукта, Scrum-мастера и команды разработки). Каждая Scrum-команда работает над специфическим продуктом или приложением, которое они могут определить, разработать, протестировать и выпустить без большой помощи извне.
Неизбежно, однако, что успех Scrum приведет к его применению в гораздо более крупных программах, системах, состоящих из подсистем, и приложениях, которые требуют участия множества часто распределенных команд по разработке и выпуску. К счастью, эффективность Scrum была доказана в проектах, состоящих из многих сотен разработчиков, следовательно, он масштабируется для решения сложных задач по разработке больших программных комплексов. Эта работа тем не менее приводит к появлению уникальных вызовов, которые должны быть решены, в частности:
1) масштабирование организации: комплексные Scrum-команды;
2) создание инфраструктуры для гибкости предприятия;
3) координация комплексных команд.
Каждый из этих вызовов рассмотрен ниже.
1.6.1. Масштабирование организации: Scrum-команды из Scrum-команд
Основанный больше на философских принципах, Scrum имеет очень небольшое количество правил. Тем не менее большинство правил, которые действительно существуют, фиксированные и относительно нерушимые. Одно из таких основных правил команда должна состоять не более чем из 11 участников и по возможности располагаться в общем рабочем помещении. Это наиболее эффективная и продуктивная модель, так как она: а) поддерживает требование постоянного неформального общения членов команды; б) воспитывает высокий уровень корпоративного духа; в) дает возможность для взаимной приверженности целям спринта членов команды, которые действительно знают друг друга и работают вместе каждый день.