agile at scale

1

DRAFT

DRAFT

®

IBM Software Group

© 2008 IBM Corporation

Масштабирование Agile -возможные стратегии

Дмитрий Лапыгинтехнический специалист по продуктам IBM Rational, IBM EE/A email: [email protected]

IBM Software Group | Rational software

Содержание

•Причины успеха и

современные вызовы Agile•Стратегии для больших команд

•Распределенные команды

•Agile в сложном окружении

•Agile на уровне предприятия

•Возможные сценарии с IBM Rational•Дополнительная информация

2

DRAFT

DRAFT


Повышение эффективности разработки ПО

Стоимость исправления дефекта возрастает вместе спродвижением по стадиям жизненного цикла ПО

Ростпроизводительностиза счет:

-Раннегообнаружения икоррекции ошибок

-Сокращениярутинной, непроизводительнойдеятельности


Успешность проектов разных типов

Agile-команды дают более качественный результат, делают это быстрее, обеспечивают лучшее

соответствие требованиям и обеспечивают болеевысокий ROI, чем традиционные команды

AgileIterativeTraditionalAd-Hoc

0.8

0.8

2.7

0.4

0.8

0.2

1.8

2.3

4.0

3.0

5.6

5.0

4.4

3.9

6.0

4.9

Time

Money

Functionality

QualityIterative

Agile

Traditional

Ad-Hoc

DDJ 2008 Project Success

3

DRAFT

DRAFT


Причины успеха Agile- техник

Стоимость

Время реакции


Цикл Agile разработки

Source: www.ambysoft.com/essays/agileLifecycle.html

4

DRAFT

DRAFT


Расширение Agile на полный циклпервый фактор масштабирования


Факторы масштабированияAgile

Сложность приложений

Straight-forward

Intricate/Emerging

Требования регуляторов

Low risk Critical,Audited

Размер команды

Under 10developers

1000’s ofdevelopers

Co-located

Географическоераспределение

Global

Корпоративная среда

Projectfocus

Enterprisefocus

Сложность технологий

HomogenousHeterogeneous,

Legacy

Распределенные команды(партнеры. подрядчики)Collaborative Contractual

Disciplined Agile

Delivery

Flexible Rigid

Сложность организции

5

DRAFT

DRAFT


Что такое Disciplined Agile?Это эволюционный подход

(итеративный и постепенный) кпоставке ПО, регулярно, вовремя и

эффективно по стоимости

производящий высококачественное ПО

в жизненном цикле, управляемом

рисками и потребностями бизнеса.

Обеспечивается тесным

взаимодействием, дисциплиной и

самоорганизацией при активном

привлечении заинтересованных лиц

для гарантии правильного понимания

их запросов командой.

Disciplined agile delivery обеспечиваетповторяемость результата на основе

необходимого количества формализма.

“Fits just right” процессПостоянное тестирование

Тесное взаимодействие в команде

Быстрый отклик на изменения

Постоянное вовлечение заказчика

Частый выпуск работающих решений

Основные принципы


Масштабирование - Agile scaling model (ASM)Базовая Agile разработка

�Фокус на реализации (кодирование)

�Цель – разработка высококачественной системы

с упором на самоорганизацию, взаимодействие и

эволюционный подход

�Ориентация на полезность заказчику и выпуск

работающих прототипов

�Небольшие локальные команды разработчиков

Disciplined Agile Delivery

�Расширение agile на полный жизненный цикл систем

�Управление на основе рисков и требований бизнеса

�Самоорганизация в рамках организационной модели управления

�Небольшие, локальные команды, создающие простые решения

Масштабирование Agile

�Disciplined Agile Delivery с учетом одного или нескольких факторов масштабирования

6

DRAFT

DRAFT


•Стратегии для больших команд






0 50 100 150

1 to 5

6 to 10

11 to 20

21 to 50

51-100

101 to 200

200+

SuccessAttempt

Влияние размера командыуспешность попыток применения Agile

Source: Dr Dobb’s 2008 Agile Adoption Survey

Кол-во ответивших

7

DRAFT

DRAFT


Большие Аgile команды

Организуйте работу на основе архитектуры

Не следует основываться на ролях

Архитектурная стратегия должна отражать стратегию

требований – формирование команд по функциональностиили по компонентам

Необходимо координировать управление проектом, управление требованиями и техническую реализацию.

Пересмотрите некоторые роли при необходимости

(например, Agile DBA)

Предоставьте руководства по инфраструктуре и

соглашениям по разработке (глоссарии. Правиланаименования и т.п.)


Каждая подкоманда имеетсобственный product backlogs

Обльшие и распределенные команды

разделяются на подкоманды

Каждая подкоманда имеет собственный

список задач и Product Owner

Потребуется координация для зависимых

задач разных подкоманд

