Устраняет частично

Устраняет полностью

Устраняет полностью

Устраняет полностью

Вариант «Не устраняет» выбирался в том случае, если методология не предлагает никаких вариантов решения рассматриваемой проблемы. Вариант «Устраняет частично» выбирался в том случае, если для решения проблемы в методологии приводились ссылки на другие практики или вариант предлагаемый методологией сложно повсеместно применять в территориально распределенных проектах.

В процессе анализа также были выявлены дополнительные ограничения использования рассматриваемых методологий, которые оказывают существенное влияние при выборе практик. Например, методология XP рассчитана на команду, состоящую в среднем из 5 человек, что не соответствует требованиям к разрабатываемой методике.

Согласно статистике использования гибких методологий наиболее часто встречаются гибриды Scrum и XP, Scrum и Kanban (Scrumban), однако Scrum по своей сути обладает крайне низкой степенью формализации и не рассчитан на крупные и сложные проекты. Для того чтобы разрабатываемые предложения могла быть использована на проектах высокой сложности, будут дополнительно применены практики методологии FDD, которые позволят формализовать модель системы.

В результате для методики были выбраны компоненты всех четырех методологий (см. Таблица 4): основной, на которой строится процесс работы над проектом, был выбран Scrum.



Таблица 4. Компоненты методологий, выбранные для методики

Scrum	Kanban	XP	FDD
Организация процесса работы (спринты), роли, практики командообразования	Практики визуального менеджмента	Практики коллективного владения кодом и стандартов кодирования	Процессы первичной проектной деятельности (нулевой спринт) и практика инспекций

Для улучшения управляемости проекта будут применены практики визуального менеджмента, предлагаемые Kanban, например, доска. Применение практики коллективного владения кодом позволит снизить зависимость от конкретных специалистов и дорабатывать программное обеспечение даже в часы недоступности части команды, а стандарты кодирования позволят повысить качество и понятность кода. Для того чтобы предложения удовлетворяли требованиям, будут использованы процессы первичной проектной деятельности, применяемые в FDD, то есть моделирование модели системы и выделение предметных областей. Контроль качества поставляемого программного обеспечения будет осуществляться с помощью инспекций проводимых в рамках каждого спринта.

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



Глава 2. Формирование документа предложения по внедрению гибких методологий в территориально распределенных проектах разработки программного обеспечения

2.1 Разработка требований к документу

Для разработки методики необходимо сформировать требования, которым она должна удовлетворять. В качестве критериев будем также использовать уже выделенные проблемы территориально распределенных проектов по разработке программного обеспечения. Перед этим проанализируем текущую ситуацию на примере проекта в отделе хранилищ данных и BI в крупной российской ИТ-компании ЛАНИТ. Для проведения анализа построим структуру команды на проекте «as-is» (как есть) и выявим характерные особенности данного проекта.

В качестве примера территориально распределенного проекта по разработке программного обеспечения был выбран проект по созданию системы анализа логистической деятельности ФГУП «Почта России» (САД Логистика). Проект относится к числу крупных и инновационных, так как наработки в данной сфере у компании отсутствуют. Разработка ведется в двух офисах: главный офис в Москве, где проводится большая часть аналитической работы и общение с заказчиков, удаленный офис в Минске, где ведется все разработка системы, а также несколько удаленно работающих специалистов по тестированию (см. Рисунок 9).



Рисунок 9. Структура проекта САД Логистика

На диаграмме было отражено взаимодействие между членами проектной команды, а также взаимодействие с заказчиком. Из диаграммы становится понятно, что руководитель проекта взаимодействует только с членами команды в рамках своего офиса, которые в свою очередь уже контактируют с членами команды из удаленного офиса. Руководитель разработчиков участвует в процессе разработки на равных с остальными разработчиками, активно взаимодействую с аналитиками и архитектором. Проектная команда состоит из 11 человек. Основной используемый канал коммуникации между членами команды - электронная почта, вследствие чего команда тратит большую часть времени на уточнение требований и в 60% случаев на последующее переделывание. По причине того, что руководитель проекта взаимодействует преимущественно с аналитиками, у него формируется искаженное представление о ходе проекта. Разработчики не успевают поставлять функциональный инкремент к программному обеспечению каждые две недели.

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

Таблица 5. Требования к методике управления территориально распределенным проектом по разработке программного обеспечения

№	Критерий	Требование к методике управления проектом
1	Проблема инициации процесса коммуникации	Предложения должны регулировать организацию внутренних коммуникаций
2	Низкая частота коммуникации
3	Высокие затраты на коммуникацию
4	Различия во временных зонах
5	Недопонимание между членами команды
6	Сложность контроля процесса разработки	Предложения должны регулировать процессы управления проектом
7	Сложность контроля качества программного продукта
8	Недостаток доверия между членами команды	Предложения должны регулировать процесс командообразования в проекте
9	Отсутствие боевого командного духа
10	Отсутствие обмена опыта между частями команды	Предложения должны регулировать обмен опытом между членами команды
11	Проектная команда размером в 11 человек	Предложения должны быть применимы для проектных команд размером от 8 до 15 человек
12	Реализация сложных и инновационных проектов	Предложения должна быть применимы для проектов, по которым отсутствуют какие-либо предварительные наработки

2.2 Формирование структуры документа

Структура разрабатываемой методики зависит от требований, предъявляемых к методике, и должна соответствовать как общепризнанным положениям, так и корпоративной культуре компании, в которой она будет использоваться. Таким образом, стоит отметить, что разрабатываемое предложение должно содержать следующую информацию:

1. Разделы, посвященные управлению территориально распределенным проектом:

