da Анна Кайсина mancano 2 anni
106
Più simili a questo
Методология Проектного Управления - набор руководящих принципов, методов, фреймворков и процедур для управления проектами
компании нужна детальная документация по всем процессам разработки
бюджет проекта строго ограничен
продукт должен быть создан к конкретному сроку
компания не готова тратить дополнительные ресурсы на налаживание ежедневной коммуникации между всеми участниками проекта
продукт разрабатывается в сфере, подверженной постоянным изменениям
заказчик выступает в качестве партнера, а не инвестора
нужно быстро получить рабочую версию продукта
над проектами работает опытная, высококвалифицированная команда
проект является Start-Up
Систематический анализ способов улучшения эффективности и корректирования стиля работы
Команда обязана быть самоорганизующейся, при таком команде рождаются лучшие требования, а также архитектурные и технические решения
Простота - искусство минимизации лишней работы - крайней необходима
Повышение гибкости путем технического совершенства и качества проектирования
Постоянная поддержка постоянного ритма
Работающий продукт - основной показатель прогресса
Личное общение - эффективнейший способ обмена информацией
Над продуктом должны работать мотивированные профессионалы
Разработчики и представители бизнеса должны ежедневно работать вместе
Работающий продукт следует выпускать как можно чаще
Изменение требование приветствуется, даже на поздних стадиях разработки
Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценности
финансовые ресурсы не являются ключевым ограничителем в проекте
компания не уверена в концепции предлагаемого проекта
компания хочет создать инновационный продукт или крупный проект
создание продукта или бизнеса построено на соблюдении строгой последовательности выполнения задач
компания не ограничена во времени и ресурсах создания продукта
есть четкая концепция продукта, который компания хочет получить
большая часть или вся работа над проектами проводится на аутсорсе
Заказчик особо не участвует в процессе разработки.
Фиксированная стоимость продукта проекта
Переход от одного этапа только после завершения предыдущего.
Жесткая последовательность этапов.
Эксплуатация и техническая поддержка: Проект передают заказчику и следят заранее определённое время, чтобы всё работало.
Тестирование: Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки.
Разработка (реализация): На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ (техническому заданию).
Проектирование: Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.
Аналитика (определение требований): Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать.
