Your SlideShare is downloading. ×
Распределенный SCRUM - to be or not to be collocated collocated
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

2,189
views

Published on

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

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


0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,189
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Идея сделать данный доклад родилась тот момент, когда стало известно, что моя команда будет состоять из разработчиков в Питере, архитектора в Бостоне и тестеров в Хьюстоне.
  • Доклад состоит из 4 частей. В первой части (введение) я расскажу о том, зачем вообще нужны сегодня распределенные команды и проекты. Затем мы рассмотрим основные трудности, с которыми сталкиваются участники таких проектов.Во второй части (классификация) мы рассмотрим типы команд по степени их распределенности а также уровни сложности распределенных проектов. Кроме того, в этой главе мы рассмотрим несколько полезных советов, которые могут быть использованы на любом распределенном проекте. В третей части (применение) мы еще раз посмотрим на жизненный цикл SCRUM проекта через призму распределенности. Здесь мы уделим внимание тем практикам, которые можно использовать на распределенных SCRUM проектах.И наконец в заключении я расскажу о тех результатах, которых добились на распределенном проекте StarSoft - Sirsi-Dynix, а также подведу итоги и еще раз суммирую все вышесказанное. Все оставшееся время я буду готов с радостью отвечать на ваши вопросы. Итак, если вопросов по содержанию нет, можно приступать.
  • Почему распределенный SCRUM как и любой другой распределенный проект сегодня становится все более актуальным?1) Во первых из за сложности современных проектов. Уже довольно редко целью проекта является разработка сверхбыстрого и безотказного ядра базы данных или алгоритма архивации, которые вполне могли бы быть написаны парой талантливых программистов. Вместо этого сегодняшние проекты имеют множество целей а разрабатываемые системы предназначены для самых разных вариантов примененения и представляют из себя интеграцию разных технологий и компонентов. Создание таких систем требует труда десятков программистов, тестировщиков, бизнес аналитиков, дизайнеров и архитекторов. Практически нереально собрать эту группу в одном месте. 2) Во вторых, распреденные проекты дают возможность доступа к огромному пулу талантов. Особенно это актуально для интернациональных компаний, имеющих филиалы в разных странах, а также компаниях, использующих услуги фрилансеров. Доступ к пулу талантов позволяет в кратчайшие сроки подобрать команду с требуемыми скилами, и при этом не вылезти за рамки бюджета проекта.3) Третья причина, по которой может иметь смысл использовать распределенный SCRUM, это возможность обеспечить работу команды в течении 16 часов. Этот подход упоминается в книжке Practical guide to distributed SCRUM и называется Follow the SUN model. Его смысл состоит в том, что одна часть команды работающая на восточном полушарии работает первые 8 часов дня, в то время как другая команда работает вторые 8 часов дня. Таких образом может быть достигнут теоретический прирост производительности в два раза. Однако, лично мне на практике не удавалось применять данный подход, кроме того есть ряд сложностей в его имплементации. В частности, у команды не остается возможности вербального онлайн общения в стандартные рабочие часы.4) Стандартная причина, по которой многие компании прибегают к распределенным проектам это стремление максимально снизить расходы. Нанять того же фрилансера гораздо дешевле чем брать человека на работу – не нужно создавать ему рабочее место, не нужно оплачивать страховку, больничные и отпускные. Это четвертая причина.5) Наконец, самая неприятная на мой взгляд причина, это стремление многих компаний сегодня избавиться от бенча – скамейки запасных, так называемого балласта сотрудников которые оказались без проекта. Это довольно болезненная процедура, не только для тех, кого сокращают, но и для тех, кто остается, ведь им в ряде случаев приходится работать за двоих. Использование распределенного управления это выход для таких компаний.
  • Несмотря на ряд очевидных преимуществ распределенного подхода к управлению проектами перед традиционным collocated, есть ряд проблем ,которые могут оказаться камнем преткновения для многих проектов, особенно на ранних стадиях, и стать могильной плитой для самых неудачливых. Во-первых, использование распределенных команд и проектов неизбежно влечет изменения в организации и управлении проектом. Приведу простой пример. Раньше мы часто рисовали истории и таски на больших ватманах, которые крепились на стену. На утреннем стендапе каждый из членов команды видел текущее состояние по историям и задачам, а также имел возможность отметить прогресс по своей задаче. Я в свою очередь ежедневно перерисовывал этот статус в простой эксель документ, который затем отсылал заказчику. Данный процесс был прост, нагляден и очень удобен. До тех пор пока в команде не появились люди, работающие удаленно. Они не видели актуального состояния перед глазами, были вынуждены лезть в эксельку, брали ее на лок, чем самым лишали возможности вносить в нее изменения другим, и тп. Так продолжалось до тех пор, пока мы не решили отказаться от экселя и начать использовать JIRA в качестве project trackingтула.Следующая проблема – обеспечение эффективных коммуникаций. Эта и предыдущая причины того, почему распределенные SCRUM проекты часто деградируют обратно в ватерфолл, с его декларативным распределением задач, строгой отчетностью, бесконечным планированием и написанием тонн документации.Третья проблема это интеграция компонентов, разработанных разными людьми в разных местах. В случае, если эта интеграция выполняется вручную, есть большой риск того, что после очередной выкладки окажется что девелопер забыл зачекинить файл конфигурации с внесенными изменениями, в результате чего поведение на интегрейшен сервере ровно как и на рабочих машинах остальных будет кардинально отличаться от того, что было у нерадивого девелопера, который, увы, уже ушел домой. В результате, весь день команды может быть потерян.Четвертая пробема связана безопасностью. В частности, с безопасностью данных клиента. В случае когда разработка аутсорсится и команда работает распределенно, необходимо внести изменения в конфигурацию сетей, обеспечить защищенный канал передачи данных, дать пользователям доступ к определенным ресурсам и тп. В больших корпорациях процесс создания нового аккаунта может занимать несколько недель. Человек при этом не может работать.Наконец, самая избитая, но оттого не менее актуальная проблема, это проблема разницы в часовых поясах и культурных различиях. Думаю не стоит подробно расписывать весь букет сложностей, с которыми сталкиваются российскииаутсорсеры в своей ежедневной работе с командой заказчика живущей на другой стороне океана.Есть ли решения этих проблем? Об этом мы узнаем во второй части доклада.
  • Очень часто можно встретить подобную классификацию команд по степени их распределенности. 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 часов в сутки, обеспечить процесс коммуникаций и управлять такой командой должно быть очень сложно.
  • РаспределенныеSCRUM проекты можно классифицировать по 4 уровням сложности. 1-й уровень – проект выполняется силами одной кросс-функциональнойскрам команды.2-й уровень – проект выполняется силами нескольких кросс-функциональныхскрам команд, сосредоточенных в одном месте (например, одно здание но разные помещения). 3-уровень – проект выполняется силами нескольких кросс-функциональныхскрам команд, распределенных по разным местам (могут быть разные регионы, страны и часовые пояса)4-й уровень – проект выполняется силами нескольких распределенных скрам команд. В случае со 2, 3 и 4 уровнями сложности имеет смысл применять SCRUM of SCRUM для организации межкомандного взаимодействия. О нем подробнее я расскажу в третей части своего доклада.
  • Перед тем как перейти к рассмотрению СКРАМ процесса применительно к распределенным командам и проектам, предлагаю рассмотреть несколько тактических приемов, которые могут приготиться на любом распределенном проекте.Использование простого языка позволит преодолеть языковой барьер, особенно в тех случаях, когда для части команды основной язык не родной. Старайтесь делать письменные предложения короткими, без использования сложных грамматических конструкций и редких фразеологизмов. Хорошим примером доступного письменного английского может быть техническая документация Microsoft доступная на ресурсах MSDN.Наглядная демонстрация обсуждаемого объекта позволяет существенно сэкономить время, пытаясь описать проблему письменно или что еще хуже, устно. Например, имеет смымл продемонстрировать поведение приложение с помощью любого тула для онлайн демонстрации, такого как Web Ex, Meeting Place и др.Часть информации передается невербальным путем – с помощью мимики и жестов. Часто невозможно понять что чувствует твой собеседник не имея возможности видеть его. Другой пример. На телеконференции присутствуют 10 человек. Один ведет длительный и нудный монолог. В это время у одного из участников рождается светлая мысль, способная сдвниуть дело с мертвой точки, но он слишком вежлив чтобы перебить другого человека. Не видя друг друга невозможно дать сигнал о праве голоса. В таких случаях использование видеооборудования позволяет решить часть проблем коммуникации в распределенных командах.Очень часто новый член команды не знает с чего начать – смотреть код, читать заметки на wiki или разбираться с документацией. Для этого очень полезно иметь единую стартовую страницу, содержащую ссылки на все полезные ресурсы проекта. Начав с этой страницы, девелопер сможет понять, в каком направлении ему двигаться. Удачным примером стартовой страницы для работы со скоупом может стать спринт бэклог, в случае если он заведен в туле для онлайнпроджект менеджмента (такой, как например Version one или JIRA). Оттуда девелопер сможет открыть конкретную историю, загрузить документ с описанием требований и мокапами, посмотреть их каких задач она состоит и какие тесты необходимо выполнить для того чтобы убедится в её корректной имплементации.Очень важно поддерживать вовлеченность всех участников проекта с первого дня, для того чтобы люди не чувствовали себя ненужными. Когда мы только начинали работать как распределенная команда, тестеры начинали шевелиться лишь к середине спринта, когда девелоперы завершали первую часть историй. Как результат – не протестированные истории переносились из спринта в спринт. Для того, чтобы избежать этой проблемы, нам пришлось корректировать процесс для того чтобы тестеры могли работать с первого же дня спринта и начинать написание тест –кейсов и сценариев для последующей автоматизации. Как только девелопер завершал очередную историю, у тестера уже был весь необходимый инструментарий и сам процесс проверки занимал всего несколько часов, и позволял проверить правильность исполнения требования и отсутствия дефектов.
  • Перейдем непосредственно к жизненному циклу СКРАМ проекта и рассмотрим основные этапы в нем.Первый этап с которого начинается 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’а. Он должен отражать реальное положение дел на проекте.
  • Следущий цикл 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 митинга писать минутки и потом рассылать их всем членам команды. Прочитав такие минутки каждый участник проекта будет знать об актуальном состоянии требований.
  • Третий и самый короткий цикл 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.
  • Теперь поговорим о том, как синхронизировать работу нескольких команд, участвующих в 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 тестам о которых мы говорили ранее добавляются также автоматизированные регресс-тесты которые могут регулярно запускаться для проверки стабильности работы системы.
  • По окончании спринта проводится т.н. 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 часов, для того чтобы еще осталось время на проведение ретроспективы.
  • После того как выполнен и завершен спринт или релиз, проводится ретроспектива. Цель проведения ретроспективы – определить как можно улучшить процесс для данной команды или для проекта в целом путем сбора и обсуждения мнений каждого из участников. Перед проведением ретроспективы полезно попросить всех членов команды (pigs) и стейкхолдеров наблюдателей (chickens) дать свой фидбек, путем ответы на несколько простых вопросов:Что на ваш взгляд было сделано хорошоГде требуются улучшения в будущемКаковы цели на следующий спринт/релизПредварительный сбор фидбека позволяет лучше подготовиться к ретроспективе и сократить время на её проведение. В ходе ретроспективы айтемы по каждому из вопросов можно проранжировать в порядке их важности.Иногда некоторым членам команды может быть сложно дать искренний ответ на вопрос о том что было хорошо. В таком случае можно обсудить это со своим скрам мастером и подумать о том, как можно максимально политкорректно донести эту информацию до всех участников проекта. Например, на нашем проекте разработчики были очень недовольны требованием архитектора со стороны заказчика писать комментарии в коде там, где на их взгляд код прост и понятен. Трудности также вызывал тот факт, что архитектор постоянно оставался недоволен качеством комментариев и оказывал определенное давление на команду. Для того, чтобы решить эту проблему, было предложено внести изменения в процесс ревью кода и проводить регулярные сессии между архитектором и девелоперами для того чтобы обсуждать те места которые могут быть непонятны и рефакторить код путем применения нативных имен и сокращения строчек кода на методы. Использование этого процесса помогло команде избавиться от написания лишних строчек комментариев которые загромождали код, а также избавиться от постоянного давления архитектора, о чем было сказано в позитивном ключе во время одной из ретроспектив.
  • В заключении, перед тем как сделать выводы, я приведу вам пример распределенного 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 в крупных распределенных проектах!
  • Подведем основные выводы:Максимально эффективными остаются мультифункциональные и независимые команды. В случае грамотно поставленного процесса, скорость распределенной SCRUM команды немногим ниже скорости обычной colocatedкоманды.Для обеспечение эффективного процесса коммуникаций и взаимодействия между членами распределенных команд необъходимо использовать средства аудио и видео конференций.У всех участников проекта должен быть постоянный доступ ко всем ресурсам проекта, включая product backlog, sprint backlog, возможность посмотреть статус по каждой из задач, прочитать требование или построить burndown chart.Использование SCRUM процесса и адаптированных XP практик помогает во много раз повысить производительность команды, при этом отказаться от таких артифактовwaterfall как комментарии в коде и сопроводительная документация.И наконец, процесс не должен стоять на месте, он должен адаптироваться и развиваться вместе с тем бизнесом, задачи которого и решает ваш проект!
  • Transcript

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