1.1. роли в проекте;

1.2. процессы жизненного цикла проекта;

1.3. управление качеством проекта;

1.4. управление коммуникациями проекта;

1.5. управление человеческими ресурсами проекта;

1.6. управление сроками и содержанием проекта.

2. Описание должностных лиц и требования к их ответственности для обеспечения выполнения положений методики.

3. Правила использования инструментов, поддерживающих реализацию положений методики.

Рассмотрим подробно разделы, которые должны быть отражены в методике:

1. Общие положения.

2. Установление ответственности.

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

Источники наполнения данного раздела - должностные инструкции специалистов компании ЛАНИТ, организационная структура компании и прочие внутренние нормативные документы.

3. Жизненный цикл проекта.

Данный раздел описывает этапы жизненного цикла проекта, так как предложения будут строиться не на одной методологии, а на их комбинации, и будет отличаться от жизненного цикла методологии Scrum. Также описываются основные роли на проекте и возможные сочетания ролей.

4. Командообразование проекта.

В основе данного раздела лежат мероприятия и инструменты, которые могут быть использованы для командообразования. Так как при использовании гибких подходов к разработке программного обеспечения поддержание боевого духа и формирование доверия между членами команды выступает одной из ключевых задач, менеджеру проекта необходимо уделить особое внимание изучению данного раздела. Основные источники раздела являются практики предлагаемые методологией Scrum.

5. Внутрипроектные коммуникации проекта.

В этот раздел войдут положения методики, регулирующие организацию внутрипроектных коммуникаций. Будут рассмотрены основные каналы коммуникации, рекомендованные инструменты взаимодействия, а также правила, регламентирующие взаимодействие удаленных команд.

6. Управление сроками и содержанием проекта

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

7. Управление качеством продукта

В данный раздел войдут положения методики, описывающие правила применения практик, обеспечивающих получение качественного программного продукта. За основу будут взяты практики методологий FDD, XP и Scrum.

8. Оценка состояния проекта

В данный раздел методики войдет список показателей, а также правила их расчёта, которые помогут руководителю проекта или скрам-мастеру управлять проектом и оценивать качество разрабатываемого продукта. Источником наполнения данного раздела являются наиболее популярные показатели методологии Scrum и Kanban, сочетание которых поможет более точно принимать управленческие решения.

2.3 Разработка содержания разделов документа

В данном разделе рассматриваются более подробно основные разделы методики - жизненный цикл проекта, управление человеческими ресурсами, управление коммуникациями, управление сроками и содержанием, управление качеством проекта.

2.3.1 Жизненный цикл проекта

Как уже отмечалось в предыдущем разделе, жизненный цикл проекта будет представлять собой модифицированный вариант предлагаемый методологией Scrum. Вместо нулевой итерации, предназначенной в Scrum для формирования взаимопонимания между членами команды и получения базовых сведений о проекте, будут проводиться предпроектные мероприятия, описываемые методологией Feature-Driven Development.

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

· разработка общей модели;

· составление списка необходимых функций;

· планирование работы над каждой функцией.

На этапе разработки общей модели системы проектная команда активно общается с заказчиком для того, чтобы получить общее представление о проекте и выделить ключевые предметные области, в рамках которых должна развиваться система.

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

За планирование работы над функциями отвечает скрам-мастер, он совместно с командой определяет взаимозависимость и последовательность реализации функций.

По окончании предпроектных мероприятий начинается классический жизненный цикл Scrum в виде спринтов, длительностью от 1 до 4 недель.

Роли на проекте соответствуют основным ролям, описанным в методологии Scrum, плюс добавляются такие роли как: эксперт предметной области и главный архитектор. Дополнительным отличием от Scrum является то, что мы специфицируем специалистов, разрабатывающих систему по типам их деятельности, так как они имеют разные сферы ответственности и не все взаимозаменяемы.

2.3.2 Командообразование проекта

Гибкие методологии предполагает постоянное взаимодействие членов команды, а для успешности проекта, такое взаимодействие должно проходить в положительном ключе, поэтому одной из основных активностей руководителя проекта является командообразование. В части практик по выстраиванию доверительных отношений в команде было принято решение руководствоваться методологией Scrum. Рентабельность использования некоторых практик, должна быть определена руководителем проекта непосредственно в контексте конкретного проекта.

2.3.3 Внутрипроектные коммуникации проекта

Вопрос организации внутрипроектных коммуникаций в территориально распределенных командах встает особенно остро. Для решения данной проблемы в методике будут использованы практики методологии Scrum, так как было проведено большое количество исследований, прорабатывающих методы организации эффективного взаимодействия. Для взаимодействия будут использованы наиболее «богатые» (информативные) каналы коммуникации, например, программное обеспечение для передачи мгновенных сообщений и организации видеоконференций.

2.3.4 Управление сроками и содержанием проекта

Главными инструментами для управления сроками и содержанием проекта будут выступать классические практики Scrum: ежедневные митинги и ретроспективы по окончанию этапа. Для полноценного анализа работ на проекте в методике будет предложен список показателей, который позволит сделать вывод о соответствии запланированных работ фактически реализованному функционалу.

Для управления сроками и содержанием территориально распределенного проекта будут дополнительно использованы техники визуального менеджмента, предлагаемые Kanban. Использование разноцветных стикеров с описанием задач позволяет не только быстро, просто и эффективно организовать работу над проектом [32], но и помочь руководителю управлять потоком работ и выявлять «узкие места».

2.3.5 Управление качеством продукта

