3. Методы и подходы к управлению проектами

1. Методы и подходы к управлению проектами

2. Методы управления проектами

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

3. Методы управления проектами

1. Метод Waterfall («Водопад»)
Этот традиционный метод предполагает последовательное прохождение всех
фаз проекта от начала до конца: анализ требований → проектирование →
разработка → тестирование → внедрение → сопровождение. Хотя этот подход
широко использовался ранее, особенно в условиях чётко сформулированных
требований и жестких временных рамок, он плохо справляется с изменениями,
возникающими в процессе разработки программного обеспечения.
Преимущества:
• Простота понимания и контроля.
• Хорошо подходит для малых проектов с ясными целями и ограниченными
ресурсами.
Недостатки:
• Отсутствие возможности оперативно реагировать на изменения
требований.
• Проблемы с интеграцией модулей в конце проекта, что увеличивает риски
неудачи.

4. Waterfall

Суть метода Waterfall:
Основная идея Waterfall состоит в том, что весь жизненный цикл проекта
делится на чётко выделенные этапы, которые следуют друг за другом
последовательно. Обычно выделяются следующие фазы:
1. Анализ требований. Сбор и документирование требований заказчика
относительно будущего продукта.
2. Проектирование. Создание технической документации, схем баз данных,
архитектурных моделей и алгоритмов функционирования будущей системы.
3. Разработка (кодирование). Написание исходного кода программы согласно
проектной документации.
4. Тестирование. Проверка работоспособности готового продукта путём
выполнения тестов, обнаружения и исправления ошибок.
5. Интеграция и настройка. Соединение всех частей системы вместе и
настройка параметров конфигурации.
6. Эксплуатация и сопровождение. Запуск продукта в промышленную
эксплуатацию и последующее обслуживание, внесение обновлений и
фиксацию багов.
Каждая фаза должна завершаться перед началом следующей. Результат каждой
стадии фиксируется документально, что обеспечивает высокий уровень контроля
и помогает избежать отклонений от первоначального замысла.

5. Waterfall

Особенности метода Waterfall:
• Последовательность.
Все этапы строго упорядочены, нельзя вернуться назад к предыдущему этапу без
существенных издержек и переосмысления всего проекта.
• Документированность.
Вся деятельность на каждом этапе документируется, что облегчает дальнейшую
поддержку и аудит проекта.
• Высокий уровень планирования.
Каждая стадия детально планируется и оценивается по срокам и ресурсам, что
даёт представление о стоимости и длительности всего проекта.
Waterfall хорошо подходит для ситуаций, когда:
• Проект имеет чёткую и однозначную постановку задач.
• Изменения маловероятны или крайне нежелательны.
• Время исполнения проекта достаточно большое, позволяя уделить внимание
каждому этапу.
• Заказчик способен точно описать все требования на старте проекта.
Например, метод Waterfall активно применяют в разработке аппаратного
обеспечения, строительстве, инфраструктурных проектах и других областях, где
возврат к предыдущей стадии невозможен либо экономически невыгоден.

6. Waterfall

Преимущества метода Waterfall:
1. Четкость этапов и планов. Водопад чётко определяет границы каждой
стадии, облегчая координацию действий команды и отслеживание прогресса.
2. Высокое качество документационного сопровождения. Благодаря
обязательному документированию на каждом этапе обеспечивается
прозрачность и лёгкость передачи знаний новому персоналу.
3. Простота в понимании. Зафиксированные правила позволяют легче
планировать расходы и временные рамки.
Недостатки метода Waterfall:
1. Невозможность оперативного реагирования на изменения. Любое
значительное изменение на позднем этапе приведёт к переделыванию
предыдущих этапов, что негативно скажется на сроках и бюджете.
2. Отсутствие обратной связи от пользователей. До завершения проекта
заказчик видит лишь готовый продукт, что повышает вероятность расхождения
ожиданий с результатом.
3. Проблемы интеграции. Часто отдельные модули разрабатываются
независимо друг от друга, что вызывает проблемы совместимости и целостности
на этапе объединения.

7. Шаблон для Waterfall

1. Анализ требований (Requirements Analysis)
Цель: собрать и задокументировать требования заказчика.
Задачи:
• Провести интервью с заинтересованными сторонами.
• Создать техническое задание (ТЗ) или спецификацию требований.
• Согласовать требования с клиентом.
Результат: утвержденные требования и согласованное ТЗ.
2. Проектирование (Design)
Цель: разработать общую архитектуру и техническую документацию.
Задачи:
• Определить высокоуровневую архитектуру.
• Составить схемы баз данных, диаграммы классов и интерфейсов.
• Документировать детали реализации.
Результат: готовая проектная документация и схема базы данных.

8. Шаблон для Waterfall

3. Кодирование (Implementation/Coding)
Цель: реализовать систему согласно проекту.
Задачи:
• Программирование согласно спецификациям.
• Интеграция сторонних библиотек и сервисов.
• Настройка окружения и компиляция приложения.
Результат: рабочее приложение, соответствующее требованиям.
4. Тестирование (Testing)
Цель: проверить работоспособность и выявить дефекты.
Задачи:
• Выполнить модульное, интеграционное и нагрузочное тестирование.
• Обнаружить и исправить баги.
• Оценить производительность и безопасность.
Результат: проверенный продукт с минимальным количеством дефектов.

9. Шаблон для Waterfall

