эволюция методологий управления (водопад, rup, agile) ...

Эволюция методологий управления (водопад, RUP, agile)

Дмитрий Башакин, Михаил КумсковУчебный Центр Luxoft

О докладчике

• Дмитрий Башакин ([email protected])• Михаил Кумсков ([email protected])• Luxoft, группа компаний IBS

• –эксперты Учебного Центра (www.Luxoft-Training.ru)

Copyright © 2009 Учебный Центр Luxoft (www.Luxoft-Training.ru)2

mailto:[email protected]

http://www.luxoft-training.ru/

Разработка ПО – хаос неизбежен?


Кто виноват?Нет, не так: что делать?

Базис большинства проблем с проектами по разработке ПО:• Молодость отрасли – десятки лет• «Детская болезнь» – попытка подходить к ИТ-проектам

как к разновидности «классических» проектов

Причины уникальности программных проектов:• Сложность• Изменчивость• Непрофессионализм


Так что же, все-таки, делать?

• Знать и учитывать уникальность отрасли «разработка ПО»• Учиться

• Читать

• Слушать

• Пробовать

• There is no silver bullet*, но есть значительный индустриальный опыт, методологии и лучшие практики

• РИСКИ!

Copyright © 2009 Учебный Центр Luxoft (www.Luxoft-Training.ru)

*«Серебряной пули нет» (Фредерик Брукс, очерк, 1986)

5

Определения:Процесс и методология

• Процесс разработки программного обеспечения – это структура, согласно которой построена разработка ПО• Определяет набор выполняемых активностей и принципы их

увязывания в определенную систему

• Иерархия процессов

• Методология (от греч. μεθοδολογία – учение о способах) – система базисных принципов, методов, методик, способов и средств их реализации в организации и построении научно-практической деятельности людей


«Железный треугольник»


Объем работ

Время Ресурсы

8


Алистэр Коуберн («Процесс как четвертое измерение», 2003):• «Некоторые из нас все же обнаруживают, что

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




Объем работ

Время Ресурсы

Процесс

11

Процесс. И никакого страха!

«Правильный» процесс:• продуман и упорядочен• задокументирован• его знают и ему реально следуют• способствует улучшению ситуации• не является «обузой»

• поставлен процесс улучшения процесса


Модели процесса разработки ПО

Две основные модели построения процесс разработки ПО:• Водопадная (каскадная или последовательная) модель• Итеративная модель


Водопадная модель.Суть и условия возникновения

• Заимствована из классического производства• В ИТ возникла в среде, где:

• требования четко определены заранее и не изменяются

• надежность ПО является критическим фактором

• Суть модели:• Этапы

• Переходы между этапами

• Артефакты

• Результат (продукт)


Водопадная модель.Графическое представление


Требования

Проектирование

Реализация

Тестирование

Эксплуатация

15

Водопадная модель.Достоинства

• Простота и понятность• Очевидность для людей из «классического бизнеса»• На каждом этапе формируется законченный набор

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

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

провести качественное тестирование• Если проект успешен, затраты на него будут минимальны


Водопадная модель.Проблемы

• Хорошо работает для систем с известными и стабильными требованиями

• В реальных проектах часто возникает потребность в возврате к предыдущим этапам с целью:• учета изменений в требованиях

• уточнения или пересмотра ранее принятых решений


Водоворот


Требования

Проектирование

Реализация

Тестирование

Эксплуатация

18

Основное противоречие

• Изменения – враг разработчиков ПО

• Однако изменения – неотъемлемая часть бизнеса заказчика и самого процесса разработки ПО

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


Итеративная модель

• Итеративная, эволюционная, спиральная, …• Мартин Фаулер (2004): «Итеративную разработку

называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада »

• Как съесть слона?


Итеративная модель.Основные принципы

• Жизненный цикл разработки ПО – последовательность относительно коротких частей (итерации)

• Итерация – маленький «водопад»• Требования – стабильность в рамках итерации• Результат – работоспособная версия системы с

дополнительной функциональностью (инкремент)• Поставка результата Заказчику, учет его отклика для

планирования следующей итерации• Завершение процесса – продукт удовлетворяет Заказчика


Итеративная модель.Графическое представление


Итеративная модель.Первая реализация

Спиральная модель Барри Боема (1988):


Итеративная модель.Достоинства (1)