В первую очередь для управления качеством будут использованы политики коллективного владения кодом методологии XP, которые позволят сформировать ответственность разработчиков за реализуемую часть функционала. С точки зрения решения поставленной задачи, политика коллективного владения кодом не может быть реализована полностью в связи с разноплановостью специализаций разработчиков, поэтому она будет распространяться только на некоторые группы разработки.

Так как основу жизненного цикла проекта будет составлять Scrum, то ответственным за контроль качества программного продукта будет отвечать владелец продукта, который будет проверять разработанный инкремент системы на предмет соответствия бизнес-требованиям.

Предлагается также использовать практику инспекций методологии FDD, которая позволит поддерживать политику коллективного владения кодом, а также мотивировать разработчиков соблюдать правила хорошего тона в процессе программирвания.

Дополнительным верификатором качества проекта будут выступать показатели качества, описанные в разделе методики Оценка состояния проекта.

2.3.6 Оценка состояния проекта

Для того чтобы оценить в каком состоянии находится проект разработки программного обеспечения, необходимо использовать показатели, отражающие ключевые процессы. Показатели необходимы для того, чтобы управлять процессом разработки и понимать, как в случае их отклонения, необходимо скорректировать процесс. Были отобраны метрики, предназначенные специально для оценки проектов использующих гибкие методологии. Метрики были разделены на 4 группы в зависимости от направления:

· производительность;

· прогнозирование;

· качество;

· ценности.

Показатели производительности

Основным и наиболее популярным в гибких методологиях показателем производительности команды за итерацию является Velocity.

В показателе Velocity учитывается количество задач, которые были реализованы за один спринт. Так как задачи отличаются друг от друга по сложности и трудозатратам, используется «относительная оценка сложности», которая называется StoryPoints.

Однако многие консультанты и скрам-мастера отмечают, что использование только метрики Velocity губительно для принципов гибкой разработки [33]. По этой причине для объективной оценки производительности проекта, будут дополнительно использоваться показатели, которые обычно применяются в методологии Kanban:

· Store Cycle Time;

· Lead Cycle Time;

· Wasted Time;

· Work in Progress (WIP).

Story Cycle Time - время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.

Work in Progress (WIP) - количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.

Lead Time - время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.

Wasted Time - время, которое задача проводит в различных очередях, а не непосредственно в работе.

Метрики из Kanban могут рассчитываться по отдельным типам задач, чтобы повысить точность полученных результатов. В контексте исследования будут рассчитываться показатели по двум типам задач: разработка новой функциональности, исправление ошибок.

Метрики прогнозирования

· Аккуратность оценки задачи [34]

· Sprint Burndown Chart

Аккуратность оценки задачи позволяет понять в конце спринта или в конце проекта, насколько точно команда смогла оценить работу над задачами. Таким образом, при последующей оценке возможно внесение коррективов и более точное планирование.

Sprint Burndown Chart - это диаграмма, позволяющая ответить на вопрос о степени готовности задач и понять укладывается ли команда в рамки спринта [35]. Представляет собой две линии плановая и фактическая линии оставшихся трудозатрат в разрезе дней в рамках спринта.

Метрики качества

· Technical Debt Points (будущие таски, рефакторинг, низкоприоритетные баги)

· Post Sprint Defect Arrival

· Post Release Defect Arrival

Показатель Technical Debt Points включает в себя «очки» запланированные в спринте на устранение технических дефектов, реинжениринг или оптимизацию программного обеспечения. Не должно составлять больше 30% от общего распределения работ.

Показатели Post Sprint Defect Arrival и Post Release Defect Arrival отражают количество дефектов, возникшее после выпуска релиза или по окончанию спринта.

Метрики ценности

· Customer Satisfaction Survey

· Employee Satisfaction Survey (например, можно использовать Niko Niko Calendar)

Ценность проекта может разделяться на два типа: ценность для клиента и ценность для сотрудника. Ценность для клиента в первую очередь это удовлетворенность клиента разрабатываемым программным продуктом и соответствие его ожиданиям. Удовлетворённость сотрудника, как правило, сфокусирована вокруг навыков и опыта, который он приобретает на проекте. Для оценки удовлетворенности клиента и сотрудника применяются специальные опросы.



Глава 3. Апробация предложений и анализ результатов внедрения

3.1 Апробация набора разработанных предложений

Набор предложений был сформирован в виде отдельного документа, вынесенного в Приложение 1 к данной работе. Данные предложения внедрялись в компании ЗАО «ЛАНИТ» в департаменте корпоративных систем, отделе хранилищ данных и BI на проекте по разработке системы анализа логистической деятельности «САД Логистика» для заказчика ФГУП «Почта России». Переход на использование гибких методологий активно поддерживается заказчиком.

На момент начала внедрения гибких методологий на проекте действительно наблюдались проблемы, характерные для территориально распределенных проектов по разработке программного обеспечения, например, отсутствие информации у участников проекта на каком этапе находится проект, какие работы являются приоритетными, какой фидбек заказчик дает о продукте, а также общая рассинхронизация действий, приводящая к дублированию работ или недопониманию внутри команды.

Проектная команда состоит из 11 человек и подразделяется на две части. В головном офисе в Москве находится четыре человека:

· руководитель проекта;

· два аналитика;

· архитектор.

Взаимодействие с заказчиком осуществляют только аналитики в Москве. Вторая часть команды находится в Минске и насчитывает семь человек:

· два специалиста по тестированию;

· три разработчика ХД;

· два разработчика BI.

Вторая часть команды специализируется на разработке и тестировании функционала программного продукта.