5. Инсталляция и интеграция (Installation & Integration)
Цель: развернуть и настроить систему в рабочей среде.
Задачи:
• Установить необходимые компоненты на серверы.
• Подготовить базу данных и конфигурационные файлы.
• Провести обучение персонала.
Результат: система готова к эксплуатации.
6. Эксплуатация и сопровождение (Operation & Maintenance)
Цель: обеспечить бесперебойную работу системы и поддерживать её в рабочем
состоянии.
Задачи:
• Оказывать техническую поддержку пользователям.
• Проводить обновления и модификации системы.
• Осуществлять резервное копирование и восстановление данных.
Результат: стабильно функционирующая система, поддерживаемая командой
поддержки.

10. Методы управления проектами

2. Метод V-образной модели
Это развитие традиционного каскадного подхода, где каждый этап разработки
сопровождается этапом тестирования. Таким образом, тестируются не только
финальный продукт, но и промежуточные результаты каждого этапа.
Преимущества:
• Улучшенное качество продукта благодаря раннему выявлению ошибок.
• Поэтапное снижение риска ошибок.
Недостатки:
• Аналогично водопаду, слабо приспособлен к изменению требований.
• Из-за жёсткой структуры трудно вносить существенные изменения в
середине проекта.

11. V-образная модель

V-образная модель (англ. V-model, от англ. Verification and Validation model) —
это модификация традиционной каскадной модели (Waterfall), которая
предусматривает параллельное проведение этапов верификации и валидации
на протяжении всего жизненного цикла проекта.
Название обусловлено формой графика, напоминающей букву "V": левый
склон соответствует этапам разработки, правый — этапам проверки и
тестирования.
Основное отличие V-образной
модели от классической
каскадной модели заключается в
том, что на каждом этапе
разработки параллельно
запускается соответствующий
этап тестирования, обеспечивая
проверку соответствия
полученных результатов
требованиям предыдущего
этапа.

12. V-образная модель

Этапы V-образной модели
Процесс проходит два основных блока:
1. Восходящие этапы (левая сторона буквы V):
• Сбор и анализ требований.
На данном этапе формируются базовые требования к конечному продукту,
собираемые от клиентов и внутренних подразделений компании. Результатом
становятся функциональные и нефункциональные требования.
• Архитектура и дизайн.
Этап проектирования системы, формирования общей архитектуры и
детальной проработки технического задания.
• Реализация.
Разработчики пишут код и реализуют задуманные функции и сервисы.
• Интеграция.
Объединяются отдельные части системы, созданные на предыдущем этапе,
для построения целостного продукта.

13. V-образная модель

2. Нисходящие этапы (правая сторона буквы V):
• Модульное тестирование.
На этом этапе проверяют отдельные блоки и компоненты системы, чтобы
убедиться в правильности написания кода и реализации функций.
• Интеграционное тестирование.
Происходит проверка взаимодействия отдельных подсистем, объединение и
синхронизация их работы.
• Система в целом (системное тестирование).
Производится проверка всей системы целиком, оцениваются характеристики
производительности, надёжности и удобства использования.
• Проверка соответствий (валидация).
Последний этап — подтверждение того, что разработанный продукт
действительно решает заявленные задачи и соответствует потребностям
пользователей.

14. V-образная модель

Ключевая характеристика V-образной модели:
Главная особенность модели — постоянный контроль качества на каждом
этапе. Например, если на этапе сбора требований обнаружились упущения
или противоречия, это немедленно отражается на последующих этапах
разработки и тестирования, предотвращая возможные проблемы на последних
стадиях проекта.
Такая структура позволяет минимизировать число ошибок, улучшив общее
качество конечного продукта.
Примеры применения V-образной модели:
Типичные случаи успешного применения V-образной модели включают
проекты с жестко заданными требованиями и небольшим риском
значительных изменений в будущем, например:
• Проектирование медицинских устройств.
• Разработка бортовых авиационных систем.
• Создание финансовых платформ и банковских приложений.
Эти сферы требуют высокой степени надежности и отсутствия критичных
ошибок, поэтому здесь применение V-образной модели оправдывает себя.

15. V-образная модель

Преимущества V-образной модели
1. Повышенный уровень качества продукции. Поскольку тестирование идёт
параллельно процессу разработки, многие потенциальные ошибки
устраняются на ранних этапах.
2. Четкое разделение ролей и обязанностей. Каждый участник проекта ясно
осознаёт свои задачи и зоны ответственности.
3. Ранняя идентификация рисков. Проблемы выявляются раньше, что
снижает стоимость устранения возможных неисправностей позже.
Недостатки V-образной модели
1. Трудности с внесением изменений. Модель довольно статична, любое
серьёзное изменение потребует возврата к началу цепочки, что увеличивает
общие затраты и сроки.
2. Требует большого объёма документации. Подробная спецификация
необходима на каждом уровне, что может замедлить процесс разработки.
3. Скрытые проблемы могут остаться незамеченными, если не проводить
систематического анализа и тестирования.

16. Шаблон для V-образной модели

Процесс разработки по V-образной модели включает две главные ветви:
• Левая ветвь: разработка (анализ требований, проектирование, реализация).
• Правая ветвь: верификация и валидация (модульное тестирование,
интеграционное тестирование, системное тестирование, приемочные
испытания).

17. Методы управления проектами