• Цена внесения изменений существенно ниже• Вероятность успеха существенно выше• Не нужно формулировать все требования до начала

разработки• Можно приоритезировать требования• Можно начать пользоваться системой рано• Можно оперативно корректировать развитие проекта


Итеративная модель.Достоинства (2)

• Можно рано адресовать технологические риски• Ключевая функциональность тестируется лучше всего• Сохраняется высокий уровень документирования• «Заставляет» использовать автоматизированное

тестирование• Спонсор может защитить свои средства от перерасхода


Что такое RUP (1)

1. Методология разработки ПО. Лучшие практики:• Итеративность

• Архитектуро-центричность, компонентность

• Движущая сила – требования в форме прецедентов использования (use cases)

• Активное использование визуального моделирования

• Постоянная проверка качества

• Управление изменениями


Что такое RUP (2)

2. Процессный продукт• Описание ролей и активностей

• Шаблоны и примеры заполнения артефактов

• Руководства по выполнению активностей

• Настраиваемость

3. Интегрированный набор инструментальных средств

4. Руководства по инструментам


Сводная диаграмма


Итеративная модель(классика) – что не так?

• Потеря полноты и согласованности проектной документацией

• Поздняя определенность бюджета проекта• «Разбухание» методологии• Сложность внедрения методологии• Итеративный процесс существенно дороже «водопада»

• Доработка артефактов всегда дороже разработки «с нуля»

• Затраты на рефакторинг

• Больше усилий на управление


Плата за универсализм

• Проекты любого уровня сложности и масштаба• Проекты любого уровня ответственности• Команды любого размера и распределенности• Команды любого уровня профессионализма и

сработанности • Отношения с Заказчиком любого уровня формализма /

доверия и «прозрачности»• Произвольная степень вовлеченности Заказчика в процесс

разработки и судьбу проектаCopyright © 2009 Учебный Центр Luxoft (www.Luxoft-Training.ru)

35

И что теперь?Нужна гибкость!

Алистэр Коуберн («Процесс как четвертое измерение», 2003):• «Секрет в том, что существует еще одна вершина,

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


Суть гибких методологий

• Зачем платить за универсализм? Ключевые моменты:• отказ от избыточного формализма

• исполнение проекта• (относительно) небольшой …

• самоорганизующейся командой …

• состоящей из высокопрофессиональных специалистов …

• «широкого профиля» …

• работающих «плечом к плечу» …

• (скорее всего) уже не первый год

• принятие изменений как неотъемлемой части разработки ПОCopyright © 2009 Учебный Центр Luxoft (www.Luxoft-Training.ru)

37

«Облегченные»«тяжелые» методологии

• RUP XP – 2002, совместная разработка Object Mentor Inc. и Rational Software Corporation

• 2 варианта RUP начиная с версии 7.0:• RUP для больших проектов (Classic RUP)

• RUP для небольших проектов (RUP for Small Projects)

• 2 варианта MSF начиная с версии 4.0:• MSF для процесса CMMI

• MSF для Agile Development


Выбор методологии

• Любая методология может привести к неудаче и, в конечном счете, к провалу проекта

• Выход:• Учет специфики конкретного проекта

• Выбор оптимальной методологии (если возможно), или

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


Сильные стороны классических итеративных методологий (RUP)

• Применимость в более широком диапазоне ситуаций («любой проект»)

• Внимание проработке архитектуры• Внимание документированию требований и отслеживанию

связей требований с другими артефактами• Внимание моделированию


Сильные стороны гибких методологий

• Внимание «человеческому фактору» (отношения, коммуникации, мотивация, лидерство)

• Гибкость• Главное для всех в команде – успех проекта (а не успех

выполнения отдельной задачи)• Упор на постоянное взаимодействие с Заказчиком• Самоорганизация и самоуправление команд• Кроссфункциональность членов команд• Минимизация количества и объема артефактов


Обратить внимание:инженерные практики XP

• Рефакторинг• Test Driven Development• Непрерывная интеграция• Коллективное владение кодом• Парное программирование


Обратить внимание:Управленческие практики Scrum• Ежедневные краткие статусные митинги• Демонстрация результатов итерации Заказчику• Внутренний анализ хода итерации в команде

(ретроспектива)• Ревью хода итерации совместно с Заказчиком• Оценка оставшихся трудозатрат


Спасибо!

Вопросы?


эволюция методологий управления (водопад, rup, agile) ...

Business