В книге Бориса Вольфсона предлагается несколько вариантов планирования внедрения гибких методологий в компании. Однако автор также подмечает, что план необходимо адаптировать под особенности компании или проекта. Ключевой особенностью внедрения гибких методологий на проекте САД Логистика является тот факт, что внедрение начинается не с нулевой фазы проекта, а в середине этапа разработки. До этого на проекте использовалась не итерационная модель жизненного цикла, а классическая водопадная модель.

Для расчета плана было установлено, что длина спринта составляет 2 недели, а длина релиза может колебаться в промежутке от 2 до 3 спринтов. В результате адаптации плана, предложенного в книге «Гибкие методологии», был получен график и основные работы по внедрению гибкой методологии.

Таблица 6. План этапов внедрения гибких методологий

№ недели	Дата	Этап	Содержание работ
1	9.03 - 15.03	Подготовка к трансформации	· тренинг по основам гибких методологий с деловыми играми (вся проектная команда вместе); · обучение скрам-мастера; · выбор практик из документа с предложениями по внедрению; · выявление ролей и персонажей по проекту; · разработка общей модели системы на основе функционала, реализованного до начала внедрения.
2	16.03 - 22.03	Старт первого «калибровочного» спринта	· разбиение оставшихся направлений работ на истории пользователей; · проведение планирования спринта и разбиение историй пользователей на детальные задачи; · проведение покер-планирования; · отработка механизмов эскалации проблем; · отработка механизма синхронизации деятельности команд.
3	23.03 - 29.03	Завершение «первого» калибровочного спринта	· проведение демонстрации заказчику и получение фидбека; · проведение ретроспективы и определение скорости работы команды эмпирическим путем.
4	30.03 - 05.04	Старт второго спринта	· планирование спринта, исходя из скорости работы команды на предыдущем спринте; · тренинг по практике коллективного владения кодом: o выработка и внедрение стандартов кодирования; o определение правил непрерывной интеграции.
5	6.04 - 12.04	Завершение второго спринта	· отработка техники завершения спринта: o использование доски, чтобы отслеживать незавершенные задачи; o анализ причин возникновения проблем и опоздания при реализации задач запланированных на спринт.
6	13.04 - 19.04	Старт третьего спринта	· отработка старта предрелизного спринта: o особое внимание уделяем задачам недоделанным в рамках предыдущих спринтов; o проведение инспекций по всем выполненным задачам; o проведение автоматического и ручного тестирования; o рефакторинг программного продукта на основании замечаний, полученных в результате инспекций и тестов.
7	20.04 - 26.04	Завершение третьего спринта	· релиз продукта с обязательным участием конечных пользователей; · Кайдзен сессия в рамках ретроспективы, чтобы выявить ключевые проблемы проекта и выработать решение.
8	27.04 - 3.05	Начала четвертого спринта	· Отработка практик по планированию релиза: o переоценка историй пользователей командой на основании полученного опыта o начинаем вести диаграмму сгорания релиза o отбор владельцем продукта наиболее приоритетных историй пользователей · контроль процесса исполнения с помощью доски, оптимизация процесса работы с целью снижения WIP.
9	4.05 - 10.05	Завершение четвертого спринта	· частичный рефакторинг системы; · внедрение практик по оценке качества разрабатываемого программного продукта.
10	11.05 - 17.05	Старт пятого «идеального» спринта	· анализируем продуктивность работы команды на предыдущих спринтах и подстраиваем диаграмму сгорания; · тренинг по практикам FDD (проведение инспекций, доработка общей схемы системы)
11	18.05 - 24.05	Завершение пятого «идеального спринта	· Релиз продукта · Анализ диаграммы сгорания релиза

Для внедрения на проекте были отобраны следующие практики:

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

· Переход на использование практик визуального менеджмента. На этапе «Подготовка к трансформации» были установлены доски в каждом офисе, где расположены участники команды, а также определены основные этапы. На этапе «Старт первого «калибровочного» спринта» был дополнительно установлен плагин к JIRA, который поддерживает синхронизацию досок в виртуальном пространстве.

· Для того чтобы команда могла взаимодействовать открыто и доверять друг другу, был организован тренинг общий для всей проектной команды (проектная группа из Минска прилетала на 3 дня). В рамках тренинга проводилось обучение работы в рамках гибких методологий, а также игра, целью которых является сплочение команды. В дополнение было решено вести Niko-niko календарь в каждой части проектной команды.Каждая часть команды не являлась кроссфункциональной, то есть не могла функционировать отдельно от другой части, поэтому была внедрена модель единого Scrum, с применением помощника скрам-мастера в удаленной части команды. Для оценки состояние проекта было решено использовать следующие показатели:

o Velocity;

o WIP;

o Диаграмма сгорания спринта;

o Диаграмма сгорания релиза;

o Post Sprint Defect Arrival;

o Количество ошибок на 100 строк кода.

· Организация контроля качества разрабатываемого программного обеспечения. На этапе «Старт второго спринта» были проведены работы по организации на проекте практики коллективного владения кодом. Участникам проекта объяснялись особенности применения данной практики, а также началось формирования документа, содержащего стандарты кодирования. На этапе «Старт третьего спринта» начинает вводиться практика инспекций, которые позволят выявить большую часть ошибок перед релизом. Дополнительно перед релизом начинается использование автоматизированных тестов и сбор статистики по ошибкам.

3.1. 

3.2 Анализ результатов внедрения разработанных предложений

