Создает ли Scrum дополнительные накладные расходы для проектов, где требования не меняются?

Я читаю Scrum - Карманный путеводитель Гюнтера Верхейена, где написано:

Отчет «Хаос» за 2011 год от Standish Group знаменует собой поворотный момент. Было проведено обширное исследование по сравнению традиционных проектов с проектами, использующими гибкие методы. Отчет показывает, что Agile-подход к разработке программного обеспечения приводит к гораздо более высокой доходности, даже несмотря на старые ожидания, что программное обеспечение должно быть доставлено вовремя, в рамках бюджета и со всеми обещанными возможностями. Отчет показывает, что Agile-проекты были в три раза успешнее, и провальных Agile-проектов было в три раза меньше, чем традиционных.

Поэтому у меня есть спор с одним из моих коллег, который говорит, что для некоторых проектов (таких как медицина / военные, где требования не меняются), Agile (и, в частности, Scrum) накладные расходы на все встречи и т. Д., И это более логично использовать водопад, например.

Моя точка зрения заключается в том, что Scrum следует использовать в таких проектах, потому что это сделает процесс более прозрачным и повысит производительность команды. Я также думаю, что события Scrum не займут много времени, если в этом нет необходимости, потому что нам не нужно сидеть целых 8 часов в спринтерском планировании в течение 1 месяца спринта. Мы можем сэкономить 5 минут, чтобы быть уверенными, что мы все на одной странице и начинаем работать.

Итак, создаст ли Scrum дополнительные накладные расходы для проекта, где требования не меняются?

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

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

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

Очень краткий ответ: да, Scrum - это более дорогой подход, но если вы называете его проектом, это почти наверняка не имеет значения, и в конечном итоге почти всегда приведет к лучшему ROI.

Более полный ответ таков:

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

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

Следующим является эмпирическое управление процессами, которое, безусловно, является самым дорогим, потому что вы должны исследовать процесс по ходу дела. Обучение невероятно высоко, но за счет производительности и эффективности. Тем не менее, почти вся проектная работа требует этого, потому что несколько проектов были выполнены ранее. Есть, конечно, исключения. Настройка среды большого активного каталога является более статистической, потому что вы работаете с некоторыми проверенными на практике инструкциями, от которых вы немного отклоняетесь от обстоятельств. Но если ваш проект не предназначен для выполнения точной работы, которая была проделана ранее, он почти наверняка требует Emperical Process Control.

Чтобы вернуть его в Scrum, Scrum предназначен для решения проблем с контролем Emperical Process. Поэтому да, он имеет больше накладных расходов, чем другие подходы. Однако, поскольку большинство проектов требуют такого подхода, это спорный аргумент.

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

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

Но подавляющее большинство программных проектов совсем не так.

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

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

Наконец, мир не стоит на месте во время проекта. Меняются внешние системы, меняются приоритеты, меняются люди. Делать вид, что требования к программному проекту не изменятся, - плохая идея, за исключением коротких проектов.

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

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

Я думаю, что это вполне может перефразировать то, что говорит @Cort Ammon, но вот мое мнение:

Внешние требования (описывающие «результаты») - не единственные требования в проекте. Даже если внешние требования не изменятся, «внутренние» требования изменятся, или их нужно будет изменить по мере работы. Разработчики обнаружат препятствия или проблемы с подходом, и это повлияет на работу других людей в команде. Ежедневные встречи будут держать всех в курсе этих внутренних изменений.

Считают, что:

• Даже с фиксированными функциональными требованиями вы должны преобразовать их в технические требования. И это может быть лучше сделано итерациями. Вы можете найти лучшие способы решения проблемы в середине проекта.

• Некоторые требования могут быть слишком общими или неоднозначными: «быть простым в использовании», «быть безопасным». Трудно проанализировать безопасность или удобство использования системы, поскольку она еще не закончена. Некоторые могут иметь скрытые последствия или могут быть не совсем понятны.

• Некоторые требования могут быть улучшены. Ответ в 200 мс может быть хорошим, но 100 может быть лучше. Вы можете достичь наилучшего возможного результата, но пожертвуйте его, если это необходимо во время проекта.

• Вы можете обнаружить некоторые скрытые требования, которые не будут записаны в контракте, но могут изменить проект от провала к успеху. Даже если вы поставите проект, клиент может не быть счастливым. Может быть, им даже нужно изменить контракт, чтобы добавить (и взимать плату) за новые функции, которые вы можете разработать в проекте дешевле на ранних стадиях.

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

• Более ранняя доставка поможет интеграции и покажет, что этот проект может принести результаты.

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

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

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

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

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