SlideShare une entreprise Scribd logo
1  sur  16
Télécharger pour lire hors ligne
Распределенный SCRUM – TO BE OR NOT TO BE COLLOCATED,[object Object],Ганчиков Михаил, Project Manager,[object Object],First Line Software, 2010,[object Object]
ПЛАН,[object Object],2,[object Object]
Зачем нужен Распределенный SCRUM?,[object Object],3,[object Object],Рост сложности проектов,[object Object],Доступ к глобальный пулу талантов,[object Object],16 часовой рабочий день (IBM’s “Follow the sun model”),[object Object],Снижение расходов,[object Object],Сокращение бенча,[object Object]
Какие проблемы?,[object Object],4,[object Object],Организация и управление,[object Object],Коммуникации,[object Object],Интеграция,[object Object],Безопасность,[object Object],Часовые пояса,[object Object],Языковой барьер и культурные различия,[object Object]
Типы команд,[object Object],5,[object Object],Объединенные,[object Object],Частично объединенные,[object Object],Распределенные в пределах 8 часов,[object Object],Распределенные за пределами 8 часов,[object Object]
Уровни сложности SCRUM проектов,[object Object],6,[object Object],1: Локальный SCRUM, 1 команда,[object Object],2: Локальный SCRUM of SCRUMs, несколько команд,[object Object],3: Распределенный SCRUM of SCRUMs, несколько объединенных команд,[object Object],4: Распределенный SCRUM of SCRUMs, несколько распределенных команд,[object Object]
Способы улучшения коммуникаций,[object Object],7,[object Object],Простой язык,[object Object],Наглядная демонстрация,[object Object],Видео связь как способ различить мимику и жесты,[object Object],Единая точка доступа ко всей информации по проекту,[object Object],Активное участие всех членов команды с первого дня проекта,[object Object]
Планирование релиза,[object Object],8,[object Object],Сбор требований и написание user stories,[object Object],Оценка (story points),[object Object],Формирование product backlog,[object Object],Подготовка плана релиза (release plan),[object Object],Длительность 5 дней на релиз 3 месяца,[object Object]
Планирование спринта,[object Object],9,[object Object],Подготовка,[object Object],Backlog grooming,[object Object],Проведение,[object Object],Обсуждение историй с Product Owner,[object Object],Пересмотр high level оценок при необходимости,[object Object],Детализация подзадач,[object Object],Оценка задач и commitment команды,[object Object],Результат,[object Object],Sprint backlog,[object Object],User stories с дополнениями,[object Object],Минутки (meeting notes),[object Object],Длительность 4 часа (2-х недельный спринт),[object Object]
Ежедневный SCRUM,[object Object],10,[object Object],Stand Up митинги,[object Object],Длительность 15 минут,[object Object],Online tracking,[object Object],XP практики,[object Object],Парное программирование,[object Object],Unit-тесты,[object Object],Integration-тесты,[object Object],Простой дизайн и понятный код,[object Object],Continuous refactoring,[object Object]
Синхронизация команд,[object Object],11,[object Object],Единый ритм (равные или кратные спринты),[object Object],SCRUM of SCRUMs митинги,[object Object],SCRUM Masters – статус и устранение проблем,[object Object],Product Owners – приоритеты PBL,[object Object],Architects - Интеграция и взаимодействие компонентов,[object Object],Интеграция,[object Object],Continuous builds,[object Object],Automated regression testing,[object Object]
Демонстрация (Show Case),[object Object],12,[object Object],Definitions of done,[object Object],Show case сессии,[object Object],Подготовка сценариев,[object Object],Получение acceptance,[object Object],Завершение спринта,[object Object],Обзор sprint backlog,[object Object],Сплит незавершенных историй,[object Object],Определение количества заработанных Story Points,[object Object],Длительность 3 часа (2-х недельный спринт),[object Object]
Ретроспектива и адаптация,[object Object],13,[object Object],Feedback,[object Object],Что было хорошо,[object Object],Что можно улучшить,[object Object],Цели на следующий цикл,[object Object],Обсуждение и определение приоритетов,[object Object],Внесение корректировок в работу команды,[object Object],Длительность 1 час,[object Object]
14,[object Object],Waterfall: 60 человек * 9 месяцев = 54 KLOC и 900 FP; скорость – 2.0 FP в месяц на разработчика,[object Object],SCRUM: 4.5 человека * 12месяцев = 51 KLOC и 960 FP; скорость – 17.8 FP в месяц на разработчика,[object Object],Distributed SCRUM: 56 человек * 14,5 месяцев = 671 KLOC и 12673 FP; скорость – 15.3 FP в месяц на разработчика,[object Object]
Выводы,[object Object],15,[object Object],Для эффективной работы распределенного SCRUM нужно: ,[object Object],Мульти-функциональные и независимые команды,[object Object],Возможность аудио и видео связи,[object Object],Online доступ ко всем ресурсам проекта,[object Object],Применение SCRUM и XP практик,[object Object],Постоянная адаптация и развитие,[object Object]
Спасибо за внимание!,[object Object],Литература:,[object Object],A practical guide to Distributed SCRUM, Elizabeth Woodward, SteffanSurdek, Matthew Ganis,[object Object],http://www.distributedscrum.com/,[object Object],Distributed SCRUM Agile, Jeff Sutherland,[object Object],http://www.scrumalliance.org/articles,[object Object],Вопросы?,[object Object],ganchikovm@gmail.com,[object Object],16,[object Object]

Contenu connexe

Tendances

Использование YouTrack для работы команды по Scrum
Использование YouTrack для работы команды по ScrumИспользование YouTrack для работы команды по Scrum
Использование YouTrack для работы команды по ScrumТатьяна Баева
 
Гибкая методология разработки
Гибкая методология разработкиГибкая методология разработки
Гибкая методология разработкиАльберт Фазуллин
 
Agile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияAgile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияjazzteam
 
Agile: разработка + тестирование
Agile: разработка + тестированиеAgile: разработка + тестирование
Agile: разработка + тестированиеAlexander Byndyu
 