В сравнении с планом, предложенным в книге Бориса Вольфсона, план, разработанный для внедрения на проекте САД Логистика, содержал меньшее количество этапов. В результате внедрение гибких методологий не было завершено в срок. Дополнительной причиной, по которой внедрение не было выполнено в срок, стала невозможность приостановить полностью процесс разработки, чтобы провести этап трансформации. Участники проекта были вынуждены знакомиться с новой методологией во внерабочее время. Также тренинги и игры пришлось проводить в выходные, чтобы не срывать сроки разработки функционала системы. В процессе планирования не было учтено обилие праздничных дней в мае, которое не позволило провести часть запланированных работ. Таким образом, на момент написания настоящего документа, проект находился на этапе «Старт пятого «идеального» спринта». Тем не менее, несмотря на то, что процесс внедрения гибких методологий не был завершен до конца, на проекте уже наблюдаются сильные положительные сдвиги.

Наиболее заметным изменением в связи с переходом на гибкие методологии было увеличение объема реализованных функций. В промежутке со второго по четвертый спринты (за 2 месяца) были выполнены задачи, на выполнение которых было первоначально отведено 3,5 месяца. Скрам-мастер отметил, что одними из ключевых триггеров к увеличению производительности команды стали:

· снижение объема документации;

· ускорение процесса принятия решений;

· видимость статусов выполнения задач и выявление «узких» мест.

Очень важным элементом перехода на гибкую разработку были тренинги, посвященные сплочению команде. Первоначально руководство отнеслось к данному пункту скептически, так как проведение соответствующих мероприятий требовало финансовых вложений, а также означало простой специалистов в течение нескольких дней. В качестве компромисса было принято решение о проведении большей части тренингов в пятницу и выходные. Позднее руководитель проекта (скрам-мастер) признал, что не ожидал такого результата от совместного времяпрепровождения. Часть команды из Минска отметила, что впервые с начала работы на проекте почувствовала себя полноценной частью всей команды. Дополнительным эффектом от знакомства команды, стало снижение числа обращений не к тем участникам команды, что в свою очередь снизило трудозатраты на переадресацию этих обращений. Теперь для всех сотрудников за каждым именем участника проекта стоял реальный человек со своим списком обязанностей.

На проекте среди всех участников начал наблюдаться интерес к тому, как идет работа по остальным задачам. Например, неоднократно возникала ситуация, когда на доске было видно, что на этапе «Разработка» у одного человека сосредоточено три и более задачи, и остальные разработчики, имеющие меньшую загрузку на тот момент, предлагали свою помощь. Таким образом, несмотря на то, что на начало внедрения гибких методологий проект уже шел три месяца, только после внедрения ряда практик начали наблюдаться процессы нормализации и функционирования проектной команды.

Как уже упоминалось ранее, до внедрения гибких методологий, заказчик общался только с аналитиками из главного московского офиса, теперь его стали привлекать не только для показов релизов, но и для планирования работ, входящих в спринт. Заказчику также высылались приглашения принять участие в ежедневных митингах, чтобы понять, как идет работа команды. Периодически заказчик принимал участие в митингах, что освобождало аналитиков и скрам-мастера от подготовки свода статусов задач. Также активное участие заказчика в процессе планирования спринта и уточнении требований к задачам, сформировало понимание у него, что команда работает в полную силу и делает все возможное для того, чтобы удовлетворить бизнес потребности заказчика.

Переход на практику коллективного владения кодом был встречен активным одобрением со стороны наиболее опытных специалистов. Выяснилось, что на проекте уже существует некая устная договоренность между парой людей о том, как следует работать с программными модулями системы, которые были рады сформировать эти выработанные подходы в виде отдельного документа. Менее опытные разработчики отметили, что были не в курсе тех тонкостей архитектуры системы, которые были отражены в документе. Специалисты по тестированию также заметили, что снизилось число ошибок в функционале, в рамках которого взаимодействует несколько модулей системы (переключение между отчетами, детализация и т.д.).

Инспекции проводились только для задач, которые относятся к истории пользователя оцененной в 16 и больше storypoints. Во время инспекций разработчики разбивались на пары: более опытный проверяющий и менее опытный проверяемый. Во время инспекций почти по 95% задач были выявлены недочеты и ошибки, которые в зависимости от их критичности устранялись в рамках того же спринта. Проведение инспекций также позволило начать собирать задачи для проведения последующего рефакторинга, что никогда на проекте прежде не делалось.

Одной из проблем наблюдаемых ранее на проекте был простой задач на этапе «Тестирования», так как специалисты по тестированию не успевали в полной мере проверить весь реализуемый функционал. Таким образом, либо происходили задержки в выпуске релизов, либо заказчику показывали функционал с возможными ошибками, что увеличивало недовольство со стороны заказчика. С применением инспекций снизилось число ошибок, обнаруживаемых специалистами по тестированию, а применение автоматических тестов позволило ускорить процесс тестирования.

Применение практик планирования позволили упростить процесс отслеживания производительности проектной команды, однако так как в планировании участвовали разработчики, которые не имели опыта планирования, оценки, полученные в рамках первых трех спринтов были не точными (см. Таблица 6). Сложность заключалась также в том, что команда не могла определиться, какую задачу считать эталонной, в итоге было решено, что эталонная задача это: «Разработка отчета, который был построен с помощью одной существующей предметной области, не имеет детализации в другие отчеты и использует табличное представление». Также возникали затруднения в переопределении оценки сложности задачи, которая не была закончена в предыдущем спринте.

Таблица 7. Планирование работ на спринт