Необходимо обеспечить взаимодействие

между подкомандами с минимальными

задержками

Burndown каждой команды должен

встраиваться в burndown всего проекта

Потребуется инструментальная

поддержка

“Complex Requirements” in Dr Dobb’s Journal, December 2008www.ddj.com/architect/211800534?cid=Ambysoft

8

DRAFT

DRAFT


3%

9%

33%

17%

23%

7%

2%

1%

6%

< 1 Week

1 Week

2 Weeks

3 Weeks

4 Weeks

5-6 Weeks

7-8 Weeks

> 8 Weeks

No Iterations

«Удлинение» итераций длякомпенсации усилий покоординациидлительность итераций в проектах







9

DRAFT

DRAFT


60

72

83

78

0 20 40 60 80 100

AllCo-LocatedNear LocatedFar Located

Рейтинг успешности Agile- проектов (%)распределенность команд



Планирование итерациймасштабирование

�Каждая подкоманда планирует свои итерации

�Рroduct owners должен знать о зависимостях

между зписками задач в итерациях подкоманд

�Ответсвенные за архитектуру (architecture owners) должны учитывать зависимости

между архитектурой подсистем

�Лидеры коман должны учитывать основные

зависимости с другими подсистемами,особенно если они имеют другое расписание

итераций

�Вам потребуются средства автоматизации

для распределенных команд, больших командили команд, вынужденных соответствоватьтребованиям регуляторов.

www.agilemodeling.com/essays/iterationModeling.htm

10

DRAFT

DRAFT


Планирование релизовмасштабирование

Для “команды команд” потребуется:

�Общий план релизов

�Планы релизов для каждой подкоманды

�Общий ритм (например 6 недель)

�Ритм каждой подкоманды коррелирует с

общим (1, 2, 3 или 6 недель)

Начальная концепция (требования) и дизайн

архитектуры – критически важные

параллельные задачи. Чем сложнее проект, тем больше моделирования потребуется. (чтоне означает детальных спецификаций в

начале проекта)

Зависимость от внешних команд –критический фактор, особенно если это НЕ

agile-команды (шансы их попадания в график

в этом случае уменьшаются)http://www.agilemodeling.com/essays/initialRequirementsModeling.htmhttp://www.agilemodeling.com/essays/initialArchitectureModeling.htm


Используйте лучшую стратегию длякоммуникаций

Используйте лучший из

доступных в данный момент

вариантов коммуникации

Прямое общение (face-to-face) невсегда может быть доступно

Документация:

•Наименее эффективноесредство коммуникации из

доступных

•Один из вариантов обменаинформацией, но в большинствеслучаев доступны лучшие

•Подходит для обзорнойинформации и информации для

заинтересованных лиц и

заказчиков

11

DRAFT

DRAFT






Сложность технологии

Потенциальные сложности:Гетерогенная среда

Устаревшие данные

Устаревшие системы

Интеграция с внешними системами

Отсутствие технологий (например, работа с beta-версией)

Open source с различными стратегиями лицензирования

Программные пакеты

Отсутствие или неполнота тестовых данных или планов

12

DRAFT

DRAFT


Agile и устаревшие системы

45%

51%

57%

78%

Working withLegacy Data

Evolving LegacySystems

Integrating WithLegacy Systems

Working WithLegacy in Some

Way

Source: Ambysoft AgileProject Initiation 2009 Survey

www.ambysoft.com/surveys/projectInitiation2009.html


Организационные сложности

Культурные различия в организации могут существеннопрепятствовать прогрессу

•Некоторые участники предпочитают работать в бюрократическом стиле

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

Существующие процессы, процедуры и стандарты могутпротиворечить agile подходу•Последовательные/вдопадные стратегии

•Медленный процесс принятия решений (например, только через архитектурныйкомитет)

Разные подразделения используют различные, частопротиворечащие друг другу подходы

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

Существующие бизнес-процессы снижают шанс на успех

•Модели бюджетирования проектов

•Стратегии управления ориентированы на «водопад»

13

DRAFT

DRAFT


Используйте подходящую стратегиюуправления

Управление в стиле «Lean»

Команды не работают в ваккуме

Самоуправление доолжно быть ограничено корпоративными

правилами

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-ldg

Автоматический учет и отчетность по проекту

Возможно автоматизировать большую часть Scrum-формализации

Rational Team Concert (RTC) для отчетности по проекту

Rational Insight для портфельной отчетности

Адаптируйте корпоративные правила

разработки

“Укрепление” политик через инструменты

статического анализа


Организация

Роли и

ответственность

Процессы

Измерения

Политики и

Стандарты

Миссия и

Принципы

Управление разработкой встиле Lean

� Прагматичное

управление

� Поэтапная реализация

программ

� Проекты

приоритезируются с

