Действительно ли Scrum подходит для всех типов проектов?

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

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

2) Хотя элементы бэклога продукта могут исходить от кого угодно, PO должен понимать их достаточно, чтобы говорить об их ценности и уметь расставлять приоритеты. Являются ли ваши элементы невыполненной работы выражением проблем, которые необходимо решить, или задач в решении. Если первое, то снова вы можете посмотреть на другой PO. Если последнее, у вас могут быть неправильные элементы в вашем отставании.

3) Во-первых, вам не нужно использовать пользовательские истории. Однако у вас есть человек или группа людей, которым ваша работа приносит пользу. Каждое из ваших невыполненных дел должно приносить пользу. Если продукт не представляет никакой ценности для кого-либо, вы должны отменить его. (Конечно, я преувеличиваю. На самом деле я никогда не сталкивался с проектом, который никому не приносил бы никакой пользы)

4) Относительная оценка предназначена для обработки неопределенностей или неизвестных и помогает в большинстве проектов. Однако в некоторых проектах так много неопределенности, что оценки становятся бесполезными. К счастью, Scrum их не требует. Я бы дал рекомендацию: если вы не используете оценки, используйте временные рамки. Временная ячейка устанавливает количество времени, которое нужно поработать над чем-то, прежде чем вернуться к группе, чтобы посмотреть, стоит ли продолжать тратить время или есть что-то более важное.

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

6) Кто хочет более высокой производительности, сколько они хотят и как это повлияет на них? Вот кто у вас в обзоре. Ваше проблемное пространство кажется очень узким, поэтому я не удивлюсь, узнав, что ваши обзоры очень прямолинейны.

Действительно ли Scrum подходит для всех типов проектов?

Как и многие вещи в индустрии программного обеспечения, Scrum не панацея. Это хорошо работает для некоторых типов проектов и менее эффективно для других. Я часто видел, как Cynefin Framework упоминается при попытке определить типы проектов, в которых может использоваться Scrum, так что, возможно, взгляните на него и посмотрите, к какой категории может относиться ваш проект.

Еще одна вещь, которую я часто видел, это то, что Scrum навязывается командам без учета типа выполняемой работы. Из вашего вопроса кажется, что это может быть так. Кто выбрал Scrum для вас и вашей команды? Почему? Рассматривали ли вы другие способы организации своей работы? Может ли Канбан выглядеть более многообещающе?

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

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

Добавив немного к отличному ответу Даниэля.

Ты говоришь:

вся работа глубоко техническая и не имеет последствий для пользователя

Но вы также говорите:

сосредоточены на повышении производительности продукта в целом

Я могу назвать две причины, по которым вы могли бы улучшить производительность продукта:

1. Для улучшения взаимодействия с пользователем (более быстрое время отклика и т. д.)
2. Чтобы уменьшить количество оборудования, необходимо получить тот же уровень производительности.

Если это причина 1, то у вас есть последствия, с которыми сталкиваются пользователи, и они будут определять ваши истории. Например, что-то вроде:

Как пользователь, я хочу, чтобы продукт реагировал быстрее, чтобы я мог сделать больше.

Если это причина 2, то клиент, скорее всего, внутренний и хочет сэкономить. Например, что-то вроде:

Как ИТ-директор я хочу сократить свой текущий бюджет на оборудование, чтобы повысить прибыльность.

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

TL;DR

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

Анализ вопросов

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

• инициация проекта
• концептуализация или выбор средств управления проектом
• организационные или проектные коммуникации

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

Для чего был разработан Scrum

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

Scrum в первую очередь предназначен для разработки продукта. Само руководство называет ряд конкретных применений:

1. Исследуйте и определяйте жизнеспособные рынки, технологии и возможности продукта;
2. Разрабатывать продукты и улучшения;
3. Выпускайте продукты и усовершенствования так часто, как много раз в день;
4. Разрабатывать и поддерживать облачные (онлайн, безопасные, по запросу) и другие операционные среды для использования продукта; и,
5. Поддерживать и обновлять продукты.

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

Когда не следует использовать Scrum

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

1. Открытые процессы поддержки или предоставления услуг.
2. Процессы по требованию (два частых примера — служба поддержки или колл-центр).
3. Когда планирование приращений точно в срок невозможно или нежелательно.
4. Крайне короткие проекты.
5. Индивидуальные проекты.
6. Очень маленькие или очень большие команды.
7. Результаты, которым не хватает центральной сплоченности.
8. Результаты, для которых отсутствует измеримое определение «Готово».
9. Проекты без активного сотрудничества с заинтересованными сторонами.

Если ваша проблемная область принципиально не соответствует модели Scrum, другие фреймворки или методологии могут подойти лучше. Какой фреймворк будет «лучшим», будет субъективным, но любой установленный фреймворк должен иметь четко определенные цели проектирования, которые вы можете использовать для управления процессом выбора.

Scrum — модное слово среди менеджеров, особенно среди тех, кто никогда не занимался кодированием/анализом/тестированием. Он подходит для некоторых конкретных проектов, но не для всех. Многим это не подходит, одним из них являются те, которые посвящены сугубо техническим темам. Скрам на самом деле известен тем, что накапливает технический долг (легко просто перетасовать эти «неприятные» задачи куда-нибудь в бэклог). Я думаю, что лучший способ для каждого проекта — это использовать базовый канбан, а затем адаптировать его в соответствии с требованиями разработчика и проекта, который должен быть либо более гибким, либо более жестким (что само по себе неплохо, особенно для проектов с высоким уровнем риска). проекты). Имейте в виду, что «водопад» — это не ругательство, как хотели бы заставить нас поверить все эти скрам-тренеры, мастера и гуру.