Спринт	StoryPoints взятые в работу	Кол-во рабочих дней в спринте	Velocity	Результат
Первый «калибровочный» спринт	Взяли три задачи весом: 2, 4, 1.	10	3	Не успели доделать задачу весом 4 SP.
Второй спринт	Взяли три задачи весом: 2 (доделывание задачи из прошлого спринта), 2, 2.	10	6	Закончили раньше на 2 дня, переоценили доделывание задачи из прошлого спринта
Третий спринт	Взяли пять задач весом: 3, 1, 1, Ѕ, 2.	15	4.5	Не успели доделать 2 задачи весом 1 и 2. Недооценили вес задач.
Четвертый спринт	Взяли пять задач весом: 2 и 1 (доделывание задач из прошлого спринта), 3, 2, Ѕ.	17	8.5	Выполнили все задачи с опозданием в 2 дня (было решено увеличить длину спринта).



Однако, несмотря на неопытность команды в части планирования, нужно отметить, что качество планирования повышалось от спринта к спринту, и по окончании шестого «идеального» спринта можно ожидать стабилизации данного процесса.



Заключение

Данная работа была посвящена разработке предложений по внедрению гибких методологий в территориально распределённых проектах по разработке программного обеспечения, отличающихся длительностью и высокой сложностью. В ходе работы были проанализированы и рассмотрены исследования, посвященные проблемам, возникающим при территориально распределенной разработке. Были выделены проблемы, возникающие в проектах данного типа, которые были дополнительно подтверждены в рамках проектной работы автора. Был проведен сравнительный анализ гибких методологий в части практик, которые они предлагают для покрытия выявленных проблем. На основе этого анализа, мы выявили, что различные гибкие методологии частично покрывают выявленную проблематику и пришли к необходимости формирования нового подхода, комбинирующего наиболее подходящие практики существующих методологии с целью закрытия все проблем.

Во второй главе мы перешли к формированию документа, содержащего предложения по внедрению гибких методологий. Для этого были разработаны требования к документу, а затем сформированы его разделы, в которых содержалось описание применения конкретных практик.

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

Внедрение позволило решить проблемы, выявленные в начале работы. Решения, предлагаемые в документе «Предложения по внедрению гибких методологий в территориально распределенных проектах разработки программного обеспечения») рассмотрены в таблице (см. Таблица 7).



Таблица 8. Решение выявленных проблем в территориально распределенных проектах

№	Проблема	Решение
1	Проблема инициации процесса коммуникации	· Размещение контактных данных всех участников проектной команды в едином информационном пространстве · Установление правил присутствия в Skype на протяжении всего рабочего дня
2	Недопонимание между членами команды	· Организация инспекций по задачам · Применение практики коллективного владения кодом
3	Низкая частота коммуникации	· Установление длительности спринта не более 2 недель
4	Высокие затраты на коммуникацию	· Применение наиболее «богатых» каналов взаимодействия - чаты и видеоконференции
5	Различия во временных зонах	· Установление формальных часов пересечения работы проектной команды · Проведение ежедневных митингов в удобное всем время или разбиение на несколько встреч
6	Сложность контроля процесса разработки	· Применение техники визуального менеджмента (доска) · Ведение задач в трекинговой систем · Проведение ежедневных митингов · Применение показателей для оценки движения проекта
7	Сложность контроля качества программного продукта	· Организация инспекций по задачам · Применение практики коллективного владения кодом · Проведение обзоров спринтов и ретроспектив
8	Недостаток доверия между членами команды	· Знакомство участников проектной команды · Организация совместных тренингов и обучения
9	Отсутствие боевого командного духа	· Совместная работа в рамках первых спринтов · Проведение тренингов и игр с целью сплочения команды · Применение niko-niko календаря для управления эмоциями команды
10	Отсутствие обмена опытом между частями команды	· Применение практики «амбасадоров»



Таким образом, внедрение разработанных предложений позволило решить выявленные проблемы. Анализ результатов внедрения гибких методологий на проекте САД Логистика показал, что, несмотря на возникающие сложности и еще не оконченный процесс внедрения, предложенные практики действительно дают положительный эффект, который в данный момент выражался в следующих фактах:

· опережение плана работ на месяц вперед;

· сработавшаяся команда высокой степени зрелости и обладающая самоорганизацией;

· смещение функций руководителя проекта (скрам-мастера) с надзорных к направляющим;

· снижение числа конфликтов с заказчиком и повышение общего уровня удовлетворенности продуктом.



Список литературы

1. Масленников В. В., Крылов В. Г. Процессно-стоимостное управление бизнесом // Сfin.ru: Корпоративный менеджмент, библиотека управления. URL: http://www.cfin.ru/management/practice/manage_business.shtml (дата обращения: 30.05.15).

2. ABM Moniruzzaman, Dr Syed Akhter Hossain Comparative Study on Agile software development methodologies // Систем. требования: Adobe Reader. URL: http://arxiv.org/ftp/arxiv/papers/1307/1307.3356.pdf (дата обращения: 30.05.15).

3. Что такое Agile? // AgileDays - сайт, посвященный конференции AgileDays'12. URL: http://msk12.agiledays.ru/about/agile/ (дата обращения: 30.05.15).

4. Основополагающие принципы Agile-манифеста // Agilemanifesto.org: сайт, содержащий agile-манифет. URL: http://agilemanifesto.org/iso/ru/principles.html (дата обращения: 30.05.15).

5. 8^th annual State of Agile survey // VersionOne: сайт платформы по управлению проектами, использующих гибкие методологии. Систем. требования: Adobe Reader. URL: http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf (дата обращения: 30.05.15).

6. Vemulapalli H. Five Agile Challenges for Distributed Teams // Agile Connection: сообщество TechWell. URL: http://www.agileconnection.com/article/five-agile-challenges-distributed-teams?page=0%2C1 (дата обращения: 30.05.15).