3. Метод Rapid Application Development (RAD)
Этот подход основан на концепции быстрого прототипирования. Вместо
длительного проектирования, команда создаёт минимальный рабочий
прототип и быстро получает обратную связь от пользователей, чтобы
скорректировать направление развития продукта.
Преимущества:
• Быстрое получение обратной связи и улучшение качества продукта.
• Сокращение цикла разработки за счёт раннего выявления проблем.
Недостатки:
• Подходит преимущественно для небольших проектов с простыми бизнеспроцессами.
• Высокие затраты на разработку множества прототипов.
Rapid Application Development (RAD) — это подход к созданию программного
обеспечения, целью которого является ускорение процесса разработки и
сокращения общего времени вывода продукта на рынок. RAD основывается
на идее быстрого прототипирования и активного вовлечения конечных
пользователей в процесс разработки, что способствует повышению качества
конечного продукта и сокращению рисков невыполнения ожиданий заказчика.

18. Rapid Application Development

Основные принципы Rapid Application Development:
1. Быстрое прототипирование:
Основное преимущество RAD заключается в том, что разработчики создают
простой рабочий прототип, позволяющий заказчику увидеть будущий продукт
и внести корректировки на ранней стадии.
Чем быстрее прототип предоставляется заказчику, тем меньше задержек и
рисков ошибочного толкования требований.
2. Активное участие пользователей:
Пользователи привлекаются к обсуждению функциональных возможностей
продукта на всех этапах разработки.
Их мнение учитывается при принятии ключевых решений, что уменьшает
необходимость дальнейших доработок и улучшает удобство пользования
продуктом.

19. Rapid Application Development

3. Минимальная документация:
Документация в RAD играет второстепенную роль. Основной упор делается
на создание рабочих прототипов и интерактивных сессий с клиентами, что
ускоряет принятие решений и устраняет потребность в длительном написании
технических заданий.
4. Компактные команды:
Радикальное упрощение командной структуры позволяет сократить время
согласования и ускорить процесс разработки. Компактные группы
разработчиков работают совместно, постоянно обмениваясь информацией и
принимающими коллективные решения.
5. Используемые инструменты:
Современные среды разработки и библиотеки помогают значительно
повысить эффективность труда разработчиков. Они предоставляют готовые
шаблоны, классы и функции, позволяющие сосредоточиться непосредственно
на решении прикладных задач, исключая рутинные операции.

20. Rapid Application Development

Процесс RAD можно разделить на четыре этапа:
1. Определение требований:
Сначала определяются ключевые требования к будущему приложению. Они
уточняются посредством консультаций с пользователями и проведением
мозговых штурмов внутри команды.
2. Создание прототипа:
Затем создаётся первый рабочий прототип, демонстрирующий основную
функциональность продукта. Прототип регулярно показывается клиентам для
подтверждения правильности выбранных направлений и своевременного
внесения изменений.
3. Конструирование:
После утверждения базовых концепций начинается собственно разработка
программного продукта. Здесь используются специальные инструментальные
средства, помогающие создавать высокопроизводительные и надежные
приложения в кратчайшие сроки.
4. Завершающее тестирование и доставка:
Готовый продукт подвергается интенсивному тестированию, устранению
найденных ошибок и подготовке к выпуску. Окончательная версия
доставляется клиенту и внедряется в производственный процесс.

21. Rapid Application Development

Преимущества RAD
1. Скорость разработки: Короткие циклы создания прототипов способствуют
быстрому достижению желаемых результатов.
2. Снижение рисков: Участие пользователей в процессе разработки
предотвращает возникновение неожиданных требований на завершающем
этапе.
3. Более качественный продукт: Постоянная обратная связь гарантирует
удовлетворение реальных нужд потребителей.
4. Экономичность: Использование специализированных инструментов и
библиотек сокращает трудозатраты и экономит ресурсы.
Недостатки RAD
1. Необходимость квалифицированного персонала: Команда должна состоять
из опытных разработчиков, умеющих быстро оценивать ситуацию и
принимать обоснованные решения.
2. Небольшие масштабы: RAD не подходит для крупных долгосрочных
проектов с множеством зависимых элементов.
3. Дефицит документации: Недостаточность официальных документов
усложняет передачу проекта другим исполнителям и последующую
модернизацию.

22. Шаблон Rapid Application Development

1. Введение
Краткое описание проекта, целей и ожидаемого результата. Объясните, почему
выбрана методология RAD и какие выгоды она принесет вашему бизнесу.
2. Цели и ограничения проекта
Определите:
• Главные цели проекта.
• Основные ограничения (бюджет, сроки, ресурсы).
• Критерии успеха.
3. Предварительное исследование
Проведите изучение существующих аналогов и соберите требования
пользователей:
• Интервью с пользователями.
• Исследование конкурентов.
• Сбор информации о текущих проблемах и возможностях улучшения.

23. Шаблон Rapid Application Development

4. Формулировка требований
Создайте список требований, разбитых на категории:
• Функциональные требования.
• Нефункциональные требования (производительность, безопасность,
доступность).
• Дополнительные пожелания и идеи для дальнейшего развития.
5. Первоначальное прототипирование
Разработайте первоначальный макет или прототип для демонстрации
ключевым заинтересованным сторонам:
• UI/UX-дизайн.
• Логика работы ключевых экранов.
• Демонстрация базовой функциональности.
6. Концептуальная разработка
Осуществляйте первую реализацию продукта с использованием доступных
инструментов и технологий:
• Начало разработки основного функционала.
• Организация автоматического тестирования.
• Начальная интеграция модулей.

24. Шаблон Rapid Application Development