Kanban vs Scrum – чьё кунг-фу сильнее
Kanban vs Scrum – чьё кунг-фу сильнееKanban vs Scrum – чьё кунг-фу сильнее
Kanban vs Scrum – чьё кунг-фу сильнееKirill Klimov
 
Переход от монолитной архитектуры к распределенной
Переход от монолитной архитектуры к распределеннойПереход от монолитной архитектуры к распределенной
Переход от монолитной архитектуры к распределеннойAlexander Byndyu
 

Tendances (8)

Использование YouTrack для работы команды по Scrum
Использование YouTrack для работы команды по ScrumИспользование YouTrack для работы команды по Scrum
Использование YouTrack для работы команды по Scrum
 
Гибкая методология разработки
Гибкая методология разработкиГибкая методология разработки
Гибкая методология разработки
 
Что такое Scrum
Что такое ScrumЧто такое Scrum
Что такое Scrum
 
Agile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияAgile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспечения
 
Agile: разработка + тестирование
Agile: разработка + тестированиеAgile: разработка + тестирование
Agile: разработка + тестирование
 
Kanban vs Scrum – чьё кунг-фу сильнее
Kanban vs Scrum – чьё кунг-фу сильнееKanban vs Scrum – чьё кунг-фу сильнее
Kanban vs Scrum – чьё кунг-фу сильнее
 
Переход от монолитной архитектуры к распределенной
Переход от монолитной архитектуры к распределеннойПереход от монолитной архитектуры к распределенной
Переход от монолитной архитектуры к распределенной
 
Scrum Wars
Scrum WarsScrum Wars
Scrum Wars
 

En vedette

En vedette (10)

Lego симуляция © Alex Krivitsky
Lego симуляция © Alex KrivitskyLego симуляция © Alex Krivitsky
Lego симуляция © Alex Krivitsky
 
7 retro
7 retro7 retro
7 retro
 
3 story mapping
3 story mapping3 story mapping
3 story mapping
 
Story mapping
Story mapping Story mapping
Story mapping
 
2 bmg
2 bmg2 bmg
2 bmg
 
Epics and User Stories
Epics and User StoriesEpics and User Stories
Epics and User Stories
 
Agile stories, estimating and planning
Agile stories, estimating and planningAgile stories, estimating and planning
Agile stories, estimating and planning
 
The 5 Levels Planning in Agile
The 5 Levels Planning in AgileThe 5 Levels Planning in Agile
The 5 Levels Planning in Agile
 
Product Lifecycle in JIRA
Product Lifecycle in JIRAProduct Lifecycle in JIRA
Product Lifecycle in JIRA
 
Agile Program and Portfolio Management
Agile Program and Portfolio ManagementAgile Program and Portfolio Management
Agile Program and Portfolio Management
 

Similaire à Распределенный SCRUM - to be or not to be collocated collocated

Практика внедрения Scrum
Практика внедрения ScrumПрактика внедрения Scrum
Практика внедрения ScrumAndrey Bibichev
 
A labs 2009 - внедрение agile
A labs 2009 - внедрение agileA labs 2009 - внедрение agile
A labs 2009 - внедрение agileAlexey Korsun
 
Проектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptПроектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptdinarium2016
 
Инструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumИнструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumDenis Tuchin
 
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
 
Scrum глазами тестировщика или как создать стратегию для любой задачи
Scrum глазами тестировщика или как создать стратегию для любой задачиScrum глазами тестировщика или как создать стратегию для любой задачи
Scrum глазами тестировщика или как создать стратегию для любой задачиIT61
 
Введение в Scrum
Введение в ScrumВведение в Scrum
Введение в ScrumSergey Semyonov
 
Введние в Scrum
Введние в ScrumВведние в Scrum
Введние в Scrumwebman86
 
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11ANDREY ZAKHODYAYCHENKO
 
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))Andrey Zakhodyaychenko
 
Практика работы с крупными проектами - от Scrum с XP к Kanban
Практика работы с крупными проектами - от Scrum с XP к KanbanПрактика работы с крупными проектами - от Scrum с XP к Kanban
Практика работы с крупными проектами - от Scrum с XP к KanbanAlexander Byndyu
 
Agile scrum - гибкое управление проектами
Agile   scrum - гибкое управление проектамиAgile   scrum - гибкое управление проектами
Agile scrum - гибкое управление проектамиMikhail Sofonov, PMP, P2M, PRINCE2
 
Как сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с AgileКак сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с AgileAlexey Krivitsky
 

Similaire à Распределенный SCRUM - to be or not to be collocated collocated (20)

Практика внедрения Scrum
Практика внедрения ScrumПрактика внедрения Scrum
Практика внедрения Scrum
 
Scrum Review
Scrum ReviewScrum Review
Scrum Review
 
Scrum: Introduction
Scrum: IntroductionScrum: Introduction
Scrum: Introduction
 
Scrum framework
Scrum frameworkScrum framework
Scrum framework
 
A labs 2009 - внедрение agile
A labs 2009 - внедрение agileA labs 2009 - внедрение agile
A labs 2009 - внедрение agile
 
Проектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptПроектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.ppt
 
Инструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumИнструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / Scrum
 
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...
 
Scrum глазами тестировщика или как создать стратегию для любой задачи
Scrum глазами тестировщика или как создать стратегию для любой задачиScrum глазами тестировщика или как создать стратегию для любой задачи
Scrum глазами тестировщика или как создать стратегию для любой задачи
 
Введение в Scrum
Введение в ScrumВведение в Scrum
Введение в Scrum
 
Введние в Scrum
Введние в ScrumВведние в Scrum
Введние в Scrum
 
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
 
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
 
Введение в Scrum
Введение в ScrumВведение в Scrum
Введение в Scrum
 
Agile Product Management Framework
Agile Product Management FrameworkAgile Product Management Framework
Agile Product Management Framework
 
Практика работы с крупными проектами - от Scrum с XP к Kanban
Практика работы с крупными проектами - от Scrum с XP к KanbanПрактика работы с крупными проектами - от Scrum с XP к Kanban
Практика работы с крупными проектами - от Scrum с XP к Kanban
 
Scrum intro
Scrum introScrum intro
Scrum intro
 