7. Shiralige A. Distributed Agile: How to Address People and Communication Challenges // Agile Buddha: сообщество, посвященное agile. URL: http://www.agilebuddha.com/agile/distributed-agile-address-people-and-communication-challenges/ (дата обращения: 30.05.15).

8. Вольфсон Б. Гибкие методологии разработки, 2012 г. // Систем. требования: Adobe Reader. URL: http://adm-lib.ru/books/10/Gibkie-metodologii.pdf (дата обращения: 30.05.15).

9. Sandeep J. Working with Agile in a Distributed Team Environment // MSDN Magazine: журнал компании Microsoft для разработчиков. URL: https://msdn.microsoft.com/en-us/magazine/hh771057.aspx (дата обращения: 30.05.15).

10. Mannaro K. Adopting Agile Methodologies in Distributed Software Development. Систем. требования: Adobe Reader. URL: http://veprints.unica.it/53/1/mannaro_katiuscia.pdf (дата обращения: 30.05.15).

11. Ladas C. Scrumban - Essays on Kanban Systems for Lean Software Development // Lean Software Engineering: сообщество специалистов по программной инженерии, практикующих методологию Lean. URL: http://leansoftwareengineering.com/ksse/scrum-ban/ (дата обращения: 30.05.15).

12. Sutherland J., Viktorov A., Blount J. Distributed Scrum: Agile Project Management with Outsourced Development Teams. Систем. требования: Adobe Reader. URL: http://141.138.141.68/~vandenho/Arjan/www/SutherlandDistributedScrumAgile2006_v4_28_Feb_2006.pdf (дата обращения: 30.05.15).

13. Официальный сайт конференции AgileDays URL: http://msk15.agiledays.ru/ (дата обращения: 30.05.15).

14. Anup Hande, Sunita Suralkar, P.M.Chawan Distributed Software Project Development // Систем. требования: Adobe Reader. URL: http://www.ijera.com/papers/Vol2_issue3/FT239981003.pdf (дата обращения: 30.05.15).

15. Balasubramaniam Ramesh, Lan Cao, Kannan Mohan, Peng Xu Сan distributed software development be agile? // Систем. требования: Adobe Reader. URL: http://www1bpt.bridgeport.edu/~dichter/cpe489/p41-ramesh.pdf (дата обращения: 30.05.15).

16. Dragusha C. Managing Virtual Teams Guidelines to Effective Leadership // Систем. требования: Adobe Reader. URL: https://www.theseus.fi/bitstream/handle/10024/50321/dragusha_cajup%20thesis.pdf?sequence=1 (дата обращения: 30.05.15).

17. Suprika Vasudeva Shrivastava Distributed Agile Software Development // Систем. требования: Adobe Reader. URL: http://arxiv.org/ftp/arxiv/papers/1006/1006.1955.pdf (дата обращения: 30.05.15).

18. Communication on Agile Software Teams // Agile Modeling: портал, посвященный внедрению гибких методологий URL: http://www.agilemodeling.com/essays/communication.htm (дата обращения: 30.05.15).

19. Calboutin J., Holst H. Distributed Agile, 2013 // SQS.com: сайт компании SQS. Систем. требования: Adobe Reader. URL: http://www.sqs.com/en-group/about-sqs/whitepaper-book-2013.php (дата обращения: 30.05.15).

20. TastyCupcakes Community: сайт, посвященный играм для проектных команд. URL: http://tastycupcakes.org/category/agile/ (дата обращения: 30.05.15).

21. Cohn M. Distributed Teams: Build Trust through Early Progress // Mountain Goat Software: блог, посвященный тренингам по скрам. URL: http://www.mountaingoatsoftware.com/blog/distributed-teams-build-trust-through-early-progress (дата обращения: 30.05.15).

22. Use Ambassadors to Improve Communication with your Offshore Scrum Teams // Payton Consulting: официальный сайт компании Payton Consulting. URL: http://www.payton-consulting.com/use-ambassadors-to-improve-communication-with-your-offshore-teams/ (дата обращения: 30.05.15).

23. Pichler R. Common Product Owner Traps // Scrum Alliance: сообщество agile специалистов. URL: https://www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps (дата обращения: 30.05.15).

24. Grazi V. Implementing Kanban in Practice // InfoQ: портал о профессиональной разработке программного обеспечения. URL: http://www.infoq.com/articles/Implementing_Kanban (дата обращения: 30.05.15).

25. Bradley C. Kanban vs. Scrum: Kanban is not for Software Development, but Scrum is //The Scrum Crazy Blog: блог коуча Bradley C. URL: https://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/ (дата обращения: 30.05.15).

26. Kircher M., Jain P., Corsaro A., Levine D. Distributed eXtreme Programming // Систем. требования: Adobe Reader. URL: http://www.kircher-schwanninger.de/michael/publications/xp2001.pdf (дата обращения: 30.05.15).

27. Shore J. The Art of Agile Development // Сайт книги The Art of Agile. URL: http://www.jamesshore.com/Agile-Book/collective_code_ownership.html (дата обращения: 30.05.15).

28. Schuemmer T., Schuemmer J. Support for Distributed Remote Pair Programming, Extreme Programming Examined, Addison-Wesley, 2001.

29. Коберн А., Вильямс Л. Парное программирование: преимущества и недостатки // Блог о разработке программного обеспечения. URL: http://www.maxkir.com/sd/pairprog_RUS.htm (дата обращения: 30.05.15).

30. Palmer S. R. An Introduction to Feature-Driven Development // DZone: сообщество для технических специалистов. URL: http://agile.dzone.com/articles/introduction-feature-driven (дата обращения: 30.05.15).