бизнес-целями

� Разработка на основе

сценариев

� Простые и

подходящие

метрики

� Постоянный

мониторинг

проекта

� Итеративность

� Адаптация

� Вехи на основе рисков

� Постоянное улучшение

� Аудируемость

� Соответствие HR правил и полезности

для IT

� Соответствие правил

заинтересованных лиц и

полезности для IT

� Самоорганизация команд

� Соответствие структуры

команд функциональности и

архитектуре

� Интегрированная среда ЖЦ

� Значимость корпоративных

активов

� Гибкая архитектура

14

DRAFT

DRAFT


•Agile на уровне предприятия•Возможные сценарии с IBM Rational

•Дополнительная информация


Agile практики управленияпортфелем

• Корпоративная стратегия и требования

регуляторов как критерии выбора

• Фокус на сотрудничестве и возможностях, ане контроле и исполнении приказов

• Управление корпоративными рисками

• Идентификация потенциальных проектов

• Выбор наиболее выгодных проектов

• Организация сходных проектов в программы

• Наблюдение за текущими проектами и

программами

• Управление сервисными контрактами

• Тесная работа с руководителями проектов

• Мониторинг проектов

www.enterpriseunifiedprocess.com

15

DRAFT

DRAFT


Agile практики и корпоративнаяархитектура

Source: www.agiledata.org/essays/enterpriseArchitecture.html


Общие антишаблоны

Вера в невозможностьмасштабирования Agile

Применение традиционных подходовк масштабированию для Аgile

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

Предположение, чтомасштабирование Agile требуеттяжелых бюрократическихстратегий

16

DRAFT

DRAFT


•Возможные сценарии с IBM

Rational•Дополнительная информация


Сценарий: Отсутствие опыта в Agile

Потребности:Убедиться, что Agile работает в его случае

Получить выгоды от Agile

Препятствия:Скепсис по поводу Agile

Значительные изменения культуры разработки

Возможное решение:Agile JumpStart для получения базовых навыков

RTC для разработчиков

Rational Team Concert

17

DRAFT

DRAFT


Сценарий: УлучшениеуправляемостиПотребности:

Улучшение мониторинга и контроля

проектов

Препятствия :Традиционные проекты – трудно управлять

Самоуправление незнакомо руководителям

Детальное планирование и оценка – не в

начале, а по ходу проекта

Возможное решение:RTC для мониторинга в реальном времени

RMC для уравления процессом

2-уровневое планирование

Управление в стиле Lean

Rational Method Composer



Сценарий: организация большой Agile командыПотребности:

Сокращение времени и стоимостибольших проектов

Препятстия:Увеличение сложности управления

Усложнение коммуникаций

Возможное решение:RRC для начального моделированиятребований

RTC для разработки и мониторинга

RBF для постоянной интеграции

RQM для независимоготестирования

RSAR для анализа качества кода

RMC для использования практикбольших команд

Rational Build Forge



Rational Requirements CompRational Requirements Composer

Rational Quality Manager

Rational Software Analyzer

18

DRAFT

DRAFT


Сценарий: географическаяраспределенная Agile команда

Потребности:Использование сотрудников в разных

регионах

Ускорение разработки

Препятствия:Увеличение коммуникационных рисков

Возможное решение:RTC прямо поддерживает

распределенные команды

BF для постоянной интеграцией между

сайтами разработки

RRC для начального моделирования

требований

RMC для практик распределенной

разработки




Rational Requirements CompRational Requirements Composer


Сценарий: Agile в среде соответствиятребованиям регуляторов

Потребности:Трассируемость

Управление рисками

Мониторинг проектов и отчетность

Препятствия:Agile не считается подходящим в такой среде

OSS инструменты не подходят

Возможное решение:RTC для трассировки и мониторинга

RQM для трассировки и гарантии качества

RSAR и Policy Tester для гарантии качества

RBF для трассировок на развернутую конфигурацию

RMC для определения процесса

Управление в стиле Lean



Rational Policy Tester

Rational Quality Manager

Rational Software Analyzer


19

DRAFT

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: WhyNot 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


http://www.ibm.com/developerworks/ru/rational/

20

DRAFT

DRAFT


https://jazz.net/


http://bit.ly/rug_russia

21

DRAFT

DRAFT


© Copyright IBM Corporation 2007. All rights reserv ed. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Дополнительная информация:

• IBM Rational software

• IBM Rational Software Delivery Platform

• Process and portfolio management

• Change and release management

• Quality management

• Architecture management

• Rational trial downloads

• Leading Innovation Website

• IBM Rational TV

• IBM Rational Business Partners

agile at scale

Technology

agile delivery agile

agile rational team

agile http

agile dba

ibm eeaemail

agile jumpstart rtc

agile adoption survey6

rtc rmc