Видел этот вопрос：Как оценить время, необходимое для тестирования во время итераций проекта, обеспечив при этом качество и сбалансированное распределение ресурсов? Должно ли время оценки включать время разработки для исправления ошибок?Очень классический вопрос управления проектами и разработки программного обеспечения.。

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

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

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

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

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

Во-первых, поделитесь концепцией: пул спроса.

Так называемый пул спроса представляет собой «контейнер», в котором хранятся требования. После простого предварительного отбора собранных или необходимых для последующих итераций требований они суммируются и вводятся в соответствии с определенными спецификациями (модулями, типами, приоритетами).

Существует множество инструментов управления пулами спроса, таких как Excel, Feishu Documents, MindManager или другие инструменты управления проектами.

Почему нам следует создавать пул спроса? Есть три преимущества:

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

После создания пула требований из него отбираются требования для всех последующих итераций, а количество требований для этой итерации определяется на основе доступных ресурсов для следующей версии (доступных человеко-дней для НИОКР/тестирования) и сложности реализации требований (стоимость).

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

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

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

• Запуск проекта с нуля: соотношение инвестиций в НИОКР и тестирование составляет 3:1-5:1.
• Обычный итерационный проект: соотношение инвестиций в ресурсы НИОКР и тестирования составляет 5:1-7:1.
• Проекты базовых технологических объектов: соотношение инвестиций в ресурсы НИОКР и испытаний составляет 7:1-10:1.

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

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

Подводя итог,Существует две идеи для оценки инвестиций в человеко-часы (ресурсы) на НИОКР: 1 – Определить необходимое количество на основе человеческих ресурсов. 2 – Определить человеческие ресурсы на основе требуемого количества;。

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