31. Palmer S. R., Felsing J. M. Practical Guide to Feature-Driven Development // InformIT: сообщество издателей, специализирующихся на информационных технологиях. URL: http://www.informit.com/articles/article.aspx?p=26059 (дата обращения: 30.05.15).

32. Allue X. Q. Visual Management for Agile Teams // XQA: блог, посвященный практикам визуального менеджмента. URL: http://www.xqa.com.ar/visualmanagement/2009/02/visual-management-for-agile-teams/ (дата обращения: 30.05.15).

33. Highsmith J. Velocity is Killing Agility! // Jim Highsmith: сайт консультанта ThoughtWorks, Inc. URL: http://jimhighsmith.com/velocity-is-killing-agility/ (дата обращения: 30.05.15).

34. Голдштайн И. Scrum метрики и отчеты - измерьте результаты управления // Agile Russia: сайт, посвященный различным аспектам гибкой разработки программного обеспечения. URL: http://agilerussia.ru/practices/scrum-metrics/ (дата обращения: 30.05.15).

35. Факторович С. Методологии разработки ПО, agile и scrum. Часть 2 // Систем. требования: Adobe Reader. URL: http://school.academpark.com/wp-content/uploads/2012/10%20metodologich_razrab_po2_faktorovich.pdf (дата обращения: 30.05.15).

36. Hanoulle Y. How to work with a whiteboard (kanban board) with a distributed team? // Yves Hanoulle: сайт коуча Yves Hanoulle. URL: http://www.hanoulle.be/2009/10/how-to-work-with-a-whiteboard-with-a-distributed-team/ (дата обращения: 30.05.15).

37. Silver Catalyst Features // Tools for agile: сайт, посвященный программному продукту Silver Catalyst. URL: http://toolsforagile.com/silvercatalyst/features/ (дата обращения: 30.05.15)

38. Deemer P. Distributed Scrum Primer // Good Agile: сертифицированные скрам тренинги. URL: www.scrumprimer.com (дата обращения: 30.05.15).



Приложение 1

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

НАЗНАЧЕНИЕ

Настоящий документ описывает основные предложения по внедрению гибких методологий для территориально распределенных проектов по разработке программного обеспечения и содержит набор подходов и практик по устранению проблем типичных для проектов данного типа.

ОГРАНИЧЕНИЯ

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

Данный документ может быть полезен для территориально распределенных команд, численностью от 8 до 15 человек. Удаленная часть проектной команды должна представлять не полноценную кроссфункциональную команду, а часть команды разработки, работа которой тесно взаимосвязана с работой основной части команды.

2. ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

Основные роли на проекте:

1. Владелец продукта. Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, выполняемой командой разработки.

2. Скрам-мастер. Скрам-мастер отвечает за то, чтобы Scrum был понят всеми участниками и работал. Скрам-мастер обеспечивает выполнение этого правила, наблюдая за тем, чтобы все участники команды придерживались теории, практик и правил адаптированного Scrum.

3. Помощник скрам-мастера - это один из наиболее опытных участников той части проектной команды, которая территориально удалена от основной команды, задача которого заключается в контроле процесса реализации спринта своей частью проектной команды.

4. Команда разработки - это группа профессионалов, отвечающих за создание инкремента программного продукта за спринт, разделяющиеся по сферам ответственности:

a. Разработчики

b. Аналитики

c. Специалисты по тестированию

d. Архитекторы

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

В качестве основы для выстраивания модели жизненного цикла проекта предлагается использовать методологию Scrum, дополнительно внеся в нее аспекты методологии Feature Driven Development (см. Рисунок 10).

Рисунок 10. Предлагаемый жизненный цикл проекта

Работа на проекте должна быть разделена на небольшие итерации - продолжительностью не более 2 недель.

В рамках нулевой итерации необходимо проводить процессы инициации, которые используются в методологии FDD:

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

2. Составление списка необходимых функций. После разработки общей модели системы составляется предварительный список наиболее важных для клиента высокоуровневых функций, которые будут относиться к какой-то компоненте системы. Результат процесса: список функций в разрезе предметных областей.

Полученный список на протяжении всего проекта служит беклогом программного продукта, на основании которого проводится планирование спринта. Перед началом каждого спринта проводится процедура планирования, которая определяет какие работы необходимо выполнить, чтобы по окончании двух недель получить полезный для клиента инкремент функционала. Более подробно техники планирования рассматриваются в разделе управление сроками и содержанием проекта настоящего документа.

В течение спринта каждый день должен проводиться митинг, занимающий не более 15 минут, на котором должна присутствовать вся проектная команда, в том числе и территориально удаленные части.

По окончании спринта должна проводиться ретроспектива, занимающая не больше 1 часа, участие в которой также обязательно для всей проектной команды.

Часы проведения встреч должны устанавливаться согласно «часам пересечения» всех территориально распределенных частей команды.

3. КОМАНДООБРАЗОВАНИЕ ПРОЕКТА

В настоящем разделе рассматриваются практики и подходы способствующие командообразованию, а также техники, используемые для установления доверительных отношений и формирования продуктивной рабочей атмосферы. Подходы, описываемые в данном разделе, будут полезны скорее новым командам, которые не работали вместе на предыдущих проектах или никогда раньше не встречались вживую.

Командообразование в гибких методологиях проходит в несколько этапов (см. Таблица 6), причем, чтобы команда работала с максимальной отдачей, она должна находиться в стадии «Функционирование». Таким образом, на начальном этапе проекта основной задачей скрам-мастера является способствование наискорейшему переходу команды в нужную стадию.

...