Agile scrum - гибкое управление проектами
Agile   scrum - гибкое управление проектамиAgile   scrum - гибкое управление проектами
Agile scrum - гибкое управление проектами
 
Agile checklist
Agile checklistAgile checklist
Agile checklist
 
Как сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с AgileКак сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с Agile
 

Plus de Nikita Filippov

Project Manager - Глупая идея
Project Manager - Глупая идеяProject Manager - Глупая идея
Project Manager - Глупая идеяNikita Filippov
 
Simple steps to makes great products
Simple steps to makes great productsSimple steps to makes great products
Simple steps to makes great productsNikita Filippov
 
Scrum в Заказной разработке
Scrum в Заказной разработкеScrum в Заказной разработке
Scrum в Заказной разработкеNikita Filippov
 
Innovation games for Agileee
Innovation games for AgileeeInnovation games for Agileee
Innovation games for AgileeeNikita Filippov
 
Who is Scrum Master Today?
Who is Scrum Master Today?Who is Scrum Master Today?
Who is Scrum Master Today?Nikita Filippov
 
Командный старт
Командный стартКомандный старт
Командный стартNikita Filippov
 
Rugby, Scrum и командная работа
Rugby, Scrum и командная работаRugby, Scrum и командная работа
Rugby, Scrum и командная работаNikita Filippov
 
Использование Пульса в оценке Fixed Price Agile проектов
Использование Пульса в оценке Fixed Price Agile проектовИспользование Пульса в оценке Fixed Price Agile проектов
Использование Пульса в оценке Fixed Price Agile проектовNikita Filippov
 
Products and People Over Process and Dogma
  Products and People Over Process and Dogma  Products and People Over Process and Dogma
Products and People Over Process and DogmaNikita Filippov
 
Как продавать Agile заказчику?
Как продавать Agile заказчику?Как продавать Agile заказчику?
Как продавать Agile заказчику?Nikita Filippov
 
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...Nikita Filippov
 
«Высоконагруженая команда: работа малых команд с большим количеством единовре...
«Высоконагруженая команда: работа малых команд с большим количеством единовре...«Высоконагруженая команда: работа малых команд с большим количеством единовре...
«Высоконагруженая команда: работа малых команд с большим количеством единовре...Nikita Filippov
 
Опыт внедрения Канбан. Первые Шаги
Опыт внедрения Канбан. Первые ШагиОпыт внедрения Канбан. Первые Шаги
Опыт внедрения Канбан. Первые ШагиNikita Filippov
 

Plus de Nikita Filippov (20)

Project Manager - Глупая идея
Project Manager - Глупая идеяProject Manager - Глупая идея
Project Manager - Глупая идея
 
6 scrum master
6 scrum master6 scrum master
6 scrum master
 
5 risk
5 risk5 risk
5 risk
 
4 woz
4 woz4 woz
4 woz
 
Simple steps to makes great products
Simple steps to makes great productsSimple steps to makes great products
Simple steps to makes great products
 
Vietnam
VietnamVietnam
Vietnam
 
Vision Crafting
Vision Crafting Vision Crafting
Vision Crafting
 
Lean startup
Lean startupLean startup
Lean startup
 
Customer Development
Customer Development Customer Development
Customer Development
 
Scrum в Заказной разработке
Scrum в Заказной разработкеScrum в Заказной разработке
Scrum в Заказной разработке
 
Innovation games for Agileee
Innovation games for AgileeeInnovation games for Agileee
Innovation games for Agileee
 
Who is Scrum Master Today?
Who is Scrum Master Today?Who is Scrum Master Today?
Who is Scrum Master Today?
 
Командный старт
Командный стартКомандный старт
Командный старт
 
Rugby, Scrum и командная работа
Rugby, Scrum и командная работаRugby, Scrum и командная работа
Rugby, Scrum и командная работа
 
Использование Пульса в оценке Fixed Price Agile проектов
Использование Пульса в оценке Fixed Price Agile проектовИспользование Пульса в оценке Fixed Price Agile проектов
Использование Пульса в оценке Fixed Price Agile проектов
 
Products and People Over Process and Dogma
  Products and People Over Process and Dogma  Products and People Over Process and Dogma
Products and People Over Process and Dogma
 
Как продавать Agile заказчику?
Как продавать Agile заказчику?Как продавать Agile заказчику?
Как продавать Agile заказчику?
 
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...
«Шустрый дизайн: подходы к декомпозиции задач проектирования UI в Agile-коман...
 
«Высоконагруженая команда: работа малых команд с большим количеством единовре...
«Высоконагруженая команда: работа малых команд с большим количеством единовре...«Высоконагруженая команда: работа малых команд с большим количеством единовре...
«Высоконагруженая команда: работа малых команд с большим количеством единовре...
 
Опыт внедрения Канбан. Первые Шаги
Опыт внедрения Канбан. Первые ШагиОпыт внедрения Канбан. Первые Шаги
Опыт внедрения Канбан. Первые Шаги
 

Распределенный SCRUM - to be or not to be collocated collocated

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.

