Есть проекты достаточно прямолинейные и относительно предсказуемые, где можно применять рациональные инструменты планирования и принятия решений. Другие проекты, более сложные или непредсказуемые, требуют другого подхода, больше опирающегося на самоорганизацию и инновации.
Большинство проектов по разработке программного обеспечения считаются сложными и непредсказуемыми по своей природе из-за совпадения трех факторов: людей, требований и технологий. Различные подходы, используемые для реализации проектов и управления ими, легче понять в контексте моделей управления процессами и сложности проекта.
Определенный процесс — традиционный плановый подход
Традиционно после запуска проекта создается пакет требований, который затем «подписывается». Руководитель проекта предполагает, что это согласование приводит к фиксированному набору требований и что теперь можно приступать к планированию. Менеджер проекта оценивает, сколько времени потребуется для выполнения требований, и создает план проекта. План предсказывает, что проект будет завершен к определенной дате, и эта дата сообщается заказчику.
Фундаментальный недостаток этого подхода заключается в том, что план, который управляет всем, основан на предположении, что требования фиксированы и не изменятся. Опыт показал нам, что это никогда не бывает; требования никогда не бывают фиксированными — они всегда меняются. Когда требования изменяются, это влияет на план; и, как следствие, дата завершения тоже должна измениться. К сожалению, во многих случаях это невозможно, и команда должна выполнить работу к намеченной дате. Это когда происходит крупный кризис, и проект начинает выходить из-под контроля.
Эмпирический процесс — гибкий подход, ориентированный на ценность
Agile-подход, ориентированный на ценность, основан на эмпиризме , который меняет весь образ мышления. С самого начала предполагается, что любые требования, существующие заранее, не являются фиксированными и будут меняться.
Гибкое мышление также предполагает, что вы должны выполнить работу к определенной дате. Этот подход фиксирует время и ресурсы и оставляет требования неопределенными. Нам такой подход больше напоминает реальность создания программного обеспечения. Теперь само понятие ценностной ориентации обретает смысл. Когда у вас есть фиксированное количество времени, в течение которого вы не уверены, сможете ли вы выполнить все требования (потому что они изменятся, и, следовательно, время, необходимое для их выполнения, изменится), естественной реакцией будет расставить приоритеты требований и закончить первым. те, которые приносят наибольшую пользу клиенту.
Вы можете подумать: «А как насчет требований, которые не выполнены к дате поставки?» Вот почему вы используете подход, ориентированный на ценность. Вы признаете тот факт, что не все требования будут выполнены к дате поставки. Важный вопрос, который следует задать, заключается в том, предоставили ли вы достаточно функций для поддержки системы, представляющей ценность для клиента.
Частота отказов программных проектов
Отчет CHAOS за 2015 год был недавно выпущен группой Standish . Отчеты CHAOS публикуются ежегодно с 1994 года и представляют собой снимок состояния индустрии разработки программного обеспечения. В этом году в отчете было рассмотрено 50 000 проектов по всему миру, начиная от крошечных усовершенствований и заканчивая массовыми внедрениями реинжиниринга систем. В этом году отчет включает расширенное определение успеха с учетом некоторых дополнительных факторов, которые были охвачены в предыдущих опросах.
Результаты показывают, что еще многое предстоит сделать для достижения успешных результатов проектов по разработке программного обеспечения. В этой таблице обобщены результаты проектов за последние пять лет с использованием нового определения факторов успеха (в срок, в рамках бюджета с удовлетворительным результатом).
С появлением в последние годы гибких методов разработки стало возможным сравнивать результаты проектов между гибкими и традиционными каскадными проектами. Гибкие подходы к проектам всех размеров приводили к большему количеству успешных проектов и меньшему количеству явных неудач, как показано в этой таблице.
Каковы проблемы традиционного подхода?
Традиционный плановый подход сам по себе не имеет недостатков; это просто не подходит для сегодняшней индустрии программного обеспечения. Плановый подход изначально основывался на традиционных концепциях управления проектами, пришедших из строительной отрасли. В строительной отрасли подходит плановый подход: чертежи, которые являются требованиями, фиксированы и, вероятно, не изменятся во время строительства здания. Вы можете оценить, сколько времени потребуется, чтобы построить стальные столбы, залить бетон и так далее.
Причина, по которой традиционный плановый подход подходит для строительной отрасли, но не для индустрии программного обеспечения, заключается в различии в том, как мы контролируем эмпирические системы (такие как разработка программного обеспечения) и как мы контролируем определенные системы (такие как строительство или производство). ). В таблице ниже показаны различия между характеристиками определенного процесса и характеристиками эмпирического процесса.
Прочитав таблицу, легко увидеть, что разработка программного обеспечения — это определенно эмпирический процесс, а не определенный процесс. Проблема в том, что мы подходили к разработке программного обеспечения в течение многих лет как к определенному процессу — и этот подход не работает.
использованная литература
- Отчет Standish Group о хаосе за 2015 г.
- Как стать гибким в несовершенном слове — Грег Смит и Ахмед Сидки
Другие чтения Scrum
Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文