7. Промежуточные тесты и корректировки
Проверьте начальную версию продукта и проведите коррекцию на основе
собранных данных:
• Внутреннее тестирование (unit-тесты, интеграция).
• Внешнее тестирование (alpha/beta-версии).
• Сбор отзывов и предложений по улучшению.
8. Последующие итерации
Продолжайте развитие продукта через последующие циклы, реализуя
оставшиеся требования и дополнения:
• Повторяйте шаги 5-7 до момента, когда достигнуты все поставленные цели.
9. Заключительная интеграция и финальное тестирование
Соберите все элементы в единую систему и выполните заключительную
проверку:
• Интеграция оставшихся компонентов.
• Финальное тестирование (QA-тесты, стресс-тесты).
• Оптимизация производительности и устранение багов.

25. Шаблон Rapid Application Development

10. Выпуск продукта
Передайте готовый продукт пользователю и обеспечьте необходимую
инфраструктуру для его запуска:
• Установка и настройка.
• Предоставление инструкций и руководств.
• Работа с первыми отзывами пользователей.
11. Дальнейшее развитие и поддержка
Организуйте пострелизную поддержку и обновление продукта:
• Периодическое обновление продукта (bug-fixing, new features).
• Обучение пользователей.
• Решение вопросов и обращений.

26. Методы управления проектами

4. Метод Iterative and Incremental Development (ИИР)
Здесь используется концепция повторяемых циклов разработки, когда работа
выполняется небольшими частями (итерациями), каждая из которых приносит
дополнительную функциональность в итоговый продукт. Такой подход
позволяет минимизировать риски и своевременно получать обратную связь.
Преимущества:
• Раннее выявление ошибок и улучшение качества продукта.
• Легче контролировать прогресс и бюджет.
Недостатки:
• Требуется больше усилий на подготовку архитектуры и инфраструктуры.
• Возникают трудности с интеграцией отдельных компонентов.
Iterative and Incremental Development (Итеративная и инкрементальная
разработка) — это подход к разработке программного обеспечения, при
котором продукт создается поэтапно, небольшими порциями, называемыми
итерациями. Цель такого подхода — постепенное наращивание функционала и
качества продукта, что позволяет команде эффективно реагировать на
изменения требований и уменьшать риски, связанные с разработкой сложного
продукта сразу целиком.

27. Iterative and Incremental Development

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

28. Iterative and Incremental Development

Процесс Iterative and Incremental Development (I&ID) обычно выглядит
следующим образом:
1.
2.
3.
4.
5.
6.
Инициализация проекта: формулировка общих целей и назначение
начальной версии продукта.
Первая итерация: выбор небольшого объема функциональности для
первой версии продукта.
Выполнение итерации: реализация выбранной функциональности,
тестирование и интеграция.
Демонстрация и сбор отзывов: показ продукта заказчику и обсуждение
необходимых изменений.
Корректировка плана: обновление списка будущих задач и
перераспределение приоритетов.
Начало новой итерации: переход к следующему этапу разработки с учётом
полученной обратной связи.
Эти шаги повторяются снова и снова, пока продукт не достигает необходимого
уровня готовности.

29. Iterative and Incremental Development

Преимущества I&ID
• Обратная связь: постоянная коммуникация с заказчиком позволяет
корректировать направление разработки.
• Менее рискованно: небольшие изменения проще внедрять и проверять, чем
большие объёмы функционала.
• Эффективное распределение ресурсов: каждая итерация ставит конкретные
задачи, делая их выполнение контролируемым процессом.
• Постоянное улучшение качества: тестирование и интеграция происходят
непрерывно, снижая вероятность появления скрытых дефектов.
Подобный подход идеально подходит для проектов, характеризующихся
высокой неопределённостью, когда требования меняются на ходу или не
совсем ясны изначально. Например, это может касаться стартапа,
стремящегося исследовать новые рынки, или инновационной инициативы
крупной корпорации.
Однако важно помнить, что успешная реализация Iterative and Incremental
Development требует сильной самодисциплины команды, эффективного
взаимодействия между всеми участниками и грамотного распределения
ответственности.

30. Шаблон Iterative and Incremental Development

1. Введение
Описание сути проекта, его цели и причины выбора подхода Iterative and
Incremental Development (I&ID).
Приведение основных преимуществ I&ID, таких как возможность гибкого
реагирования на изменения и снижение рисков за счет маленьких
инкрементов.
2. Жизненный цикл проекта
Описание основной структуры жизненного цикла проекта по I&ID. Включает
в себя следующие ключевые этапы:
• Инициализация: формулировка общей концепции и выделение первого
инкремента.
• Планирование: разработка плана разработки, установка критериев оценки и
утверждение расписания.
• Исполнение: выполнение задач и выпуск очередного инкремента.
• Мониторинг и контроль: анализ состояния проекта, проверка выполнения
задач и корректировка курса.
• Заключение: завершение проекта, сдача итогового продукта и анализ
выполненных работ.

31. Шаблон Iterative and Incremental Development

3. Основные этапы разработки
3.1. Определение целей и ограничений
Формулировка целей проекта, установление требований, учет ограничений по
ресурсам и временным рамкам.
3.2. Первая итерация
3.2.1. Подготовка к первой итерации
• Выделение ядра функциональности.
• Назначение исполнителей.
• Распределение задач.
3.2.2. Реализация первой итерации
• Реализация отобранных задач.
• Оформление отчетов и ведение журнала изменений.
3.2.3. Демонстрация и сбор отзывов
• Презентация первого инкремента.
• Получение обратной связи от пользователей и заказчиков.
3.3. Следующие итерации
Повторение вышеуказанного цикла для следующих инкрементов, уточнение
требований, расширение функциональности и исправление выявленных
ошибок.