Notes de l'éditeur

  1. Идея сделать данный доклад родилась тот момент, когда стало известно, что моя команда будет состоять из разработчиков в Питере, архитектора в Бостоне и тестеров в Хьюстоне.
  2. Доклад состоит из 4 частей. В первой части (введение) я расскажу о том, зачем вообще нужны сегодня распределенные команды и проекты. Затем мы рассмотрим основные трудности, с которыми сталкиваются участники таких проектов.Во второй части (классификация) мы рассмотрим типы команд по степени их распределенности а также уровни сложности распределенных проектов. Кроме того, в этой главе мы рассмотрим несколько полезных советов, которые могут быть использованы на любом распределенном проекте. В третей части (применение) мы еще раз посмотрим на жизненный цикл SCRUM проекта через призму распределенности. Здесь мы уделим внимание тем практикам, которые можно использовать на распределенных SCRUM проектах.И наконец в заключении я расскажу о тех результатах, которых добились на распределенном проекте StarSoft - Sirsi-Dynix, а также подведу итоги и еще раз суммирую все вышесказанное. Все оставшееся время я буду готов с радостью отвечать на ваши вопросы. Итак, если вопросов по содержанию нет, можно приступать.
  3. Почему распределенный SCRUM как и любой другой распределенный проект сегодня становится все более актуальным?1) Во первых из за сложности современных проектов. Уже довольно редко целью проекта является разработка сверхбыстрого и безотказного ядра базы данных или алгоритма архивации, которые вполне могли бы быть написаны парой талантливых программистов. Вместо этого сегодняшние проекты имеют множество целей а разрабатываемые системы предназначены для самых разных вариантов примененения и представляют из себя интеграцию разных технологий и компонентов. Создание таких систем требует труда десятков программистов, тестировщиков, бизнес аналитиков, дизайнеров и архитекторов. Практически нереально собрать эту группу в одном месте. 2) Во вторых, распреденные проекты дают возможность доступа к огромному пулу талантов. Особенно это актуально для интернациональных компаний, имеющих филиалы в разных странах, а также компаниях, использующих услуги фрилансеров. Доступ к пулу талантов позволяет в кратчайшие сроки подобрать команду с требуемыми скилами, и при этом не вылезти за рамки бюджета проекта.3) Третья причина, по которой может иметь смысл использовать распределенный SCRUM, это возможность обеспечить работу команды в течении 16 часов. Этот подход упоминается в книжке Practical guide to distributed SCRUM и называется Follow the SUN model. Его смысл состоит в том, что одна часть команды работающая на восточном полушарии работает первые 8 часов дня, в то время как другая команда работает вторые 8 часов дня. Таких образом может быть достигнут теоретический прирост производительности в два раза. Однако, лично мне на практике не удавалось применять данный подход, кроме того есть ряд сложностей в его имплементации. В частности, у команды не остается возможности вербального онлайн общения в стандартные рабочие часы.4) Стандартная причина, по которой многие компании прибегают к распределенным проектам это стремление максимально снизить расходы. Нанять того же фрилансера гораздо дешевле чем брать человека на работу – не нужно создавать ему рабочее место, не нужно оплачивать страховку, больничные и отпускные. Это четвертая причина.5) Наконец, самая неприятная на мой взгляд причина, это стремление многих компаний сегодня избавиться от бенча – скамейки запасных, так называемого балласта сотрудников которые оказались без проекта. Это довольно болезненная процедура, не только для тех, кого сокращают, но и для тех, кто остается, ведь им в ряде случаев приходится работать за двоих. Использование распределенного управления это выход для таких компаний.
  4. Несмотря на ряд очевидных преимуществ распределенного подхода к управлению проектами перед традиционным collocated, есть ряд проблем ,которые могут оказаться камнем преткновения для многих проектов, особенно на ранних стадиях, и стать могильной плитой для самых неудачливых. Во-первых, использование распределенных команд и проектов неизбежно влечет изменения в организации и управлении проектом. Приведу простой пример. Раньше мы часто рисовали истории и таски на больших ватманах, которые крепились на стену. На утреннем стендапе каждый из членов команды видел текущее состояние по историям и задачам, а также имел возможность отметить прогресс по своей задаче. Я в свою очередь ежедневно перерисовывал этот статус в простой эксель документ, который затем отсылал заказчику. Данный процесс был прост, нагляден и очень удобен. До тех пор пока в команде не появились люди, работающие удаленно. Они не видели актуального состояния перед глазами, были вынуждены лезть в эксельку, брали ее на лок, чем самым лишали возможности вносить в нее изменения другим, и тп. Так продолжалось до тех пор, пока мы не решили отказаться от экселя и начать использовать JIRA в качестве project trackingтула.Следующая проблема – обеспечение эффективных коммуникаций. Эта и предыдущая причины того, почему распределенные SCRUM проекты часто деградируют обратно в ватерфолл, с его декларативным распределением задач, строгой отчетностью, бесконечным планированием и написанием тонн документации.Третья проблема это интеграция компонентов, разработанных разными людьми в разных местах. В случае, если эта интеграция выполняется вручную, есть большой риск того, что после очередной выкладки окажется что девелопер забыл зачекинить файл конфигурации с внесенными изменениями, в результате чего поведение на интегрейшен сервере ровно как и на рабочих машинах остальных будет кардинально отличаться от того, что было у нерадивого девелопера, который, увы, уже ушел домой. В результате, весь день команды может быть потерян.Четвертая пробема связана безопасностью. В частности, с безопасностью данных клиента. В случае когда разработка аутсорсится и команда работает распределенно, необходимо внести изменения в конфигурацию сетей, обеспечить защищенный канал передачи данных, дать пользователям доступ к определенным ресурсам и тп. В больших корпорациях процесс создания нового аккаунта может занимать несколько недель. Человек при этом не может работать.Наконец, самая избитая, но оттого не менее актуальная проблема, это проблема разницы в часовых поясах и культурных различиях. Думаю не стоит подробно расписывать весь букет сложностей, с которыми сталкиваются российскииаутсорсеры в своей ежедневной работе с командой заказчика живущей на другой стороне океана.Есть ли решения этих проблем? Об этом мы узнаем во второй части доклада.
  5. Очень часто можно встретить подобную классификацию команд по степени их распределенности. 1) Локальные команды (co-located) это команды работающие в одном помещении и имеющие возможность постоянного общения друг с другом. Это, как мы знаем, идеальные условия для всех agile проектов.2) Частично локальные команды (partially-co-located) могут работать в разных местах, но как правило в одном регионе и часовом поясе. Таким образом, такие команды также могут проводить регулярные F2F митинги, хотя и реже чем полностью локальные команды. Примером такой команды может быть команда состоящая из SCRUM Мастера, Тех Лида, QA лида, двух девелоперов и тестера работающих в одном помещении, а также двух девелоперов и одного автоматизатора, работающих по freelance контракту удаленно, но при этом имеющих возможность в случае чего приехать в офис для проведения sprint planning митинга. 3) Третий вариант это команды распределенные в пределах 8 часов (т.н. рабочего дня). Члены команды не имеют возможность ежедневных F2F митингов, однако у них остается 2-4 ‘общих’ часов, когда члены команды могут общаться друг с другом. Такая команда была в моем проекте – SCRUM Master,тех лид и девелоперы работали в Питере, в то время как QA работали в Бостоне, а архитектор в Хьюстоне. Таким образом, у нас было ежедневно несколько часов перекрытия по времени, когда мы могли общаться друг с другом. 4) Наконец, самый экстремальный вариант это команда, члены которой распределены вне пределов 8 часов. Этот пример я уже описывал ранее. Несмотря на преимущества работы 16 часов в сутки, обеспечить процесс коммуникаций и управлять такой командой должно быть очень сложно.
  6. РаспределенныеSCRUM проекты можно классифицировать по 4 уровням сложности. 1-й уровень – проект выполняется силами одной кросс-функциональнойскрам команды.2-й уровень – проект выполняется силами нескольких кросс-функциональныхскрам команд, сосредоточенных в одном месте (например, одно здание но разные помещения). 3-уровень – проект выполняется силами нескольких кросс-функциональныхскрам команд, распределенных по разным местам (могут быть разные регионы, страны и часовые пояса)4-й уровень – проект выполняется силами нескольких распределенных скрам команд. В случае со 2, 3 и 4 уровнями сложности имеет смысл применять SCRUM of SCRUM для организации межкомандного взаимодействия. О нем подробнее я расскажу в третей части своего доклада.
  7. Перед тем как перейти к рассмотрению СКРАМ процесса применительно к распределенным командам и проектам, предлагаю рассмотреть несколько тактических приемов, которые могут приготиться на любом распределенном проекте.Использование простого языка позволит преодолеть языковой барьер, особенно в тех случаях, когда для части команды основной язык не родной. Старайтесь делать письменные предложения короткими, без использования сложных грамматических конструкций и редких фразеологизмов. Хорошим примером доступного письменного английского может быть техническая документация Microsoft доступная на ресурсах MSDN.Наглядная демонстрация обсуждаемого объекта позволяет существенно сэкономить время, пытаясь описать проблему письменно или что еще хуже, устно. Например, имеет смымл продемонстрировать поведение приложение с помощью любого тула для онлайн демонстрации, такого как Web Ex, Meeting Place и др.Часть информации передается невербальным путем – с помощью мимики и жестов. Часто невозможно понять что чувствует твой собеседник не имея возможности видеть его. Другой пример. На телеконференции присутствуют 10 человек. Один ведет длительный и нудный монолог. В это время у одного из участников рождается светлая мысль, способная сдвниуть дело с мертвой точки, но он слишком вежлив чтобы перебить другого человека. Не видя друг друга невозможно дать сигнал о праве голоса. В таких случаях использование видеооборудования позволяет решить часть проблем коммуникации в распределенных командах.Очень часто новый член команды не знает с чего начать – смотреть код, читать заметки на wiki или разбираться с документацией. Для этого очень полезно иметь единую стартовую страницу, содержащую ссылки на все полезные ресурсы проекта. Начав с этой страницы, девелопер сможет понять, в каком направлении ему двигаться. Удачным примером стартовой страницы для работы со скоупом может стать спринт бэклог, в случае если он заведен в туле для онлайнпроджект менеджмента (такой, как например Version one или JIRA). Оттуда девелопер сможет открыть конкретную историю, загрузить документ с описанием требований и мокапами, посмотреть их каких задач она состоит и какие тесты необходимо выполнить для того чтобы убедится в её корректной имплементации.Очень важно поддерживать вовлеченность всех участников проекта с первого дня, для того чтобы люди не чувствовали себя ненужными. Когда мы только начинали работать как распределенная команда, тестеры начинали шевелиться лишь к середине спринта, когда девелоперы завершали первую часть историй. Как результат – не протестированные истории переносились из спринта в спринт. Для того, чтобы избежать этой проблемы, нам пришлось корректировать процесс для того чтобы тестеры могли работать с первого же дня спринта и начинать написание тест –кейсов и сценариев для последующей автоматизации. Как только девелопер завершал очередную историю, у тестера уже был весь необходимый инструментарий и сам процесс проверки занимал всего несколько часов, и позволял проверить правильность исполнения требования и отсутствия дефектов.
  8. Перейдем непосредственно к жизненному циклу СКРАМ проекта и рассмотрим основные этапы в нем.Первый этап с которого начинается SCRUM проект это планирование релиза. Релиз это цикл верхнего уровня в СКРАМЕ, который проходит через этапы планирования, исполнения, тестирования и стабилизации (maintenance sprint) и подготовки продукта, который отправляется в производство.Еще до того, как приступить к планированию релиза, заказчик делает высокоуровневый план проекта, иногда он называется program plan или flight plan. На этапе этого планирования заказчик определяет собственные business needs и группирует их в эпики. Эпики это высокоуровневые бизнес требования. Примером эпики может бытьнапример:‘Сотрудники компании клиента должны иметь возможность управлять своими страховыми полисами через web interface системы’Или‘Сотрудники колл-центра компании должны иметь возможность просматривать и редактировать данные по каждому клиенту’.Как правило эпику невозможно оценить даже приблизительно. Иногда для их оценки используются т.н. T-shirt sizing (S, M, L, XL, XXL), с неким дефолтным размером по каждому элементу шкалы, например эпики размера S могут заниматься порядка 2 недель, M – 4 недель, L – 6-8 недель, XL – 12 недель (3 месяца), XXL – даже грубо оценить невозможно. Целью выполнения любых business needs является изменение определенных показателей, характеризующих состояние бизнеса. Часто их называют Key Performance Indicators. Такие показатели можно измерить численно. Примером KPI могут быть:33 новых клиента в 2011 году рост прибыли на 15 % уменьшение времени на деплоймент системы с 3 месяцев до 2 недель снижение обслуживающего персонала с 50 до 20 человек путем автоматизации части операцийи тд. После того как определены цели и способы их достижения, рисуется высокоуровневый план проекта, состоящий из нескольких этапов, называемых milestones. Каждый milestone это релиз системы в производство. Как правило, СКРАМ команда начинает принимать участие с этапа планирования релиза (план полета обычно составляется без их участия). Релиз представляет из себя промежуток времени (обычно порядка 2-3 месяцев) разделенный на равнозначные спринты. В конце релиза делается maintenance спринт для стабилизации продукта и подготовки сопроводительной документации. Лишь после того как продукт был стабилизирован, его можно отправлять в production environment. В ходе релиза команда(ы) делают несколько деливери, обычно раз в спринт, однако сымплементированный функционал помещается в т.н. Pre-production environment к которому имеют доступ реальные пользователи и могут тестировать систему на предмет ненайденных багов, но главное, на поиск фидбека, который может быть учтен уже в ходе релиза путем имплементации в одном из следующих его спринтов. Следующий этап планирования релиза это сбор и написание требований. На этом этапе принимают участие пользователи системы, бизнес аналитики и product owner’ы со стороны заказчика. Со стороны команды это могут быть SCRUM Master, Technical Lead, QA Lead или UI Designer. Целью этого процесса является формализация требований в определенной форме. Обычно на SCRUM проектах это user story. Майкл Кохн в своей книге User Story Applied for Agile Software Development предлагает такой формат user story:As a <role> I want to <action> so that <business value>Существуют разные способы написания юзерстори, например на карточках – с одной стороны пишется narrative, а с другой – acceptance criteria по которым можно валидировать корректность выполнения данной истории. Тот же Кохн предлагает такой формат для acceptance criteria:Given (pre-condition), When (action), Then (expected result)В распределенных командах имеет смысл сразу же писать user story и acceptance tests к ним в электронном виде. Например, на нашем проекте мы использовали определенный word темплэйт, состоящий из нескольких секций:NarrativeBackground (optional)Acceptance criteriaAssumptions (optional)Mockups (optional)Никто не ждет, что в начале релиза команда сможет написать все истории в полном объеме, учитывая что само планирование релиза должно быть time-boxed сессией. Наш опыт показал что для релизов длительностью 3 месяца (12 недель) достаточно планирования длинной в неделю. За это время команда успевает кратко обсудить все истории и сформировать бэклог а также детально обсудить истории на ближайшие 2-3 спринта. Когда нет возможности собираться F2F на планирование релиза, полезно использовать видео связь чтобы видеть всех собеседников и их реакции. Для формирования product backlog полезно использовать online тул а не один excel документ. Результатом данной работы должен стать список всех историй запланированных на спринт, чтобы была возможность его ранжирования в порядке приоритетов истории а также мапить истории на их детальные описания.После того как PBL составлен, можно начинать высокоуровневую оценку в story points. Я не буду подробно останавлиться на определении SP, а лишь уделю внимание процессу оценки для распределенной команды. Есть бесплатный тул под названием www.planningpoker.com, разработанный компанией КохнаMountain Goat. Он позволяет членам распределенной команды давать оценки независимо друг от друга, и выгружать бэклог с оценками в виде excel файла.Для того чтобы понять, сколько историй можно теоретически успеть сделать в релиз, нужно сделать допущение о скорости команды. Сложнее всего это сделать в начале проекта когда скорость команды еще неизвестна. Поэтому ожидания от первого релиза как правило несколько меньше чем от последующих, тк. в это время команда проходит еще только forming, storming и normingэтапы (forming, storming, norming, performing). После того как это допушение сделано, или известна реальная скорость команды в спринт, можно определить какую часть бэклога теоретически реально выполнить умножив велосити на число спринтов (вот почему важно чтобы длина спринта оставалась постоянной). В зависимости от того, какую часть от общего скоупа по силам выполнить команде, Product owner может поменять приоритеты историй. Наконец, финальный этап это подготовка плана релиза. Он представляет из себя помимо всего прочего PBL, разбитый по спринтам. В случае когда на проекте несколько команд, PBL также полезно разбить по командам, например, сгруппировав истории в независимые блоки или feature sets, для того чтобы обеспечить максимально эффективную работу команд независимо друг от друга. Однако, важно чтобы все команды оставались в одном ритме – спринты дожны быть либо равной длины либо кратными.Стоит также отметить что релиз план должен оставаться живым документом. Релиз план, это не коммитмент для скрам команды, а инструмент планирования для product owner’а. Он должен отражать реальное положение дел на проекте.
  9. Следущий цикл SCRUM проекта – спринт. Спринт начинается с проведения sprint planning митинга. В распределенных командах, особенно в тех где отствует возможность провести sprint planning F2F в течение всего дня, остается довольно узкий временной диапазон, от 2 до 4 часов. Для того, чтобы уложиться в отведенное время и оценить имеющийся скоуп, все члены команды должны уже хорошо представлять себе требования на следующий спринт. Для этого часто применяются т.н. Pre-planning митинги или по другому их называют backlog grooming.Backlog grooming представляет собой time-boxed митинги (обычно 1-1.5 часа) для того чтобы держать всех участников в фокусе. В таких митингах как правило участвуют не все члены команды чтобы сделать их более эффективными, а лишь SM, PO, Tech Lead, QA Lead. Цель backlog grooming – обсудить истории запланированные на следующий спринт, задать вопросы, от которых будет зависеть оценка, уточнить отсутствующие детали. Иногда делается оценка в story points для того чтобы Product Owner имел возможность менять приоритеты. Проведение самих Sprint Planning митингов также представляет из себя определенный челлендж в распределенных командах. Предположим, на вашем проекте используются двухнедельные спринты. Как правило, в таком случае на каждый спринт отводится 1 день для проведения Sprint Planning в начале спринта и showcase/retrospective в конце. Если часть вашей команды работает с 8-часовым сдвигом (что характерно для команд распределенный между Россией и США), у вас остается максимум 4 часа в день, при условии рабочего дня с 12 до 8 вечера. В таком случае имеет смысл проводить sprint planning во вторую половину дня в понедельник, первую половину можно потратить на выполнение задач, перенесенных с прошлого спринта, либо на нетрудоемкие (занимающие не более 4 часов) задачи рефакторинга и багфиксинга. Для того чтобы уложиться в 4 часа, необходимо чтобы сам sprint planning проходил сжато и динамично, и имел определенный ритм. Например:В течении 10 минут Product owner в общих чертах описывает историюВ течении следующих 10 минут проводится блиц сессия – Q&AСледущие 10 минут команда дает оценку в story points, при этом может потребоваться несколько циклов в случае если оценки сильно варьируютсяТаким образом, за первые два часа реально обсудить до 6 историй (при условии, что члены команды уже в курсе и сами истории не требуют доработки). Следующие два часа команда может провести уже без участия product owner для того чтобы дать детальный эстимейт по каждой из историй путем разбиения её на инженерные подзадачи и оценки каждой из задач в часах. При этом важно чтобы все члены команды видели sprint backlog в режиме онлайн редактирования.Результамиsprint planning является коммитмент команды под определенный набор историй, выраженный в виде sprint backlog. Помимо этого, полезно хранить user story cards с теми дополнениями и уточнениями которые были сделаны командой во время backlog grooming и sprint planning митингов. Есть и другой вариант – в случае, если нет возможности оперативно вносить изменения в сами user story (особенно когда время на обсуждение ограничено), полезно одному или нескольким участникам SP митинга писать минутки и потом рассылать их всем членам команды. Прочитав такие минутки каждый участник проекта будет знать об актуальном состоянии требований.
  10. Третий и самый короткий цикл SCRUM проекта– daily SCRUM. В распределенных командах процесс Daily SCRUM имеет ряд отличий, о которых мы поговорим.Во-первых, это Standup митинги. Если часть вашей команды работает с разницей в 8 часов, имеет смысл проводить standup митинги дважды – утром для локальных членов проекта и вечером – для всей распределенной команды. Это помогает держать ритм в команде и отслеживать прогресс выполнения спринта.Во-вторых, это постоянная возможность доступа для всех членов команды к sprint backlog с возможностью видеть burndown chart, а также отслеживать статусы по каждой из историй и задач, включая назначения и предполагаемое количество времени требуемое для завершения каждой из задач.Перед началом каждого stand up митинга для локальной части команды полезно либо распечатывать sprint backlog, либо поберечь деревья и использовать, например, проектор.Наконец, немного поговорим про XP практики ,которые не только до сих пор не утратили свою ценность но и приобрели еще большее значение в распределенных командах.Парное программирование. Два члена команды работающие на разных материках по прежнему могут работать в паре. Для этого ведущему требуется расшарить свой desktop (например, через Skype либо любую из conference meeting инструментов, поддерживающих демонстрационный интерфейс) и вслух комментировать код, который он пишет. Единственным ограничением здесь может стать ограничение по времени, например для программистов работающих в СПб и Бостоне нет возможности работать в паре более 4 часов, хотя этого в большинстве случаев может быть достаточно.Unit тесты принимают критическую важность, особенно в тех случаях, когда код пишут люди, не имеющие возможность ежедневного контакта. В таком случае unit тесты становятся первым рубежом, который защищает билд от некорректных сабмитов. Естественно, каждому члену команды требуется запускать локальные тесты перед тем как сабмитить код в СКВ. Помимо локальных тестов в SoSпроектах также используются интеграционные тесты, запускаемые уже после того как был выполнен deployment в рабочий (test) environment и нужно проверить как ведет себя приложение после интеграции. Примерами таких тестов могут быть тесты использующие реальную базу данных (вместо моков, которые используются в unit тестах) либо же тесты, дергающие public API уже задеплоенных компонентов, например web сервисовИспользование простого дизайна и понятного кода (имеются в виду прежде всего имена классов, методов и переменных, а также требования к числу строчек кода на класс или метод) позволяет членам распределенной команды понимать что делает приложение без необходимости писать комментарии или сопроводительную документацию. Регулярные ревью кода и рефакторинг позволяют обеспечить выполнение требований простого дизайна и понятного кода, а кроме того способствуют общему владению кодом, что также характерно для XP.
  11. Теперь поговорим о том, как синхронизировать работу нескольких команд, участвующих в SOS проекте (тип сложности 3, 4 и по шкале распределенности)Во первых, сложно переоценить значение SCRUM of SCRUMs митингов, которые следует проводить по меньшей мере 3 раза в неделю. Участниками таких митингов могут быть:-СКРАМ мастера каждой из команд-Product owners-Tech лиды-QA лиды-любые другие члены команд которые могут отвечать за всю командуОт каждой команды как правило выступает один человек, который отвечает на вопросы:Какие задачи выполняла моя команда вчераКакие задачи моя команда выполняет сегодняКакие сложности есть в моей команде, вляющие на ход выполнения задачА также, какие сложности могут возникнуть у других команд в результате выполнения задач вашей командойИногда одновременно могут проводиться несколько SoSмитингов, например:-SoSдля SCRUM Masters для обсуждения прогресса своих команд и блокеров-SoSдля Product Owners каждой из команд для обсуждения приоритетов взаимосвязанных задач-SoSдля Architects/Tech Leads каждой из команд для обсуждения вопросов интеграции и интерфейсов взаимодействия параллельно разрабатываемых компонентовСледующим важным требованием к многокомандному проекту является сихронность циклов разработки – спринтов. В качестве примера приведу опыт проекта Eclipse выполняемого в компании IBM, где в качестве базовой длины спринта были 6 недель. Поскольку проект состоял из множества больших и малых команд, не всем было удобно использовать спринт такой длины. Однако, у них были варианты использовать также спринты длиной 1, 2 или 3 недели. Таким образом, все команды независимо от их размера и сферы ответственности двигались синхронно и команда работающая по 6 недельному циклу могла получать еженедельные деливери от команды работающей по недельному циклу.Приоритизация задач на многокомандных распределенных проектах имеет важное значение. Особенно это относится к задачам, которые являются зависимыми друг от друга, и находятся в бэклогах разных команд. В случае, если приоритетность задач невозможно расставить таким образом, чтобы сначала была сделана задача, от которой зависят другие задачи, имеет смысл применять подход имплементации STUB интерфейсов – т.е. реализация заглушек отвечающих требованиям интерфейса взаимодействия и последующая подмена их реальными компонентами работающими по тем же интерфейсам.Наконец, интеграция компонентов, о которой уже упоминалось ранее также играет решающее значение для распределенных SCRUM of SCRUMs проектов. Во многих крупных компаниях еще сохранилась привычка выделять отдельного человека, играющего роль тнBuild manager, в задачи которого входит ручная интеграция всех компонентов системы и проверка их работоспособности. К счастью, сегодня можно обойтись без этой рутинной работы и самое главное, исключить влияние пресловутого человеческого фактора, путем частичной или полной автоматизации билда системы и деплоймента в рабочий environment. В добавок к автоматическим unit и integration тестам о которых мы говорили ранее добавляются также автоматизированные регресс-тесты которые могут регулярно запускаться для проверки стабильности работы системы.
  12. По окончании спринта проводится т.н. Show case сессия в ходе которой команда демонстрирует product owner’у и другим стейкхолдерам результаты которых они достигли – а именно, работающие истории. Для того чтобы считать историю завершенной, команда и product owner договариваются о ряде критериев, которые должны выполняться для каждой истории. Например:Все acceptance тесты должны быть пройденыКритические дефекты должны отсутствоватьShow case сессия в распределенных командах мало чем отличается от тех что проводится для обычных colocatedкоманд, разве что для демонстрации используются средства online презентаций а все участники используют phone или video conferencing для общения. Перед проведением show case полезно подготовить несколько сценариев, которые будут демонстрироваться product owner’у. Эти сценарии может написать либо сам PO, либо QA лид, и обычно они включают в себя выполнение acceptance тестов для данной истории.После проведения show case для истории PO может дать по ней acceptance, если все DoDсоблюдены. Также на этом этапе у стейкхолдеров могут появиться новые идеи, фидбек, которые можно занести в PBL как истории на будущие спринты.После завершения show case команда и PO могут выполнить завершение спринта (Sprint closure). На этом этапе ревьюитсяsprint backlog, те истории в которых остались невыполненные задачи сплиаются на следующий спринт. Важным моментом является то, что количество заработанных командой story points за спринт считается только по выполненным историям.В заключении добавлю, что на проведение этой сессии следуюет уделять не более 3 часов, для того чтобы еще осталось время на проведение ретроспективы.
  13. После того как выполнен и завершен спринт или релиз, проводится ретроспектива. Цель проведения ретроспективы – определить как можно улучшить процесс для данной команды или для проекта в целом путем сбора и обсуждения мнений каждого из участников. Перед проведением ретроспективы полезно попросить всех членов команды (pigs) и стейкхолдеров наблюдателей (chickens) дать свой фидбек, путем ответы на несколько простых вопросов:Что на ваш взгляд было сделано хорошоГде требуются улучшения в будущемКаковы цели на следующий спринт/релизПредварительный сбор фидбека позволяет лучше подготовиться к ретроспективе и сократить время на её проведение. В ходе ретроспективы айтемы по каждому из вопросов можно проранжировать в порядке их важности.Иногда некоторым членам команды может быть сложно дать искренний ответ на вопрос о том что было хорошо. В таком случае можно обсудить это со своим скрам мастером и подумать о том, как можно максимально политкорректно донести эту информацию до всех участников проекта. Например, на нашем проекте разработчики были очень недовольны требованием архитектора со стороны заказчика писать комментарии в коде там, где на их взгляд код прост и понятен. Трудности также вызывал тот факт, что архитектор постоянно оставался недоволен качеством комментариев и оказывал определенное давление на команду. Для того, чтобы решить эту проблему, было предложено внести изменения в процесс ревью кода и проводить регулярные сессии между архитектором и девелоперами для того чтобы обсуждать те места которые могут быть непонятны и рефакторить код путем применения нативных имен и сокращения строчек кода на методы. Использование этого процесса помогло команде избавиться от написания лишних строчек комментариев которые загромождали код, а также избавиться от постоянного давления архитектора, о чем было сказано в позитивном ключе во время одной из ретроспектив.
  14. В заключении, перед тем как сделать выводы, я приведу вам пример распределенного SCRUM проекта SirsiDynix. Итак, компания SirsiDynixразрабатывает ПО для онлайн библиотек. Еще до того, как начать применять agile и SCRUM, компания использовала waterfall approach на своих проектах. Опыт waterfall проекта – 60 человек в течение 9 месяцев написали 54 тысячи строк кода. За это время было реализовано 900 functional points. Впоследствие, проект был переписан с использованием одной colocated SCRUM команды из 4.5 человек работающих в течение 12 месяцев. За это время было написано 51 тысяча строк кода и реализовано 960 functional points. Конечно, этие результаты могут быть весьма условными, но для сравнения, средняя скорость в waterfall равнялась 2 Functional Points на разработчика в месяц. В SCRUM проекте средняя скорость была выше в 9 (девять) раз!После того как SirsiDynixзаключил контракт с компанией Star Soft Labs на выполнение распределенного SCRUM проекта, общая численность достигла 56 человек. Длительность проекта составляла 14,5 месяцев. За это время было написано суммарно 671 тысячас строк кода. Для того чтобы измерить тот объем функциональности, который был реализован за это время, в functional points, использовалось соотноние 53 JAVA LOC на 1 FP, полученное Capers Jones из Software Productivitiy Research после анализа 10 тысяч software development проектов. Таким образом, средняя скорость в распределенном SCRUM проекте была лишь немногим ниже чем в colocated SCRUM проекте, что является одним из самых успешных случаев использования SCRUM в крупных распределенных проектах!
  15. Подведем основные выводы:Максимально эффективными остаются мультифункциональные и независимые команды. В случае грамотно поставленного процесса, скорость распределенной SCRUM команды немногим ниже скорости обычной colocatedкоманды.Для обеспечение эффективного процесса коммуникаций и взаимодействия между членами распределенных команд необъходимо использовать средства аудио и видео конференций.У всех участников проекта должен быть постоянный доступ ко всем ресурсам проекта, включая product backlog, sprint backlog, возможность посмотреть статус по каждой из задач, прочитать требование или построить burndown chart.Использование SCRUM процесса и адаптированных XP практик помогает во много раз повысить производительность команды, при этом отказаться от таких артифактовwaterfall как комментарии в коде и сопроводительная документация.И наконец, процесс не должен стоять на месте, он должен адаптироваться и развиваться вместе с тем бизнесом, задачи которого и решает ваш проект!