2. IBM Software Group | Rational software
Повышение эффективности разработки ПО
Рост
производительности
за счет:
-Раннего
DRAFT
обнаружения и
коррекции ошибок
-Сокращения
рутинной,
непроизводительной
деятельности
Стоимость исправления дефекта возрастает вместе с
продвижением по стадиям жизненного цикла ПО
IBM Software Group | Rational software
Успешность проектов разных типов
4.9
Iterative Quality 5.0
2.3
0.4
Agile
DRAFT Functionality 1.8
2.7
5.6
6.0
3.9
Money 3.0
Traditional 0.2
0.8 Agile
Iterative
4.4 Traditional
Time 4.0
0.8 Ad-Hoc
Ad-Hoc 0.8
Agile-команды дают более качественный результат,
делают это быстрее, обеспечивают лучшее
соответствие требованиям и обеспечивают более
высокий ROI, чем традиционные команды
DDJ 2008 Project Success
2
3. IBM Software Group | Rational software
Причины успеха Agile-техник
DRAFT
Стоимость
Время реакции
IBM Software Group | Rational software
Цикл Agile разработки
DRAFT
Source: www.ambysoft.com/essays/agileLifecycle.html
3
4. IBM Software Group | Rational software
Расширение Agile на полный цикл
первый фактор масштабирования
DRAFT
IBM Software Group | Rational software
Факторы масштабирования
Agile
Размер команды Требования регуляторов
Under 10 1000’s of Critical,
Low risk
developers
DRAFT
developers Audited
Географическое Сложность приложений
распределение Straight Intricate/
Co-located Global -forward Emerging
Disciplined
Корпоративная среда Agile Распределенные команды
Project Enterprise
Delivery (партнеры. подрядчики)
focus focus Collaborative Contractual
Сложность организции Сложность технологий
Flexible Rigid Heterogeneous,
Homogenous Legacy
4
5. IBM Software Group | Rational software
Что такое Disciplined Agile?
Это эволюционный подход
(итеративный и постепенный) к
поставке ПО, регулярно, вовремя и
эффективно по стоимости
DRAFT
производящий высококачественное ПО
в жизненном цикле, управляемом
рисками и потребностями бизнеса.
Обеспечивается тесным
взаимодействием, дисциплиной и
Основные принципы
самоорганизацией при активном
привлечении заинтересованных лиц “Fits just right” процесс
для гарантии правильного понимания Постоянное тестирование
их запросов командой. Тесное взаимодействие в команде
Быстрый отклик на изменения
Disciplined agile delivery обеспечивает Постоянное вовлечение заказчика
повторяемость результата на основе Частый выпуск работающих решений
необходимого количества формализма.
IBM Software Group | Rational software
Масштабирование - Agile scaling model (ASM)
Базовая Agile разработка
Фокус на реализации (кодирование)
Цель – разработка высококачественной системы
DRAFT
с упором на самоорганизацию, взаимодействие и
эволюционный подход
Ориентация на полезность заказчику и выпуск
работающих прототипов
Небольшие локальные команды разработчиков
Disciplined Agile Delivery
Расширение agile на полный жизненный цикл систем
Управление на основе рисков и требований бизнеса
Самоорганизация в рамках организационной модели управления
Небольшие, локальные команды, создающие простые решения
Масштабирование Agile
Disciplined Agile Delivery с учетом одного или нескольких факторов масштабирования
5
6. IBM Software Group | Rational software
•Стратегии для больших команд
•Распределенные команды
DRAFT
•Agile в сложном окружении
•Agile на уровне предприятия
•Возможные сценарии с IBM Rational
•Дополнительная информация
IBM Software Group | Rational software
Влияние размера команды
успешность попыток применения Agile
200+
101 to 200
51-100
DRAFT
Success
21 to 50
Attempt
11 to 20
6 to 10
1 to 5
0 50 100 150
Кол-во ответивших
Source: Dr Dobb’s 2008 Agile Adoption Survey
6
7. IBM Software Group | Rational software
Большие Аgile команды
DRAFT
Организуйте работу на основе архитектуры
Не следует основываться на ролях
Архитектурная стратегия должна отражать стратегию
требований – формирование команд по функциональности
или по компонентам
Необходимо координировать управление проектом,
управление требованиями и техническую реализацию.
Пересмотрите некоторые роли при необходимости
(например, Agile DBA)
Предоставьте руководства по инфраструктуре и
соглашениям по разработке (глоссарии. Правила
наименования и т.п.)
IBM Software Group | Rational software
Каждая подкоманда имеет
собственный product backlogs
Обльшие и распределенные команды
разделяются на подкоманды
Каждая подкоманда имеет собственный
список задач и Product Owner DRAFT
Потребуется координация для зависимых
задач разных подкоманд
Необходимо обеспечить взаимодействие
между подкомандами с минимальными
задержками
Burndown каждой команды должен
встраиваться в burndown всего проекта
Потребуется инструментальная
поддержка
“Complex Requirements” in Dr Dobb’s
Journal, December 2008
www.ddj.com/architect/211800534?cid=Ambysoft
7
8. IBM Software Group | Rational software
«Удлинение» итераций для
компенсации усилий по
координации
No Iterations
длительность итераций в проектах
6%
> 8 Weeks 1% DRAFT
7-8 Weeks 2%
5-6 Weeks 7%
4 Weeks 23%
3 Weeks 17%
2 Weeks 33%
1 Week 9%
< 1 Week 3%
Source: Dr Dobb’s 2008 Agile Adoption Survey
IBM Software Group | Rational software
•Распределенные команды
•Agile в сложном окружении
DRAFT
•Agile на уровне предприятия
•Возможные сценарии с IBM Rational
•Дополнительная информация
8
9. IBM Software Group | Rational software
Рейтинг успешности Agile-проектов (%)
распределенность команд
DRAFT78
All
83
Co-Located
Near Located
72
Far Located
60
0 20 40 60 80 100
Source: Dr Dobb’s 2008 Agile Adoption Survey
IBM Software Group | Rational software
Планирование итераций
масштабирование
Каждая подкоманда планирует свои итерации
Рroduct owners должен знать о зависимостях
DRAFT
между зписками задач в итерациях подкоманд
Ответсвенные за архитектуру (architecture
owners) должны учитывать зависимости
между архитектурой подсистем
Лидеры коман должны учитывать основные
зависимости с другими подсистемами,
особенно если они имеют другое расписание
итераций
Вам потребуются средства автоматизации
для распределенных команд, больших команд
или команд, вынужденных соответствовать
требованиям регуляторов.
www.agilemodeling.com/essays/iterationModeling.htm
9
10. IBM Software Group | Rational software
Планирование релизов
масштабирование
Для “команды команд” потребуется:
Общий план релизов
Планы релизов для каждой подкоманды
Общий ритм (например 6 недель) DRAFT
Ритм каждой подкоманды коррелирует с
общим (1, 2, 3 или 6 недель)
Начальная концепция (требования) и дизайн
архитектуры – критически важные
параллельные задачи. Чем сложнее проект,
тем больше моделирования потребуется. (что
не означает детальных спецификаций в
начале проекта)
Зависимость от внешних команд –
критический фактор, особенно если это НЕ
agile-команды (шансы их попадания в график
в этом случае уменьшаются)
http://www.agilemodeling.com/essays/initialRequirementsModeling.htm
http://www.agilemodeling.com/essays/initialArchitectureModeling.htm
IBM Software Group | Rational software
Используйте лучшую стратегию для
коммуникаций
Используйте лучший из
доступных в данный момент
вариантов коммуникации
Прямое общение (face-to-face) не
DRAFT
всегда может быть доступно
Документация:
•Наименее эффективное
средство коммуникации из
доступных
•Один из вариантов обмена
информацией, но в большинстве
случаев доступны лучшие
•Подходит для обзорной
информации и информации для
заинтересованных лиц и
заказчиков
10
11. IBM Software Group | Rational software
•Agile в сложном окружении
•Agile на уровне предприятия
DRAFT
•Возможные сценарии с IBM Rational
•Дополнительная информация
IBM Software Group | Rational software
Сложность технологии
Потенциальные сложности:
Гетерогенная среда
Устаревшие данные DRAFT
Устаревшие системы
Интеграция с внешними системами
Отсутствие технологий (например, работа с beta-
версией)
Open source с различными стратегиями лицензирования
Программные пакеты
Отсутствие или неполнота тестовых данных или планов
11
12. IBM Software Group | Rational software
Agile и устаревшие системы
Working With
Legacy in Some 78%
Way
Integrating With
DRAFT
57%
Legacy Systems
Evolving Legacy
51%
Systems
Working with
45%
Legacy Data
Source: Ambysoft Agile
Project Initiation 2009 Survey
www.ambysoft.com/surveys/projectInitiation2009.html
IBM Software Group | Rational software
Организационные сложности
Культурные различия в организации могут существенно
препятствовать прогрессу
•Некоторые участники предпочитают работать в бюрократическом стиле
DRAFT
•Всеобъемлющая документация и рецензирование считаются необходимыми для
успеха
Существующие процессы, процедуры и стандарты могут
противоречить agile подходу
•Последовательные/вдопадные стратегии
•Медленный процесс принятия решений (например, только через архитектурный
комитет)
Разные подразделения используют различные, часто
противоречащие друг другу подходы
•Разработчики хотят использовать agile подход, контроль качества хочет
последовательный процесс
Существующие бизнес-процессы снижают шанс на успех
•Модели бюджетирования проектов
•Стратегии управления ориентированы на «водопад»
12
13. IBM Software Group | Rational software
Используйте подходящую стратегию
управления
Управление в стиле «Lean»
Команды не работают в ваккуме
DRAFT
Самоуправление доолжно быть ограничено корпоративными
правилами
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?la
ng=en_US&source=swg-ldg
Автоматический учет и отчетность по проекту
Возможно автоматизировать большую часть Scrum-
формализации
Rational Team Concert (RTC) для отчетности по проекту
Rational Insight для портфельной отчетности
Адаптируйте корпоративные правила
разработки
“Укрепление” политик через инструменты
статического анализа
IBM Software Group | Rational software
Управление разработкой в
стиле Lean
Соответствие HR
Прагматичное правил и полезности Итеративность Простые и
управление для IT Адаптация подходящие
Поэтапная реализация Соответствие правил Вехи на основе рисков метрики
заинтересованных лиц и
DRAFT
программ Постоянный
полезности для IT Постоянное улучшение
Проекты мониторинг
приоритезируются с Аудируемость
проекта
бизнес-целями
Разработка на основе
сценариев
Организация
Процессы
Миссия и
Измерения
Принципы
Роли и Политики и
ответственность Стандарты
Самоорганизация команд Интегрированная среда ЖЦ
Соответствие структуры Значимость корпоративных
команд функциональности и активов
архитектуре Гибкая архитектура
13
14. IBM Software Group | Rational software
•Agile на уровне предприятия
•Возможные сценарии с IBM Rational
DRAFT
•Дополнительная информация
IBM Software Group | Rational software
Agile практики управления
•
портфелем
Корпоративная стратегия и требования
регуляторов как критерии выбора
• Фокус на сотрудничестве и возможностях, а
DRAFT
не контроле и исполнении приказов
• Управление корпоративными рисками
• Идентификация потенциальных проектов
• Выбор наиболее выгодных проектов
• Организация сходных проектов в программы
• Наблюдение за текущими проектами и
программами
• Управление сервисными контрактами
• Тесная работа с руководителями проектов
• Мониторинг проектов
www.enterpriseunifiedprocess.com
14
15. IBM Software Group | Rational software
Agile практики и корпоративная
архитектура
DRAFT
Source: www.agiledata.org/essays/enterpriseArchitecture.html
IBM Software Group | Rational software
Общие антишаблоны
Вера в невозможность
масштабирования Agile
Применение традиционных подходов DRAFT
к масштабированию для Аgile
Предположение, что практики для
локальных команд разработки
могут остаться неизменными
Предположение, что
масштабирование Agile требует
тяжелых бюрократических
стратегий
15
16. IBM Software Group | Rational software
•Возможные сценарии с IBM
Rational DRAFT
•Дополнительная информация
IBM Software Group | Rational software
Сценарий: Отсутствие опыта в Agile
Потребности: Rational Team Concert
Убедиться, что Agile работает в его случае
Получить выгоды от Agile
Препятствия:
DRAFT
Скепсис по поводу Agile
Значительные изменения культуры разработки
Возможное решение:
Agile JumpStart для получения базовых навыков
RTC для разработчиков
16
17. IBM Software Group | Rational software
Сценарий: Улучшение
Потребности: управляемости Rational Team Concert
Улучшение мониторинга и контроля
проектов Rational Method Composer
Препятствия : DRAFT
Традиционные проекты – трудно управлять
Самоуправление незнакомо руководителям
Детальное планирование и оценка – не в
начале, а по ходу проекта
Возможное решение:
RTC для мониторинга в реальном времени
RMC для уравления процессом
2-уровневое планирование
Управление в стиле Lean
IBM Software Group | Rational software
Сценарий: организация большой Agile
Потребности: команды Rational Requirements Comp
Composer
Сокращение времени и стоимости
больших проектов Rational Team Concert
Препятстия: DRAFT
Увеличение сложности управления
Rational Build Forge
Rational Quality Manager
Усложнение коммуникаций
Rational Software Analyzer
Возможное решение:
Rational Method Composer
RRC для начального моделирования
требований
RTC для разработки и мониторинга
RBF для постоянной интеграции
RQM для независимого
тестирования
RSAR для анализа качества кода
RMC для использования практик
больших команд
17
18. IBM Software Group | Rational software
Сценарий: географическая
распределенная Agile команда
Rational Team Concert
Потребности: Rational Requirements Comp
Composer
Использование сотрудников в разных
регионах
Ускорение разработки
DRAFT Rational Build Forge
Rational Method Composer
Препятствия:
Увеличение коммуникационных рисков
Возможное решение:
RTC прямо поддерживает
распределенные команды
BF для постоянной интеграцией между
сайтами разработки
RRC для начального моделирования
требований
RMC для практик распределенной
разработки
IBM Software Group | Rational software
Сценарий: Agile в среде соответствия
требованиям регуляторов
Потребности: Rational Team Concert
Трассируемость
Управление рисками
DRAFT
Мониторинг проектов и отчетность
Rational Quality Manager
Rational Policy Tester
Препятствия: Rational Software Analyzer
Agile не считается подходящим в такой среде
Rational Build Forge
OSS инструменты не подходят
Возможное решение: Rational Method Composer
RTC для трассировки и мониторинга
RQM для трассировки и гарантии качества
RSAR и Policy Tester для гарантии качества
RBF для трассировок на развернутую конфигурацию
RMC для определения процесса
Управление в стиле Lean
18
19. IBM Software Group | Rational software
•Дополнительная информация
DRAFT
Dr. Dobb’s Journal’s 2008 Adoption Survey.
www.ambysoft.com/surveys/agileFebruary2008.html
Dr. Dobb’s Journal’s 2008 Project Success Survey.
www.ambysoft.com/surveys/success2008.html
Glazer, H. , Dalton, J. , Anderson, D.J., Konrad, M., Shrum, S. (2008). CMMI® or Agile: Why
Not Embrace Both! www.sei.cmu.edu/publications/documents/08.reports/08tn003.html
www.ibm.com/rational/agile/
www.ibm.com/developerworks/
www.ibm.com/developerworks/blogs/page/ambler
www.jazz.net
IBM Software Group | Rational software
http://www.ibm.com/developerworks/ru/rational/
DRAFT
19
20. IBM Software Group | Rational software
DRAFT
https://jazz.net/
IBM Software Group | Rational software
http://bit.ly/rug_russia
DRAFT
20