32. Шаблон Iterative and Incremental Development

4. Управление рисками
Описание способов идентификации и предотвращения потенциальных угроз
проекта:
• Перечень возможных рисков.
• Механизмы их предупреждения и смягчения последствий.
5. Оценка качества
Рассказ о критериях оценки качества продукта на каждой итерации:
• Тестирование (Unit-тесты, интеграционные тесты, QA).
• Ревью кода.
• Проверка соответствия требованиям.
6. Заключение проекта
Подведение итогов проекта, составление отчета о проделанной работе, разбор
успехов и неудач, предложение рекомендаций для последующих проектов.
7. Приложение
Дополнительные материалы и пояснения:
• Графики выполнения задач.
• Лист фиксации изменений.
• Таблица требований и их статуса.

33. Методы управления проектами

5. Метод Spiral Model («Спиральная модель»)
Модель сочетает идеи прототипирования и пошагового развития. Каждый цикл
начинается с малого и постепенно расширяется, пока не достигнет полной
функциональности.
Преимущества:
• Отличается лучшей устойчивостью к изменениям требований.
• Эффективен для сложных и дорогостоящих проектов.
Недостатки:
• Затраты на создание многочисленных прототипов могут оказаться высокими.
• Процесс может стать хаотичным без должного контроля.
Spiral Model (Спиральная модель) — это одна из популярных методологий
разработки программного обеспечения, предназначенная для снижения рисков и
повышения гибкости проекта. Её основная идея заключается в том, что
разработка проходит по спирали, состоящей из нескольких витков, каждый из
которых подразумевает серию шагов, аналогичных традиционному каскадному
подходу, но с добавлением важных аспектов управления рисками и постоянной
оценки.

34. Spiral Model

Основные характеристики спиральной модели
1. Фазы повторения:
В отличие от традиционного каскадного подхода, спиральная модель
предусматривает повторение ряда шагов на каждом витке спирали. Это
позволяет не только уточнять требования и развивать продукт, но и периодически переоценивать состояние проекта и анализировать возникающие риски.
2. Оценка рисков:
Важнейшей особенностью спиральной модели является обязательное включение
анализа рисков на каждом витке. Именно эта составляющая отличает её от
других подходов и делает её идеальной для проектов с высокой степенью
неопределённости.
3. Построение прототипов:
Спиральная модель поддерживает концепцию быстрого прототипирования,
позволяя показать клиенту предварительный вариант продукта на раннем этапе и
получить его реакцию. Это минимизирует риски недопонимания и помогает
скорректировать дальнейшее развитие проекта.
4. Параллельная разработка:
Продукт развивается по мере прохождения витков спирали, причём на каждом
следующем витке строится следующая версия продукта, содержащая
дополнительные возможности и улучшенную реализацию.

35. Spiral Model

Каждый виток спирали включает четыре основных шага:
1. Определение целей и ограничений:
Устанавливаются критерии успешности текущего витка, выбираются
приоритеты и ограничения проекта.
2. Анализ рисков:
Определяются потенциальные угрозы и препятствия, влияющие на успех
проекта. Формируются стратегии минимизации рисков.
3. Развитие и оценка:
Создается рабочая версия продукта (прототип), и производится её оценка.
Полученные отзывы и результаты тестирования влияют на формирование
следующего витка.
4. Принятие решений:
Исходя из полученного опыта и анализа рисков, принимается решение о
продолжении или завершении проекта.
Эти шаги повторяются многократно, создавая эффект вращения по спирали,
отсюда и название модели.

36. Spiral Model

Преимущества спиральной модели
1. Работа с рисками: Формальное рассмотрение рисков на каждом витке
позволяет снизить негативные последствия их возникновения.
2. Повышение качества: Регулярное тестирование и обратная связь
обеспечивают высокое качество конечного продукта.
3. Лучшая реакция на изменения: Спонтанные изменения могут быть учтены
на любом этапе проекта.
4. Получение одобрения заказчика: Клиент участвует в процессе разработки,
давая возможность быстро оценить промежуточные результаты.
Недостатки спиральной модели
1. Большие накладные расходы: Многочисленные итерации и необходимость
повторного анализа увеличивают объём документации и время на организацию.
2. Чувствительность к рискам: Неудачный анализ рисков на одном витке может
привести к значительным проблемам в дальнейшем развитии проекта.
3. Требование высокой квалификации команды: Команда должна уметь
грамотно организовывать процессы, собирать обратную связь и правильно
интерпретировать её.

37. Шаблон Spiral Model

Введение
Спиральная модель (Spiral Model) — это подход к разработке программного
обеспечения, который отличается особым вниманием к риску и
последовательным прохождением четырёх фаз на каждом витке спирали:
определение целей, оценка рисков, развитие и тестирование, принятие решений.
Каждое движение по спирали приближает вас к законченному продукту.
1. Первый виток (инициализация)
Определение целей
• Постановка миссии проекта и предварительных целей.
• Определение главного назначения и сфер применения продукта.
Оценка рисков
• Идентификация возможных препятствий и трудностей.
• Прогноз рисков, связанных с бюджетом, временем и технологиями.
Развитие и тестирование
• Создание прототипа или минимально жизнеспособного продукта (MVP).
• Демонстрация проекта основным заинтересованным лицам.
Принятие решений
• Утверждение стартовой версии продукта.
• Постановка целей и ограничений для второго витка.

38. Шаблон Spiral Model

2. Второй виток (расширение)
Определение целей
• Расширение и уточнение требований к продукту.
• Добавление новых функций и улучшений.
Оценка рисков
• Повторная оценка рисков с учетом нового функционала.
• Предложение мер противодействия выявленным рискам.
Развитие и тестирование
• Реализация предложенных улучшений и нового функционала.
• Выполнение модульного и интеграционного тестирования.
Принятие решений
• Одобрение усовершенствованной версии продукта.
• Постановка задач для третьего витка.

39. Шаблон Spiral Model

3. Третий виток (доработка)
Определение целей
• Анализ обратной связи и пожеланий пользователей.
• Рассмотрение возможности добавления дополнительной функциональности.
Оценка рисков
• Оценка влияния нововведений на стабильность и безопасность продукта.
• Внесение изменений в планы рисков.
Развитие и тестирование
• Реализация новых функций и доработок.
• Проведение полноценного тестирования всех компонент.
Принятие решений
• Принятие решения о готовности к выпуску готовой версии продукта.
• Задание целей для четвертого витка (если потребуется).

40. Шаблон Spiral Model

4. Четвёртый виток (заключение)
Определение целей
• Завершение разработки и подготовка к передаче продукта в эксплуатацию.
• Упрощение документации и подготовка инструкции по сопровождению.
Оценка рисков
• Проверка готовности продукта к выходу на рынок.
• Оценка остаточных рисков и разработка путей их минимизации.
Развитие и тестирование
• Выпуск последней версии продукта.
• Проведение приёмочных испытаний и тестирование в реальной среде.
Принятие решений
• Окончательное утверждение продукта.
• Передача продукта заказчику и публикация продукта.
Заключение
Подведите итоги проекта, проанализировав пройденные витки и выявленные
риски. Сделайте вывод о целесообразности продолжения разработки и укажите
перспективы дальнейшего развития продукта.

41. Методы управления проектами

6. Метод Agile (Гибкие методологии)
Наиболее популяризированный подход в современных программных проектах.
Характеризуется быстрым созданием минимально жизнеспособного продукта
(MVP), постоянным взаимодействием с пользователями и возможностью легко
изменять направления разработки.
Среди гибких методологий выделяют:
• Scrum: методология, включающая постоянные двухнедельные циклы
(спринты), ежедневные встречи и высокую вовлечённость команды.
• Kanban: методика, направленная на визуализацию рабочего процесса и
ограничения количества одновременно выполняемых задач.
• XP (Экстремальное программирование): философия, подчеркивающая
простоту дизайна, постоянное рефакторинг и автоматическое тестирование.

42. Agile

Agile (Агил) — это современный подход к управлению проектами, особенно
популярным в разработке программного обеспечения. Термин появился в
результате публикации Манифеста Agile-разработки в 2001 году группой
специалистов, стремившихся противопоставить устаревшим иерархическим
методикам управления новыми гибкими подходами.
Главное отличие Agile от традиционных методов (например, Waterfall)
заключается в его способности быстро адаптироваться к изменениям,
поддержке открытого сотрудничества между членами команды и ориентации
на создание высококачественных продуктов, соответствующих интересам
заказчика.
Преимущества:
• Высокая скорость адаптации к изменениям.
• Низкое количество дефектов благодаря постоянному тестированию и
интеграции.
Недостатки:
• Неприменим для организаций с жесткой структурой управления.
• Необходимо наличие высококвалифицированной и дисциплинированной
команды разработчиков.

43. Agile

Основы философии Agile
Манифест Agile-разработки провозглашает четыре фундаментальных
принципа:
1.
2.
3.
4.
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее заключения контракта.
Готовность к изменениям важнее следования первоначальному плану.
Эти принципы подчёркивают важность человеческого фактора, живой
коммуникации и быстрого отклика на запросы пользователей. А также
предлагают смещение акцента с бюрократической формальности на реальную
ценность продукта.

44. Agile

Хотя термин "Agile" обобщает целый класс подходов, существует несколько
признанных фреймворков, основанных на этой философии:
• Scrum: Одна из самых популярных методологий, предусматривающих
деление работы на небольшие промежутки времени (спринты), регулярные
собрания и активный контакт с заказчиком.
• Kanban: Методология, использующая визуализацию задач и ограничение
числа одновременных задач для оптимизации потока работ.
• Lean: Ориентация на удаление лишнего и сосредоточение внимания на
ценных функциях, созданных специально для заказчика.
• Extreme Programming (XP): Экстремальное программирование, которое
поощряет пары разработчиков, быструю доставку релизов и постоянное
тестирование.
Все эти методологии основаны на общих принципах Agile, но имеют
уникальные механизмы достижения гибкости и быстроты.

45. Agile

Основные преимущества Agile-подхода:
1. Способность быстро адаптироваться к изменениям:
В Agile-командах изменения приветствуются, так как они могут
способствовать улучшению продукта.
2. Постоянная обратная связь:
Регулярный контакт с заказчиком позволяет своевременно понимать его
пожелания и исправлять любые отклонения.
3. Команды автономны и самоуправляемы:
Члены команды самостоятельно принимают решения, повышая мотивацию и
инициативу.
4. Качество повышается естественным образом:
Частые релизы и тестирования делают возможным постоянное улучшение
качества продукта.
5. Понимание продукта улучшается:
По мере продвижения проекта понимание потребностей и технологий
углубляется, что положительно сказывается на конечном результате.

46. Agile

Agile-методологии прекрасно подходят для:
• Компании, работающие в условиях постоянных изменений и высоких
рисков.
• Малые и средние предприятия, ищущие способы ускорения выхода
продукта на рынок.
• Стартапы, которым нужно быстро выпускать MVP (Minimum Viable
Product) и получать обратную связь от пользователей.
Также Agile успешно применяется в крупных компаниях, желающих повысить
эффективность работы и укрепить корпоративную культуру открытости и
доверия.
Несмотря на многочисленные достоинства, Agile иногда критикуется за:
• Нехватку формальной документации, что затрудняет масштабируемость и
преемственность проектов.
• Проблемы с управлением большими командами и интегрированными
системами.
• Слабую поддержку крупных предприятий с сильно регламентированными
процессами.
• Agile-фреймворки предъявляют высокие требования к качеству команды и
уровню профессионализма руководителя

47. Шаблон Agile

1. Введение
Краткое описание проекта, его целей и контекста, обоснование выбора Agileметода. Включите ссылку на манифест Agile и перечислите ключевые
ценности и принципы, используемые в вашем проекте.
2. Команда проекта
Опишите состав команды, ее роли и обязанности. Используйте таблицы для
наглядности:

48. Шаблон Agile

3. Требования к проекту
Приведите краткое изложение требований, включая функциональные и
нефункциональные аспекты. Желательно оформить их в форме user stories
(описание задачи от лица пользователя).
Пример user story:
"Как пользователь, я хочу иметь возможность фильтровать товары по цене,
чтобы упростить поиск нужного товара."
4. Планирование проекта
4.1. Roadmap (общий план)
Опишите глобальные цели проекта и график выпуска ключевых версий
продукта. Возможно, включить простую таблицу или диаграмму Gantt.
4.2. Backlog (список задач)
Представьте перечень задач (backlog items), сгруппированный по категориям
(например, User Stories, Bugs, Features). Можно использовать следующую
форму:

49. Шаблон Agile

5. Спринты (Sprints)
Опишите планирование спринтов, длительность каждого спринта и цели
спринтов. Можете добавить схему или таблицу, иллюстрирующую динамику
работы команды.
Пример описания спринта:
Спринт #1 (продолжительность: 2 недели):
• Цели: Реализация первичной версии каталога товаров, регистрация
пользователей.
• Объем работы: 40 часов.
6. Ежедневные стендап-встречи (Daily Standups)
Кратко опишите процедуру ежедневных собраний, цели и участники.
Обязательно упомяните стандартные вопросы:
• Что сделано за вчерашний день?
• Какие задачи стоят на сегодняшний день?
• Есть ли какие-либо блокировки или препятствия?

50. Шаблон Agile

7. Ретроспективы
Опишите процесс ретроспективных собраний после окончания каждого
спринта, как проходят обсуждения, как собираются идеи по улучшению
процесса.
8. Показатели эффективности (Metrics)
Какие KPI будут использованы для измерения эффективности команды и
качества продукта? Например:
• Скорость выполнения задач (Velocity);
• Качество (дефекты на единицу функционала);
• Satisfaction Index (удовлетворенность клиентов).
9. Результаты и заключение
В этом разделе резюмируйте достигнутые результаты, расскажите о проблемах
и уроках, которые извлекла команда. Дополнительно можете представить
статистику или графики, подтверждающие рост эффективности.

51. Методы управления проектами

7. Метод Lean Software Development (LSD)
Подход основывается на принципах бережливого производства, направленных
на устранение потерь и оптимизацию процессов разработки ПО. Основная
цель LSD — максимальное сокращение ненужных операций и увеличение
ценности продукта для клиента.
Принципы LSD:
• Устранение потерь (waste elimination).
• Постройка процесса вокруг потоков ценности (value stream mapping).
• Управление потоком (flow management).
• Тянущие системы (pull systems).
Преимущества:
• Фокусировка исключительно на значимой работе.
• Экономия ресурсов и уменьшение затрат.
Недостатки:
• Подходит не для всех типов проектов.
• Требует существенного изменения культуры и поведения сотрудников.

52. Lean Software Development

Lean Software Development (бережливое производство программного
обеспечения) — это подход к разработке ПО, заимствовавший принципы
производственной системы Toyota (TPS) и адаптировавший их к миру
разработки программного обеспечения.
Главной идеей Lean является устранение любых видов потерь и ненужных
расходов в процессе разработки, что позволяет достичь максимальной
эффективности и повысить качество конечного продукта.
Практически Lean-подход проявляется в следующих аспектах:
• Автоматизация: Максимальное исключение ручной работы и
стандартизация процессов.
• Непрерывная интеграция: Частая интеграция изменений и
автоматизированное тестирование.
• Микро-сервисная архитектура: Модульность системы, позволяющая
менять и добавлять компоненты независимо друг от друга.
• Простота кода: Стремление к чистоте и читаемости кода, минимальное
дублирование и максимальная лаконичность.

53. Lean Software Development

Основные принципы Lean Software Development
1. Устранение потерь (Eliminate Waste):
Одним из главных принципов Lean является борьба с потерями, то есть
любыми действиями, которые не добавляют ценности конечному продукту.
Потери могут проявляться в виде избыточной документации, неэффективных
коммуникаций, непродуктивных совещаний и неиспользованного кода.
2. Создание ценностей (Amplify Learning):
Второй важный принцип Lean призывает к постоянному обучению и
совершенствованию процесса разработки. Команда должна учиться на своём
опыте, находить пути повышения эффективности и постоянно искать новые
знания и технологии.
3. Решение задач позднее (Defer Commitment):
Согласно этому принципу, важные решения принимаются тогда, когда имеется
максимум доступной информации. Отложенные обязательства снижают риск
неправильных решений и позволяют более гибко реагировать на изменения.

54. Lean Software Development

4. Послепродажное совершенствование (Deliver Fast):
Lean рекомендует поставлять работающий продукт как можно скорее, чтобы
начать получать обратную связь от пользователей и продолжать развиваться на
основании их запросов.
5. Свобода от перегрузки (Empower the Team):
Командам предоставляется свобода и полномочия самостоятельно решать, как
наилучшим образом выполнять задачи. Это стимулирует креативность и
инициативность членов команды.
6. Максимизация целого (See the Whole):
Весь процесс рассматривается как единое целое, где каждая деталь влияет на
остальные. Соответственно, оптимизировать надо всю систему, а не отдельные
её части.

55. Lean Software Development

Преимущества Lean Software Development
1. Повышение качества:
Бережливый подход помогает устранить лишнюю нагрузку и сосредотачивает
усилия на достижении значимых результатов.
2. Снижение затрат:
Исключая потери и бесполезные активности, компания экономит деньги и
ресурсы.
3. Быстрота доставки:
Постепенная доставка продукта позволяет рано начинать получать прибыль и
накапливать полезную обратную связь.
4. Оптимизация процессов:
Наличие чётких метрик и постоянного анализа позволяет улучшить рабочие
процессы и повысить эффективность команды.

56. Lean Software Development

Однако, как и любая методология, Lean имеет свои слабые стороны:
• Может требовать радикальных изменений в организационной структуре и
культурных установках компании.
• Полностью исключить потерю сложно, и некоторые виды "потерь"
неизбежны в сложных системах.
• Переход на Lean часто сталкивается с сопротивлением со стороны
консервативных сотрудников и руководителей.
Применение Lean в современном мире
Сегодня Lean активно используется не только в ИТ-компаниях, но и в других
секторах экономики. Особенно он популярен в стартапах, работающих в
условиях ограниченных ресурсов и высокой конкуренции. Многие крупные
технологические гиганты также начали внедрять Lean-практики, сочетая их с
методами Agile и DevOps.

57. Шаблон Lean Software Development

1. Введение
Предоставьте вводную информацию о проекте, его целях и причинах выбора
подхода Lean Software Development. Сообщите, каким образом Lean-подход
повлияет на вашу стратегию разработки и какие преимущества вы
рассчитываете получить.
2. Стратегия минимизации отходов
2.1. Анализ текущей ситуации
Проведите оценку текущего положения дел и определите области, где
наблюдаются наибольшие потери:
• Перепроизводство.
• Несоответствующие требования.
• Избыточная обработка.
• Простои и задержки.
• Транспортировка данных и артефактов.
• Бесполезные перемещения (человеческие ресурсы).
• Недоиспользование талантов и способностей сотрудников.
2.2. Формулировка стратегии
Определите конкретные меры по снижению указанных потерь и способы
повышения эффективности работы команды.

58. Шаблон Lean Software Development

3. Карта потока создания ценности (Value Stream Mapping)
Представьте графическую иллюстрацию (диаграмму) процесса разработки с
указанием всех основных точек и этапов, а также места возникновения потерь.
Используйте это изображение для анализа узких мест и поиска областей для
улучшения.
4. Улучшения и практика Continuous Improvement
4.1. Программа улучшений
• Определите, какие изменения планируете провести в ближайшее время:
• Автоматизация рутинных задач.
• Рефакторинг старого кода.
• Улучшение инструментов CI/CD.
• Оптимизация коммуникационных процессов.
4.2. Целевые показатели (KPI)
Установите измеримые целевые показатели, которые позволят отслеживать
прогресс и достижение целей Lean-подхода:
• Количество выпущенных релизов.
• Среднее время выполнения задачи.
• Коэффициент дефектов на единицу функционала.

59. Шаблон Lean Software Development

5. Кадровая политика и культура Lean
5.1. Сотрудники и компетенции
Продемонстрируйте план повышения компетенций сотрудников и расширения
полномочий для стимулирования творчества и инициативности.
5.2. Вопросы мотивации
Опишите мероприятия по повышению внутренней мотивации сотрудников,
обеспечивающие лучшее усвоение Lean-контекстов.
6. Материальные ресурсы и инфраструктура
Опишите оборудование, программное обеспечение и инфраструктуру, которые
потребуются для реализации Lean-подхода. Укажите требуемые инвестиции и
предлагаемые способы экономии.
7. Анализ выгод и рисков
7.1. Ожидаемая выгода
Подробно опишите ожидаемый экономический эффект от внедрения Lean:
• Снижение затрат на разработку.
• Рост производительности команды.
• Сокращение времени поставки продукта.

60. Шаблон Lean Software Development

7.2. Оценка рисков
Определите возможные риски, связанные с внедрением Lean, и способы их
минимизации:
• Риски неверного восприятия сотрудниками.
• Проблемы, связанные с изменением привычной культуры работы.
8. Итоговая таблица сравнения до и после Lean
Представьте сравнительную таблицу показателей до и после внедрения Leanподхода, чтобы наглядно продемонстрировать положительные эффекты.
9. Заключение
Подведите итоги и сделайте выводы о применимости Lean Software
Development для вашего проекта. Упомяните планы по дальнейшему развитию
и оптимизации процессов.

61. Методы управления проектами

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

62. Благодарю за внимание