Почему Scrum: определенный процесс против эмпирического процесса

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

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

Определенный процесс — традиционный плановый подход

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

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

Эмпирический процесс — гибкий подход, ориентированный на ценность

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

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

Вы можете подумать: «А как насчет требований, которые не выполнены к дате поставки?» Вот почему вы используете подход, ориентированный на ценность. Вы признаете тот факт, что не все требования будут выполнены к дате поставки. Важный вопрос, который следует задать, заключается в том, предоставили ли вы достаточно функций для поддержки системы, представляющей ценность для клиента.

Частота отказов программных проектов

Отчет CHAOS за 2015  год  был недавно выпущен группой  Standish . Отчеты CHAOS публикуются ежегодно с 1994 года и представляют собой снимок состояния индустрии разработки программного обеспечения. В этом году в отчете было рассмотрено 50 000 проектов по всему миру, начиная от крошечных усовершенствований и заканчивая массовыми внедрениями реинжиниринга систем. В этом году отчет включает расширенное определение успеха с учетом некоторых дополнительных факторов, которые были охвачены в предыдущих опросах.

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

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

Каковы проблемы традиционного подхода?

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

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

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

использованная литература

1. Отчет Standish Group о хаосе за 2015 г.
2. Как стать гибким в несовершенном слове — Грег Смит и Ахмед Сидки

Другие чтения Scrum

• Скрам за 3 минуты
• Каковы 5 ценностей Scrum?
• Что такое эволюция Scrum?
• Классическое управление проектами против гибкого управления проектами
• Почему Scrum сложно освоить?
• Что такое скорость в Scrum?
• Что такое Agile? Что такое Скрам?