Софт за 30 дней. Как Scrum делает невозможное возможным

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

1.5.1. Выявление препятствий при помощи 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 участников и по возможности располагаться в общем рабочем помещении. Это наиболее эффективная и продуктивная модель, так как она: а) поддерживает требование постоянного неформального общения членов команды; б) воспитывает высокий уровень корпоративного духа; в) дает возможность для взаимной приверженности целям спринта членов команды, которые действительно знают друг друга и работают вместе каждый день.