Стоимость против качества: железный треугольник в разработке программного обеспечения
programming software-development

Стоимость против качества: железный треугольник в разработке программного обеспечения

11 мая 2023 г.

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

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

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

В настоящее время считается, что методология Agile положительно влияет на проекты разработки программного обеспечения.

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

Что такое пирамида управления проектами?

Железный треугольник разработки программного обеспечения, треугольная модель или пирамида управления проектами — это одно и то же. Так что не запутайтесь в терминах. Это было впервые обсуждался доктором Мартином Барнсом в 1969 году и основывался на каскадном подходе.

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

Основные теории за пирамидой управления проектами:

  1. Качество работы имеет три ограничения: бюджет проекта, сроки и объем (функции).

2. Менеджер проекта может найти компромисс между ограничениями.

3. Изменения в одном ограничении требуют изменений в других, чтобы компенсировать это, иначе качество ухудшится.

Таким образом, классическое противопоставление стоимости и качества можно обсудить с учетом трех факторов разработки программного обеспечения: стоимости, масштаба и времени.

Как расставить приоритеты в пирамиде управления проектами?

Железный треугольник разработки программного обеспечения полезен для руководителей проектов, команд и руководителей высшего звена. Модель манипулируется и наиболее полезна в модели водопада. Но Agile-разработка лучше подходит для функциональных команд. А модель треугольника можно использовать в Scrum.

Что нам нужно знать: какие переменные исправить, какие изменить и почему.

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

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

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

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

Фиксированная стоимость против качества

Установка фиксированной стоимости для проекта — самый простой способ установить ресурсы. Эта идея напоминает разницу между временем и ресурсами и контрактами на разработку программного обеспечения с фиксированной ценой.

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

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

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

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

Фиксированное время

Этот подход очень похож на вариант с фиксированным бюджетом разработки, но с определенными временными ограничениями, установленными для разработки. Имея это в виду, вам может потребоваться скорректировать объем и бюджет, чтобы достичь желаемого качества и целей в установленные сроки. n n Крайне важно отдать предпочтение краткосрочным срокам над долгосрочными. Например, этот метод можно использовать для разработки определенной функции в программном проекте, такой как реализация среды базы данных и обеспечение ее функциональности в серверной части.

Фиксированный объем проекта

Исходя из нашего опыта, метод фиксированных ресурсов является наименее популярным подходом в соответствии с концепцией развития железного треугольника.

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

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

Подведение итогов

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

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

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE