Обзор методологий : ●XP ●Lean ●FDD ●Kanban ●DSDM Atern ●PMI●PRINCE 2 ●Crystal Обзор фреймворков: ●RUP ●MSF ●Scrum

1. Управление проектами. Модуль 2.

2. Лекция 9-10
Обзор методологий :
● XP
● Lean
● FDD
● Kanban
● DSDM Atern
● PMI
● PRINCE 2
● Crystal
Обзор фреймворков:
● RUP
● MSF
● Scrum

3. Экстремальное программирование (XP)
Экстремальноепрограммирование (англ.Extreme
Programming,XP) - является методологией программного
обеспечения, которая призвана улучшать качество программного
обеспечения и реагировать на изменяющиеся требования
клиентов.
Цели XP:
Основными целями XP являются повышение доверия
заказчика к программному продукту путем предоставления
реальных доказательств успешности развития процесса
разработки и резкое сокращение сроков разработки продукта.
При этом XP сосредоточенона минимизации ошибок на ранних
стадиях разработки. Это позволяет добиться максимальной
скорости выпуска готового продукта и даёт возможность
говорить о прогнозируемости работы. Практически все приемы
XP направлены на повышение качества программного продукта.

4. Экстремальное программирование (XP)
XP практики:
● Разработка через тестирование
● Игра в планирование
● Заказчик всегда рядом
● Парное программирование
● Непрерывная интеграция
● Рефакторинг кода
● Частые небольшие релизы
● Простота проектирования
● Метафора системы
● Коллективное владение кодом
● Стандарт оформления кода
● 40-часовая рабочая неделя

5. Экстремальное программирование (XP)
● XP роли:
● Заказчик
● Разработчик
● Тестировщик
● Доп.роли: трекер, коуч
● XP артефакты:
● План работ заказчика
● План релизов
● План итераций
● Приемочные тесты
● Таблицы,схемы

6. Lean software development
Бережливая разработкапрограммного обеспечения-
методология разработки программного обеспечения,
использующаяметоды концепции бережливого
производства. Возникла из среды сторонников концепции
гибкой методологии разработки.
Представляетсобой методологию, которая ориентирована
на определение, созданиеи доставку сложных
программных систем, то что помогает бизнесу оставаться
конкурентоспособным.LDS использует традиционные
принципы бережливостив модифицированной форме,а
также набор из 22 инструментови сравниваетинструменты
с гибкими практиками.Lean похож на Scrum, так как
больше касается аспектов управленияпроектами
разработки ПО, а не технических ролей.

7. Lean software development
● ПринципыLean
● Исключение потерь
● Повышение качества
● Создание знаний
● Отсроченные обязательства
● Быстрая поставка
● Уважение людей
● Полная оптимизация
● Роли Lean:
● Скрам мастер
● Заказчик
● Разработчики

8. FDD- Feature Driven Development
Feature driven development(FDD, разработка,
управляемаяфункциональностью) — итеративная
методология разработки программного обеспечения,
одна из гибких методологий разработки (agile).FDD
представляет собой попытку объединитьнаиболее
признанныев индустрииразработки программного
обеспечения методики, принимающиеза основу
важнуюдля заказчика функциональность (свойства)
разрабатываемогопрограммного обеспечения.
Основной целью данной методологии является
ыразработка реального, работающегопрограммного
обеспечения систематически,в поставленныесроки.

9. FDD- Feature Driven Development
● Состоит из основных 5 видов процессов:
● Разработкаобщей модели
● Составление списка
● Планирование работы над каждой функцией
● Проектирование функции
● Реализация функции
● Роли FDD:
● Менеджер проектов
● Главный архитектор
● Менеджер развития
● Разработчик
● Экспертдомена
● Тестировщик
● Технический писатель
● Деплойментспециалист

10. Kanban метод
Канбан- метод управленияразработкой, реализующий
принцип«точно в срок» и способствующий равномерному
распределению нагрузки между работниками.При
данном подходе весь процесс разработки прозрачен для
всех членов команды. Задачи по мере поступления
заносятсяв отдельный список, откуда каждый
разработчикможет извлечь требуемую задачу.
Основная задача карт Канбан в этой системе— это
уменьшатьколичество «выполняющейсяв данный
момент работы»(work in progress).

11. Kanban- принципы, практики
● ПринципыКанбан:
● Опора на существующие метода разработки
● Предварительная договренность о проведении важных
изменений
● Уважение к существующему порядку,ролям и
обязанностям
● Поощрение инициативы
● Практики Канбан:
● Визуализировать
● Лимит по задачам
● Постоянное улучшение
● Время цикла
● Можно изменять ход производства/разработки

12. DSDM Atern
Метод разработки динамических систем (Dynamic Systems
Development Method, DSDM) - это главным образом методика
разработки программного обеспечения, основанная на
концепции быстрой разработки приложений (Rapid Application
Development, RAD). DSDM - это итеративный и инкрементный
подход, который придаёт особое значение продолжительному
участию в процессе пользователя/потребителя.
Цель метода - сдать готовый проект вовремя и уложиться в
бюджет, но в то же время регулируя изменения требований к
проекту во время его разработки. DSDM входит в семейство
гибкой методологии разработки программного обеспечения, а
также разработок не входящих в сферу информационных
технологий.

13. DSDM Atern
Основные принципы:
● Вовлечение пользователя- это основа ведения эффективного проекта,где разработчикиделят с
пользователями рабочее пространствои поэтому принимаемыерешениябудут более точными.
● Команда должнабытьуполномоченаприниматьважные для проектарешения безсогласования с
начальством.
● Частая поставка версийрезультата,с учётом такогоправила,что «поставитьчто-тохорошее раньше - это
всегда лучше,чем поставитьвсё идеальносделанное в конце».Анализпоставокверсийс предыдущей
итерации учитываетсяна последующей.
● Главный критерий- какможно более быстрая поставкапрограммногообеспечения,которое удовлетворяет
текущим потребностям рынка.Но в то же время поставкапродукта,который удовлетворяетпотребностям
рынка,менее важна,чем решение критическихпроблем в функционале продукта.
● Разработка- итеративнаяи инкрементная.Она основываетсяна обратной связис пользователем,чтобы
достичьоптимальногос экономической точки зрениярешения.
● Любые изменениявовремя разработки- обратимы.
● Требованияустанавливаютсяна высоком
уровне прежде,чем начнётсяпроект.
● Тестирование интегрированов жизненный
цикл разработки.
● Взаимодействие и сотрудничествомежду
всеми участникаминеобходимодля его эффективности.

14. PRINCE 2 - метод
PRINCE2(акроним от PRojects IN Controlled Environments -
проекты в контролируемыхсредах) представляет собой
структурированный методуправленияпроектами,
одобренный правительствомВеликобританиив качестве
стандарта управленияпроектами в социальнойсфере.
Методология PRINCE2 включает в себя подходы к
менеджменту,контролю и
организациипроектов.
Является гибким методом
и ориентированна
все типы проектов.

15. PRINCE 2
Методология PRINCE2 в отличие от, например,свода знаний PMBOK не содержит:
● Специализированных аспектов управленияпроектом,например,отраслевых;
● Конкретных практик и инструментов управленияпроектами,таких как диаграмма Гантта,
WBS и т.п.
PRINCE2 концентрируетсяна управленческих сторонах проекта,выраженных в 7 принципах, 7
процессах и 7 темах проекта.
● 7 принципов определяют общие правила управления проектами по PRINCE2, определяют
базу методологии;
● 7 процессов определяют шаги продвиженияпо проектномуциклу;
● 7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.
Кроме того, PRINCE2 рекомендует адаптироватьметодологиюпод каждую конкретную
организацию.
● В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:
● Бизнес-аспект (Принесёт ли этот проект выгоду?)
● Потребительский аспект (Какой нужен продукт, что мы будем делать?)
● Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)
В PRINCE2 более чётко определённая структура команды проекта, чем у большинства подходов к
проектномууправлению. Это связано с тем, что PRINCE2 ориентированна масштабные
государственные проекты и крупные организации.

16. PRINCE 2- схема ролей

17. PRINCE 2 – “+”/”-”
Сильные стороны PRINCE2
● Адаптируемость к особенностям организации;
● Наличие чёткого описания ролей и распределения
ответственности;
● Акцент на продуктах проекта;
● Определённые уровни управления;
● Фокус на экономической целесообразности;
● Последовательность проектной работы;
● Акцент на фиксации опыта и постоянном совершенствовании.
Слабые стороны PRINCE2
● Отсутствие отраслевых практик;
● Отсутствие конкретных инструментов для работы в проекте.

18. Crystal Clear ( семейство)
CrystalClear – это легковесная гибкая методология,
созданная АлистеромКоуберном (Cockburn, 2004).Она
предназначена для небольшихкоманд в 6-8 человек для
разработки некритичныхбизнес-приложений.Как и все
гибкие методологии создания приложений Crystal Clear
больше опирается на людей, чем на процессы и
артефакты.
Единственной «лучшей»методологии Crystal Clear нет,
каждая из модификацийподходит для разных типов
проектов. При этом сама организация или проект
создают эту модификацию на основе «генетического
кода» (базовыхправил использования) Crystal

19. Crystal Family ( семейство)
Crystal Clear использует семь методов/практик, три из которых являются обязательными:
● Частая поставка продукта
● Улучшения через рефлексию
● Личные коммуникации
● Чувство безопасности
● Фокусировка
● Простой доступ к экспертам
● Качественное техническое окружение
Самая простая из возможных классификаций
Crystal — по критерию количества людей в проекте:
Clear — от 2 до 8 человек,
которые сидят вместе в одном или смежных офисах
Yellow — 10-20 человек
Orange — 20-50 человек в команде
Red — от 50 до 100.
Для масштабных проектов
используют дополнительные цвета:
Maroon, Blue и Violet.

20. PMI- PMBok
Области знаний:
● Управление интеграцией проекта (Project Integration Management).
● Управление содержанием проекта (Project Scope Management)
● Управление сроками проекта (Project Time Management).
● Управление стоимостью проекта (Project Cost Management).
● Управление качеством проекта (Project Quality Management).
● Управление человеческими ресурсами проекта (Project Human
Resource Management).
● Управление коммуникациями проекта (Project Communications
Management).
● Управление рисками проекта (Project Risk Management)
● Управление поставками проекта (Project Procurement Management).
● Управление заинтересованными сторонами проекта (Project
Stakeholder Management).

21. PMI- PMBok
Группы процессов:
● Группа процессов инициации
● Группа процессов планирования
● Группа
процессов исполнения
● Группа процессов
мониторинга и
управления
● Группа
завершающих
процессов

22. RUP- Rational Unified Process
Rational Unified Process (RUP) — методология
разработки программногообеспечения, созданная
компанией Rational Software.
Представляет собой комплексную структуру процессов,
которая обеспечивает практику разработки
программного обеспеченияи управления проектами.
Можно легко настроить RUP для удовлетворения
уникальных потребностей вашего проекта. Он
позволяет вам выбирать и развертывать только те
компоненты процесса, которые вам нужны

23. RUP- Rational Unified Process
ПринципыRUP:
● Ранняя идентификация и непрерывное (до окончания проекта) устранение
основных рисков.
● Концентрация на выполнении требований заказчиков к исполняемой
программе (анализ и построение модели прецедентов (вариантов
использования)).
● Ожидание изменений в требованиях, проектных решениях и реализации в
процессе разработки.
● Компонентная архитектура,
реализуемая и тестируемая на
ранних стадиях проекта.
● Постоянное обеспечение качества на
всех этапах разработки проекта
● Работа над проектом в сплочённой
команде, ключевая роль в которой
принадлежит архитекторам.

24. MSF- Microsoft Solution Framework
MicrosoftSolutions Framework (MSF)— методология
разработки программного обеспечения, предложенная
корпорацией Microsoft. MSF опирается на практический
опыт Microsoft и описывает управлениелюдьми и
рабочими процессами в процессе разработки решения.
MSF содержит:
модели:
● модель проектной группы
● модель процессов
дисциплины:
● дисциплина управлениепроектами
● дисциплина управлениерисками
● дисциплина управлениеподготовкой

25. MSF- Microsoft Solution Framework
MSFвключаетв себя ряд основныхпринципов.Вот те из них, которые имеют
отношение к успешной работе команды:
● Распределение ответственностипри фиксации отчетности
● Наделяйте членов командыполномочиями
● Концентрируйтесь на бизнес-приоритетах
● Единое видение проекта
● Проявляйте гибкость— будьте готовы к переменам
● Поощряйте свободноеобщение
Успешное использованиемодели
проектной группы MSFосновывается
на ряде ключевых концепций (key concepts):
● Командасоратников
● Сфокусированностьна нуждахзаказчика
● Нацеленность на конечный результат
● Установкана отсутствие дефектов
● Стремление к самосовершенствованию
● Заинтересованные командыработаютэффективно

26. Scrum Framework
Скрам (от англ – Scrum “схватка”)- фреймворк гибкой
разработки. Фреймворк основан на эмпирическом методе и
предназначен для разработки продуктов высокой ценности в
запутанной среде.
Это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные и
небольшие по времени итерации, называемые спринтами
(sprints), предоставлять конечному пользователю работающее
ПО с новыми возможностями, для которых определён
наибольший приоритет. Возможности ПО к реализации в
очередном спринте определяются в начале спринта на этапе
планирования и не могут изменяться на всём его протяжении.
При этом строго фиксированная небольшая длительность
спринта придаёт процессу разработки предсказуемость и
гибкость.

27. Scrum Framework
● Практики Скрама:
● Ежедневные митинги
● Игра в планирование
● Демо – презентация
● Ретроспектива
● Роли в Скраме
● Скрам мастер
● Владелец продукта
● Команда
● Скрам Артефакты
● Беклог продукта
● Беклог спринта (итерации)
● Диаграмма сгорания

28. Scrum Framework
● Сильные стороны Scrum
● Scrum был разработан дляпроектов, в которыхнеобходимы «быстрые победы»
в сочетании с толерантностьюк изменениям.Кроме того, этот фреймворк
подходитдля ситуаций, когдане все члены командыимеют достаточныйопыт в
той сфере, в которой реализуетсяпроект – постоянные коммуникациимежду
членами командамипозволяют недостаток опытаили квалификации одних
сотрудниковза счёт информации и помощи от коллег.
● Слабые стороны Scrum
● Scrum очень требователен к командепроекта. Она должнабыть небольшой (5-9
человек) и кроссфункциональной– то есть члены командыдолжны обладать
более чем одной компетенцией, необходимой дляреализации проекта.
Например разработчикПО должен обладатьпознаниямив тестировании и
бизнес-аналитике.Делаетсяэто для того, чтобы часть командыне «простаивала»
на разных этапах проекта,а также для того, чтобы сотрудники могли помогатьи
подменятьдруг друга.
● Кроме того, члены командыдолжныбыть «команднымиигроками», активно
брать на себя ответственностьи уметь самоорганизовываться.Подобратьтакую
зрелую командуочень непросто!
● Scrum подходитне для всех команди организаций ещё и потому, что
предлагаемыйпроцесс может не подойти для разработкиконкретного продукта
– например промышленногостанкаили постройки здания.